Message brokering across different systems, with transactionality and the ability to have fine tuned control over what happens using Java (or other languages), instead of a heavy, proprietary languages. One situation that it doesn't fit very well (as far as I have experienced) is when your workflow requires significant data mapping. While possible when using Java tooling, some other visual data mapping tools in other integration frameworks are easier to work with.
Camel has an easy learning curve. It is fairly well documented and there are about 5-6 books on Camel.
There is a large user group and blogs devoted to all things Camel and the developers of Camel provide quick answers and have also been very quick to patch Camel, when bugs are reported.
Camel integrates well with well known frameworks like Spring, and other middleware products like Apache Karaf and Servicemix.
There are over 150 components for the Camel framework that help integrate with diverse software platforms.
Easy to use: The simplicity of its programming language allows fast learning. Visual environment to generate complex code.
Robust: A fall of the system will not be a problem. Never again will information of the transactions in progress be lost. Never more messages lost.
Connect to the world: The most popular connection is possible to implement quickly. FTP, File folder, TCP, SMPT, REST.... all method are ready to use. Only define "where" and "how"
Given that Ensemble and Cache are one of if not the only true fully object orientated database/development technologies for massive transactional data systems its customizability is extensive and it just comes down to the creativity of the developer to get the products to pretty much do whatever they want to do with it. However, this is not necessarily obvious to newcomers to the technology.
The developer community could do with greater participation from the software developers/application specialists and engineers within InterSystems.
More extensive documentation and greater access to proven working solutions particularly in the realm of some of the lesser known or new and upcoming technologies.
I have yet to raise an issue with InterSystems WRC that they have been unable to resolve to my satisfaction in the 20+ years that I have worked with their products.
If you are looking for a Java-based open source low cost equivalent to webMethods or Azure Logic Apps, Apache Camel is an excellent choice as it is mature and widely deployed, and included in many vendored Java application servers too such as Redhat JBoss EAP. Apache Camel is lacking on the GUI tooling side compared to commercial products such as webMethods or Azure Logic Apps.
Mirth is another integration platform that we have used but its development, in Java, made us always create new methods every time a new product was integrated. Every connection process had to be developed from the beginning and it was not easy to reuse code. Nor did it allow us to have an extensive catalog of HL7 messaging, having to perform the validation of each and every one of its fields manually.
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.
We have integrated 5 laboratories in a treatment monitoring system in less than a month of development. Being able to integrate the following in a period no longer than a week.
