JBI - "O barramento dentro do barramento"

Java Business Integration, ou simplesmente JBI, é um framework que define uma arquitetura de integração de componentes plugáveis e um modelo de troca de mensagens entre esses componentes. Nessa arquitetura, diferentes componentes podem ser conectados a um mediador de mensagens, e interoperar ou colaborar com os demais componentes do ambiente. O JBI é especificado pela JSR-208.
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.

Antes de fazer a analogia de SOA com a arquitetura JBI precisamos conhecer alguns integrantes de um ambiente JBI. São eles:

• 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.

Provavelmente você já deve ter começado a encaixar os BCs, SEs e o NMR na figura que apresentamos acima. Vamos ver como ficaria isso?

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:

1. Uma mensagem chega em um BC através de algum protocolo de comunicação (Ex: SOAP, REST, JMS, FTP, CIFS, SMTP etc);
2. 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;
3. O BC envia a menssagem normalizada para o NMR;
4. O NMR entrega a mensagem para um SE;
5. O SE processa a mensagem e devolve a resposta para o NMR;
6. O NMR envia a mensagem de volta ao BC original ou a outro BC.
7. 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).

Essa é a visão estrutural de como um ambiente JBI funciona. Quando digo "ambiente JBI" refiro-me a qualquer servidor que implemente a especificação JBI. Alguns servidores que implementam são: Oracle Glassfish ESB (Open ESB), Apache Service Mix, Petals ESB 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

A listagem completa dos componentes implementados pelo Service Mix está |aqui|.

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;

Certamente você seria capaz de fazer tudo isso usando sua linguagem de programação predileta e com a ajuda de algumas bibliotecas e frameworks. O grande benefício do uso de um JBI é que você consegue fazer isso tudo de maneira muito fácil, rápida e sem escrever praticamente nenhuma linha de código. Isso porque ao invés de programar você apenas configura os componentes para funcionarem da forma desejada e colaborarem para, em conjunto, atinginrem os requisitos e objetivos desejados.
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:

1. Conectar serviços ao barramento (ESB) através do BC apropriado, ou seja, de acordo com o protocolo falado pelo serviço;
2. Escolher o SE apropriado para processar a requisição de um serviço (Ex: rotear, log, transformar mensagem etc); e
3. 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.