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 had some workloads where we need to integrate multiple sources & sinks of data, with different formats & protocols, while doing some pretty complex logic on top of that. Apache Camel was a natural choice for it since there are tons of built-in components that allow making easy connections to all the sources & sinks that we need. On the other hand, the Java-native nature of Apache Camel means writing & testing whatever logic we need is just business-as-usual for the engineers.
Pros
Easy & reliable integration with lots of types of source or sink of data.
Complex business logic could be written in Java.
Excellent unit testing support with Java.
Cons
Documentation could be improved
Support for complex & advance integration options could be better
Navigating the Java code base requires learning curve
Likelihood to Recommend
There are tons of integration technologies available, the point is to pick the one most suited for your use case. Apache Camel offers easy connections to lots of types of sources or sinks of data while supporting custom complex business logic, all testable. However, it means configuring using Java source code, which is a hurdle when all your logic need is very simple. There are many other GUI-based integration technologies that get those types of logic-lite work done faster.
We use Apache Camel as a bridge between various systems, where implementation and message format is changing fairly often. Integration and tasks workflow pipeline. This system allows for fast and scale able integrations and deployment. This has saved us man time and power.
Pros
Adding new routes is very easy and efficient
Easy to use, easy to get up and running
Great integration with java frameworks
Cons
The documentation is a little deficient
Lacking a framework integration with big data capabilities
Likelihood to Recommend
Could be used to trigger batches and do large-scale processing, using its throttling. We have lots of end-points where the system needs to talk and pass the request to get the response. Using Apache camel it is extremely easy to configure and implement such business requirements. However, the drawback is you need someone in your team to understand and code for Apache Camel.
VU
Verified User
Engineer in Information Technology (5001-10,000 employees)
Apache Camel is used to provide a component of our Enterprise Service Bus, we use it for defining message routing and transformation rules, enabling the business to integration disparate on premise applications and cloud services in a robust and relatively low effort way. Our primary pattern for integration that we use is asynchronous messaging exchanged via an Enterprise Service Bus.
Pros
Rules for routing messages between senders and receivers
Applying transformations to messages
Low cost low effort solution
Cons
Open source solution relies on community for support
Lacks graphical user interface for message routing and transformation definitions
Relatively steep learning curve
Likelihood to Recommend
Apache Camel is a very mature open source solution for implementing enterprise integration patterns, and is good for organizations that are comfortable using open source solutions with only community support that need the ability to route and transform messages between senders and receivers connected to an enterprise message bus solution with no licensing costs.
VU
Verified User
Professional in Information Technology (5001-10,000 employees)
My team uses Apache Camel as a Platform as a Software service in the tech stack to perform integration of their code on a component basis by deriving it from files based on a defined logic and processes and then make those available to testers and UAT group. Apache Camel being opensource is very helpful for our team to perform their daily integration activities in non prod environment for quick testing of their work.
Pros
open source and a great set of component feature set - always latest features available for integration
works well with spring boot
great community and support for any kind of workflow
based on enterprise integration patterns which helps our developers achieve integration tasks with all kinds of API services
Cons
didn't work well when our developers tried to transform heavy data sets
Apache Camel's whole logic is based on java so team needs to have a great skill set in java
if there are a handful of workflows then Apache Camel's full potential can't be realized
Likelihood to Recommend
very well suited when data has to be extracted in itself from files based on defined logic and process workflows and integrated with other processes and applications in your architecture. Our teams put a gateway in front of the APIs for integrating data and ensuring data integrity before letting the application process the data.
VU
Verified User
Analyst in Information Technology (10,001+ employees)
I've used Apache Camel as a great alternative integration framework compared to heavier middleware solutions from companies like IBM. It serves that purpose wonderfully, and is a total pleasure to use. Great plugins for almost any connector you could need, and they all work as expected.
Pros
Open source, which is vitally important
Great integration with Java frameworks such as Spring Boot, allowing it to be deployed however you need to deploy it
Wonderful testing tools as part of the framework
Cons
Documentation could use some work, sometimes it takes a bit of trial and error to figure out how to do something.
Likelihood to Recommend
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.
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.
Apache Camel is being used for multiple projects in different organizations that I have worked at. It is being leveraged for EIP as well as writing event based code.
I worked for an organization that used Camel with Karaf (OSGi) and other organizations where Camel was used just as an open source framework.
Pros
EIP - enterprise integration patterns. Read events from queue, route to different processes and work on the messages.
REST APIs- Apache CXF is used and Camel could be used to provide endpoints.
Batches - Camel could be used to trigger batches and do large scale processing, using its throttling. It provides lots of connectors to work with.
Cons
I feel that Apache Camel is lacking a Spring XD like framework integration with big data capabilities.
Apache Camel seems to be very dependent on Spring.
Likelihood to Recommend
Camel is very suited where ever you want to use enterprise integration patterns like endpoint integration, routers, aggregators, splitters etc. Also Camel can be used for REST endpoints, designing event driven systems and integration with queues and it provides whole lot of connectors for integration with social etc.
When we switched from a monolithic architecture to a service oriented one we were researching on all the enterprise integration technologies. We chose Apache Camel because it was lightweight, was easy to get started with, had a groovy DSL and because it was an implementation of existing integration patterns. Over the last few years, Apache Camel became the glue that binds all our micro services. We use publish-subscribe pattern the most i.e consuming from and producing to AWS SQS queues. A lot of our quartz jobs are heavily depended on Apache Camel as well. I would highly recommend Apache Camel as a lightweight yet formidable enterprise integration solution.
Pros
Producing to and consuming from any messaging system
Message type conversion
Large support library
Cons
Documentation could use some more detail
Hot deployment
Likelihood to Recommend
For basic publish subscribe use cases, Apache Camel is the clear winner.
Apache Camel is used by many departments at Cox Communications, but not the entire organization. It enables quick and scaleable integration of diverse business systems at Cox and reduces development effort and resources. Various Camel components are used and there is even a customized version of Camel Http4 component. Also Camel fits well in the existing infrastructure at Cox.
Pros
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.
Camel is also good for creating microservices.
Cons
Camel features and documentation can get confusing to new users. Documentation can and should be improved. Also it would help if there are more tutorials available. Certification in Camel and related technologies like Servicemix and Karaf would also help.
The Camel infrastructure probably needs to be rebuilt (hopefully this may happen with version 3.0). At this time the latest production release of Camel (2.17.x) is not built with the latest version of Java (JDK 1.8).
Camel should also move towards becoming a "heavyweight" ESB product, though this may detract from some of its desirable features.
Likelihood to Recommend
Apache Camel is well suited for integration of existing software programs/components with newer and external systems. It supports SOAP and REST protocols pretty well. It was not designed to directly support front end systems. It has limited to non-existent support for Javascript. It is not suitable for creating simple standalone applications and meaningful deployment does require use of other frameworks like Spring/Karaf/JBoss.
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.