Camel

Apache Camel

Open Source Middleware Leave a comment

During the past 18 months, I have been working with a customer who did not have a budget for purchasing Commercial Middleware licenses.  At first, I was very skeptical about the capability that my team was going to be able to build with the open source stack.  My previous integration experience was with all the major software vendors such as Oracle, IBM, Tibco and Vitria.

I like challenges, so we chose Apache Camel to build mediation services for several systems with different messaging formats.  It turns out that Apache Camel is the Swiss Army knife of Open Source Middleware (OSM).

I don’t want to start a purist war on Commercial versus Open Source software; However, I am going to point a few of the benefits to using Apache Camel given the business decisions that our team faced.

  • Team Skill Set – Apache Camel is written in Java and it’s easy for Java Developers to climb the learning curve due to Camel’s Domain Specific Language (DSL).
  • Portability – One of the requirements that our team had, was the ability to ship the services to partners.  Camel is highly portable, since you can run it as a web application in tomcat or jetty.  Or you can embed the mediation module inside your web application.  At first, we ran our camel services in Glassfish. Then, we migrated to tomcat.
  • Prototyping – We found that the level of effort to design and prototype services was minimal.  Granted, our team was composed of proficient Java developers.
  • Enterprise Integration Patterns (EIP) – Apache Camel was built to provide the EIP as components. http://camel.apache.org/eip.html

Also, there are some obvious drawbacks such as no WYSIWYG editor, limited support and too much flexibility.  What I mean by too much flexibility is that Camel provides you with low level API’s to process and route messages.  In the wrong hands, your code can become very complex.  For example, I had one of my Senior developers implement the low level API in order to execute XSLT with SAXON.  He wrote approximately 100 lines of code to do this.  When all he needed to do was use camel DSL’s like this.

from("activemq:My.Queue").
  to("xslt:com/santisij/mytransform.xsl").
  to("activemq:Another.Queue");
Apache Camel is a light weight Middleware component. It does not come with all the bells and whistles.  For example, if you want a JSR-94 Business Rule engine, you will need to use Drools and integrate the business rule engine with your Camel routes. Then, there’s clustering and high availability that you can set-up as well, but there’s no wizard nor dedicated administrative server to configure.
Camel does provide a lengthy list of components that you can leverage to build your mediation modules.  In camel, the components are the piping. You still have to develop the logic in Java.  Also, there are no JCA compliant adapters.  For some Enterprises this can be a deal breaker specially if you are trying to service enable an IBM Mainframe.  IBM definitely does not make a Camel Component.
When do you want to use camel?  There are several scenarios that Camel is ideal for.  The first one that comes to mind is when a Web Application needs to handle messaging (JMS/MQ), and message routing based on content along with message transformation.  Camel is lightweight and can be embedded in the application, which helps reduce the code footprint when compared to non-camel applications.  Another scenario is for file polling and processing.  Camel provides a file poller component that is robust and multi-threaded.  And you can implement it with one line of code:
from("file://inbox?preMoveNamePrefix=inprogress/")
Remember the days that you had to right the Java Code for this?   How much code did you write? Even with Spring – this is not as trivial as with Camel. (You can also use Camel with your Spring Applications)
In the near future, I will update my blog site with meaningful Apache Camel scenarios with code.  If you have a favor topic that you need me to address – leave me a comment.