Monday, August 10, 2009

Camel vs. JBI

People are, in general, blown away by Camel. Hearts melt and grown men weep with joy when they learn how easy it is to write an integration flow, package it as an OSGi bundle, and then drop it into the FUSE ESB 4 container. But when the emotions have subsided and rationality comes again to the fore, I often hear the question ‘if Camel can do so much so easily, then why do I need JBI anymore?’. The answer is, that in many cases, you *don’t*.

This is hard for some ServiceMix users to stomach, and delightful to others. I have written before about my ‘love affair’ with JBI on this blog, a love affair that was soon to be blighted by some hardened home truths about what really goes on on the NMR. With my JBI relationship in almost tatters, I embraced Camel with open arms. Am I on the rebound? Hardly. Camel is simply a better technology choice when implementing ESB solutions than JBI. What makes it better? A great DSL (domain specific language) for implementing integration patterns. Extensible beyond Java into other scripting languages and technologies. No canonical intermediary format (XML). Dynamic routing. On-demand type conversion. Parameterizable routes (do *that* with JBI!). Support for unit testing of routing logic with ‘mock’ endpoints. An extensive list of technology components, with easy-to-use URI configuration. All these things make for a faster way to produce more with less.

With all these things going for it, then why continue to support JBI in ServiceMix/ FUSE ESB 4? There are a number of good reasons, and, I like to think that while my amorous intentions for JBI are firmly in the past, we do now remain “Just Good Friends’. There are many users out there who currently rely on JBI solutions, and there are a certain number of users for whom the JBI architecture is a cornerstone of a larger enterprise architecture. For these users, JBI will always be important: one of the reasons why is the promise of a standards-based modular architecture. This is good in large organizations because the adherence to a standard (i.e., the JBI 1.0 specification), you know that a component written by one of your teams in, say, Texas, will work when deployed in JBI a solution developed by a team in Hyderabad. Or, alternatively, a component written by a third-party for a CRM System will plug right into your JBI framework.

Of course, you can get this kind of plug’n’play with Camel - the Camel architecture and APIs are open source! However, some enterprises are going to be wary of working to an API that could change at the whim of a community, and prefer the solidity and comfort that only a standards-based specification can afford. I can appreciate this argument. However, I must respond that, if I were Chief Architect, I’d rather join in with a thriving open source community than a specification that’s been largely untouched and unrevised for some time, such as JBI 1.0.

All that aside, it’s clear that what’s right for some organizations is typically not right for others. ServiceMix (and FUSE) is all about supporting the integration community and, most importantly, offering choice. The advice I give my customers is to use Camel as the integration technology of choice, with an underpinning of ActiveMQ for reliable, asynchronous messaging and a touch of CXF for providing SOA or RESTful facades - all deployed in FUSE ESB 4 using OSGi. For me, the JBI container that used to be at the centre of ServiceMix / FUSE ESB is now a simply a feature that can be used to integrate with third-party or existing components that conform to the JBI specification. Camel, through the ‘jbi:’ and ‘nmr:’ components, can interoperate with such components as necessary. You get the best of all worlds.

To the JBI warriors out there, I salute you. You were not wrong. It’s just that there’s a new ‘right’ in town.

13 comments:

Anonymous said...

Nice post Ade, I cannot agree more, Camel really rocks !

François Fouquet said...

Really a greet post Ade !

cmoulliard said...

Everything is said in more than a few words. I raise the same conclusion one year ago.

m_fawaz said...

Very Interesting. Great Article. Performance could be also an interesting subject concerning Camel Vs JBI

Unknown said...

Thanks for your enlightenment.

Unknown said...

Right on Ade! JBI is the EJB of integration space while Camel is the brash "early days Spring" equivalent.

Unknown said...

Why do you need the Fuse ESB 4 container. Why not just run Camel stand-alone? And please don't send me to that faq on the Camel site. It is a terrible explanation.

Unknown said...
This comment has been removed by the author.
Ade said...

Hi bktaylor,

You are of course right: you don't need to use FUSE ESB 4 to run Camel; you can run it almost anywhere. For example, I've seen one of our customers drop a camel route JAR into the lib directory of AciveMQ, and then just initialize the route from within the activemq.xml config file. And, I wouldn't dare send you to a FAQ that clearly doesn't seem to answer your Qs.

I guess the reasons for pursuing a FUSE ESB 4 approach are:

* Lifecycle events (start, stop, restart, refresh, update) can be applied to your routes without having to restart the entire JVM.

* Elegant provisioning mechanism using the Karaf/Servicemix 'features' mechanism

* Hook right into a flexible configuration mechanism (OSGi Config Admin Service)

* Use OSGi services to create reusable POJO components that can be invoked from within your route.

* All the other goodness of OSGi (versioning, classpath resolution)

Those are the reasons that pull me in to deploying Camel in FUSE ESB/ServiceMix. Of course, what's important to me may be not be important to you. What do you think: do these features motivate you?

Anonymous said...
This comment has been removed by a blog administrator.
龜毛 said...
This comment has been removed by a blog administrator.
Stephen Kay said...

Thank you Ade for your lights.
Your post explains exactly what I was looking for : Is JBI redudant with Camel or not.
Now its clear.
But could you please clarify Fuse documentation ?
When you are starting reading, you get confused with these two technologies. Explained like "use JBI as a connector to other JBI systems" help the newbies to get right to the point.
Thank you again !

Ade said...

Thanks SkayBlog!

On behalf of my pals on the FuseSource team, sorry if there is any confusion. I think though it's to be expected as the ServiceMix world as a whole is moving from a world where JBI was the centre of all things, to a more OSGi-centric world where JBI is just one part of the many fantastic technologies we can deploy into the ServiceMix runtime. I will be meeting the docu guys later on this week, so I'll be glad to pass on your thoughts then.