Camel Integration

Sweet monkey spit... did I just miss January entirely? Is it seriously February? Dang.

One thing I have been researching lately has been enterprise integration frameworks. I'm a big fan of thinking in patterns while doing design and development and that goes double for architecting systems as well. When I sit down to architect a system I do my best to first think in terms of Enterprise Integration Patterns, then in terms of the Gang of Four's Design Patterns, and then in terms of implementation.

For a current project I've completed the architecture and a good chunk of design, so now I'm looking at implementation. I need to tie together a lot of disparate views to a lot of disparate services, which originally sent me down the path of evaluating Enterprise Service Bus products. I liked the content based routing using Drools utilized by JBoss ESB and ServiceMix. The orchestration of Chainbuilder was also a nice move forward. All had proper integration with naming and directory services as well. Ultimately, however, I found that most of the functionality within an ESB solution simply wouldn't be leveraged; the authentication and authorization model would need to be refactored, I didn't really need transactional support and there was no business process management to speak of.

I really just needed component adapters, translators and content-based routing. Slimming things down to just an integration framework left two main choices: Apache Camel and Spring Integration. Both offered the decoupling I needed and mirrored the Enterprise Integration Patterns I had already used in my architecture layouts. Even though these two frameworks are remarkably different in their implementation they are difficult to contrast. The rumor is that this similar-but-different approach is well known, in that the Camel team originally envisioned becoming a part of Spring. Of course Spring decided to roll their own ultimately to better fit their view and style (especially in a Spring 3.0 world).

Probably the best comparison is provided by actual, concrete examples of event notification on Hendy Irawan's blog: one written with Spring Integration, another with Apache Camel. The examples are written to leverage Spring Remoting, a remote method invocation mechanism not unlike Jini's remoting mechanism. While the examples do have to jump through the hoops of creating a proxy object, the meat of the comparison is in the application context of the two examples. Note that the Spring Integration configuration is a bit more readable and maps more distinctly to an integration pattern layout. The Apache Camel configuration just looks like a standard Spring bean context, however it uses URIs for connecting components rather than using dependency injection to connect them.

Ultimately I like the convention of having endpoints addressable by URIs rather than keeping them as actual bean references. For my tastes this makes things more agnostic (even from Java itself) and more coherent. Having URIs indicate addressable resources is a convention most developers are familiar with, if not just by writing curl scripts.

There are a lot of facets to view when attempting to evaluate integration frameworks and service buses. Gunnar Hillert's blog can give you a small peek into how wide of an ecosystem this really is - you can't just perform a straight-forward SWOT analysis any more. One must always architect first, design second then look at what implementation can get you their with ease and speed.