Existe uma maneira bem fácil de entender a arquitetura do JBI. Imagine um barramento de serviços (ESB) de uma Arquitetura Orientada a Serviços (SOA). Provavelmente você deve ter imaginado uma imagem parecida como a abaixo.
Figura 1 - Visão de uma arquitetura SOA com ESB
Se esse não foi o caso, não tem problema. O que acontece é que a maioria dos desenhos que explicam um barramento de serviços possui um formato como esse, onde:
- Camada 1: Trata-se dos serviços, ou seja, da exposição de funcionalidades e/ou regras de negócio de sistemas existentes;
- Camada 2: Representa a interação dos serviços com o barramento para colaboração com os demais serviços ligados ao barramento. Quando falamos de web services, essa camada poderia ser, por exemplo, SOAP ou REST;
- Camada 3: É o barramento de serviços ou ESB, que faz a mediação da comunicação entre os serviços.
- Binding Components (BC): São componentes que fazem a ligação do ambiente JBI com o mundo externo. Eles são as portas de entrada e saída para o ambiente JBI;
- Service Engines (SE): São componentes do ambiente JBI que processam dados que chegam através dos Binding Components e, quase sempre, enviam uma resposta através do mesm ou ou de outro Binding Component;
- Normalized Message Router (NMR): BCs e SEs se comunicam trocando mensagens padronizadas. Essa comunicação é mediada pelo NMR.
Figura 2 - Visão de uma arquitetura JBI
Por questões didáticas mostramos os SEs na parte de cima da Camada 1 e os BCs na parte de baixo. A Camada 2 representa a forma de comunicação entre BCs e SEs através do NMR, que por sua vez está na Camada 3. Em linhas gerais, a dinâmica de funcionamento típico de um ambiente JBI segue o seguinte processo:
- Uma mensagem chega em um BC através de algum protocolo de comunicação (Ex: SOAP, REST, JMS, FTP, CIFS, SMTP etc);
- O próprio BC normaliza a mensagem, ou seja, padroniza a menssagem para que ela possa trafegar dentro do ambiente JBI e chegar até um SE ou outro BC;
- O BC envia a menssagem normalizada para o NMR;
- O NMR entrega a mensagem para um SE;
- O SE processa a mensagem e devolve a resposta para o NMR;
- O NMR envia a mensagem de volta ao BC original ou a outro BC.
- O BC que receber a mensagem desnormaliza e transforma a mensagem para o padrão de comeunicação implementado por el (Ex: SOAP, REST, JMS, FTP, CIFS, SMTP etc).
Cada um desses produtos possui um conjunto de implementações de Binding Componentes e Service Engines. As figuras abaixo representam um resumo dos BCs e SEs implementados pelo Apache Service Mix e pelo Oracle GlassFish ESB. Inclusive percebe-se que foi a imagem do Service Mix que eu utilizei como exemplo para fazer a analogia com SOA :-)
Figura 3 - Alguns componentes do Apache Service Mix
Figura 4 - Alguns componentes do Oracle GlassFish ESB
A listagem completa dos componentes implementados pelo GlassFish ESB está |aqui|.
Na prática o que podemos fazer em um ambiente JBI?
Como o JBI é baseado em troca de mensagens através do NMR, existem alguns padrões de trocas de mensagens (Message Exchange Patterns) definidos na especificação, tais como In-Only, In-Out, Robust In-Only, In Optional Out etc [1][2]. Não entrarei nesse nível de detalhe aqui nesse post. Por outro lado, vamos a alguns casos de uso práticos desses padrões:
- Configurar um JMS BC para escutar uma fila JMS e, ao chegar uma mensagem, redirecionar o seu conteúdo para um web service implementado usando SOAP através do SOAP BC ou HTTP BC;
- Orquestrar diferentes serviços disponibilizados como SOAP (SOAP BC ou HTTP BC) ou EJB (EJB SE);
- Expor como um web service a view de um banco de dados, ou seja, implementar um Data Services;
- Monitorar uma pasta de rede através de CIFS (File BC) ou FTP BC e, ao chegar um arquivo, processar seu conteúdo de forma a inserí-lo em um banco de dados através de JDBC;
Enfim, são várias as possibilidades de integrações que podem ser implementadas. Tudo depende da necessidade, das implementações de BCs e SEs disponíveis no ambiente que você escolher e também, por que não dizer, da sua criatividade.
Finalmente, qual o motivo desse post ter o título "O barramento dentro do barramento"?
Isso deve-se ao fato da possibilidade de uso do JBI como um ESB. Como o JBI possui um "barramento" interno, que é o NMR, ao usar o JBI como um ESB teremos "um barramento (NMR) dentro do barramento (ESB)". Na prática, o que faríamos seria:
- Conectar serviços ao barramento (ESB) através do BC apropriado, ou seja, de acordo com o protocolo falado pelo serviço;
- Escolher o SE apropriado para processar a requisição de um serviço (Ex: rotear, log, transformar mensagem etc); e
- Devolver uma resposta, se necessário, através do BC original ou de um outro BC, caso o protocolo de resposta seja diferente do protocolo da requisição original.
