In this posting, I would like to talk about some of the alternatives that I see might be interesting for you to investigate, when considering an open-source enterprise integration framework. Hereby however, things always get a bit fuzzy in my opinion, depending on your business requirements.
On one side, you want to have components which allow you to communicate with other services, but on the other side you also want to have some sort of workflow-capabilities in order to orchestrate your business processes. Furthermore, you may be interested in monitoring and reporting functionality. From a different view-angle, you may desire a higher-level solution versus a solution that embeds easily into existing code using plain Java APIs. The list could probably be expanded considerably, but I hope you get the picture.
Ergo, depending on your specific business requirements, the following list of frameworks may or may not provide a better choice compared to Apache Camel:
- Spring Integration
- Spring Batch
- Full ESBs such as Service Mix, Mule ESB, OpenESB, JBossESB
Before I was even aware of Apache Camel, I learned about Spring Integration at the No Fluff Just Stuff (NFJS) Java conference one year ago. Back then I thought that Spring Integration was the best thing since Nutella. Then a little later I learned about Apache Camel and tried to figure which one to take for a spin. As it turns out, comparative information on Google is rather sparse:
- Matt Raible has some interesting tidbits in one of his blog entries
- There are some comments by Mark Fischer on the Spring Blog
To me a good argument for Apache Camel was the greater availability of components compared to Spring Integration, as well as its adoption by other frameworks such as ActiveMQ and ServiceMix.
If your business requirement is to process large amounts of data, you may also want to look at Spring Batch which is specifically designed for batch processing requirements. There are some pointers on the Spring Batch website for integrating it with Spring Integration. I considered it for one of my past projects, but unfortunately I do not have massively deep experience with it as we ultimately chose JBoss jBPM.
In my opinion another option worth considering is jBPM from JBoss. I used it in one of my past projects. Integrating it back then with Spring was certainly a bit tricky (especially asynchronous execution of Nodes), but it is doable. Interestingly, starting with version 4.0, JBPM provides native Spring integration. Unfortunately, I did not have any opportunity, yet, to try out JBPM 4.0. JBPM is certainly much heavier compared to Apache Camel or Spring Integration. I would say that its focus is also slightly a different one. While it provides support for human task management during workflow executions, managing the state of your workflow nodes etc., it totally looses out compared to the available components, which are provided by Apache Camel.
A little bit jBPM on steroids is nexusBPM (An older blog post of mine about it is here). Developed by Intercontinental Hotels Group here in Atlanta, it is open-sourced at Sourceforge and provides a set of useful components in addition to the original JBpm distribution.
You probably would not necessarily think of Drools being a Workflow solution but what originally started out as a rules engine seems to venture increasingly into other areas as well. In fact, at least from a 30k foot view, it pretty much provides similar functionality as JBPM (Workflow, human task management etc.) and also provides a few components such as FTP, mail, executing system commands, etc.
What kind of baffles me is the fact that JBoss is maintaining 2 very similar products...
Cascading and Hadoop
If you need to process large amounts of file-based data, then Cascading might also be an interesting alternative. Cascading uses MapReduce to handle chunks of data. Interestingly, you can also use it for creating workflows. Not too long ago I attended an interesting presentation on that subject at AJUG. The presentation can be found here.
ESB like ServiceMix, Mule, OpenESB
Last in my list of alternative frameworks to Apache Camel is an entire category of solutions: Enterprise Service Buses (ESB). Enterprise Service Buses are basically stand-alone products, and as such, have a much heavier foot-print than for example Apache Camel which is basically just a set of light-weight Java APIs. In fact Apache Service Mix 4.0 is using Apache Camel under the hood in order to provide message routing. Besides Apache ServiceMix, you may also look into these OSS products:
¡Hasta la próxima!