Apache Camel

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

I used it when I worked at Verizon Wireless. We used apache Camel on a couple projects as an integration layer between the UI and backend services and databases. We used Apache Camel's REST component. We used it as xml and java dsl [solution].