Padrões de Integração com Apache Camel

Hoje em dia é difícil encontrar uma aplicação que funciona de maneira isolada, sem depender de nenhuma outra funcionalidade externa. Queremos reaproveitar funcionalidades já existentes que é a ideia principal do SOA. Ou seja, em tempos de Cloud e SOA a integração entre aplicações se tornou algo muito comum e faz parte do dia-a-dia do desenvolvedor.

O problema é que integração é uma tarefa árdua! Fazer que aplicações se comuniquem de maneira robusta e desacoplada não é fácil, pois não criamos as aplicações pensando na integração. Além disso, temos que trabalhar com plataformas, linguagens, formatos e protocolos diferentes, manter versões diversas, lidar com problemas da rede e falhas em geral, entre outras preocupações.

Logo Apache Camel

Um framework de integração ajuda a diminuir a complexidade e o impacto dessas integrações. Ao invés de escrever código de integração na mão usamos componentes para isso. Com um framework de integração seguimos boas práticas que foram identificadas e amadurecidas ao longo do tempo.

Os Enterprise Integration Patterns definem uma série de boas práticas na integração que foram documentadas no livro com o mesmo nome. O livro descreve as vantagens e desvantagens de cada padrão e define um vocabulário comum a ser seguido. O Apache Camel, como framework de integração, implementa a maioria dos padrões de integração.

Essencialmente, Camel é um roteador (routing engine) e a tarefa do desenvolvedor é configurar, através de um Builder, as regras de roteamento. O desenvolvedor decide de onde vem as mensagens (from()), para onde enviar (to()) e o que fazer com a mensagem no meio desse processo (mediation engine).

Veja um exemplo de uma rota com Apache Camel configurada pela Camel DSL em Java:

	from("jpa://br.com.caelum.livraria.modelo.Pedido?consumer.delay=5s")
	    .marshal().xstream()
	   	.log(LoggingLevel.INFO, "XML do pedido: ${body}")
	.to("jms:queue:pedido")
	    .marshal().xmljson()
	   	.log(LoggingLevel.INFO, "JSON do pedido: ${body}")
	.to("http4://localhost:8080/pedidos")
	.end();

Nesse exemplo verificamos a cada 5 segundos se há um novo pedido no banco de dados. Caso exista, serializamos para XML e encaminhamos para uma fila JMS. Depois transformamos o XML para JSON para enviar uma requisição HTTP. A rota deve ser configurada pelo RouteBuilder que, por sua vez, é adicionado ao CamelContext:

CamelContext context = new DefaultCamelContext();
context.addRoutes(new RouteBuilder() {
	//configuração da rota from(..).to(..)
});

context.start();

Pelos métodos from(..) e to(..) definimos os endpoint, ou seja de onde vem e para onde vai a mensagem (routing). No meio dos endpoints podemos aplicar regras (mediation) de transformação ou enriquecer, serializar para vários formatos, validar e processar os dados e muito mais, sempre seguindo os Enterprise Application Patterns. A lista de componentes é impressionante (+120), mas não estamos limitados aos componentes oficiais, pois é relativamente fácil criar o seu próprio componente.

Nesse momento poderia parecer que o Camel é um ESB (Enterprise Service Bus) e, realmente, algumas das funções de um ESB tradicional o Apache Camel também possui. O próprio site do Camel define o framework como “a small, lightweight embeddable ESB“.

A explicação do site também deixa clara a diferença: O Apache Camel roda embutido dentro da aplicação. Um ESB é um container/servidor separado, um produto mais complexo com várias funcionalidades. Além do roteamento e mediação já vistos, um ESB adiciona outros recursos como monitoramento e gerenciamento de processos, balanceamento de carga e alta disponibilidade, oferece um registro de serviços, força segurança e disponibiliza ferramentas (tooling), entre outras funções. Isso também faz com que um ESB seja um produto mais complexo, enquanto o Apache Camel foca no roteamento e mediação.

Mais sobre a integração com Apache Camel é visto no nosso treinamento SOA na prática: Integração com Web Services e Mensageria.

