Qual o futuro do GlassFish Open ESB e da sua implementação JBI?


Quando a Oracle anunciou a compra da Sun o assunto principal foi o que aconteceria com o MySQL já que o maior fornecedor de banco de dados comercial estava comprando a empresa que mantinha a maior distribuição de banco de dados open source. Entretanto a minha atenção, e certamente de vários profissionais que trabalham com SOA e integração de sistemas, voltou-se para o GlassFish ESB. Qual seria o futuro do GlassFish ESB e da sua implementação JBI?

Mesmo antes da aprovação da compra da Sun pela Oracle pela Comissão Européia, os mais pessimistas praticamente auto decretaram o fim não só do GlassFish ESB mas um genocídio onde o servidor de aplicação GlassFish e o a IDE NetBeans também estariam com os dias contados.

Passados mais de 6 meses desde a efetivação da compra, podemos considerar como incerto o futuro do GlassFish ESB?. De fato parece que nada concreto está definido por parte da Oracle. No que diz respeito à comunidade que desenvolvia o produto e as empresas que prestavam (e ainda prestam) suporte, as novidades já começam a surgir. O código-fonte do GlassFish ESB e a versão mais atual do OpenSSO estão disponívis em http://www.forgerock.com/. Além disso, está programado para os dias 4 e 5 de outubro de 2010 um encontro na Bélgica para discutir e definir os seguintes pontos em relação ao GlassFish ESB:

  • Definir um novo modelo de governança para a comunidade
  • Definir um novo processo de manutenção e evolução do código-fonte
  • Desenhar o Roadmap para as próximas versões do Open-ESB V2.x e do Fuji (considerada a versão 3)
  • Reorganização das documentações do projeto

O evento contará também com laboratórios, apresentação de casos de sucesso e painéis de discussão e utilização do GlassFish ESB. Temporariamente o site do evento está no endereço http://87.106.30.213:8081/ezpublish/index.php/eng mas em breve estará em definitivo no endereço http://openesb-community.org/.

Voltando ao assunto Oracle… na minha opinião o que acontecerá com o GlassFish ESB é que a Oracle irá portar o padrão JBI para o Oracle Service Bus permitindo que componentes JBI possam ser compostos na implementação SCA (Service Component Architecture). Essa “simples” ação ao menos preservaria o investimento daqueles que possuem utilizam o GlassFish ESB e desejarem migrar o stack Oracle.

Vamos aguardar cenas dos próximos capítulos esperando que boas notícias do passado em relação ao GlassFish ESB possam novamente ser manchete.

[]’s

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 MixPetals 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-OnlyIn-OutRobust In-OnlyIn 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.