Olá pessoal,

Hoje venho falar de uma tecnologia muito interessante e que vem sendo adotado cada vez mais em arquiteturas de aplicações enterprise, o SOA – Service Oriented Architeture (Arquitetura Orientada a Serviços). O objetivo desse artigo é mostrar a necessidade da adoção dessa abordagem, além das dificuldades encontradas em sua implementação.

O que é SOA?

Como o nome diz, SOA é um estilo de arquitetura que é orientada a serviços, ou seja, ela possui como princípio fundamental o fato de que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços. As aplicações interagem entre si utilizando um protocolo que define toda a estrutura desses serviços. Um protocolo muito popular é o SOAP (Simple Object Access Protocol) que, por meio de um arquivo WSDL (Web Service Definition Language), define uma maneira comum de conversação entre as aplicações e os serviços. Esses serviços são gerenciados e conectados normalmente por um ESB (Enterprise Service Bus) que disponibiliza interfaces por meio de WebServices. Vale lembrar que SOA não é a tecnologia. Ela é uma arquitetura que se baseia em serviços como forma de troca de mensagens e pode ser implementada com qualquer tecnologia padronizada baseada em web como por exemplo SOAP, REST, WSDL, WebServices.

Serviço

Um serviço, no mundo SOA, é uma funcionalidade ou função disponibilizada para qualquer sistema. Ele deve ter uma interface bem definida, uma espécie de contrato do tipo “você me passa tais parâmetros, que eu te devolvo esse resultado”. Imagine uma declaração de método em uma linguagem qualquer (Java, por exemplo):

public Integer somar(Integer n1, Integer n2) {
 return n1 + n2;
}

Acima temos definido o seguinte contrato: “me passe 2 números inteiros que eu te devolvo a soma dos mesmos”. Essa declaração simples de método pode perfeitamente representar um serviço (claro que com sua devida infraestrutura). Este por sua vez, disponibilizado na web em um servidor de aplicação (como o Glassfish, por exemplo) é chamado de WebService. Este WebService poderá ser “consumido” (ou executado) de qualquer outra aplicação que entenda o protocolo SOAP (e siga o contrato do WSDL).

O WSDL define o contrato (parâmetros de entrada e retorno) a ser utilizado entre as duas aplicações. O processo de consumação de um serviço é conhecido como “Find-Bind-Execute” e segue um paradigma bem definido para sua concretização.

No fim das contas, onde eu uso isso?

Um dos cenários mais indicados para a utilização de uma arquitetura desse tipo, é na integração de sistemas legados, onde um não faz a mínima idéia da existência do outro. A criação de interfaces de serviços de ambos os lados permite um intercâmbio de informações sendo trafegadas de maneira transparente para as aplicações. No meio disso tudo, pode existir um software chamado ESB, ao qual faz o roteamento e promove a conversação entre esses vários sistemas, servindo como um middleware, pois faz o “meio-de-campo” entre as aplicações. Uma outra funcionalidade muito importante do ESB é a abstração das cadeias de chamadas de serviços (vários serviços numa ordem definida, como sendo um só).

Eu já vi isso em algum lugar…

Sim, naquelas máquinas de cartão. As empresas que possuem o serviço (Redecard, Visa, American Express) possuem um serviço disponível na web que autentica e valida transações de usuários. Quando você digita sua senha numa máquina, ela envia uma requisição para o servidor da bandeira correspondente, perguntando se: a máquina está autorizada a realizar requisições (se está com a mensalidade paga, etc.), se a senha informada é válida e se o cliente tem saldo suficiente na conta para realizar aquela operação. O serviço, por sua vez, responde sim ou não. O mesmo serviço fica disponível para consumo em qualquer plataforma que entenda o contrato que a bandeira possui, como por exemplo uma loja virtual.

Já que é tão legal, por que todo mundo não sai implementando?

Imagine que, para isso tudo funcionar, é requerida uma grande infraestrutura, servidores de aplicação robustos e muito, muito conhecimento técnico. Isso custa caro. Muito caro. E, principalmente, essa arquitetura não é aplicável a todas as situações, como muitos “profissionais” de TI pensam (claro que vender uma solução desse porte pode render muito $$$$). Outro grande problema é a complexidade técnica necessária para a implementação de algo desse tipo, as consultorias cobram caro e nem sempre sai como o esperado.