E você, já usou Apache Camel?

12 Comentários

  1. Ricardo Longa 28/01/2014 at 12:51 #

    Bacana essa introdução sobre o Camel!

  2. Alexandre Aquiles 28/01/2014 at 14:51 #

    Muito bom! Hoje é fundamental ter algo como o Camel na nossa caixa de ferramentas.
    ___

    Há algum tempo, implementamos um sistema que integrava com várias estações telemétricas usando FTP.

    Utilizar o Camel foi uma primeira opção porque pensávamos em ampliar as possibilidades de integração, mas o componente de FTP [1] do Camel não atendeu. Na verdade, a estrutura de alguns servidores de FTP mantinha milhares de arquivos no mesmo diretório e o componente de FTP fazia um list, que demorava um bocado.

    Resolvemos retroceder e fazer uma solução em casa, utilizando Apache Commons Net FTP Client. Aí, fizemos um esquema de ir diretamente no arquivo, ao invés de listar o diretório.

    Poderíamos ter criado um componente customizado mas, como o uso do Camel seria limitado, acho que foi uma decisão acertada.

    Acabamos tendo apenas mais duas integrações: com um diretório da rede interna e com HTTP GET em algumas URLs.
    ___

    Podemos dizer que, para integração, temos 3 opções [2] :

    a) Solução caseira: bom quando o problema é pontual. Mais rápido, menos coisa pra aprender. Mas manutenção pode ser mais difícil e a solução menos robusta.

    b) Framework de integração: reutiliza soluções testadas por aí e utilizam padrões de integração. Robusto, mas mais difícil de aprender.

    c) ESB: vale a pena quando a empresa é gigante e Processos (BPM), registro e monitoramento de negócios (BAM) estão na mira. As ferramentas são bem complexas e, muitas vezes, caras.

    Aí, vale analisar os trade-offs e o contexto da sua equipe e da sua empresa.

    [1] http://camel.apache.org/ftp2.html
    [2] http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/

  3. Alexandre Aquiles 28/01/2014 at 15:19 #

    Acabei de descobrir que o componente de FTP do Camel tem uma opção de verificar a existência de um arquivo sem listar o diretório todo: fastExistsCheck.

    Foi criada essa opção a partir da versão 2.8.2, de 24/10/2011:
    https://issues.apache.org/jira/browse/CAMEL-4356

  4. Raul 31/01/2014 at 21:53 #

    Bom texto Nico, e valeu por documentar sua experiência Alexandre 😉

  5. Hugo Marques 05/02/2014 at 11:16 #

    Excelente post, dá uma boa pincelada no camel e deixa ótimas referências para quem tá começando. Que venham mais posts do CAMEL =)

    Parabéns!!!

  6. ednei 09/02/2014 at 22:30 #

    muio bom

  7. Luciano 09/04/2014 at 15:34 #

    Excelente artigo Nico! Parabéns e obrigado por compartilhar!

  8. Édion Torres 25/05/2014 at 18:30 #

    Excelente artigo. Estou iniciado em uma nova oportunidade utilizando ESBs como Jboss Fuse, Apache ServiceMix ou até mesmo o Apache Camel puro. É um novo mundo (não tão novo assim) que todo desenvolvedor deve ter interesse e aprofundar-se.

  9. Glauber 09/09/2014 at 08:44 #

    Ótimo artigo, obrigado por compartilhar.

  10. Sidney Amaral 06/03/2015 at 12:59 #

    Parabéns pelo post! O Camel é uma ótima implementação de ESB que além de ter um small footprint ainda é muito robusta e flexível (como todo ESB deveria ser :p). Topa desenvolvermos um conector ATMI opensource para o Camel? 🙂 Grande abraço.

  11. Jony Santos 08/04/2015 at 14:38 #

    Ótimo post introdutório sobre Apache Camel.

    Aproveito para dizer que o curso SOA na prática: Integração com Web Services e Mensageria é altamente recomendado. Estou fazendo e estou gostando muito.

Deixe uma resposta