ht=34 alt=imagem_pdf.jpg src="/imagens/imagem_pdf.jpg" width=34 border=0>
Integração com JBI
Parte 2: Explorando a API e o ServiceMix
Julio Faerman
Na primeira parte deste artigo, foi apresentada a especificação Java para integração corporativa, o Java Business Integration (JSR-208), e sua primeira implementação open source, o Apache ServiceMix (servicemix.org). Também foi mostrado como usar os componentes do ServiceMix para realizar diversas tarefas de integração.
Nesta segunda parte, analisaremos em detalhe os componentes e as trocas de mensagens necessárias para desenvolver um componente personalizado. Também mostramos mais detalhes sobre a configuração e gerenciamento do Enterprise Service Bus (ESB, o coração de uma implementação JBI).
Explorando os componentes
Os componentes, junto com as mensagens, são elementos centrais do JBI. Para garantir o comportamento apropriado dos componentes em qualquer implementação do JBI, a especificação define as características dos componentes e o que o ESB fornecerá a um componente instalado.
A primeira coisa a se definir é o tipo do componente:
· Service Engine (SE) – Componentes deste tipo são configurados para executar uma operação ao receberem uma mensagem. Por exemplo, podemos ter Service Engines de execução de scripts ou consultas SQL, validação de dados. SEs são usados para expor partes da lógica de negócios, processos de negócios, ou serviços de transformação de dados.
· Binding Component (BC) – Componentes de binding fornecem pontos de acesso ao ESB. Normalmente, obtêm informações usando um protocolo e as convertem em mensagens para o ESB. O ESB, por sua vez, entrega essas mensagens a outro componente. Por exemplo, podemos criar BCs para receber ou enviar requisições HTTP, arquivos via FTP ou mensagens SOAP.
O que define o tipo do componente é muito mais seu objetivo do que sua implementação. Se for um componente “trabalhador”, é um Service Engine; se for um “conector”, é um Binding Component. Na API do JBI a diferença entre os dois tipos é determinada apenas por um flag.
A API do JBI é bastante abstrata, deixando muitas decisões e trabalho para o desenvolvedor do componente. O ServiceMix disponibiliza classes de apoio que simplificam a programação e a instalação de componentes JBI. Assim, para uma classe poder ser instalada como um componente, basta que implemente a interface org.servicemix.MessageExchangeListener. O único método dessa interface, onMessageExchange(MessageExchange exchange), será invocado pelo ServiceMix para a troca de mensagens com o componente.
Para instalar um novo componente, é suficiente que ele esteja no classpath ao ser inicializado o ServiceMix, ou que seja colocado a qualquer momento no diretório deploy do ServiceMix. É importante destacar que os componentes desenvolvidos usando APIs específicas ao ServiceMix são aderentes à especificação JBI. Na instanciação, eles são encapsulados em um objeto da classe ComponentAdaptor (pacote org.apache.servicemix.components.util), que toma conta de toda infra-estrutura necessária para cumprir a especificação. (ComponentAdaptor implementa a interface javax.jbi.component.Component do JBI).
Service Units
Os componentes JBI devem ser projetados para fazer parte da infra-estrutura de integração, não das aplicações específicas. E devem ser configuráveis de maneiras diferentes, de acordo com cada necessidade de integração. Por exemplo, podemos ter um componente de execução de scripts, e ao longo do tempo adicionarmos novos scripts sem alterar o código do componente; um componente de verificação ortográfica poderia receber novos dicionários, e assim por diante.
Os elementos individuais que podem ser instalados nos componentes, como scripts e dicionários, são chamados Service Units (SU). Diversas SUs podem ser agrupadas num arquivo chamado Service Assembly (SA).
Um SA é distribuído como um arquivo zip contendo os arquivos a serem fornecidos ao componente e um descritor (/META-INF/jbi.xml). Este XML informa, principalmente, qual é o componente alvo de cada SU do SA, como mostrado na Listagem 1.
O ServiceMix monitora seu subdiretório install para instalação automática de SAs. Para cada SU contida no SA, o ServiceMix solicitará ao componente um objeto responsável pela instalação e remoção de SUs. Esse objeto deve implementar a interface javax.jbi.ServiceUnitManager e ser retornado pelo método getServiceUnitManager() do componente. Em seguida o ServiceMix invoca os métodos init() e start() do ServiceUnitManager recebido.
Explorando mensagens
O outro elemento fundamental do JBI são as mensagens, que carregam informações, sendo roteadas, transformadas e passadas aos componentes. A parte responsável por controlar este fluxo de mensagens é chamada Normalized Message Router – NMR – e as mensagens são definidas por classes que implementam a interface javax.jbi.messaging.NormalizedMessage.
Antes que possam ser manipuladas pelo NMR, mensagens precisam ser convertidas de objetos Java para um formato padrão e independente de plataforma. No JBI o padrão adotado é o WSDL (a linguagem XML para a descrição de web services). O processo de conversão entre objetos Java e documentos WSDL é chamado normalização. Ao chegar a um componente, mensagens são convertidas de volta em objetos Java (desnormalização).
Mensagens normalizadas são divididas em duas partes: contexto e conteúdo. O contexto é um conjunto de propriedades em pares nome-valor, onde o valor pode ser qualquer objeto. Tais propriedades podem ser ajustadas usando os métodos get/setProperty() definidos em NormalizedMessage. O conteúdo é o corpo da mensagem, em WSDL.
Com a mensagem no formato normalizado, o NMR pode usar componentes para transformar e examinar a mensagem e decidir a quem será destinada. O NMR também é responsável por ativar o serviço de destino e transportar as mensagens de acordo com um Message Exchange Pattern (MEP). Um MEP define como é feita a troca de mensagens entre quem usa um serviço (o consumidor) e quem oferece o serviço (o fornecedor). O JBI define os seguintes MEPs:
· ...
