Overall Satisfaction with Apache Camel
I worked on a product development team creating an enterprise cybersecurity product. The core event processing mechanism of the product used Apache Camel in many places, mainly to handle interactions over JMS between the various modules of the product. Apache Camel especially makes the process of sending a POJO from one method to another across two separate application components, handling the marshaling and unmarshaling via JAXB, and the sending and receiving via JMS. It achieves all this routing via a simple XML configuration that is part of the application's spring context (although it can also be configured procedurally).
- Configuration of information routing via XML in a Sprint Context.
- Robustness. Apache Camel is capable of handling many different information transfer protocols out-of-the-box.
- Extensibility. Apache Camel also allows for custom routing handlers where needed.
- Some of the documentation is a little sparse. In particular, its TCP-based routes use an underlying Netty server, and the interactions between Netty's decoder capabilities and Apache Camel's routing/handler capabilities can be a little muddy at times. In general it is clear which routes and endpoints are the more frequently used and which haven't been given as much attention.
- There was certainly a positive impact in terms of code maintainability and ease of implementing new messaging pipelines, however, it's a little difficult to quantify.
Esper is only similar in that they both are involved in complex even processing, however Esper's aim is a little more complex and specialized. In general however I found Apache Camel to be much easier to understand, implement and debug, whereas Esper's DSL can get very complicated and hard to debug and test. When done correctly however, Esper offers much more analytical capabilities for correlating and reasoning about asynchronous events.
In my experience, Apache Camel was very useful for the main use case that we leveraged it for, i.e. wiring up JMS messaging. I found the less-frequently-used handlers and endpoints to be either less reliable, maintainable, or easy to work with than just rolling my own data transfer logic. I would stick to straightforward use cases where the XML configuration conveys the intent in a very clear manner, and avoid using Apache Camel to do large portions of moving data around that involve business logic or custom intermediaries.