Artigos Java Artigo Java Magazine 59 - JBoss ESB
Por que eu devo ler este artigo:

Este artigo apresenta uma visão geral sobre o JBoss ESB, possibilitando que desenvolvedores de todos os níveis possam ter um primeiro contato com a forma de utilização e conceitos a respeito de Arquitetura Orientada a Serviços – SOA, entre eles: Enterprise Services Bus - ESB.

O mercado comenta muito a respeito de ESB, desta forma, apresentamos um projeto Opensource, o qual permite download para que seja possível aplicar o exemplo mostrado no artigo. O JBoss ESB é uma implementação de barramento de serviços que possibilita o roteamento de mensagens, comunicação com inúmeros protocolos (filesystems, ftp, jms, smtp, ejb, webservices etc), e um conjunto rico de componentes auxiliares que possibilitam a criação de canais de serviços de forma fácil e rápida.

Um ESB é considerado a espinha dorsal de uma arquitetura orientada a serviços, pois cabe a ele a sustentação de uma infra-estrutura que permite a mediação, roteamento, transformação de dados e até orquestração para os serviços. Com isto, é possível criar integrações das mais diversas entre aplicações. Imagine que uma empresa quer receber dados de compras de n-fornecedores, só que cada fornecedor tem um sistema diferente, sendo assim, através de um ESB, poderia ser estabelecido um canal, onde fosse elencado algum protocolo de comunicação para que fosse possível estabelecer esta comunicação. Exemplos como estes, são necessidades reais que várias empresas possuem no dia-a-dia, e é esta uma das arestas que tentamos resolver quando queremos aplicar SOA numa empresa.

Integrar sistemas de forma simples e aderentes a padrões modernos de mercado não é uma das atividades mais simples, e requerem certa experiência em termos de integrações. Para facilitar as integrações, soluções de Enterprise Service Bus - ESB, agregam valor abstraindo grande parte da complexidade de integrações. Este artigo aborda o JBoss ESB, que é um ESB Open-source com uma rica documentação e exemplos de modelo.

No artigo, abordaremos uma visão geral sobre SOA (Arquitetura Orientada a Serviços), as origens e conceitos primordiais de um ESB, além de um exemplo real, que pode ser aplicado em situações do dia-a-dia.

A Arquitetura Orientada a Serviços – SOA, é o assunto do momento no mundo de tecnologia. Várias empresas estão em busca da adoção de uma maneira de estruturar os serviços de forma que possam ser reaproveitados, gerenciados e interoperáveis. A primeira opção para obter isto no mundo SOA é através de um barramento de serviços, os quais conhecemos como Enterprise Service Bus, ou mais popularmente: ESB.

SOA - Arquitetura Orientada a Serviços: Uma Introdução

Falar de todos os conceitos de SOA é impossível em um único artigo, entretanto gostaria de ressaltar alguns caminhos que poderão lhe facilitar a vida para entender este que está se tornando um requisito obrigatório para as empresas modernas.

Para entendermos melhor, vamos cercar SOA em duas abordagens: Técnica e de Negócio.

Técnica

Quando falamos de tecnologia, você pode pensar como um Desenvolvedor e estará liberado para olhar SOA do ponto de vista de implementação técnica, sendo assim, é hora de pôr em prática vários conhecimentos a respeito de Objetos Distribuídos, Mensageria e Orientação a Objetos. Ao abordar SOA do ponto de vista técnico você irá se deparar com os conceitos de:

  • MOM (Messaging Oriented Middleware) – Os servidores de mensagens assíncronas estão se tornando mais populares com o SOA, mas não são nenhuma novidade. A programação assíncrona está presente há muitos anos, principalmente no mercado financeiro, onde há uma larga presença se soluções como: CICS, WebSphere MQ, Tibco, MS-MSQM e Tuxedo. Esta prática ganhou o pseudônimo de “Mensageria”, que consiste basicamente no processo de publicar uma Mensagem com as informações necessárias para o processamento, e aguardar que algum agente processe estas mensagens e tome alguma ação. Como exemplo de prática de Mensageria, imagine uma declaração de Imposto de Renda, como é uma prática no Brasil, sempre entregamos tudo na última hora, sendo assim, a carga de processamento síncrono (que espera retorno) seria inviável durante os últimos dias e horas de entrega. Ao passo que se reduzíssemos o processo a apenas entregar a declaração, que é o mais importante, deixaríamos o processamento para uma fase posterior. Em outras palavras: Assíncrona, ou seja, sem a espera de retorno imediato. Com uma implementação desta forma, o foco do Serviço Entrega de Declaração é priorizado, perante outros que podem ser processados posteriormente;
  • Transferência de Arquivos (File Transfer) – Muitas empresas ainda usam tecnologias e/ou linguagens como Cobol, Natural, DataFlex, Zim, Clipper, FoxPro, Progress e muitas outras, as quais chamamos nos dias de hoje de “Legado”. Uma das formas de integração mais comuns ainda são as famosas gerações de arquivos-texto (ex.: CSV). Antes que você ache que isto é somente das aplicações “estilo terminal”, há vários ERPs de mercado que também usam destes subterfúgios para que você consiga gerar relatório ou consolidar informações. Um ESB entre suas características básicas, deve possuir Transformadores / Conversores (Transformers / Converters). Imagine que várias empresas publiquem seus pedidos em TXT separados por vírgula, porém quando os dados contidos neles são consumidos, deve haver uma transformação de primeira fase do TXT para um XML, e este XML por sua vez pode originar outras comunicações, ou outra fase de transformação, no caso para Java, caso você utilize um framework de databinding xml como o JAXB ou XStream;
  • Bancos de Dados Distribuídos – Não é difícil termos exemplos de empresas que usam mais de um banco de dados, sendo comum que um gerente queira informações consolidadas de dois ou mais bancos de dados num relatório, por exemplo. Temos então uma das formas mais tradicionais de integração. Ao passo que isto se torna mais comum, em SOA podemos ver o conceito de Federação de Dados que visa oferecer uma camada única de abstração sobre todos os seus bancos de Dados. Como exemplo, imagine um único comando SELECT que reúna o relacionamento entre uma tabela de um banco Oracle e uma outra de um banco MySQL, mas na perspectiva do desenvolvedor a integração entre dois bancos é encapsulada. Soluções como estas já existem no mercado;A Red Hat adquiriu em 2007 uma empresa chamada ...
    Quer ler esse conteúdo completo? Tenha acesso completo