À medida que as empresas desenvolvedoras de software crescem, elas passam por um amadurecimento de seus produtos e serviços. Padrões de projeto são implementados e processos são melhorados afim de diminuir custos, ganhar tempo e aumentar a qualidade dos produtos.
No caso do produto ser um software, uma das táticas para elevar o grau de maturidade e qualidade é criar um canal padrão de comunicação entre o produto (software) e o mundo externo (outros softwares que precisam compartilhar dados).
Olhando para a área tecnológica atual, vemos que a Arquitetura Orientada a Serviços (SOA) tem se tornado um modelo interessante a ser utilizado no desenvolvimento de softwares, e vem de encontro com este canal padrão de comunicação dos softwares.
Serviços
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.
Estrutura de 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.
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 *.
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.
Problemas
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:
>> 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. 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/Conversor de Mensagens
Softwares de conversão de mensagens existem há 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 software de conversão de mensagens inclui 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 conversã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 pode ser substituído sem alto custo, e com baixo prazo de implantação.
* Exemplos de mensagens que podem ser trocadas através de Serviços
- Endereço – Leitura de endereços cadastrados em certo software;
- Clientes – Leitura de clientes cadastrados em certo software;
- Estoque – Leitura de produtos e sua quantidade em estoque atual;
- Nota Fiscal – O Serviço cria uma nota fiscal no aplicativo;
- Pedido de Orçamento – Cria um pedido de orçamento;
O uso de uma Arquitetura Orientada à Serviços é um dos passos para aumentar o nível de maturidade de um software. O software ganha uma identidade e se torna mais organizado, facilitando sua comunicação e integração com o ambiente externo. Cada vez mais as empresas de software estão preocupadas em especilizar seus produtos, gastando tempo e dinheiro no que realmente importa, ou seja, nas regras de negócio, e optam por terceirizar áreas paralelas, que também são essenciais, através de parcerias com fornecedores especialistas. Elas saem ganhando ao investir na área core de seu negócio, especializando e criando uma interface única dos produtos, e terceirizando os módulos de integração e comunicação com os outros softwares do ambiente em que irá atuar.
Referência:
Microsoft. SOA in the Real World. 2007.
Autores da Hub2b
A Hub2b conecta a sua marca com os maiores marketplaces. Conheça a ferramenta mais prática para gerenciar e automatizar a sua operação nos marketplaces.