The Camel DSL

All integration routes are defined in Camel through its own domain-specific language (DSL). This book presents the two main DSL flavors when discussing routing, the Java DSL, and the Spring XML DSL. OSGi Blueprint XML DSL is modeled after Spring, and is touched on lightly in this book. The Spring and OSGi Blueprint XML DSLs are collectively referred to as the XML DSL). There are other DSL variants available for defining Camel routes, including Groovy and Scala. For details on these see the following links:

• Groovy DSL: http://camel.apache.org/groovy-dsl.html
• Scala DSL: http://camel.apache.org/scala-dsl.html

Here is an example of a classic Content Based Router configured in Camel using both the XML and Java DSLs. You can find out more details on this in the Content Based Router recipe in Chapter 2, Message Routing.

In the XML DSL, you would write the routing logic as:

<route>
  <from uri="direct:start"/>
  <choice>
    <when>
      <simple>${body} contains 'Camel'</simple>
      <log message="Camel ${body}"/>
    </when>
    <otherwise>
      <log message="Other ${body}"/>
    </otherwise>
  </choice>
  <log message="Message ${body}"/>
</route>

In the Java DSL, the same route is expressed as:

from("direct:start")
  .choice()
    .when().simple("${body} contains 'Camel'")
      .log("Camel ${body}")
    .otherwise()
      .log("Other ${body}")
  .end()
  .log("Message ${body}");

The decision of which flavor of DSL to use is largely a personal one, and using one does not rule out using another alongside it. There are pros and cons to each, though none are functional. All of the DSL variants allow you to fully use Camel's features.

DSL	Pros	Cons
Java	Routes can be defined in a very flexible manner (for example, the definition of a route can be conditional depending on the environment) RouteBuilder objects can be instantiated multiple times with different processors and endpoints, allowing route templating Routes tend to be shorter in terms of lines of code than the corresponding XML Each RouteBuilder can be tested independently without requiring the startup of every route in the whole Camel context	Route definitions can sometimes get too clever in their use of advanced Java language features, such as large anonymous inner classes code blocks for in-lined processor steps, obscuring the intent of the route, and making future code maintenance more difficult As routes are defined using the builder pattern, automatic code reformatting in an IDE will mess up your indentation It may not always be obvious where a block of processing steps within an EIP ends It is sometimes necessary to break up the use of some EIPs within other EIPs to their own sub-routes due into limitations of using Java as a language for writing DSLs
XML	Easily formatted automatically Easier to read by non-Java programmers Supported by round-trip engineering tools such as the Fuse IDE and hawtio Easier to use for environments where it may be difficult to deploy Java code, for example, alongside ActiveMQ configurations	Verbose ("death by angle bracket") Not as easy to test as standalone Java routes; any Spring bean dependencies within routes pointing to external resources need to be mocked or stubbed in test Spring configurations