ht=34 alt=imagem_pdf.jpg src="/imagens/imagem_pdf.jpg" width=34 border=0>
Integração com JBI
Parte 1: Conhecendo na prática o Java Business Integration
É possível estabelecer um padrão em cenários caóticos de integração? O Java está mostrando que sim, com o JBI
Julio Faerman
Imagine uma grande empresa operando há décadas. Ela certamente possui sistemas legados escritos em linguagens antigas, comunicando-se por protocolos estranhos e obsoletos. Também provavelmente terá aplicações Java de diversos sabores: de console, web, EJB, Swing. E há sempre os “contornos técnicos” – scripts, planilhas do Excel etc. Não seria bom se todas essas aplicações pudessem se comunicar de maneira padronizada e independente de fornecedor? Esta é a idéia do Java Business Integration – JBI.
O Java Business Integration é uma especificação do JCP (JSR-208), que define padrões para a integração de aplicações através de um "barramento de serviços corporativos". Neste artigo, serão mostrados os principais conceitos do JBI e um exemplo usando sua primeira implementação open source, o ServiceMix.
Integração corporativa
A integração entre aplicações é um desafio antigo, e muitas tecnologias já foram desenvolvidas para que aplicações comuniquem-se eficientemente. Antes de mergulhar no JBI, precisamos conhecer as principais técnicas de integração, e suas vantagens e desvantagens, para melhor entender quais problemas a nova tecnologia resolve.
Troca de arquivos
A troca de arquivos é o tradicional processo de exportar arquivos de um sistema e importar em outro. É uma forma de integração muito comum no processamento em lote (batch), típico dos mainframes. As principais dificuldades desse tipo de integração estão na definição do formato para os arquivos e na sincronização das informações existentes com as novas, depois de cada importação de dados.
A disseminação do XML facilitou a definição dos formatos para a troca de arquivos, mas o problema de sincronização permanece difícil. Uma vantagem da integração por troca de arquivos é dispensar softwares intermediários de integração, pois o sistema operacional já fornece quase toda a infra-estrutura necessária, requerendo talvez apenas um analisador para o formado escolhido, por exemplo um parser XML.
Bancos compartilhados
Nessa forma de integração, as aplicações que precisam se comunicar lêem e escrevem no mesmo banco de dados. Isso elimina grande parte do problema de sincronização, pois ao se cadastrar uma informação nova, as outras aplicações terão acesso a ela instantaneamente.
Como a maioria das aplicações corporativas já usa bancos de dados relacionais, a integração por bancos compartilhados é muito comum. A principal desvantagem é a dificuldade de se chegar a um modelo de dados que atenda a todas as aplicações – um problema particularmente complexo quando se está usando software de terceiros, como um ERP, que dificilmente lida com outros modelos de dados além daqueles que ele mesmo define ou suporta.
RPC
Muitas vezes é importante compartilhar não somente dados, mas funcionalidades completas. Uma das primeiras tecnologias criadas para esse fim foi a invocação ou chamada remota de procedimentos (RPC). Usando RPC, objetos são publicados para que seus métodos possam ser invocados remotamente através da rede. Para objetos Java, diversas tecnologias de publicação e invocação remota estão disponíveis, como RMI, EJB e JAX-RPC.
Normalmente a invocação remota é tratada por classes intermediárias geradas automaticamente (stubs), o que torna o código da invocação de um método remoto pouco diferente da invocação de um método local. Uma desvantagem dessa “transparência” é que ela pode iludir o programador, fazendo-o tratar métodos remotos e locais da mesma forma – apesar de a performance e a segurança de invocações remotas serem muito diferentes. Além disso, o uso de RPC muitas vezes leva à mistura de código de negócio com o código de invocação.
Troca de mensagens
Na integração por troca de mensagens, quando uma aplicação precisa de dados ou funcionalidades de outra, ela lhe envia uma mensagem. Esta mensagem é processada pela aplicação de destino, que atende à requisição e possivelmente envia uma mensagem de resposta. Uma das vantagens da troca de mensagens é ser assíncrona, ou seja, ao mandar uma mensagem, uma aplicação não fica bloqueada e pode continuar executando outras tarefas.
Tipicamente, a troca de mensagens é gerenciada por um middleware de mensagens (Message Oriented Middleware – MOM). Uma vantagem dos MOMs é permitir que sistemas que estão trocando mensagens falhem ou sejam interrompidos sem conseqüências permanentes, pois as mensagens podem ficar retidas no MOM até serem entregues com sucesso. Um MOM pode oferecer outras funcionalidades, como entrega de mensagens a diversos destinos, garantia de entrega e persistência das mensagens.
A tecnologia Java tem um papel importante no segmento de MOMs, pois desde a versão 1.3 do J2EE/JEE, todo servidor de aplicações precisa incluir um JMS Provider, ou seja, um MOM que implemente a especificação Java Message Service. Várias implementações de middlewares líderes de mercado, como Tibco, SonicMQ e ActiveMQ, implementam a JMS.
Avaliando mecanismos de integração
Tantas possibilidades de integração possibilitam o aproveitamento dos sistemas existentes e do investimento em tecnologia da empresa. Entretanto, as integrações tendem a ser criadas de acordo com a necessidade, usando o melhor mecanismo (ou o mais fácil) em cada caso. Essa abordagem costuma causar problemas em duas áreas importantes:
· Manutenibilidade e flexibilidade – A arquitetura sendo definida ao longo do tempo, com os sistemas se comunicando diretamente, acaba formando um emaranhado de integrações difícil de ser alterado ou estendido com novas funcionalidades. Essa é a famosa arquitetura “por acaso” ou “espaguete”, como o exemplo mostrado na Figura 1.
· Escalabilidade – Se cada uma das N aplicações conversar diretamente com todas as outras, isso gera N*(N-1) integrações, com o número portanto crescendo geometricamente a cada nova aplicação integrada. Centralizar as integrações em um mediador diminui a quantidade de integrações, mas cria novos problemas: esse intermediário tende a ser sobrecarregado, torna-se um ponto único de falha e geralmente tem manutenção cara.
Em um cenário ideal num processo de negócio envolvendo diversas aplicações, cada aplicação fornece seus serviços de acordo com o mecanismo que lhe for mais conveniente, e um sistema externo fica responsável por acessar cada aplicação envolvida. Este estilo de integração, em que aplicações heterogêneas e altamente distribuídas são coordenadas para cumprir processos de negócio é chamado de Arquitetura Orientada a Serviços (Service Oriented Architecture – SOA).
Uma maneira eficaz de se implementar uma arquitetura orientada a serviços é através de um Enterprise Service Bus (ESB) ou barramento de serviços corporativo. O JBI padroniza os ESBs, da mesma maneira que a especificação JEE padroniza os servidores de aplicações.
A seguir, veremos como funciona um ESB e como integrar aplicações usando o ServiceMix, uma implementação open source do JBI.
Enterprise Service Bus
Um ESB é um canal em que diversas aplicações serão conectadas. As integrações são realizadas instanciando-se componentes que se conectam ao ESB e se comunicam através de mensagens, como ilustrado na Figura 2.
Apesar do ESB ser baseado em mensagens, cada aplicação pode usar a técnica de integração que lhe for mais conveniente. Por exemplo, o ESB pode ler de um arquivo-texto exportado por uma aplicação e inserir as informações no banco de dados de outra. Internamente, o ESB usará mensagens para fornecer a infra-estrutura necessária para tal integração.
O JBI define as principais funcionalidades oferecidas por um ESB:
§ Publicação – O ESB deve fornecer mecanismos para a publicação de serviços, como acesso a web services, importação de arquivos e acesso a bancos de dados.
§ Comunicação confiável – Os serviços podem estar publicados em redes diferentes, conectadas via links não confiáveis; o ESB é responsável por garantir a entrega de informações e a invocação de serviços sem perdas.
