Hello , today i will talk about my experience with Apache Camel.
I worked on a product development team creating a smart metering 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).
what i doesn’t like about apache camel :
in my case i faced many problems using apache camel specially problems with documentation 😥,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.
what i like about apache camel :
- 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.
as a conclusion , it was a very rich experience using apache camel in production environement , with many modules communicating with each other sometimes with large sizes of messages,which makes us deal with a perf problems (for example when dealing with larges files we switched to use sharedFolders between modules to avoid crashes in JMS broker)..