Ao longo de alguns treinamentos que tenho participado e/ou ministrado, tenho percebido que muitas empresas e muitas pessoas não têm a menor noção sobre qual é a importância do um "Enterprise Service Bus".
Trabalhei em uma empresa que de uma hora para outra, resolveu partir para o 1o. projeto SOA, e erroneamente, primeiro definiram que precisariam de um ESB.
Começaram então, a desenvolver um monte de webservices, sem critério algum, e a criar um monte de proxy para cada webservice. Não preciso nem falar que esse projeto foi por água abaixo.
A impressão que eu tenho é que o web service, virou a solução mágica para todos os problemas de TI, e que utilizar o ESB, entre outras coisas vai deixar a aplicação seja ela qual for extremamente rápida, ledo engano.
Estive recentemente em um projeto onde todos os EJB´s (Session Beans Stateless) são anotados como webservices e consumidos por um ESB. Vi lá, EJB´s/webservices para consultar combustível, sexo,
relatórios síncronos e outros absurdos mais.
Quando me deparei com isso, me questionei :
1. Realmente estes EJB´s devem ser anotados como web services para serem consumidos internamente?
2. Será que as pessoas esqueceram que um EJB pode ser utilizado remotamente?
3. Por que devo colocar este EJB/web service em um ESB?
4. Este EJB/webservice possui agora um intermediário, o ESB, será que isso é realmente necessário?
5. Será que um relatório seja lá do que for, deve ser gerado por um webservice síncrono plugado em um ESB?
A impressão que tenho é que quando surgiu o web service, tudo tinha que ser escrito como web service, e isso é um grande absurdo. Acredito que a mesma coisa aconteceu quando os EJB´s surgiram, todo mundo começou a utilizar os EJB´s sem o menor critério.
Um Enterprise Service Bus, seja lá qual for, deve ser utilizado quando temos as seguintes necessidades:
1a. As aplicações devem por algum motivo possuir um mediador que deve atuar entre os serviços oferecendo funcionalidades.
2a. Localização Transparente de Serviços :
Um "Enterprise Service Bus" tem que agir como proxy para muitos "endpoints" para um mesmo serviço, possibilitando que um mesmo serviço possa estar ativo em várias máquinas, realizando o balanceamento de carga entre os possíveis servidores. Essa característica, permite que os webservices possam ser alterados sem que os clientes sofram alterações.
3a. Agregação de Serviços :
Um "Enterprise Service Bus", atua com dois conceitos fundamentais : Proxy Services e Business Services.
Proxy Services são os serviços publicados no Enterprise Service Bus.
Business Services representam serviços que são externos ao Enterprise Service Bus.
Um serviço configurado em um "Proxy Service", pode utilizar vários "Business Services", agregando lógica adicional ao serviço que está sendo executado.
4a. Camada de Abstração de Serviços :
Um "Enterprise Service Bus", permite que seja criada uma camada de abstração entre os clientes e provedores. Isso permite que integrações sejam feitas através de transformações, possibilitanto a modificação de documentos XML´s, criando-se assim uma camada de abstração entre os clientes e provedores.
5a. Localização centralizada de log e monitoramento de métricas :
Um "Enterprise Service Bus", oferece mecanismos centralizados de log, permitindo através de métricas estabelecer SLA´s sobre os serviços, medindo sua performance. Essas métricas podem ser trabalhadas através de monitoramentos estatísticos obtidos através de relatórios que são fornecidos através de ferramentas disponibilizadas pelo ESB.
6a. Localização centralizada de políticas de segurança :
Um "Enterprise Service Bus", atua de forma centralizada como uma plataforma para o fornecimento de políticas de segurança aos seus serviços.
São estas as características que tornam essencial a utilização de um ESB.
Infelizmente muitas empresas não utilizam o ESB da forma correta, utilizando-o somente como um proxy para consumo de serviços.
Espero de alguma forma ter ajudado.
Abraços.
