A Arquitetura Orientada a Serviços (SOA) tem se tornado um modelo interessante de desenvolvimento de softwares para automatização de processos das empresas.
A ideia de Serviços em SOA é criar componentes ou porções de software contendo regras de negócio (ou ainda apenas partes de regras de negócio), que sejam isolados o suficiente para que possam ser reutilizados por diferentes aplicativos.
Uma das formas de disponibilizar estes serviços é utilizando web-services. Assim, com o crescimento da comunicação através de web-services, a Arquitetura Orientada a Serviços veio à tona novamente.
Entretanto, SOA não está totalmente associada à web-services, e nem está fortemente ligada às tecnologias. Como o próprio nome diz, SOA é uma arquitetura. Ela nada mais é que uma maneira de projetar software com baixo acoplamento (sem dependência complexa), considerando as necessidades/regras do negócio.
Diferente do que parece, SOA não é algo novo. Esta arquitetura era muito associada no passado com tecnologias como CORBA, DCOM, e tecnologias de integração baseadas em documentos, como o EDI (Troca Eletrônica de Documentos).
A publicação de serviços deve ser focada em como expor os investimentos existentes de TI como um conjunto, baseado em padrões, e permitindo que estes investimentos estejam disponíveis para a maior quantidade de consumidores possíveis. Normalmente, estes investimentos consideram plataformas heterogêneas dos parceiros comerciais. Assim, a exposição de quais serviços e de que forma estarão disponíveis deve ter como foco atender aos requisitos do negócio.
Os Serviços descritos nesta arquitetura são lógicas do negócio, em forma de software, expostos para que diferentes aplicações os utilizem. Serviços podem ser “montados” para criar processos de negócio, e então serem disponibilizados para consumo por usuários, aplicativos ou ainda outros serviços.
Para ser realmente útil, um serviço precisar ser separado entre interface e implementação. Enquanto a interface é exposta, onde os usuários, aplicativos ou outros serviços precisam conhecê-la para consumi-la; a implementação é privada, ou “escondida”. Desta forma, diferentes implementações podem oferecer a mesma interface, e modificações em uma implementação não causará interferência nos usuários, aplicativos e serviços que se utilizam daquela interface.
Também, os Serviços são independentes e devem ser capazes de participar de uma arquitetura de baixo acoplamento.
Divisão do Serviço em Interface e Implementação
Mas como a comunicação com Serviços ocorre? Basicamente, a comunicação com Serviços é feita através de mensagens com estruturas bem definidas. Estas mensagens possuem o formato definido pela interface do Serviço. Imagine um programa que importa um arquivo com dados em determinado formato. Neste contexto, o programa é o Serviço, e o arquivo é a Mensagem. Veja alguns exemplos de mensagens no fim deste artigo *.
Troca de Mensagens entre Serviços
Sabemos que o uso de SOA tem como objetivo facilitar o reuso de lógicas do negócio, seja por aplicativos do próprio negócio, seja por parceiros comerciais.
Também, Serviços são disponíveis para consumo através de interfaces, e através de certo meio de comunicação – web-service, arquivos, etc. Além do meio de comunicação, que pode diferenciar, a interface também define a estrutura da mensagem que vai ser recebida e enviada, o que pode ser algo específico do negócio.
Surge então um problema: como um Serviço que realiza sua comunicação através de web-services, com uma interface cuja estrutura de mensagem é específica, por exemplo, será consumido por um programa de um parceiro comercial, onde a comunicação é feita através de arquivos EDI (ou até mesmo através de web-services), possuindo uma diferente estrutura de mensagem (e meio de comunicação)?
Existem algumas possibilidades de solução deste problema. Algumas são efetivas apenas quando o meio de comunicação é o mesmo, enquanto outras são efetivas quando se deseja escalabilidade e flexibilidade, outras ainda podem destruir as vantagens trazidas pelo uso de Serviços. Vejamos:
>> Serviços de descoberta ou Utility Services
Utility Services são parte de conjuntos de serviços maiores chamados Bus Services. Em geral, os Utility Services não possuem relação nenhuma com lógicas de negócio, e são responsáveis pela descoberta de novos serviços, além de lidar com questões de segurança. Estes serviços são vistos como parte da infraestrutura da SOA.
Os Utility Services também podem ser instruídos e configurados por uma aplicação específica para executar uma operação no seu meio. Um exemplo assim é um Serviço de Transformação de Mensagem. Através deste serviço é possível fazer com que mensagens sejam transformadas de um esquema para outro baseado em um mapeamento fornecido pela aplicação que consome este serviço.
O ponto positivo neste contexto é a transformação de mensagens de um esquema para outro. Entretanto também existem “pontos fracos”, como a aplicação precisar conhecer todos os esquemas que serão recebidos ou enviados, e o meio de comunicação utilizado pelo serviço. Isto pode ser interessante para uma organização utilizando SOA, criando a existência de um padrão de comunicação entre os aplicativos internos (SOAP, por exemplo). Porém, os problemas ficam visíveis quando é necessária a integração com parceiros comerciais, principalmente em grande escala, quando os serviços a serem consumidos podem ser encontrados na forma de EDI, COM, e outros.
>> Modificação de aplicativo para consumo do serviço em específico
Sobre a modificação de aplicativos para que façam o consumo de determinados serviços, esta não é vista como uma boa solução. De forma similar aos Utility Services, visualizam-se problemas como a necessidade de conhecimento de todos os esquemas que serão recebidos ou enviados, e o meio de comunicação utilizado em cada serviço. Além disso, este tipo de solução traz problemas de escalabilidade, quando os serviços a serem consumidos são encontrados na forma de EDI, COM, e outros; e, por fim, o custo de desenvolvimento e manutenção deste tipo de solução se torna extremamente alto ao longo do tempo.
>> Middleware de integração, ou Tradutor de Mensagens
Softwares de tradução de mensagens existem a um longo tempo, sendo utilizados para realizar integrações EDI (Troca Eletrônica de Dados) entre empresas. Assim, muitos destes aplicativos fazem uma cobertura completa das necessidades de integração encontradas no mercado.
Um middleware de integração funciona de forma parecida com o Serviço e Transformação de Mensagens descrito com os Utility Services. A diferença entre ambos é que o middleware é especialista em tradução de mensagens, com soluções para os casos de diferentes meios de comunicação encontrados em serviços, e a vantagem da escalabilidade. Além disso, a possibilidade de configuração de esquemas e das transformações entre estes esquemas permite um fácil gerenciamento dos processos de integração de aplicativos.
Outra vantagem de softwares de tradução é a flexibilidade. A flexibilidade adquirida através do uso de middlewares de integração possibilita que diversos aplicativos sejam utilizados e integrados internamente em uma empresa. Além disso, quando um destes softwares não corresponde às expectativas, este software pode ser substituído sem alto custo, e com baixo prazo de implantação.
O ponto negativo do software tradutor é seu custo de aquisição, pois atualmente o foco destes aplicativos é voltado para empresas com grande demanda de troca eletrônica de documentos (em geral empresas de grande porte).
* Exemplos de mensagens que podem ser trocadas através de Serviços
- Endereço – Leitura de endereços cadastrados em certo software;
- Documento de Despacho – Enviado ao cliente quando uma venda foi despachada;
- Contatos – Leitura de contatos cadastrados em certo software;
- Clientes – Leitura de clientes cadastrados em certo software;
- Descontos – Leitura de uma lista de descontos disponíveis para um usuário específico;
- Estoque – Leitura de produtos e sua quantidade em estoque atual;
- Formas de Pagamento – Leitura das formas de pagamento utilizadas pelo negócio;
- Lista de Preço – Leitura de uma lista de preços específica para o cliente;
- Grupos de Produtos – Leitura de grupos de produtos utilizados pelo negócio;
- Nota Fiscal – O Serviço cria uma nota fiscal no aplicativo;
- Pedido de Orçamento – Cria um pedido de orçamento;
- Confirmação de venda – Leitura de confirmações de vendas com identificador;
Referência:
Microsoft. SOA in the Real World. 2007.
