Uma das questões mais importantes a serem avaliadas numa solução de ESB é o quanto ele te possibilita seu uso e administração com a menor curva de especialização possível. Isso se dá porque um ESB é um padrão arquitetural para integração que deve ser agnóstico de tecnologia, e portanto, o uso do mesmo não deve implicar no conhecimento de tecnologias ou plataformas específicas.
Existem ESB's muito bons no mercado que possibilitam este tipo de coisa, e a maioria deles o fazem com o auxilio de ferramentas visuais de administração e desenvolvimento que escondem a complexidade da plataforma, tornando a vida do usuário do ESB mais simples. Bom, o quanto isso é interessante para quem administra e desenvolve em cima de ESB's? Olhando pelo lado da produtividade, este pode ser um ponto muito importante pois você rapidamente pode "sair fazendo" sem a pré-condição do domínio prévio do produto. Entretanto, isso é ruim em termos de flexibilidade pois você acaba preso a tudo aquilo que a ferramenta visual te deixa fazer.
Isso significa perda de flexibilidade. Se você quiser fazer algo que vá mais além do que os recursos que a ferramenta suporta, você terá que "abrir a caixa" e meter a mão na massa. E muitas das vezes, alguns produtos nem suportam a abertura da caixa. Neste caso, é preciso balancear corretamente o que é mais importante no ESB, se é a certeza de que ele fará (não importa como) o que ele diz que faz e ter fé, ou ter uma ferramenta que possibilite a criação de soluções de forma flexível mas também sem precisar conhecer os detalhes "técnicos" do ESB. Eu particularmente sou a favor da segunda opção.
Tendo trabalhado com alguns dos melhores ESB's do mercado, observo que cada um deles têm pontos que são muito interessantes, mas são exatamente os pontos que os deixam "amarradões". Para resolver este problema, é preciso que a solução de ESB lhe facilite sim certas coisas, mas sem deixar com que você fique com as mãos presas nas costas. É preciso poder mostrar o caminho, mas um caminho que seja simples de atravessar, e que não crie dependências em sua solução. Três dos melhores ESB's que pude ver que possibilitam este tipo de coisa é o JBoss ESB, AquaLogic e Sonic ESB. Todos eles, possuem ferramentas interessantes para criação de soluções de EAI e serviços, mas em um dado momento, todas elas possibilitam que o trabalho seja feito usando apenas o mínimo que um arquiteto de integração deve conhecer: XML!
Neste post, irei mostrar um pouco deste poder criando passo a passo, um web service do tipo Hello World no JBoss ESB. A grande sacada é que não iremos escrever nenhuma linha de código Java para isso. O JBoss ESB é normalmente criticado por ser um ESB "muito atrelado a coisas de JEE", e com este post, iremos provar que isso não é verdade, como é o caso também do Sonic e AquaLogic ESB. Ao final do exemplo, você verá que com um módulo de apenas 3K de tamanho, teremos um endpoint SOAP hospedado no JBoss ESB funcional e operante.
1) Crie um módulo ESB para acomodar os arquivos do projeto
A primeira coisa a se fazer é criar um projeto novo no JBoss ESB. Para isso, basta criar um projeto novo usando qualquer ferramenta que possa criar arquivos e diretórios. O post Integração de Aplicações usando o JBoss ESB pode ajuda-lo a entender um pouco da estrutura de projetos no JBoss ESB. Feito isso, podemos partir para a parte da configuração dos canais de mensagem usados pelo serviço. A figura abaixo mostra a estrutura do projeto final depois de todas as configurações.
2) Crie os canais de mensageria usados pelo serviço
Segue abaixo a configuração do arquivo queue-service.xml que define todas as filas usadas para o processamento das mensagens enviadas ao serviço, e as mensagens geradas pelo serviço para o consumidor (cliente) do mesmo.
3) Crie arquivos XML Schema para definição do contrato do seu serviço
Todo serviço precisa de um contrato. O contrato é todo mecanismo usado para especificar como será dado a troca de informações entre o provedor do serviço e o seu respectivo consumidor (ou grupo de consumidores). No contrato, é definido que informações devem ser passadas para o serviço para que ele faça o que ele se propôe a fazer, bem como que informações esperar do serviço depois de passar as informações necessárias.
Ums serviço é uma unidade lógica e coesa sobre um determinado assunto. Neste caso, a melhor forma de pensar num serviço é num conjunto pequeno e coeso e operações correlatas sobre um determinado domínio. A coesão, granularidade e politicas são fatores importantes a serem considerados no desenho de serviços, mas iremos abordar este assunto em outros posts mais focados no assunto. A propósito, estarei abordando este assunto bem como governança em SOA nas próximas edições da revista Mundo Java, portanto, fique atento as novidades da revista.
No caso do nosso serviço Alô Mundo, iremos definir o contrato das operações de entrada e saída do serviço. Ele terá apenas uma operação chamada 'hello' que irá receber o primeiro e ultimo nome de uma pessoa, e irá responder com uma mensagem simpática contendo o primeiro e ultimo nome passado como argumentos. A listagem abaixo mostram os arquivos XML Schema de definição dos tipos de entrada e saída do serviço, respectivamente.
4) Configure seu módulo ESB com as definições do serviço e contratos
Agora que temos definido os contratos do serviço, é hora de realizar a especificação do serviço em si. Para isso, edite o arquivo META-INF/jboss-esb.xml conforme mostrado na listagem abaixo.
Repare na listagem que existem algumas coisas interessantes e novas pra quem já usa o JBoss ESB. A primeira coisa é que não precisamos definir que o listener do serviço é gateway. Para usuários novos do JBoss ESB, um gateway é a definição de que nosso serviço irá responder para o "mundo externo" através daquele canal de mensageria. Usando o recurso de contracts do JBoss ESB 4.5, podemos facilmente criar web services a partir de qualquer serviço previamente criado no módulo ESB.
A segunda coisa que nota-sa na listagem é que na TAG actions, informamos qual é os arquivos de XML Schema que definem o contrato do serviço. Essa é uma prática interessante para todos os serviços, pois por padrão, todo serviço interno do JBoss ESB possue uma propriedade chamada 'webservice' cujo valor padrão é true. Neste caso, todo serviço do JBoss ESB é em ultima análise um web service. Se você não quiser que um serviço seja exposto como um endpoint SOAP, basta definir 'explicitamente' na TAG actions o atributo webservice como false.
Nosso serviço está pronto pra uso. Vamos passar agora a parte mais interessante: Definir a lógica do serviço sem precisar escrever nenhuma linha de código Java. Digo que isso é interessante pois é um recurso poderoso de um ESB possibilitar este tipo de coisa, mas não ache que escrever código Java para a lógica de um serviço seja algo errado; de fato, em alguns casos, pode ser uma opção bem sensata se por exemplo seu serviço tiver premissas de desempenho críticas. XML é um recurso poderoso para configuração e definição de lógicas, mas é pesado em termos de processamento. Dito isso, considere a escrita de lógicas em XML uma prática interessante mas não imperativa.
5) Crie a lógica do serviço usando apenas transformação de mensagens XML
Para a lógica deste serviço, iremos usar o recurso de Smooks do JBoss ESB. A listagem abaixo mostra como deve ser configurado o arquivo META-INF/smooks-logic.xml.
Na listagem, fizemos a leitura do XML que é enviado pelo consumidor (notamente, um post contendo um XML no padrão SOAP) e gravamos as informações lidas no contexto do Smooks. Feito isso, usando o recurso de FreeMarker (recurso integrado do Smooks), definimos o template do XML que deverá ser enviado de volta para o consumidor em resposta ao pedido de execução. A resposta, é baseada no XML Schema de saída da operação hello, e deve respeitar as regras de definição impostas no arquivo META-INF/helloOutput.xsd.
Uma forma de garantir que o XML definido no template criado está de acordo com o contrato que foi definido via XML Schemas, é usar o atributo validate na TAG actions do seu serviço. O valor padrão deste atributo é false, indicando que uma validação do conteúdo da resposta não será validado junto ao XML Schema. Mas é interessante habilitar este atributo em tempo de desenvolvimento do serviço, para garantir o reforço do contrato, um dos fatores mais importantes na orientação a serviços.
6) Faça o deploy do seu módulo no JBoss ESB e realize um teste!
Simples assim! Nosso serviço está pronto. Crie um módulo ESB deste projeto (um arquivo cuja estensão seja .esb) e faça a instalação do módulo no JBoss ESB. Depois disso, inicie seu servidor e você poderá realizar testes de acesso ao seu serviço. Você com certeza irá perguntar algo óbvio: Mas e o WSDL deste serviço, como tenho acesso para passar aos meus clientes? Bom, você pode fazer isso de duas formas: Acessando a geração dinâmica do WSDL. Para isso, acesse o seguinte endereço:
E você terá acesso ao WSDL do serviço Alô Mundo que acabamos de criar. Repare que a URL foi montada baseado nas informações do nome do módulo ESB criado, bem como as informações da categoria e nome de serviço definido no arquivo META-INF/jboss-esb.xml.
A segunda forma de recuperar o WSDL do serviço, é acessar o WSDL que é gerado automaticamente pelo JBoss ESB. Todo serviço possui um WSDL gerado na seguinte pasta:
$JBOSSESB_HOME$/server/default/data/wsdl
Procure pelo seu projeto ESB criado, ele deverá estar nesta pasta depois que você iniciar seu JBoss ESB. Recuperado o WSDL do seu serviço, você pode facilmente construir clientes para testes do seu serviço. Uma boa ferramenta para testes é o soapUI. Na edição 34 da revista Mundo Java, escrevi um artigo que mostra passo a passo como construir um web service no JBoss ESB (usando uma abordagem baseada em Java + XML) e testar na ferramenta soapUI. Vale a pena conferir!
Boas Integrações ;-)
