Spring Integration. Saiba como desenhar uma solução completa utilizando padrões EAI com o Spring Integration

Transcrição

1 capa_ Aplicando padrões EAI com Spring Integration Saiba como desenhar uma solução completa utilizando padrões EAI com o Spring Integration Giuliano Bem Hur Firmino giulianofirmino@yahoo.com.br especialista em Engenharia de Software pelo Instituto da Computação da Unicamp e certificado pela Sun (SCJP). Atua na área de desenvolvimento de softwares há 12 anos. Com a plataforma JAVA nos ambientes Web, Mobile e Enterprise. Aplicações raramente vivem isoladas, normalmente são desenvolvidas para se comunicar com outras aplicações, banco de dados, sistemas de mensagem, sistemas legados e até mesmo com redes sociais. Como lidar com os desafios que essas integrações oferecem? EAI propõe uma forma abstrata e prática de lidar com esses desafios, através de padrões. E o Spring Integration se propõe a implementar esses padrões de forma simples, sem a necessidade de grandes mudanças no processo de desenvolvimento. 5 \

2 EAI (Enterprise Application Integration) O termo EAI já existia dede o início de 2000, mas o problema que ele se propõe a resolver é muito antigo, vem desde os primórdios da computação, quando nos deparamos com a necessidade de fazer aplicações se comunicarem. Podemos resumir a integração entre uma aplicação e outra como uma conversa. Se ela não for conduzida em uma determinada linguagem e em um determinado padrão, o que chamamos protocolo de comunicação, não há diálogo. Hoje temos basicamente as seguintes formas de comunicação entre aplicações: File Transfer: aplicações transferem ou disponibilizam, em local comum, arquivos para que outras aplicações possam ler. Shared Database: aplicações acessando um ou mais banco de dados em comum, com intuito de compartilhar informações. Remote Procedure Call: aplicações acessando outras aplicações através de chamadas remotas. Abrangendo diversas tecnologias, como CORBA, RMI e WebService. Messaging: aplicações enviando mensagens a outras aplicações. Em uma arquitetura empresarial, tende a existir diversos sistemas e aplicações, para atender a diversos departamentos e serviços que uma empresa pode oferecer e consumir. É muito comum que todos esses recursos estejam distribuídos dentro da organização. No entanto para obter os benefícios desse tipo de distribuição, é necessário se preocupar com a forma com que essas aplicações se integram. Hoje temos os seguintes tipos de integrações entre aplicações. Point-to-Point: neste tipo de integração as conexões são feitas de forma direta. A vantagem é que o mesmo atende bem necessidades pontuais, dentro de uma arquitetura pequena. A desvantagem ocorre quando queremos aumentar o número de aplicações participantes, neste caso, temos um aumento exponencial do número de conexões. Veja um exemplo na figura 1. Hub and Spoke: todas as aplicações se comunicam através de um mediador e é esse mediador que se comunica com as outras aplicações. A vantagem é que todas aplicações se convergem em uma só conexão, simplificando a manutenção e o gerenciamento das conexões. A desvantagem é justamente pelo fato de centralizar todas as conexões, pois quando o serviço fica indisponível, todas as aplicações sofrem com isso. Veja um exemplo na figura 2. Figura 2. Tipo de integração Hub and Spoke. Diferentemente do que parece, EAI não trabalha diretamente com nenhum dos tipos de integrações mencionados acima, tão pouco atende especificamente a alguma forma de comunicação existente. EAI possui simplesmente uma notação genérica e baseada em padrões. Cada framework/ferramenta/ plataforma implementa a especificação de EAI da forma que lhe convir. Existe um padrão dentro da especificação EAI, por exemplo, chamado Message Bus que visa representar uma boa prática de integração entre aplicações (Hub and Spoke, mencionado anteriormente), veja como funciona o mesmo na figura 3. Esse padrão foi responsável pelo surgimento de diversas interpretações, nomeadas de ESB (Enterprise Service Bus). application application message bus application Figura 1. Tipo de integração Point-to-Point. Figura 3. Exemplo de funcionamento do padrão Message Bus. / 6

