Enterprise Service Bus - Uma visão didática

Explicar de forma bem didática o porque e pra que utilizar um Barramento de Serviço. Através de um exemplo bem simples procurei demonstrar o por que utilizar um Barramento de Serviços

Trabalho em uma equipe da Memora Processos Inovadores SA, empresa especializada em soluções Middleware da Oracle, onde constantemente somos solicitados para realizar uma apresentação sobre SOA (Arquitetura Orientada a Serviços), Enterprise Service Bus e BPMS (Automação de Processos de Negócios). Mostrando nossos casos de sucesso, exemplos e um pouco de teoria sobre estes assuntos.

Decidi escrever este pequeno artigo pois pude verificar que, na maioria das vezes, o que as pessoas estão buscando é uma explicação simples de cada um destes termos. Muitas vezes as pessoas tem o conhecimento de como fazer e usar uma determinada ferramenta, mas não sabem para que nem o por que.

Neste artigo vou falar de forma bem simples do Enterprise Service Bus. O famoso barramento de serviços.

O barramento de serviços serve para promover a interconectividade entre os serviços complexos. Estabelece uma camada intermediária de processamento que pode ajudar a superar problemas comuns associados com a confiabilidade, escalabilidade e comunicação entre plataformas.

Quando eu li isso pela primeira vez, minha reação foi: tá e daí? Minha primeira pergunta foi: Porque não subir o serviço direto no Servidor de Aplicação ao invés de usar o Barramento de Serviço? Meu objetivo será mostrar o que me convenceu que vale a pena usar um Barramento de Serviço.

Para facilitar, vou dar um exemplo. Para atender a área de compras da empresa XPTO, criamos uma solução em java e em dispositivos móveis. Para não corrermos o risco de existir mais de um lugar fazendo a mesma coisa optamos por utilizar WebService para atender tanto as requisições do mobile quanto a em java, ver figura 1.

Figura 1: Serviço disponível direto no Servidor de Aplicação.

Tudo vai bem até que aparece a oportunidade de vender a mesma solução para uma empresa XPTOAA, maior, que possui a sede e 24 filiais.

Após a análise da alteração foi concluído que é necessário inserir o código da filial em todas as tabelas. Bem, aí vem o impacto, uma vez que o dispositivo mobile conecta diretamente o WebService, qualquer alteração nele irá impactar aplicativos clientes que utilizam este serviço.

Figura 2: Impacto da alteração nesta arquitetura

Este é um impacto que pode ser muito grande, caso seu serviço seja disponível para vários aplicativos clientes. Todos terão que ser alterados. Normalmente o que acontece é: as empresas alteram seu WebService e nem avisam os aplicativos clientes. Estes só vão notar o problema depois que o erro já aconteceu e a aplicação já parou de funcionar. Muitas vezes procuram primeiro o problema do seu lado do aplicativo só depois que vão ver que o WebService mudou. Ou seja, gera um grande problema!

Figura 3: Serviço disponível no Enterprise Service Bus.

Vale informar que o WebService criado na parte de baixo do barramento é o mesmo que teoricamente subiu no Servidor de Aplicação da arquitetura anterior. O Barramento de Serviços é uma camada intermediária. Se for necessário realizar a mesma alteração nesta nova arquitetura como ficaria?

Figura 4: Impacto na nova arquitetura

Como o Barramento entra como uma camada intermediária entre o banco, WebService e os Aplicativos clientes. O impacto é a alteração ou criação de novo serviço. Orquestrando ou Compondo novos serviços não alterando o contrato do WebService que está sendo utilizado pelos Aplicativos Clientes.

Concluindo, vivi em alguns projetos aqui na Memora uma alteração de escopo que exigia por exemplo, mudar todo o destino da informação de uma base para outra totalmente diferente, e realizarmos a tarefa em 5 dias úteis, trabalhando apenas as 8 horas diárias.

O Barramento de Serviços ajuda em muito no desacoplamento da solução. Uma alteração na parte negocial do serviço não altera quem utiliza ele. Uma alteração na forma de segurança de um serviço não altera o serviço que cuida da parte negocial. Isso é muito bom pois podemos pegar um problema gigantesco e quebrá-lo em partes, separar na arquitetura e desenvolver tudo em paralelo. Usando direito tem retorno de produtividade, agilidade na alteração e ajustes das soluções.

Irei publicar em breve novos artigos onde vou tentar mostrar formas de criar soluções utilizando estas tecnologias. Quando você acostuma com elas ficam muito empolgante.

ExibirMinimizar
aci institute 15 anos compartilhando conhecimento