Estamos fazendo um projeto aqui na empresa e gostaríamos da opinião de vocês na seguinte questão: ESPECIFICAMENTE em um sistema SOA a ser implantado na NUVEM, o que seria afetado ou deveríamos verificar na arquitetura, baseando-se nos atributos de qualidade abaixo?
Interoperability, Performance, Security, Reliability, Availability, Modifiability, Testability, Usability and Scalability
Por exemplo:
Interoperability
O serviço deve ser WS-I compliance e o cloud provider deve permitir tais serviços.
Performance
SOA involves distributed computing. Service providers and service users are normally located on different machines. The need to communicate over the network increases the response time, so…
Estamos fazendo um projeto aqui na empresa e gostaríamos da opinião de vocês na seguinte questão: ESPECIFICAMENTE em um sistema SOA a ser implantado na NUVEM, o que seria afetado ou deveríamos verificar na arquitetura, baseando-se nos atributos de qualidade abaixo?
Interoperability, Performance, Security, Reliability, Availability, Modifiability, Testability, Usability and Scalability
Por exemplo:
Interoperability
O serviço deve ser WS-I compliance e o cloud provider deve permitir tais serviços.
Performance
SOA involves distributed computing. Service providers and service users are normally located on different machines. The need to communicate over the network increases the response time, so…[/quote]
Bom… vamos lá:
Performance: sua implementação de nuvem deve ser auto-escalável (pasme, já ví “nuvens” que não eram assim)
Segurança: sua nuvem deve, preferencialmente, aceitar estabelecimento de VPN’s e livre tráfego de mensagens (tanto se forem HTTP puro - REST - quanto SOAP)
Confiabilidade: tenha certeza de seguir as melhores práticas em termos de versionamento de API’s
Disponibilidade: sua implementação de nuvem deve permitir o posicionamento das aplicações em áreas geográficas distintas (e permitir a comunicação entre essas áreas)
Testabilidade: aí o bicho pega… não é lá muito fácil, embora existam iniciativas para facilitar isso, como o Simian Army (particularmente, o Chaos Monkey) da Netflix (que roda sobre o AWS)
Escalabilidade: use uma nuvem =)
Não conheço muitas implementações de nuvem, mas a que eu conheço que implementa tudo isso é a AWS. Não por acaso, é uma que eu recomendo em 99,999% dos casos =)
Obrigado pela resposta Alexandre (estou cursando a formação Consultor SOA na SOA | Expert /fortemente recomendado!/, o Felipe Oliveira nos falou sobre você :))
Quanto à Interoperabilidade, as especificações WS-I fomentam a interoperabilidade de Web Services. Eles funcionam sobre o protocolo HTTP, right? I mean, WS-I independe de infraestrutura?
Digo isso pois imagine que em meu sistema utilizo, por exemplo, as especificações WS-Authorization, WS-Privacy, WS-Tx. Meu sistema funcionará tanto no AWS como no Cloud Bees?
[quote=brccosta]Obrigado pela resposta Alexandre (estou cursando a formação Consultor SOA na SOA | Expert /fortemente recomendado!/, o Felipe Oliveira nos falou sobre você :))
Quanto à Interoperabilidade, as especificações WS-I fomentam a interoperabilidade de Web Services. Eles funcionam sobre o protocolo HTTP, right? I mean, WS-I independe de infraestrutura?
Digo isso pois imagine que em meu sistema utilizo, por exemplo, as especificações WS-Authorization, WS-Privacy, WS-Tx. Meu sistema funcionará tanto no AWS como no Cloud Bees?[/quote]
Está correto! Como o tráfego das mensagens vai correr todo sobre o HTTP, você não precisa se preocupar com isso em nível de mensagens, mas em nível de implementação. Por exemplo, se você quiser rodar WS-Transaction, você tem que ter algum jeito de garantir que sua nuvem vai poder parar/continuar suas transações de acordo com a mensagem. Acontece que um Cloud Bees da vida é um PaaS - ou seja, se você tiver algo que é muito dependente do servidor (caso do WS-Transaction), você pode se dar mal num PaaS. Já AWS é IaaS (ou seja, você mesmo instala seu servidor). Dessa forma, você consegue garantir as configurações do servidor e o que mais você precisar para fazer sua aplicação funcionar.
Certo. Acho que não me fiz entender. Ou não entendi sua resposta
Aquela pergunta que havia feito: WS-I independe de infraestrutura? Sua resposta: Sim
Compreendi. Refiro-me a infraestrutura de Hardware.
Agora, nesta pergunta: Você conhece outras especificações, além da WS-Transactions, que dependem de configuração no servidor? Resposta: Não. Tirando WS-Addressing (em partes, ainda)… todas!
Eu preciso de configuração no Servidor mesmo? Ele não seria apenas um Container? Trataria as requisições HTTP, e sendo SOAP sobre HTTP, seria feito o redirecionamento e minha aplicação quem trataria tudo. Quero dizer: estas configurações não seriam no nível da aplicação?
[quote=brccosta]Certo. Acho que não me fiz entender. Ou não entendi sua resposta
Aquela pergunta que havia feito: WS-I independe de infraestrutura? Sua resposta: Sim
Compreendi. Refiro-me a infraestrutura de Hardware.
Agora, nesta pergunta: Você conhece outras especificações, além da WS-Transactions, que dependem de configuração no servidor? Resposta: Não. Tirando WS-Addressing (em partes, ainda)… todas!
Eu preciso de configuração no Servidor mesmo? Ele não seria apenas um Container? Trataria as requisições HTTP, e sendo SOAP sobre HTTP, seria feito o redirecionamento e minha aplicação quem trataria tudo. Quero dizer: estas configurações não seriam no nível da aplicação?[/quote]
Vamos por partes: o que o WS-I regula é o formato das mensagens, protocolos, etc. Nada é regulado em termos da implementação. Ou seja, o WS-I é independente da infraestrutura? Depende. Se estivermos falando de hardware, então sim. Se estivermos falando de servidores, então não.
Quando eu falei das especificações, estou falando em nível de implementação, código Java. Aí, a única especificação padronizada (mais ou menos) é WS-Addressing - ou seja, algumas coisas que você fizer com WS-Addressing serão portáveis entre servidores (consequentemente, entre nuvens). A partir daí, todas as outras especificações dependerão, em maior ou menor grau, de intervenção (falando de configurações do servidor e/ou código desenvolvido por você que é dependente das API’s do mesmo).
Nesse ponto, essas configurações serão menos portáveis, particularmente falando de PaaS (Cloud Bees, Google App Engine, Openshift…). Em geral, os servidores PaaS não te deixam manipular a configuração do servidor, o que acaba te limitando a IaaS (ou seja, você constrói o seu servidor e o administra da maneira como achar melhor).
A sua última pergunta eu não entendí muito bem:
Então, reforçando: o WS-I regula o formato das mensagens, e não a maneira de implementar. Neste ponto, se sua nuvem permitir tráfego HTTP, OK. Mas existem coisas que estão no âmbito do controle do servidor. Por exemplo, WS-Security: alguns servidores podem habilitar WS-Security com JAAS, outros não… depende do servidor. Isto é algo que não é padronizado nem pela WS-I nem pelo JAX-WS, ou seja, pode depender de configurações realizadas diretamente no servidor.
Espero ter ficado um pouco mais claro… precisando, à disposição