3 data message message channel message data endpoint endpoint sender application receiver application Figura 4. Elementos básicos da notação EAI. O Framework Spring Integration Spring Integration é uma extensão do Spring (framework de inversão de controle) que possibilita a utilização da notação EAI de forma declarativa e/ou programática. O mesmo disponibiliza uma interface de integração com os adaptadores do Spring, abstraindo a complexidade de acessar vários tipos de plataformas, sistemas, tecnologias e protocolos como HTTP, TCP/ UDP, Banco de Dados, Arquivos, FTP, RMI, JMS, e- -mail, até a redes sociais, como Twitter, possibilitando ainda reaproveitar e acessar outros tipos de recursos externos através de serviços customizados. No Spring Integration podemos observar os seguintes elementos para utilização de EAI, acompanhando na figura 4. Data: representa os dados a serem processados. Message: no Spring Integration, é formada por Header (cabeçalho) e Payload (corpo) conforme a ilustração da figura 5. No Header podemos trafegar informações adicionais que serão usadas para tomada de decisões no fluxo, e no corpo estão os dados propriamente ditos. message header payload Figura 5. Estrutura da mensagem. Message channel: é o canal de comunicação de mensagens. Um canal possui duas pontas, por onde as mensagens trafegam: Entrada: por onde os produtores enviam as mensagens. Saída: por onde os receptores conseguem resgatar as mensagens enviadas pelos produtores. Os canais ainda podem ser categorizados de duas formas: Handoff: que podem ser síncronos, ou seja, a mensagem é recebida diretamente pelo receptor. Ou assíncronos, ou seja, a mensagem é armazenada no canal antes de ser enviada ao receptor. Delivery: que podem ser point-to-point, ou seja, um produtor envia uma mensagem diretamente para um receptor ou publish- -subscribe, onde um produtor envia uma mensagem e N receptores podem se inscrever para receber a mesma mensagem. Message Endpoints: são todos os componentes que efetivamente sabem receber/manipular/enviar as mensagens. São divididos basicamente em Gateway, Sevice Activator, Router, Splitter e Aggregator. Os mesmos serão detalhados no decorrer da explicação da implementação do projeto de exemplo a seguir. Diferentemente de muitas das soluções de mercado, Spring Integration não é considerado um ESB, pois não é baseado no padrão Message Bus. Mas por se tratar de um framework robusto, provê uma boa base para implementação do mesmo. Projeto de exemplo Meu intuito é mostrar não só os padrões EAI e como utilizá-los no Spring Integration, mas um exemplo prático e funcional de aplicação dos principais padrões de integração em um cenário fictício, mas suficientemente complexo que será explorado abaixo. História Grandes empresas varejistas e atacadistas ainda aceitam um grande volume de cheques diariamente de seus clientes. O banco Sua Poupança vendo um nicho de mercado ainda pouco explorado, decide criar um novo produto e atrair esses clientes. Sabendo do trabalho que estas empresas têm em depositar esse grande volume de cheques, decide criar um processo que facilite este trabalho. 7 \

4 Problema Para atender essa quantidade de cheques, hoje o banco conta com profissionais que avaliam um a um os cheques os separando e os enviando através de malotes para os respectivos bancos. Esse processo é lento e também envolve a burocracia do banco de destino. Ao final o banco de destino envia os dados confirmando o débito na conta do cliente. O tempo total do depósito do cheque gira em torno de 5 dias. Solução de negócio Esses cheques são na grande maioria preenchidos por impressoras nos caixas, por isso são passíveis de serem lidos sem a necessidade de intervenção humana. Para a leitura automática dos cheques, foram encontradas várias opções de impressoras que conseguem processar centenas de cheques por minuto, gerando imagens de qualidade e capturando dados via OCR. Essas impressoras seriam disponibilizadas para os clientes para que os mesmos possam enviar mais rapidamente as imagens e os dados dos cheques através de um serviço a ser disponibilizado para o mesmo. Este serviço por sua vez, agruparia os cheques por banco e os enviaria aos bancos que já possuem uma política de recebimento de cheques digitalizados. A previsão é que o tempo do depósito de cheques desses clientes caia para 2 dias. Solução técnica Esse processo é um tanto complexo, pois envolve integração com várias tecnologias, então a equipe de negócio pede a equipe de Arquitetura que desenhe a solução e escolha a melhor forma de resolver o problema. Em uma reunião, a equipe de arquitetura chegou a conclusão que seriam necessárias duas aplicações, para atender a solução. A figura 6 mostra o diagrama de arquitetura levantado. 1. Uma aplicação Desktop que irá capturar as imagens scaneadas e dados extraídos dos cheques, através do OCR presente no scanner de cheques. Esses cheques formarão um lote a ser enviado ao serviço Web a ser desenvolvido. Um lote pode possuir N cheques e depende da capacidade do scanner de cheques. 2. Serviço Web que irá separar os cheques e enviá-los a seus respectivos bancos de destino. Os únicos bancos que possuem serviços que recebem e processam cheques digitalizados é o Banco do Povo e o Banco de Todos. O Banco do Povo disponibiliza um servidor FTP para enviar os dados e as imagens dos cheques e o Banco de Todos disponibiliza um servidor de filas para enviar os dados via remessa, com todas as imagens e informações dos cheques. O serviço precisará acessar um componente EJB que está em outro servidor, para buscar informações do cliente (beneficiário) uma vez que só será enviado o código do mesmo. Para desenvolver o serviço Web, foi optado pelo framework Spring Integration e para chegar nessa decisão, foram considerados os seguintes critérios:» A integração deve ser feita de forma menos trabalhosa e mais flexível possível, uma vez que as tecnologias podem mudar, o número de clien- Figura 6. Diagrama de arquitetura da solução. / 8

