1. Home
  2. Electronic Data Interchange (EDI)
  3. Apache Camel Reviews
  4. User Review of Apache Camel
EIP using Camel
April 03, 2017

EIP using Camel

Anonymous | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

Overall Satisfaction with Apache Camel

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.
  • 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.
  • 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
  • Very fast time to market in that so many components are available to use immediately.
  • Error handling mechanisms and patterns of practice are robust and easy to use which in turn has made our application more robust from the start, so fewer bugs.
  • However, testing and debugging routes is more challenging than working is standard Java so that takes more time (less time than writing the components from scratch).
  • Most people don't know Camel coming in and many junior developers find it overwhelming and are not enthusiastic to learn it. So finding people that want to develop/maintain it is a challenge.
  • Spring Integration
We did a comparison of the two products with an example application that tested about 10 distinct EIP pattern. We wrote Camel in XML and Java DSL and SI in XML. This was about 3 years ago. At the time, I found the threading model in SI to be more intuitive and Camel's seda. However, Camel's documentation at the time was far and away more complete (Wiki pages for Camel vs looking through XML schema for SI). Since the SI has improved their documentation. The main factor that I believe still sets Camel apart is the Java DSL. Writing routes is complicated enough, but doing so in XML would be just painful.
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.