TrustRadius Insights for Apache Camel are summaries of user sentiment data from TrustRadius reviews and, when necessary, third party data sources.
Pros
Easy Learning Curve: Several users have found Apache Camel to have an easy learning curve, allowing them to quickly grasp the concepts and start using it efficiently.
Extensive Integration Support: Many reviewers have praised Apache Camel for its extensive support for integration with diverse software platforms. With over 150 components available, users can seamlessly integrate Camel with various frameworks and middleware products such as Spring, Apache Karaf, and Servicemix.
Robustness and Reliability: Numerous users have highlighted the robustness of Apache Camel in handling various information transfer protocols out-of-the-box. They appreciate that it is a reliable solution for their integration needs, making it suitable for creating microservices and handling complex business logic.
We use it as the processing backbone/Enterprise Integration Pattern (EIP) framework for several products that we develop. It is used to provide components for message ingest, orchestration and export. By orchestration, I mean the determination and execution of the path of any single message through the application. It also is our primary error handling mechanism as it provides out-of-the-box error retry, waiting and exponential backoff.
Pros
The Java DSP is one of the primary reasons we chose Camel over Spring Integration's XML-based route definitions. It provides compile-time checking of syntax with auto-complete in an IDE (Eclipse, etc).
The component documentation on the website is phenomenal.
Error handling mechanisms are robust and easy to use and set up. Default settings are great and intuitive.
The ability to define distinct contexts within the same application and define context-wide, context-specific error handling is great as well.
Cons
I find the "seda" endpoint to be less obvious that it is doing multi-threading than Spring Integration's executor mechanism.
Integration with Spring Beans is pretty good, but I believe SI's is a bit better (for obvious reasons, both being Spring products).
SI's use support is probably a bit better/faster and I believe the user base is larger so that there are most questions/answers for SI on StackOverflow
Likelihood to Recommend
Message processing, especially with high throughput, is an excellent use case. File system monitoring, JMS ingest, etc., is really great. I would most consider it for automated processing scenarios. Although it provides components to support REST endpoints, I would choose frameworks such as Jersey or Spring REST for that. Although it supports a response mechanism, I don't think I would choose to use it in systems where I need fine-tuned control of responses.
VU
Verified User
Engineer in Engineering (Defense & Space company, 11-50 employees)
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).
Pros
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.
Cons
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.
Likelihood to Recommend
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.