Tools of trade: Camel

Para estrear no CbE, achei legal discutir algumas ferramentas bastante úteis no dia-a-dia de um desenvolvedor. Para começar, uma bastante útil para quem precisa escrever código de integração, chamada Apache Camel.

Por que eu deveria ligar pra isso?

Exceto alguns casos extremos, sistema nenhum existe no vácuo e integração é uma necessidade recorrente em qualquer aplicativo. Essas necessidades costumam envolver operações como transformação, roteamento, rastreio e filtragem de mensagens.

Para resolver este problema, podemos:

• Desenvolver “na mão”: normalmente uma decisão tomada em casos severos de síndrome NIH (Not Invented Here syndrom). Sério, com exceção de casos extremamente simples, é difícil achar uma justificativa para esse approach;
• Usar algum middleware: neste caso, temos duas grandes estratégias à disposição:
  • “Big ass SOA”: Arquitetura de Serviços com letra maiúscula. Grande foco em governança, uso de barramentos corporativos (ESBs), BPM, etc. Não é hoje white vou falar mal disso, mas se esse é o seu foco o restante do post pode não lhe ingressar;
  • “Lightweight SOA”: nem todo middleware precisa ser grande ou centralizador. E o fato de você não ter um ESB não invalida suas necessidades de integração;

A sacada do Camel é se prestar para os dois cenários: no caso de uso de um bus, ele pode ser a engine de mapeamento/roteamento/etc., como ocorre nos interessantes ServiceMix, Fuse e Talend (nem todo ESB precisa ser caro); no caso de uma abordagem leve, é possível pluga-lo abaixo de um servidor de aplicação (ex: TomCat), de mensageira (ex: ActimeMQ) ou de qualquer coisa rodando uma JVM.

Tudo isso porque o Camel não é um bus. Nem é mensageira. Ele é apenas uma biblioteca de código que oferece os mais importantes padrões de integração (Enterprise Integration Patterns) de forma simplificada.

Ok, estou convencido. O que é esse Camel, afinal?

O Camel é uma biblioteca de roteamento e mediação de mensagens, que implementa todas as EIPs tradicionais (mais sobre isso abaixo) e suporta uma variedade de protocolos (ex: REST, SOAP, JMS, FTP, etc) e formatos (ex: JSON, XML, EDI, etc).

Detalhes sobre Integration Patterns merecem um post em si, mas resumidamente, elas são as Design Patterns da integração: da mesma maneira que o GoF se reuniu para escrever seu livro sobre design orientado a objetos, dois caras (Gregor Hohpe e Bobby Woolf) sintetizaram anos de experiência num conjunto de padrões recorrentes quando se precisa criar interfaces entre sistemas.

Interessante. E como ele faz tudo isso?

O mais importante: de maneira simples. O Camel oferece uma série de DSLs (Domain-Specific Languages) para integração, baseadas em linguagens de programação como Java e Scala ou em XML (Spring ou Blueprint) através das quais é possível definir rotas para trocas de mensagens.

Mas é claro, nada expressa algo tão bem na nossa área quanto um pouco de código 🙂

<?xml version="1.0" encoding="UTF-8"?>
<blueprint
 xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
   <camelContext xmlns="http://camel.apache.org/schema/blueprint">
     <route>
       <from uri="file://camel/in"/>
       <to uri="file://camel/out"/>
     </route>
   </camelContext>
</blueprint>

O código acima, praticamente um Hello World de integração usa uma DSL em XML para copiar arquivos de uma pasta “in” para uma pasta out. Para os XMLfóbicos (e frequentemente me encontro nesse campo), é possível escrever o mesmo comportamento usando a DSL Java:

public class TimerRouteBuilder extends RouteBuilder {
    public void configure() {
    	from("file://camel/in")
    	.to("file://camel/out");
    }
}

O grande poder da ferramenta reside em alguns pontos fundamentais:

• Grande variedade de componentes. Com esta variedade, é fácil plugar endpoints (arquivos, FTP, REST, SOAP, JMS, a lista é longa), trabalhar com vários formatos de mensagem (JSON, XML, EDI, etc) e também de extender a funcionalidade através de POJOs;
• DSLs simples e expressivas. No exemplo acima, bastante complexidade (usar polling? o que fazer em casos de problemas de leitura? fazer o block do arquivo? evitar releitura? o que fazer com o arquivo depois?) é varrida para baixo do tapete, usando comportamento default que pode ser ajustado;
• Agnosticismo. Não, não estou falando de religião (se bem que pode chegar perto). O Camel não assume nada com relação ao que deveria ser o formato das mensagens (vários ESB assumem XML, por exemplo), quais os veículos de mensageria, etc. Isso permite flexibilidade e escalabilidade;

Legal, onde posso obter mais informações?

• O próprio site da Apache é um excelente ponto de referência, em especial sobre a maneira como o Camel implementa EIPs;
• Falando em EIPs, a Bíblia é o livro original e o site EAI Patterns uma boa fonte de consulta;
• Os fontes do Camel contém exemplos, em diversas DSLs;
• Instalar um ServiceMix facilita vários aspectos de deploy e oferece uma série de features interessantes para quem está aprendendo;

Advertisement