Coulouris definiu sistemas distribuídos como “sistemas nos quais componentes de hardware e/ou software existentes em uma rede de computadores se comunicam e coordenam suas ações trocando mensagens”.
Este conceito tornou-se popular nos últimos anos, devido a vários fatores. O primeiro fator que promoveu o desenvolvimento de sistemas distribuídos foi o surgimento de redes locais de alta velocidade. Outro fator importante foi o avanço tecnológico no desempenho dos computadores pessoais e o desenvolvimento de softwares para suportar aplicações distribuídas. Os sistemas distribuídos estão ligados ao conceito de Web e Internet. Com a evolução da Web, e o aparecimento de novas áreas, interações, necessidades e aplicações, surge o conceito de Web 2.0. Este termo foi cunhado por Tim O’Reilly em 2004 para se referir a uma segunda geração na história da Web baseada em comunidades de usuários e uma gama especial de serviços, como redes sociais, blogs, wikis ou folksonomias, que incentivam a colaboração e o troca ágil de informações entre os usuários.
As primeiras arquiteturas que podem ser consideradas orientadas a serviços (SOA) eram baseadas em CORBA (Common Object Request Broker Architecture), que atuava como uma camada de abstração para interligar os diferentes elementos da arquitetura e construir os serviços. Outras tecnologias anteriores eram DCOM (Distributed Component Object Model) ou RPC (Remote Procedure Protocol). Com a necessidade de projetar e implementar sistemas distribuídos na Web de forma eficiente, surgem vários desafios, alguns focados no desenvolvimento em si (performance, experiência do usuário, etc.) e outros complementares, baseados na reusabilidade e compatibilidade dos serviços. A partir dessas necessidades surgem os Web Services, que fornecem mecanismos padronizados para interligar diferentes usuários com servidores de informação.
ARQUITETURAS ORIENTADAS A SERVIÇOS
Segundo SOA (Arquitetura Orientada a Serviços) são arquiteturas de software que definem o uso de serviços para dar suporte aos requisitos de negócios, cujo objetivo é atingir o mínimo de acoplamento possível entre os agentes de software. Um serviço é uma unidade de trabalho executada por um provedor de serviços para alcançar um resultado final desejado por um consumidor do serviço. Tanto o provedor de serviço quanto o consumidor de serviço são papéis desempenhados por agentes de software, e não por seus proprietários. Em um sentido geral, uma arquitetura orientada a serviços é uma solução de software destinada a permitir que uma empresa organize e faça uso de vários processos. Com SOA, os aplicativos de software não são mais blocos enormes de funções e processos. Em vez disso, esses aplicativos são compostos de serviços modulares montados. Lembre-se de que um serviço é uma simples função de software (como cancelar a reprodução de um CD). Pode ser executado sob demanda por qualquer sistema, independentemente do sistema operacional, plataforma, linguagem de programação ou localização geográfica.
O que é revolucionário em SOA não é o conceito em si, que já existe há muito tempo, mas o fato de poder ser implementado através da WWW (World Wide Web). Da mesma forma que as páginas da web são carregadas em qualquer plataforma, os serviços da web funcionam de maneira semelhante, independentemente da plataforma, pois são construídos usando
padrões universais.
A ideia de SOA decorre diretamente da programação orientada a objetos, que sugere uma relação entre dados e seu processamento. Assim, eles definem serviços formalmente por meio de interfaces independentes da plataforma subjacente e da linguagem de programação. Essas interfaces escondem as peculiaridades de sua implementação, o que as torna independentes do desenvolvedor e linguagem de programação. Por meio dessas arquiteturas, é possível projetar e implementar sistemas altamente escaláveis que reflitam a lógica do negócio e ao mesmo tempo facilitem a interação entre diferentes sistemas proprietários ou de terceiros. A razão pela qual queremos que alguém faça o trabalho para nós é porque eles são especialistas. Usar um serviço geralmente é mais barato e mais eficaz do que fazê-lo sozinho. Assim, a maioria de nós entende que não podemos ser especialistas em tudo. A mesma regra pode ser aplicada à construção de sistemas de software.
As interfaces são importantíssimas, se não forem bem definidas ou não funcionarem, o sistema não funciona. Integrar mais interfaces é caro e também aumenta a possibilidade de erros em aplicativos distribuídos. As interfaces remotas são a parte mais lenta da maioria dos aplicativos distribuídos. Com tudo isso, ao invés de construir novas interfaces para cada aplicação, faz mais sentido reutilizar interfaces genéricas para todas as aplicações.
Assim, como temos apenas algumas interfaces genéricas disponíveis, devemos incluir a semântica específica do aplicativo nas mensagens. Podemos enviar qualquer tipo de mensagem por nossas interfaces, mas existem algumas regras a serem seguidas para dizer que uma arquitetura é orientada a serviços.
– Em primeiro lugar, as mensagens devem ser descritivas, e não instrutivas, pois o prestador de serviço é o responsável por solucionar o problema. Por exemplo, seria semelhante à situação de ir a um restaurante e dizer ao garçom o que você gostaria de beber e suas preferências, mas não devemos explicar ao cozinheiro como preparar seus pratos, passo a passo.
‐ Em segundo lugar, os provedores de serviços não conseguirão entender sua solicitação se suas mensagens não forem escritas em um formato, estrutura e vocabulário compreensíveis por todos os envolvidos. Assim, limitar o vocabulário e a estrutura das mensagens é uma
necessários para uma comunicação eficaz. Quanto mais restrita a mensagem, mais fácil de entender.
‐ Em terceiro lugar, a possibilidade de prorrogações é de vital importância. O mundo é um lugar em constante mudança, assim como o ambiente em que o software vive. Essas mudanças exigem mudanças correspondentes no software do sistema, consumidores de serviços, provedores e as mensagens que eles trocam. Se as mensagens não forem extensíveis, os consumidores e provedores serão bloqueados para uma versão específica do serviço. Restrição e extensibilidade estão profundamente relacionadas, você precisa de ambas, e aumentar uma significa reduzir a outra. O ideal é conseguir um equilíbrio correto.
– Em quarto lugar, uma SOA deve ter um mecanismo que permita ao consumidor descobrir um provedor de serviços no contexto de um serviço procurado pelo consumidor. O mecanismo deve ser flexível e não deve ser um registro centralizado.
‐ Quinto, serviço Stateless (sem estados): Cada mensagem que um consumidor envia a um provedor deve conter todas as informações necessárias para que o provedor a processe. Essa restrição torna um provedor de serviços mais escalável, pois o provedor não precisa armazenar informações de estado entre as solicitações. Isso pode ser chamado de “serviço de produção em massa”, pois cada solicitação pode ser tratada de forma genérica. Essa restrição também oferece mais visibilidade, pois qualquer software de monitoramento pode inspecionar uma solicitação independente e extrair sua intenção. Isso também permite uma fácil recuperação de falhas parciais, pois não há estados intermediários, tornando o serviço mais confiável.
‐ Sexto, solicitações idempotentes (que não fazem alterações): solicitações duplicadas recebidas por um agente de software têm o mesmo efeito que uma única solicitação. Este requisito permite que provedores e consumidores aumentem a confiabilidade geral do serviço, simplesmente repetindo a requisição caso tenha ocorrido alguma falha.
Então podemos dizer que SOA não é uma ferramenta, mas sim um conjunto de padrões para construção de novas aplicações, mais dinâmicas e menos dependentes. SOA facilita o acesso a lógica de negócios e informações entre diversos serviços de forma sistemática, podendo também orquestrar diversos serviços remotos para compor um único. A maioria de as definições identificam o uso de Web Services, que veremos no próximo capítulo, na implementação de uma arquitetura orientada a serviços. No entanto, ele pode ser implementado usando qualquer outra tecnologia baseada em serviço.