Apache Camel vs elastic.io Integration Platform

• 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.

Read full review

• Streamlining data directly between relevant ES plugins
• Automating ES configuration management
• Batching data relays

Read full review

• 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

Read full review

• Paid solutions are always challenging when the tool itself is free
• Available training for this paid solution

Read full review

• 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.

Read full review

• If your datasets are diverse and could use automation, this will bring good ROI for time spent

Read full review