Como se implementa a arquitetura SOA?

Na postagem anterior, iniciamos nossos estudos sobre SOA explicando quais são os serviços implementados nessa arquitetura e trazendo alguns conceitos específicos, como a orquestração. Na postagem de hoje, vamos falar um pouco sobre a implementação de SOA e a forma como ela é cobrada em concursos.

Para implementar SOA, temos protocolos baseados em XML (Extensible Markup Language) que foram projetados para oferecer suporte à comunicação de serviço e à troca de informações. Consequentemente, esses protocolos garantem a comunicação entre os serviços e os sistemas usuários desses serviços. Ou seja, os serviços podem ser implementados em qualquer linguagem de programação e, ainda assim, ficarem disponíveis para uso.

A figura a seguir apresenta como funciona uma arquitetura orientada a serviços, os seus componentes e as ligações entre eles:

Nessa figura, vemos que um provedor de serviços publica seus serviços em um registro de serviços (ou broker de serviços), o qual é consultado pelo solicitante ou cliente do serviço com o objetivo de se descobrir as especificações do serviço desejado. Posteriormente, o solicitante do serviço se liga ao provedor de serviços para ter acesso ao serviço desejado.

Detalhando os diversos componentes de uma arquitetura SOA, temos:

Provedor de serviços. Cria um serviço e possivelmente publica sua interface e informações de acesso no registro de serviço. Cada provedor deve decidir quais serviços expor, como fazer intercâmbio entre a segurança e a fácil disponibilidade e como definir preços aos serviços.
Registro de serviços. É responsável por disponibilizar a interface dos serviços e as informações de acesso de implementação a qualquer solicitante de serviço potencial. Servidores de registro de serviços públicos são disponíveis por meio da Internet, enquanto servidores privados são acessíveis apenas a um público limitado, como, por exemplo, usuários da intranet de uma empresa. Além disso, algumas decisões precisam ser tomadas sobre a quantidade de informações oferecidas. Alguns registros de serviço se especializam em muitas listas. Outros oferecerão altos níveis de confiança nos serviços listados. Alguns cobrem um amplo horizonte de serviços e outros se concentram em uma indústria. Alguns registros de serviço catalogam outros registros de serviço. Dependendo do modelo de negócios, os registros de serviço podem tentar maximizar os pedidos de consulta, o número de listagens ou a exatidão das listagens.
Solicitante de serviços. Localiza entradas no registro do broker, usando várias operações de localização e, em seguida, conecta-se ao provedor de serviços para chamar um de seus serviços.

Pensando em camadas de software, quantas camadas podemos ter em SOA? Cataloguei algumas camadas que são associadas à arquitetura:

Camada de Interface do Consumidor: É o ponto onde os consumidores vão interagir com a SOA.
Camada de Processos de Negócio: Essa camada identifica e documenta os processos de negócio chave da empresa.
Camada de Serviços: Responsável por mapear e expor os serviços que provêm as funcionalidades que dão suporte aos processos de negócio.
Camada Componentes do Serviço: mapeia os componentes que são utilizados pela camada de serviço. Componentes são os blocos de construção de serviços na arquitetura SOA e, embora vários sejam construídos com esta finalidade, a maioria será reaproveitada a partir de aplicações já existentes, através de técnicas de encapsulamento.
Camada de Sistemas Operacionais: Onde os recursos de infra estão alocados (exemplo: banco de dados). Nessa camada, também podemos encontrar aplicações legadas e classes de objetos representando alguns modelos de dados.
Camada de Integração: Responsável por intermediar a comunicação entre o provedor de serviço e o consumidor de serviço. É a camada onde estarão os serviços de conectividade. Insere um nível de indireção entre consumidor/provedor. É importante que a conexão ao serviço é realizada por esta camada e não direto pelo provedor de serviços.

Para finalizar a postagem de hoje, vamos falar dos princípios de design de SOA elencados por ERL (2009)[1], uma vez que já os vi em algumas questões de concurso. São oito princípios:

Padronização do contrato de serviço: Manter contratos padronizados, com as capacidades e modelos de dados do serviço, em alto nível, sem se perder em detalhes, ligando o provedor ao consumidor do serviço.
Baixo acoplamento: Deve-se evitar a dependência entre serviços, criando-se serviços com baixo acoplamento.
Abstração do serviço: O serviço deve ser genérico o bastante para se adaptar ao máximo de composições possíveis, mas ao mesmo tempo não pode ser abstrato demais ao ponto de o consumidor não saber do que se trata o serviço. Esse princípio prega o ideal de ocultar informações de implementação do serviço, além de estabelecer uma abstração suficiente para que o serviço se torne agnóstico – multipropósito – para a corporação.
Autonomia do serviço: Prega que cada serviço deve ser responsável pelo seu ambiente em tempo de execução e projeto. No entanto, em composições complexas, à medida com que o serviço se aproxima do topo da cadeia de composição, o nível de autonomia é comprometido. Em contrapartida, quanto menor for a posição do serviço na composição, maior será sua autonomia.
Visibilidade do serviço: Um serviço deve ser de fácil interpretação e descoberta.
Independência do controle de estado do serviço: Um serviço não deve guardar estado. Quem mandou a mensagem, o histórico do que foi feito e o retorno obtido não é problema do serviço, mas do solicitante do serviço.
Reusabilidade: Esse é fácil! Os serviços devem ser projetados para o reúso pela organização.
Capacidade de composição do serviço: Os serviços devem ser projetados para formarem composições ou orquestrações de serviços mais complexos.