5 tes pode aumentar e, no futuro, o número de bancos atendidos também pode aumentar. Ser open-source, pois há um risco de investir em ferramenta e treinamento e a solução não ter o retorno esperado. Desenvolver uma versão piloto no menor tempo possível, pelo mesmo motivo do item anterior. Aproveitamento da equipe de desenvolvimento, pelo mesmo motivo do item anterior. Aproveitar a infraestrutura já existente, pelo mesmo motivo do item anterior. Configuração de Ambiente Maven Plugin do eclipse Maven Integration for Eclipse Plugin do eclipse Spring Tool Suite for Eclipse Criando o projeto Crie um novo workspace. Clique com botão direito e selecione New > Other.... Selecione Maven > Maven Project e clique em Next >. Em New Maven Project, Select project name and location, marque a opção Create a single project (skip archetype selection) e clique em Next >. Em New Maven Project, Enter a group id and the artifact, preencha os campos Group Id e Artifact Id, selecione war em Packaging e clique em Finish. Configurando o projeto No projeto dentro da pasta src/main/webapp, crie a pasta WEB-INF e em seguida o arquivo web.xml. Como nosso projeto disponibilizará um serviço Web, devemos criar o arquivo web.xml que ficaria conforme a Listagem 1. Por se tratar de um projeto Spring não poderia faltar o arquivo de configuração do mesmo, veja na Listagem 2 o básico para o projeto funcionar. Iremos explicar a configuração do arquivo spring-integration.xml no decorrer da explicação. No arquivo pom.xml adicione a dependência conforme a Listagem 3, para que o projeto funcione com o Spring MVC, Spring Integration e como o serviço será um REST, usamos o JAXB que faz os parses de Objeto Java para XML e vice-verça, através da extensão O/X Mappers do Spring. Listagem 1. Arquivo web.xml. <?xml version= 1.0 encoding= UTF-8?> <web-app...> <servlet> <servlet-name>dispatcher-servlet</servlet-name> <servlet-class>org.springframework.web.servlet. DispatcherServlet</servlet-class> <init-param> <param-name>contextconfiglocation </param-name> <param-value> classpath:application-context.xml </param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcher-servlet</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> </web-app> Listagem 2. Arquivo application-context.xml. <beans xmlns= schema/beans xmlns:xsi= XMLSchema-instance xmlns:context= xsi:schemalocation= schema/beans beans/spring-beans.xsd org/schema/context context/spring-context.xsd > <context:component-scan base-package= mundoj.springintegration /> <import resource= spring-integration.xml /> </beans> Listagem 3. Arquivo pom.xml. <dependency> <groupid>org.springframework.integration</groupid> <artifactid>spring-integration-core</artifactid> <version>${spring.integration.version</version> </dependency> <dependency> <groupid>org.springframework</groupid> <artifactid>spring-webmvc</artifactid> <version>${spring.version</version> 9 \

6 </dependency> <dependency> <groupid>javax.servlet</groupid> <artifactid>servlet-api</artifactid> <version>${servlet-api.version</version> </dependency> <dependency> <groupid>org.springframework</groupid> <artifactid>spring-oxm</artifactid> <version>${spring.version</version> </dependency> Explicação do fluxo Para desenhar o fluxo, foi optada pela utilização da forma declarativa, ou seja via XML, pois o plugin Spring Tool Suite consegue exibi-lo facilmente na forma gráfica, facilitando a geração de documentação. Como nosso foco é mostrar o funcionamento dos padrões EAI, para explicar o fluxo, omitiremos alguns padrões que se repetem ao longo da solução. Para facilitar a explicação os padrões foram enumerados, conforme pode ser visto na figura 7. Ao receber uma notificação HTTP, o Spring através do Servlet org.springframework.web.servlet. DispatcherServlet registrado no web.xml, repassa a requisição para o Spring Integration, no caso, chamando o primeiro elemento do fluxo a ser explicado, o padrão Gateway. Gateway É um padrão de adaptação, disponibilizando conexão a algum recurso de entrada (inbound) ou saída (outbound). Este padrão repassa a mensagem ao recurso adaptado e então fica esperando uma resposta, conforme pode ser observado na figura 8. Ainda pode atender a diversos formatos, como HTTP, TCP/ UDP, FTP, Feed (RSS), JDBC, JMS, JMX, JPA, Arquivos e muitos outros. No nosso exemplo o Gateway é de entrada e representa uma chamada HTTP, veja como ficou a configuração do mesmo na forma declarativa na Listagem 4. Como é um serviço web para representar o endereço a ser disponibilizado, utilizamos a propriedade name. Podemos também estipular o tipo de entrada através da propriedade request-payload, no caso, enviamos um XML no corpo da mensagem e como a Classe mundoj.springintegration.to.lote está mapeada utilizando anotações da biblioteca Jaxb, o Spring Integration se encarrega de fazer a conversão sem a necessidade de código algum. Além dos canais de entrada e saída, configurados através das propriedades request-channel e reply-channel, respectivamente, e o canal onde os erros que ocorrem no fluxo serão encaminhados error-channel. Listagem 4. Exemplo de configuração do padrão Gateway. <int- request-channel= inputchannel reply-channel= outputchannel name= /lote supported-methods= POST request-payload-type= mundoj.springintegration.to.lote error-channel= errorchannel /> Figura 7. Modelagem do fluxo da solução baseada nos padrões EAI. GatEway GatEway application a output application b output Figura 8. Funcionamento do padrão Gateway. / 10

7 Channel O segundo padrão é o Channel. No exemplo de configuração da Listagem 5, utilizamos o canal de comunicação DirectChannel que é uma implementação síncrona e do tipo point-to-point. Este é o canal mais simples suportado pelo Spring Integration, por isso não exige qualquer configuração especial, simplesmente um id para identificar o mesmo. Por padrão esse tipo de canal implementa um balanceamento de carga que é baseado em uma abordagem round-robin, ou seja, se existirem mais de um receptor acoplado ao canal as mensagens serão repassadas de forma rotativa. Um recurso também interessante a ser mencionado no balanceamento de carga, é a configuração do atributo failover como true, neste caso se o receptor que está atendendo uma mensagem emitir uma exceção, a mensagem é repassada automaticamente ao receptor subsequente. Ainda no balanceador é possível estabelecer a ordem de execução dos receptores através da propriedade order, configurada em cada receptor. Listagem 6. Exemplo de configuração do padrão Filter. <int:filter input-channel= lotechannel output-channel= lotevalidochannel ref= lotefilter method= filtrar /> Listagem 7. Exemplo de implementação do padrão public class LoteFilter { public boolean filtrar(final Lote lote) { checkargument(lote.getnumerolote()!= null, Numero do lote não pode ser vazio ); checkargument(lote.getbeneficiario()!= null, Código do beneficiário não pode ser vazio ); checkargument(lote.getcheques()!= null &&!lote.getcheques().isempty(), A lista de cheques não pode ser vazia ); Listagem 5. Exemplo de configuração do padrão Channel. <int:channel id= inputchannel /> //... return true; Filter É responsável por decidir se a mensagem deve continuar no fluxo ou ser descartada, conforme ilustrado na figura 9. Também é muito simples de ser implementado, exigindo um canal de entrada input- -channel e um canal de saída de mensagens output- -channel, conforme pode ser observado na Listagem 6. Além disso, é necessário indicar uma implementação através do atributo ref e method, ou mesmo passar uma expressão de decisão do tipo SpEL (Spring Expression Language). A implementação pode ser vista na Listagem 7, no caso, estamos apenas validando os campos obrigatórios para que a mensagem possa ser processada sem erros. Note a presença da responsável por mapear os Endpoints do Spring Integration como beans do Spring. Service Activator Este padrão é similar ao padrão de programação orientada a objeto Delegate que simplesmente tem a função de delegar chamadas, conforme pode ser observado na figura 10. Conforme pode ser visto na Listagem 8, além dos canais de entrada e saída, através das propriedades input-channel e output- -channel, respectivamente, o Service Activator necessita também do bean a ser chamado através da propriedade ref e o método propriedade method. No lugar do bean, podemos utilizar uma expressão SpEL, quando queremos executar uma operação mais simples, como uma operação aritmética, por exemplo. Em isolado, seria necessário configurar o canal de entrada e saída, com as propriedades input-channel e output-channel, respectivamente. widget quote gadget quote widget quote widget quote widget quote message filter Figura 9. Funcionamento do padrão Filter. 11 \

8 A implementação do mesmo pode ser analisada na Listagem 9, onde simplesmente chamamos um serviço EJB, mapeado como beneficiarioservice (veja configuração na Listagem 10, no nosso exemplo, estamos utilizando o OpenEJB e o MockEJB), mas o serviço poderia ser outro recurso, como, uma chamada a um programa Mainframe, ou simplesmente a um POJO. Note que estamos trabalhando com uma mensagem que contém um Lote é importante trabalhar desta forma, pois apesar do Spring Integration cuidar de criar uma mensagem de saída. Às vezes, queremos por exemplo, adicionar informações ao Header da mensagem, mas o Spring Integration, não deixa você simplesmente adicionar uma informação no Header, para isso, devemos criar um novo Header, que encapsula o original, adicionar a nova informação, no caso, o objeto Beneficiario, retornado pelo serviço e utilizar a classe utilitária MessageBuilder para gerar uma nova mensagem. Listagem 8. Exemplo de configuração do padrão Service Activator. <int:service-activator input-channel= lotevalidochannel output-channel= lotebeneficiariochannel ref= beneficiarioserviceactivator method= consultar /> Listagem 9. Exemplo de implementação do padrão Service public class BeneficiarioServiceActivator private BeneficiarioService beneficiarioservice; public Message<Lote> consultar(final Message<Lote> message) { Integer codigobeneficiario = message. getpayload().getbeneficiario(); Beneficiario beneficiario = beneficiarioservice. obterporcodigo(codigobeneficiario); if (beneficiario == null) { throw new BeneficiarioInvalidoException( String.format( Beneficiário %d inválido, codigobeneficiario)); Map<String, Object> headers = Maps.newHashMap (message.getheaders()); headers.put( beneficiario, beneficiario); return MessageBuilder.withPayload( message.getpayload()).copyheaders(headers). build(); Listagem 10. Configuração do EJB BeneficiarioService. requestor request reply service activator replier Figura 10. Funcionamento do padrão Service Activator. service <jee:remote-slsb id= beneficiarioservice jndi-name= java:openejb/ejb/beneficiarioservice business-interface= mundoj.springintegration.ejb.service.beneficiarioservice /> Content Enricher Este padrão representa uma ação de enriquecimento do conteúdo da mensagem, conforme podemos observar na figura 11. O Spring Integration possui duas variações desse padrão: header-enricher: enriquece apenas o Header da mensagem, podemos ver um exemplo na Listagem 10. Para configurá-lo são necessários os canais de entrada e saída e as informações a serem adicionadas ao Header. No nosso exemplo, é informado o correlation-id que será utilizado no padrão Aggregator a ser explicado mais a frente. Mas podemos ser mais genéricos utilizando a tag header, passando o nome a ser utilizado, através da propriedade name e o valor, propriedade value. enricher: enriquece apenas o Payload. Nele po- / 12

9 basic message demos atribuir propriedades do objeto contido no Payload, através da tag property e das propriedades name, expression ou value, para atribuir seus valores. enricher Figura 11. Funcionamento do padrão Content Enricher. enriched message Listagem 10. Exemplo de configuração do padrão Content Enricher. <int:header-enricher input-channel= lotebeneficiariochannel output-channel= lotebeneficiarioenriquecidochannel > <int:correlation-id expression= payload.numerolote /> </int:header-enricher> Splitter Como o próprio nome diz, ele é responsável por dividir a mensagem em N mensagens, conforme pode ser observado na figura 12. Sua configuração é simples, bastando fornecer os canais de entrada e saída, através das propriedades input-channel e output- -channel, assim como o bean e seu método a ser chamado, através das propriedades ref e method, conforme é mostrado na Listagem 11. A complexidade da sua implementação dependerá da função do mesmo no fluxo, no nosso caso, como pode ser observado na Listagem 12, temos como entrada um lote e queremos retornar todos os cheques para serem processados individualmente. Note que criamos a classe QuantidadeCheques que será utilizada como contador de cheques. Essa contagem de cheques é feita por banco e será utilizada pelo agrupador de cheques, a ser explicado mais a frente, necessário para enviar informações ao Banco de todos mais especificamente. Listagem 11. Exemplo de configuração do padrão Splitter. <int:splitter input-channel= lotebeneficiarioenriquecidochannel output-channel= chequeschannel ref= lotesplitter method= split /> Listagem 12. Exemplo de implementação do padrão public class LoteSplitter { public Collection<Message<Cheque>> split(message<lote> message) { Collection<Cheque> cheques = message.getpayload().getcheques(); Map<String, Object> headers = Maps.newHashMap( message.getheaders()); for (Cheque cheque : cheques) { String chavechequebanco = String.format( CHEQUES_BANCO_%d, cheque.getbanco()); if (headers.containskey(chavechequebanco)) { QuantidadeCheques quantidade = (QuantidadeCheques) headers.get(chavechequebanco); quantidade.incrementar(); else { headers.put(chavechequebanco, new QuantidadeCheques()); Collection<Message<Cheque>> messages = Lists.newArrayList(); for (Cheque cheque : cheques) { messages.add( MessageBuilder.withPayload(cheque). copyheaders(headers).build()); return messages; splitter order item 1 order item 2 order item 3 new order Figura 12. Funcionamento do padrão Splitter. 13 \

10 Router É um padrão de decisão e desvio de fluxo, onde a mensagem que é recebida pode ser enviada para determinado canal, através da satisfação de determinada condição, conforme podemos acompanhar na ilustração da figura 13. Para facilitar, o Spring Integration provê uma série de variações desse padrão. Todas essas variações seguem a mesma estrutura, tendo pequenas mudanças entre uma e outra abordagem. Basicamente, precisamos configurar um canal de entrada, propriedade input-channel e um canal para condições não mapeadas, se necessário, neste caso pela propriedade default-output-channel. Os mapeamentos de desvios também devem possuir um canal mapeado, propriedade channel. Seguem as implementações disponíveis: payload-type-router: onde é possível, através do tipo do dado contido no Payload da mensagem, estipular o caminho que a mensagem deve seguir. header-value-router: possibilita rotear uma mensagem através das informações contidas no Header da mensagem. recipient-list-router: decisão através de expressões que podem ser referentes tanto ao Header como ao Payload da mensagem. exception-type-router: permite executar o roteamento da mensagem que contenham uma exceção encapsulada. router: permite criar uma implementação customizada de um roteador. Se quiser utilizar o plugin do Spring para gerar o diagrama, não é aconselhável a utilização de um bean para essa variação, pois não permite ao Spring Integration saber de imediato, quais serão os caminhos a serem tomados, quebrando o gráfico. Neste caso, aconselho recuperar as informações em uma etapa anterior, ficando somente uma expressão ou valor para a decisão de roteamento, como no exemplo da Listagem 13. Listagem 13. Exemplo de configuração do padrão Router. <int:router input-channel= chequeschannel expression= payload.banco > <int:mapping value= 341 channel= chequesbancodopovochannel /> <int:mapping value= 237 channel= chequesbancodetodoschannel /> </int:router> Wire Tap Padrão responsável por copiar uma mensagem de um canal e repassá-la a outro canal, conforme podemos acompanhar na figura 14. Isto é muito útil quando queremos monitorar as mensagens de um canal, ou até mesmo fazer outro processamento em paralelo com a mesma mensagem, como é o caso do nosso fluxo. Podemos observar na Listagem 14 que estamos utilizando a tag interceptors dentro da tag channel para interceptar a mensagem e a tab wire-tap para copiar a mesma. source wire tap Figura 14. Funcionamento do padrão Wire Tap. destination outqueue 1 inqueue outqueue 2 message router Figura 13. Funcionamento do padrão Router. / 14

11 Listagem 14. Exemplo de configuração do padrão Wire Tap. <int:channel id= chequesbancodopovochannel > <int:interceptors> <int:wire-tap channel= chequesbancodopovowirechannel /> </int:interceptors> </int:channel> Aggregator Se trata de um agrupador de mensagens, conforme mostrado na figura 15. Ao contrário do padrão Splitter que divide as mensagens o Aggregator junta N mensagens. A sua configuração é simples de entender, conforme podemos notar na Listagem 15, além das típicas propriedades referentes aos canais de entrada e saída, o mesmo possui algumas propriedades específicas. Basicamente para que o Aggregator possa transmitir uma mensagem são necessários três passos a serem explicados abaixo: Estratégia de correlação: é a estratégia responsável por identificar quais mensagens serão consideradas no agrupamento. Por padrão o Aggregator utiliza a informação correlation-id presente no Header da mensagem. No nosso caso, o mesmo é configurado utilizando o padrão header-enricher e tomando como base o número do lote, conforme podemos constatar na Listagem 16. A mesma ainda pode ser implementada de forma mais sofisticada, utilizando as propriedades correlation-strategy, passando o bean que contém a estratégia, a propriedade correlation-strategy-method, contendo o método do bean de estratégia a ser chamado, ou simplesmente correlation-strategy-expression, contendo uma expressão SpEL. Estratégia de liberação: é responsável por identificar em que momento a mensagem está pronta para ser transmitida. No caso do fluxo, tivemos que implementar uma estratégia, a setando através das propriedades release-strategy e release-strategy-method. A implementação, pode ser avaliada na Listagem 17, no método verificar, onde simplesmente estamos verificando se a quantidade de cheques, até o momento, corresponde a quantidade de cheques do banco informada no Header da mensagem. Outra forma de implementar essa estratégia é através da propriedade release-strategy-expression. Estratégia de envio: efetivamente transmite a mensagem. A mesma só é acionada se as outras estratégias explicadas anteriormente forem verdadeiras. Para utilizá-la, basta setarmos o bean e o método nas propriedades ref e method. Veja na Listagem 17, no método enviar que estamos juntando as mensagens em um novo lote. Esse lote é referente a um banco e um número de lote. Como todas as mensagens contêm as mesmas informações no Header, então estamos o copiando, da primeira mensagem. Listagem 15. Exemplo de configuração do padrão Aggregator. <int:aggregator input-channel= chequesbancodetodoschannel output-channel= lotebancodetodoschannel ref= chequeaggregator method= enviar release-strategy= chequeaggregator release-strategy-method= verificar /> Listagem 16. Exemplo de configuração da Estratégia de correlação do padrão Aggregator. <int:header-enricher input-channel= lotebeneficiariochannel output-channel= lotebeneficiarioenriquecidochannel > <int:correlation-id expression= payload.numerolote /> </int:header-enricher> inventory item 1 inventory item 2 inventory item 3 aggregator inventory order Figura 15. Funcionamento do padrão Aggregator. 15 \

12 Listagem 17. Exemplo de implementação do padrão public class ChequeAggregator { public boolean verificar( Collection<Message<Cheque>> messages) { Message<Cheque> primeiramensagem = messages.iterator().next(); String chavechequebanco = String.format( CHEQUES_BANCO_%d, primeiramensagem.getpayload().getbanco()); QuantidadeCheques quantidadecheques = ((QuantidadeCheques) primeiramensagem.getheaders(). get(chavechequebanco)); return messages.size() == quantidadecheques. getvalue(); public Message<Lote> enviar(final Collection<Message<Cheque>> messages) { Map<String, Object> header = Maps.newHashMap(messages.iterator(). next().getheaders()); Lote lote = new Lote(); lote.setcheques(lists.<cheque>newarraylist()); for (Message<Cheque> message : messages) { lote.getcheques().add(message.getpayload()); return MessageBuilder.withPayload(lote). copyheaders(header).build(); translator Message Translator Esse padrão tem uma função bem simples, transformar mensagens. Ou seja, a mensagem produzida é a mensagem que foi utilizada, mas em outro formato, conforme pode ser observado na figura 16. Por exemplo, entra um objeto Java e sai um objeto Serializado / JSON / XML ou vice-versa. Normalmente utilizado, para adaptar os tipos internos as chamados de aplicativos externos. No nosso fluxo, é utilizado principalmente para atender aos tipos exigidos pelos bancos, supondo que devemos enviar mensagens para uma fila no Banco De Todos em formato XML, temos que fazer uma transformação do objeto interno Lote, para esse XML, já para o Banco do Povo por se tratar de um FTP, devemos converter o objeto em bytes a serem salvos como arquivos. Assim como o padrão Router existem algumas implementações prontas com intuito de facilitar a transformação de mensagens. Todas as variações possuem uma configuração similar, necessitando basicamente dos canais de entrada e saída. Abaixo uma listagem desses facilitadores: object-to-string-transformer: simplementes transforma o objeto em String, chamam o método tostring(). payload-serializing-transformer: serializa o objeto JAVA. payload-deserializing-transformer: deserializa o objeto JAVA. object-to-map-transformer: transforma o objeto em um Map. Esse map será formado por chave (atributo) e valor (valor do atributo). map-to-object-transformer: transforma um Map em um objeto, o inverso de object-to- -map-transformer. object-to-json-transformer: transforma o objeto JAVA em objeto JSON. json-to-object-transformer: transforma objeto JSON em objeto JAVA. transformer: é um transformador genérico. Se a transformação for simples basta montar uma expressão, utilizando a propriedade expression. Se for mais sofisticada, podemos definir um bean e método que irão executar a transformação, através das propriedades ref e method, respectivamente, conforme a configuração da Listagem 18. No exemplo, é transformado um objeto cheque interno para um cheque no formato específico do Banco do Povo, como pode ser constatado na implementação da Listagem 19. Listagem 18. Exemplo de configuração do padrão Message Translator. incoming message translated message Figura 16. Funcionameto do padrão Message Translator. <int:transformer input-channel= dadoschequebancodopovochannel output-channel= ftpbancodopovochannel ref= imagemchequeparabytestransformator method= transformar /> / 16

13 Listagem 19. Exemplo de implementação do padrão Message public class ChequeParaChequeBancoDoPovoTransformer { public Message<ChequeBancoDoPovo> transformar( final Message<Cheque> message) throws Exception { Cheque cheque = message.getpayload(); Beneficiario beneficiario = (Beneficiario)message.getHeaders(). get( beneficiario ); ChequeBancoDoPovo chequebancodopovo = new ChequeBancoDoPovo(); chequebancodopovo.setagenciabeneficiario( beneficiario.getagencia()); chequebancodopovo.setcontabeneficiario( beneficiario.getconta()); chequebancodopovo.setvalor(cheque.getvalor()); return MessageBuilder.withPayload( chequebancodopovo). copyheaders(message.getheaders()).build(); Chain O funcionamento do mesmo pode ser observado na figura 17. Ele não é mencionado dentre os padrões EAI, pois é simplesmente um facilitador, que o Spring Integration oferece, onde podemos ligar os Endpoints em sequência sem a necessidade de um canal para conectá-los, formando um elemento composto. Na Listagem 20, o utilizamos para agrupar dois Message Translators. Note que os Endpoints não indicam quais serão os canais de entrada e saída, pois os mesmo são definidos no Chain. chain /chain Figura 17. Exemplo de funcionamento do padrão Chain. Listagem 20. Exemplo de configuração do elemento Chain. <int:chain input-channel= lotebancodetodoschannel output-channel= jmsbancodetodoschannel > <int:transformer ref= lotepararemessabancodetodostransformer method= transformar /> <int:transformer ref= objetoparaxmltransformer method= transformar /> </int:chain> Channel Adapter É o padrão de adaptação responsável por prover uma conexão de entrada ou saída há algum recurso. Assim como o Gateway pode atender a diversos recursos diferentes. Basicamente a única diferença entre esses padrões é que o Channel Adapter não fica esperando a resposta, conforme pode ser visto na figura 18. No nosso fluxo, estamos utilizando adaptadores do tipo saída. Um, para acessar um servidor FTP e outro, para acessar uma fila de mensagens através de JMS, conforme pode ser acompanhado na Listagem 21. Para configurá-los, necessitamos basicamente de um canal setando a propriedade channel e então temos as configurações especiais para cada tipo de recurso acessado. No caso do servidor FTP, temos que estipular o bean SessionFactory (sua configuração pode ser vista na Listagem 22, no exemplo estamos utilizando o framework FakeFTP), através da propriedade session-factory, o separador de arquivos, propriedade remote-file-separator, se o diretório será criado automaticamente ou não, propriedade auto-create- -directory e o diretório remoto onde os arquivos serão criados, propriedade remote-directory-expression. A mensagem repassada a este adaptador deve encapsular três tipos: um array de bytes, uma String ou um tipo java.util.io.file. No caso, estamos criando dois tipos de arquivos, um de imagem que é gerado se utilizando do atributo imagem do Cheque e o outro é um XML do tipo ChequeBancoDoPovo. No caso da fila de mensagens com JMS, temos que apenas referenciar os beans da fábrica de conexão e da fila propriamente dita, através das propriedades connection-factory e destination, respectivamente. Na Listagem 23, temos as configurações necessárias para apontar para o servidor de mensagens. Para o projeto de exemplo, estamos utilizando o framework Active- MQ da Apache. 17 \

14 channel adapter channel adapter application a INput application b Figura 18. Funcionamento do padrão Channel Adapter. Listagem 21. Exemplos de configuração do padrão Channel Adapter. <int-ftp:outbound-channel-adapter id= ftpbancodopovo channel= ftpbancodopovochannel session-factory= ftpbancodopovosessionfactory remote-file-separator= / auto-create-directory= true remote-directory-expression= /123/ /> <int-jms:outbound-channel-adapter id= jmsbancodetodos channel= jmsbancodetodoschannel destination= bancodetodosqueue connection-factory= bancodetodosconnectionfactory /> Listagem 22. Configuração do Session Factory do servidor FTP do Banco do Povo. <bean id= ftpbancodopovosessionfactory class= org.springframework.integration.ftp.session. DefaultFtpSessionFactory > <property name= host value= localhost /> <property name= port value= 9981 /> <property name= username value= mundoj /> <property name= password value= mundoj /> </bean> Listagem 23. Configuração da fila de mensagens do Banco De Todos. <jee:jndi-lookup id= bancodetodosconnectionfactory jndi-name= jms/bancodetodosconnectionfactory /> <jee:jndi-lookup id= bancodetodosqueue jndi-name= jms/bancodetodosqueue /> Bridge Este padrão estabelece uma ponte entre dois canais, não alterando a mensagem, ou seja, a mesma mensagem que chega através do canal de entrada é transmitida ao canal de saída, conforme exibido na figura 19. O mesmo pode ser utilizado tanto para facilitar os testes, pulando trechos do fluxo, como para o nosso exemplo, onde temos um canal de tratamento de erro que pode se ligar tanto a um canal de log, quanto a um canal de resposta, conforme o administrador optar. Veja na Listagem 24, dois exemplos utilizados no fluxo que ilustram bem as configurações deste padrão. Note a presença da propriedade auto- -startup, que pode ser usada na maioria dos padrões, indicando se o mesmo será startado (true) ao iniciar o fluxo ou ficará stopado (false). Se omitido o valor padrão é true. Listagem 24. Exemplos de utilização do padrão Bridge. <int:bridge id= logbridge input-channel= errorchannel output-channel= logerrorchannel auto-startup= true /> Figura 19. Funcionamento do padrão Bridge. / 18

15 message flow control bus Figura 20. Funcionamento do padrão Control Bus. <int:bridge id= errorbridge input-channel= errorchannel output-channel= outputchannel auto-startup= false /> Control Bus O Control Bus é um padrão muito importante dentro de uma solução EAI, pois o mesmo é responsável por prover uma administração de todo o fluxo em tempo de execução, conforme ilustrado na figura 20. No Spring Integration, o mesmo não é acoplado a nenhum EndPoint. Basta apenas disponibilizar acesso externo ao mesmo que esse elemento tem controle sobre todo o fluxo. No nosso caso é feito via um Gateway HTTP, através do endereço conforme podemos constatar na Listagem 25. No Spring Integration, o Control Bus funciona a base de comandos, no nosso caso, iremos habilitar ou desabilitar os dois Bridges mencionados anteriormente. Veja na Listagem 26 um exemplo de utilização do mesmo, onde, estamos stopando o Brigde logbridge e startando o Bridge errorbridge, fazendo com que os erros que antes eram logados, passem a ser lançados para a aplicação cliente. Listagem 25. Exemplo de configuração do padrão Control Bus. <int- request-channel= controlchannel name= /control supported-methods= POST /> <int:channel id= controlchannel /> <int:control-bus input-channel= controlchannel /> Listagem 26. Exemplo de utilização do padrão Control Bus. ); ); Rodando o projeto Para rodar o projeto que está disponível no site da revista, basta executar o comando do Maven: mvn integration-test Isso fará com que o Jetty suba, junto também é startado os servidores/containers OpenEJB, Apache ActiveMQ e de FakeFTP, tudo isso para que você não precise subir nada a parte, para ver o exemplo rodando. Ao final da execução, os testes irão verificar se os arquivos foram copiados no servidor FTP e se as mensagens foram enviadas ao servidor MQ. Considerações finais Como podemos observar, EAI não é nenhum bicho de sete cabeças. Muito pelo contrário, o mesmo utiliza uma notação funcional. Por trabalhar com uma estrutura simples, voltada à utilização de padrões, facilita em muito o desenho de soluções, a separação de tarefas e a reutilização de componentes. Já o Spring Integration é open source, utiliza a madura plataforma Java e o famoso framework Spring como base, possuindo integração com diversas tecnologias, protocolos, plataformas e sistemas. O que faz como que seja uma ótima opção na hora de escolher uma ferramenta EAI. Se você está pensando em implementar SOA na sua empresa e pretende investir fortemente em uma ferramenta ESB, equipamentos, treinamentos e contratações, fica a dica, vale a pena avaliar as opções open source antes. > Enterprise Application Integration /referências > Documentação Spring Integration htmlsingle/ > Exemplos de utilização do Spring Integration 19 \