Uma arquitetura desacoplada com o Spring Integration
A cada dia crescem mais as aplicações que disponibilizam serviços Web para que qualquer cliente possa consultá-los. E a cada dia que passa nossas aplicações dependem mais e mais desses serviços para obter informações de usuários, armazenar dados remotamente, consultar emails, postar entradas no twitter dentre outros. Por isso logo surge um problema o qual é bem difÃcil de lidar: dependência da API dos serviços.
Depender de uma determinada API para algum serviço é um fator de risco bem alto se considerarmos que as APIs podem mudar e nossa aplicação pode parar de funcionar do dia para a noite. E pior, dependendo da mudança é necessário uma reestruturação muito grande em nosso código para se adequar a nova especificação. Pensando nisso que programamos seguindo padrões de design de código e boas práticas de programação. Ainda assim pode não ser suficiente se pensarmos de uma maneira um pouco mais macro em nossa aplicação, pois em algum ponto do nosso sistema ainda existirá uma “ponte” de integração com algum determinado serviço (entenda serviço como qualquer WebService, classe ou biblioteca que consultamos).
A solução é desacoplar o máximo possÃvel nossa aplicação de tais serviços, e deixarmos nossa aplicações executar independente de como o serviço será consultado. Para obter esse nÃvel de abstração é necessário programar e planejar o sistema pronto para se adequar as mudanças, e a melhor maneira de se programar para mudança é não programar. Parece um pensamento meio estranho, mas se analisarmos com cuidado veremos que existe uma certa razão para isso, pois quanto menos código tivermos, menos precisará ser mudado.
Spring Integration permite que criemos serviços de maneira totalmente desacoplada entre si e outros serviços Web, e disponibiliza as conexões em sua própria Bean Factory, ou seja, nosso sistema é livre de qualquer consulta a serviços ou API externa a aplicação. Vamos entender um pouco da arquitetura do Spring Integration.
Entendendo o que está acontecendo
A idéia por trás do spring integration é bem simples na verdade: todo serviço só distribui informação e recebe informação através de channels (canais). Canais são uma forma de acoplar os serviços, sem que estes dependam da API ou da maneira com que as chamadas são feitas.
Toda canal trafega mensagens. Mensagens possuem um cabeçalho e um conteúdo qualquer:
E um canal nada mais é do que o responsável por receber e disponibilizar tais mensagens a quem estiver interessado. Para ser mais direto, qualquer bean definido no contexto do spring tem acesso a tais canais.
Fica claro aqui que podemos ter vários tipos diferentes de canais com várias configurações e comportamentos diferentes. De fato o spring disponibiliza tais configurações e comportamentos out of the box. Veremos mais pra frente.
Exemplo prático
Vamos criar um exemplo para entender melhor os conceitos.
A primeira coisa a se fazer é baixar os jars do spring integration. Feito isso adicione-os ao classpath do seu projeto que deve ser um spring application padrão. Se você está usando o maven, basta adicionar as seguintes dependências:
|
1
2 3 4 5 6 7 8 9 10 11 |
? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? |
Estou assumindo que as dependências para o contexto do spring já estejam corretamente configuradas.
Agora em nosso arquivo de beans do spring, basta adicionarmos o seguinte namespace e schema location:
|
1
2 3 4 5 6 7 8 9 10 11 12 |
<?xml version=“1.0″ encoding=“UTF-8″?>
? ? xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xmlns:amq=“http://activemq.apache.org/schema/core” ? ? xmlns:context=“http://www.springframework.org/schema/context” xmlns:si=“http://www.springframework.org/schema/integration” ? ? xsi:schemaLocation=“http://activemq.apache.org/schema/core http://www.springframework.org/schema/aop ? ? ? ? http://www.springframework.org/schema/beans ? ? ? ? http://www.springframework.org/schema/beans/spring-beans-3.0.xsd ? ? ? ? http://www.springframework.org/schema/context ? ? ? ? http://www.springframework.org/schema/context/spring-context-3.0.xsd ? ? ? ? http://www.springframework.org/schema/integration ? ? ? ? http://www.springframework.org/schema/integration/spring-integration-2.0.xsd”> > |
Podemos começar a configurar nossos serviços e canais agora.
Crie um serviço bem simples que recebe e guarda uma String, e disponibiliza-a em um getter:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Repare que estou usando a criação de beans por anotação, por isso tenho que colocar em meu arquivo de beans que o pacote de tal serviço deve ser “escaneado”:
|
1
|
? ?
|
Crie um teste unitário para nosso serviço, e certifique-se que a injeção dos beans está sendo feita corretamente e que o spring está corretamente configurado até aqui. Não é o foco deste artigo mostrar como configurar tal teste, por isso vou supor que as configurações já estão corretas e vou colocar o código do teste diretamente (estou usando JUnit 4):
|
1
2 3 4 5 6 |
? ? private SimpleService simpleService;
? ? @Test |
Vamos criar agora um canal de entrada e um canal de saÃda em nossos beans. Para isso basta adicionar o seguinte código em nosso xml de beans:
|
1
2 3 4 5 |
? ?
? ? |
Estou setando uma capacidade para nosso canal de saÃda para ilustrar uma das possÃveis configurações do canal.
Até aqui nenhum segredo. Vamos agora disparar nosso serviço quando uma determinada mensagem for adicionada ao canal de entrada. É aqui que o spring integration se mostra muito flexÃvel e poderoso. Não necessário nenhuma mudança no código para que essa conexão do serviço com o canal seja feita, basta adicionarmos um service-activator para fazer o trabalho. Para isso basta adicionar o seguinte bean ao xml:
|
1
2 3 |
? ?
? ? ? ? output-channel=“output” ref=“simpleService” method=“setString”> ? ? :service-activator> |
Estamos dizendo que uma mensagem que chega no canal input, deve ter seu conteúdo enviado para o método setString no bean simpleService, e que o resultado deve ser adicionado no canal output.
Simples não? Vamos testar agora:
|
1
2 3 4 5 6 7 8 9 10 |
? ? private MessageChannel input;
? ? @Test |
Vamos mudar nosso serviço para devolver o valor que foi setado no métodosetString, com isso nosso service activator irá pegar o resultado e enviá-lo para o canal de saÃda:
E agora conseguimos fazer o seguinte teste:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 |
? ? private MessageChannel output;
? ? @Test |
Rode o teste e verifique que ele passa.
Vamos recapitular então o que vimos até agora. Criamos um serviço que é totalmente livre de qualquer API que apenas guarda uma String que é setada através do método setString. Criamos um canal de entrada (input) e um de saÃda (output) que guarda até 10 mensagens. Conectamos os canais com um service activator, que quando recebe uma mensagem no canal de entrada, invoca o método setString em nosso serviço e envia uma mensagem para o canal de saÃda com o valor que o serviço devolveu. Fizemos um teste que envia uma String para o canal de entrada, verifica que chegou até o serviço, e verifica que estava disponÃvel no canal de saÃda.
Um fato interessante é que o método receive do canal de saÃda “trava” até que chegue uma nova mensagem, portanto estamos falando de uma arquitetura passiva baseadas em eventos que são disparados com o recebimento de mensagens. Muito bom!
Gateways
O conceito de Gateway existe para facilitar o envio de mensagens aos canais, estabelecendo um interface comum para que possam ser usados de maneira natural no código.
Vamos criar um gateway para invocar nosso serviço que guarda a String:
|
1
2 3 4 5 |
Pronto! Basta agora adicionarmos o gateway em nosso arquivo de beans:
|
1
2 |
? ?
? ? ? ? service-interface=“br.com.dclick.services.SimpleGateway” /> |
Estamos dizendo aqui que nosso gateway irá despachar as mensagens para o canal input, e como o gateway recebe uma String, o Spring sabe que o conteúdo da mensagem que deve ser enviada é do tipo String. Vamos ao teste:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
? ? private SimpleGateway simpleGateway;
? ? ? ? @Test ? ? public void testChannels() { ? ? ? ? Assert.assertNotNull(this.simpleService); ? ? ? ? ? ? ? ? input.send(new GenericMessage ? ? ? ? ? ? ? ? Assert.assertEquals(“hello!”, this.simpleService.getS()); ? ? ? ? ? ? ? ? Message ? ? ? ? Assert.assertEquals(“hello!”, msg.getPayload()); ? ? ? ? ? ? ? ? this.simpleGateway.call(“uma string”); ? ? ? ? ? ? ? ? Assert.assertEquals(“uma string”, this.simpleService.getS()); ? ? } |
Próximos passos
Spring Integration é uma ferramenta muito poderosa, que permite criarmos aplicações de qualquer porte com uma arquitetura muito desacoplada facilitando a escalabilidade e reação a mudanças externas. Repare que sua aplicação ganha um aspecto de arquitetura voltada a eventos que são disparados através de mensagens, e que não há limitações de tipos e quantidades de conexões. Por exemplo, nosso canal de saÃda poderia sem problemas ser o canal de entrada para um outro serviço, ou até mesmo para um outro método do mesmo serviço. Também existem várias regras de encaminhamento de mensagens disponÃveis no spring integration, como por exemplo um roteador de mensagens, um replicador de mensagens, um agregador, etc. Veremos alguns exemplos no futuro.
Existem muitos outros pacotes disponÃveis como por exemplo o de integração com o twitter, o de integração com arquivos, o de integração com jms, dentre outros. Veremos tais integrações mais para frente.
Por @Gust4v0_H4xx0r
As imagens foram tiradas do próprio site do Spring Integration.
