EIP using Camel
Rating: 8 out of 10
IncentivizedUse Cases and Deployment Scope
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.