Apache Camel is a powerful integration library that provides mainly three things: lot’s of integration connectors + implementation of multiple integration patterns + a higher-level Domain Specific Language (DSL) abstraction to glue all together nicely. While the connectors and pattern choices are use case and feature driven and easy to make, choosing which Camel DSL to use might be a little hard to reason about. I hope this article will help to guide you in your first Camel journey.
I work for Red Hat Consulting as an Integration Architect and one of my primary goals is to help customers get the design and the architecture of their future systems as right as possible, and consequently get the best value out of Apache Camel. One of the common questions I get at the start of every new Camel-based project is: “Which Camel DSL should we use? What are the pros and cons of each?”
I have two pieces of good news for you. First, by choosing to use Apache Camel you have already made the right choice. Camel will turn out to be a very useful toolkit in your arsenal of libraries for lot’s of future use cases and projects to come. And second, the DSL is just a technicality that will not impact the success of your project. You can always change your mind later and even mix and match.
If you are a part of large company, with multiple independent two-pizza size teams that use Java language here and there, the chances are that some teams are already using Camel. Even in small companies, teams use Camel without being aware of each other. Camel is useful for all kind of tasks and has a small enough library for you to add to your pom.xml and use it without a permission from the technical design board. If that is the case, just talk to your colleagues and learn first hand about their experience with their DSL of choice.
If you need a more comprehensive comparison and a reason to choose one of the DSLs, the chart below is a brain dump from multiple engineers developing Apache Camel along with consultants using Camel at multiple customer projects across the globe. Pick the arguments that are valid in your context and make your choice.
If this table doesn’t give you the straight answer you were looking for, probably the answer is: it doesn’t matter. Camel has multiple DSLs, but there are good reasons for both Java and XML-based DSLs to be equally popular. The more important takeaway from here is for developers to get used to thinking in terms of Pipes and Filters, learning the Enterprise Integration Patterns and their notations. Using one of the Camel DSLs to express these patterns is a technicality without a technical consequence. Usually it is a team preference and culture-based choice, such as “We are a hard-core Java shop and we hate XML” or “Can we do all through drag and drop?”.
All that said, the only advice I can suggest is to strive for consistency. Avoid using different DSLs in the same service, even for different services in the same project. If you can convince everybody in the company to use the same DSL, even better.
About the author:
Bilgin Ibryam is a member of Apache Software Foundation, Integration Architect at Red Hat, a software craftsman and blogger. He is an open source fanatic, passionate about distributed systems, messaging and application integration. He is the author of Camel Design Patterns & Kubernetes Patterns books. Follow @bibryam for future blog posts on related topics.
Red Hat JBoss Fuse is an open source, lightweight, modular integration platform. Leveraging Apache Camel, JBoss Fuse comes with over 160 built-in components. Get started with JBoss Fuse development using Red Hat Development Suite.