Article

Which Camel DSL should you use?

Java, XML, and YAML DSLs: A comparison

September 20, 2023
Camel KIntegrationKubernetesMicroservices
Technical Marketing Manager
Bruno Meseguer
Technical Marketing Manager
A code editor with four icons symbolizing DevOps, developers, a gear, and a cluster.

Every developer (at some point) has to write code to interact with subsystems of some sort, databases and other types of storage, message brokers, or remote services, to name a few. When you need to do it often (or even if you don't), it is best to find an integration tool to help out.

Apache Camel is a powerful integration library that provides mainly three things: 

  • Lots of integration connectors.
  • Implementation of multiple integration patterns.
  • A higher-level domain-specific language (DSL) abstraction to glue all together nicely.

And why are integration technologies better fit for the task than developers writing their own code using a mix of libraries? The answer is, as usual, for more than one reason. However, much has to do with the DSL the tool provides to help developers define processing flows in a leaner and more efficient manner.

Note: This article is an update to Which Camel DSL to choose and why?

5 benefits of DSLs

The advantages of using a DSL over general-purpose languages are the following:

  1. They are easier to work with. The code is easier to understand. To begin with, you can see where the main logic begins and ends. For example, code written in C++ or Java is more challenging to follow all the way through and may contain buggy behavior that is difficult to locate.
  2. They produce safer code. In the case of Apache Camel, its DSL relies on solid and proven building blocks. It internally wires all the processing steps together, leaving the developer to focus on what's important: the business use case at hand.
  3. Errors are domain-specific. When failures arise, error descriptions are more explicit and explanatory. Also, DSLs provide a safety net preventing developers from falling into error scenarios that are hard to explain, like some unexpected null pointer exceptions of difficult interpretation. Simpler code also means less error-prone code.
  4. They are easier to port. DSLs are designed to be platform-independent. Think about how code is generally affected when moving from one platform to another; it typically requires adaptation. Because DSLs are an abstraction language protecting developers from underlying complexity, they delegate the impact of any code change to lower layers. Take, for instance, Apache Camel and how it has evolved over the years; its DSL has barely changed during that time.
  5. They contribute to faster learning. Solving complexity from scratch is hard. A DSL focuses on a particular domain to help developers. A simpler language saves them from learning it all. It accelerates them in knowing how to deliver solutions, resulting in more and faster productivity.

DSL choices in Camel

Something unusual about Apache Camel, in contrast to other options out there (or DSLs in general), is that you can implement the same DSL flow using different languages (Figure 1). For example, you can write a Camel route that bridges messages using Java, XML, or YAML. The community even supports a few more languages to choose from.

Figure 1. DSL choices in Camel.
Figure 1. DSL choices in Camel.

The popularity of Apache Camel and its widespread adoption made Camel respond to different developer language preferences. Also, how trends push technologies in one direction influences their roadmap. The latest DSL added to Camel is YAML, helping to pave the way to cloud-native integration in Kubernetes environments.

Which DSL to choose?

Red Hat Integration Architects strive 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 customers ask at the start of every new Camel-based project is: “Which Camel DSL should we use? What are the pros and cons of each?”

There are two pieces of good news for you. First, by choosing to use Apache Camel, you have already made the right decision. Camel will be a very useful toolkit in your arsenal of libraries for lots 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.

The reality of a personal DSL preference is that different developers like different DSLs. Good reasons for one developer to choose a DSL might not be relevant to another. We have, however, compiled a comprehensive comparison chart. It is a brain dump from multiple engineers developing Apache Camel and consultants using Camel at multiple customer projects across the globe. Pick the arguments that are valid in your context and make your choice.

Read on for a comparison of Java, XML, and YAML DSLs, also shown in Figure 2.

Figure 2. Comparison chart of Camel Java/XML/YAML DSLs
Figure 2: Comparison chart of Camel Java/XML/YAML DSLs.

Linked in Figure 2:

Development tools

  • Java DSL
    • You can use every IDE with Java support. 
    • Red Hat provides tooling in VS Code when installing the Extension Pack for Camel. It contains all the necessary extensions to work with Camel in VS Code. This includes language support for Camel K Java standalone, support for Camel URI completion and diagnostics, and running and debugging Camel routes from the source editor.
    • Community provides a plug-in for IntelliJ IDEA, which supports Java, XML, and YAML DSLs. It provides code assistance and offers a route debugger.
    • Language support and basic Camel textual route debugging is also provided in Eclipse Desktop.
  • XML DSL
    • You can use every IDE with XML support.
    • Red Hat provides tooling in VS Code when installing the Extension Pack for Camel. It contains all the necessary extensions to work with Camel in VS Code. This includes Camel URI completion and diagnostics, ands running and debugging Camel routes from the source editor.
    • Community provides a plug-in for IntelliJ IDEA, which supports Java, XML, and YAML DSLs. It provides code assistance and offers a route debugger.
    • Language support and basic Camel textual route debugging is also provided in Eclipse Desktop.
  • YAML DSL
    • You can use every IDE with YAML support.
    • Red Hat provides tooling in VS Code when installing the Extension Pack for Camel. It contains all the necessary extensions to work with Camel in VS Code. This includes language support for Camel URI completion and diagnostics as well as running and debugging Camel routes from the source editor. It also includes the Kaoto VS Code extension, which offers a visual integration designer.
    • Community provides a plug-in for IntelliJ IDEA, which supports Java, XML, and YAML DSLs. It provides code assistance and offers a route debugger.
    • Language support and basic Camel textual route debugging is also provided in Eclipse Desktop.
    • Apache Camel Karavan offers a VS Code extension with a visual integration designer. See Camel Karavan.

Hawtio / Fuse Console

  • Java DSL
    • Hawtio retrieves the routes from the runtime as XML and display the routes regardless of which DSL was used to create the routes.
  • XML DSL
    • Hawtio retrieves the routes from the runtime as XML and display the routes regardless of which DSL was used to create the routes.
  • YAML DSL
    • Hawtio retrieves the routes from the runtime as XML and display the routes regardless of which DSL was used to create the routes.

Software development model

  • Java DSL: The DSL adopts a fluent builder API, which Java teams are increasingly familiar with.
  • XML DSL: Modeling development approach with graphical editor is possible (Eclipse Desktop). Allows drag-and-drop based development. Textual-based development is also possible with very mature IDE support.
  • YAML DSL: Harder to write from scratch, but certain tools can help. A modelling development approach with a graphical editor is possible—see Kaoto.

Debugging code

  • Java DSL
    • There are IDE plug-ins that can do DSL debugging step by step over the EIPs. You can step into the RouteBuilder, but keep in mind, it is called only at startup and not during processing.
    • Breakpoints can be put in Java code of the core Camel classes.
    • It is possible to add temporary Processors and use the Java debugger. See demo videos.
  • XML DSL
    • There are IDE plug-ins that can do DSL debugging step by step over the EIPs. Additionally, breakpoints can be put in Java code of the core Camel classes. See demo videos.
  • YAML DSL
    • There are IDE plug-ins that can do DSL debugging step by step over the EIPs. Additionally, breakpoints can be put in Java code of the core Camel classes. See demo videos.
  • For all DSLs, see Aurélien Pupier's Debugging in VS Code demo videos on YouTube.

Integration with dependency injection (DI) frameworks

  • Java DSL: It's easier to integrate with any DI framework, being pure Java.
  • XML DSL: While it is possible to refer to existing beans from DI frameworks in XML DSL, declaring new beans in XML makes these beans exclusive to Camel itself, and not part of the DI framework (i.e., Quarkus or Spring Boot).
  • YAML DSL: While it is possible to refer to existing beans from DI frameworks in YAML DSL, declaring new beans in YAML makes these beans exclusive to Camel itself, and not part of the DI framework (i.e., Quarkus or Spring Boot).

Team size and churn

  • Java DSL: More flexible, but harder to read code. Good for small co-located teams that work and support code for a long period.
  • XML DSL: Beneficial for large and disparate teams, as it doesn't require Java knowledge. Less flexible, making it challenging to create complicated routes.
  • YAML DSL: Beneficial for large and disparate teams, as it doesn't require Java knowledge. Less flexible, making it challenging to create complicated routes..

Team structure

  • Java DSL: Requires the team to have Java developers for developing Camel integrations. Also, other team members such as support, the business, and testers have to understand Java in order to read the integration flow.
  • XML DSL: XML is a widespread language, and all developers can reuse existing skills when developing with Camel. It offers a higher level of abstraction and makes it easy to communicate  with business developers and support teams.
  • YAML DSL: YAML is a widespread language, and all developers can reuse existing skills when developing with Camel. It offers a higher level of abstraction and makes it easy to communicate with business developers and support teams.

Developer experience and preference

  • Java DSL: More suited to experienced developers as Java is more concise than XML, with inner classes and functional aspects. Java developers tend to prefer pure Java and annotations rather than XML.
  • XML DSL: Ideal for new users, as it offers a graphical approach for designing routes.
  • YAML DSL: Ideal for new users, as it offers a graphical approach for designing routes.

Summary

  • Java DSL: Good for Java-focused small teams that can manage slightly more complicated but shorter and concise code base.
  • XML DSL: Good for teams new to Camel or large mix-skilled teams where many developers have to read, write, and maintain the integration code.
  • YAML DSL: Good for teams new to Camel, or large mix skilled teams where many developers have to read, write, and maintain the integration code.

Key takeaways

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 all DSLs to be equally popular. The more important takeaway from here is 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 hardcore Java shop, and we hate XML” or “Can we do it all through drag-and-drop?”

All that said, the only advice I can offer 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.

Whatever DSL you choose, it will not influence the success of your project. Depending on the scenario, you might want to mix DSLs in order to achieve the best developer experience possible.

Learn more about Camel