JBI consiste em uma especificação que define uma arquitetura e comportamentos para hospedagem de componentes plugáveis, onde a comunicação entre estes componentes se fará através do uso de WSDL (Web Services Description Language) 2.0.
O principal objetivo do JBI é permitir que possamos utilizar componentes plugáveis, provendo todas as funções necessárias para uma solução de integração, sem sermos dependentes de um fornecedor específico. Ou seja, os componentes poderão ser facilmente portáveis entre quaisquer implementações do JBI.
O JBI também é conhecido como um "container of containers".
Imaginando um cenário para aplicação do JBI por arquitetos/desenvolvedores Java EE, seria mais ou menos assim: Os EJBs implementados, poderiam ser compostos dentro de processos de negócios, mais precisamente em Stateful Business Processes, através da linguagem BPEL, permitindo com isto, a orquestração do componentes de negócios (EJBs) sem a necessidade de implementação "hard-code" em classes Java destes processos de negócios. Conseguindo com isto, uma maior flexibilidade e interoperabilidade na utilização e otimização destes processos.
O JBI possui dois componentes principais: Os "Service Engines" e os "Binding Components".
Os "Service Engines" são responsáveis por prover lógicas de negócios e/ou serviços de tranformações de mensagens entre outro componentes, além de consumirem serviços (é claro). Já os "Binding Components" provêem serviços externos ao ambiente JBI, tal como atuando como um Adapter entre protocolos de comunicações diferentes, entre os serviços externos e o ambiente JBI.
É interessante destacar que a distinção entre os "Service Engines" e os "Binding Components" é apenas de caráter arquitetural, separando as lógicas de negócios das lógicas de comunicação com intuito de reduzir a complexidade de entendimento, implementação e flexibilidade.
Mas como funciona as interações entre os componentes dentro do ambiente JBI?
Estas interações funcionam da seguinte forma:
Dentro do ambiente JBI, existe um BPEL Engine, que é um "Service Engine", responsável pela hospedagem e execução dos processos de negócios no formato BPEL (é claro).
É lógico que estes processos não saberão quais protocolos os clientes irão utilizar para acioná-los. Com isto, faz-se necessário a utilização de "Binding Components" que irão converter estes protocolos heterogênios em uma forma normalizada, ou seja, uma mensagem XML em conformidade com um dado WSDL, adicionar nesta mensagem normalizada, meta-dados tais como: segurança, transação, dentre outras. E a partir daí, repassar para o ambiente JBI.
Logo após, o ambiente JBI determinará qual componente, ou melhor "Service Engine", poderá atuar como um serviço qua atenda à requisição, que neste caso é o próprio BPEL Engine. Assim, a mensagem normalizada será repassada para BPEL Engine, para que o mesmo possa instanciar o processo de negócio requisitado pelo cliente.
Vale destacar que, se o processo instanciado precisar de algum tipo de serviço complementar (tal como alguma transformação), o JBI irá determinar qual componente proverá este serviço, e redirecionará a requisição para o mesmo (no caso de transformação, XSLT engine, por exemplo), que responderá de volta para o BPEL Engine.
Obs1: O BPEL Engine é um consumidor e provedor de serviços, porém ele trabalha apenas com mensagens normalizadas.
Obs2: A escolha de quais componentes atuarão como um dado serviço, é feita através de componentes inteligentes (smart components), configurados para fazer estas escolhas. Inclusive, podem ser customizados.
Um comentário:
Show de bola este post Breno, parabéns!
Postar um comentário