Apache Camel routing rules: a DSL?

Apache Camel is a powerful rule based routing and mediation engine which provides a POJO based implementation of the Enterprise Integration Patterns using an extremely powerful fluent API (or declarative Java Domain Specific Language) to configure routing and mediation rules.

The authors probably meant embedded DSL. The examples of its use feel remarkably similar to "criteria queries" DSLs, as popularized in Java by Hibernate (and yes, many others as well).

To start a discussion - where is the boundary between an API and an embedded DSL? Is it in the eye of beholder or are there some objective differences? Some APIs have a strong feel of a DSL - remarkably various parser libraries in Haskell. Is it the quality of the host language (Haskell) or the domain (parsers)?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What Makes a DSL?

I think there can be value in considering even simple configuration files and APIs as DSLs. The biggest benefit of thinking about APIs as DSLs is that it allows you to take advantage of all of the concepts for versioning, interacting models, refactoring of DSLs and the ideas of separating the concrete syntax from the abstract grammar and potentially supporting n-projections.

We have an in-house generator with a cms for editing metadata that is stored in a database, generated to XML (which is where we're working on formal transformation based approaches to grammar refactorings) and consumed by an API.

When you have an API, you're stuck with an API. When you have a DSL there are lots of potential concrete syntaxes that can be used for different use cases.

The LtU archives contain

The LtU archives contain many discussions about API vs. DSLs. I suggest searching the archives with these two keywords. You'll find plenty of relevant stuff. (Use the google search, to include the "LtU classic" archive).

Read follow post by Martin Fowler

Piers Cawley makes the point that a key characteristic of DSLs is their narrow focus on a domain.


While this is somtimes the

While this is somtimes the case (see the recent discussion of Amazon's Gatekeeper language), the term DSL is often used around here as a synonym for "little language" (the term Jon Bentley used in a classic article in CACM). Not all "little languages" are all that domain specific.

Another thing to keep in mind is that diffeent people think of different things when using the term "domain". Example: Are regualr expressions a DSL (the domain being string recognition) or are they too general to be called domain-specific, since a domain should be a complex set of human activities?

It's all in the question

'I' in the API is the interface. 'L' in the DSL is a language. Language is surely an interface for communication. You can have application-specific programming language -- that's the subset of an API. When your API starts to be domain-specific, you are getting a DSAPI. I believe the difference between API and DSL here is just the last letter -- if you want to call your interface a language or not.


Here's my current informal view:

Language = syntax + semantics
API = data structure + operations

Syntax often reflects an underlying structure, and operations define legal transitions so in a sense, we can establish an equivalence of syntax == structure, semantics == operations; so languages are APIs and v.v. Many APIs are not very well-designed languages, because people don't make this connection, but it's always there.

Also, lifting an API to a real language is only an advantage when you're dealing with multiple abstractions rather than a single abstraction, as working in the host language's syntax is often sufficient for single abstractions. There's a high barrier to entry to creating a new language, hence all the interest in extensible languages/syntaxes, etc.

Multiple abstractions?

What do you mean by the phrase: '... lifting an API to a real language is only an advantage when you're dealing with multiple abstractions rather than ...'?

If your API provides only a

If your API provides only a single abstraction, say a list, then manipulating that abstraction via the host language is often not excessively verbose, and so doesn't warrant a DSL (Lisp has more than one abstraction, since it has other values). However, when you have multiple co-operating abstractions (like LINQ/embedded SQL DSL in HaskellDb), manipulating them via the host language syntax can become cumbersome, at which point a DSL makes more sense.

One way that I like to think

One way that I like to think of this, is to ask "what is the total number of distinct messages that can be produced by this API or DSL?" I tend to think of an API as having a limited and discrete number of messages, because this makes the interface testable. However a language has many more permutations of the messages that can be sent via the interface, so it is governed more by a set of rules about parts of the message. Somewhere along this continuum, where you measure the number of message permutations, I think is the dividing line between an API and a DSL.

Where is the DSL in camel?

Call me thick, but I could not find DSL in Camel. An API - yes, a DSL - no. My prime example of a DSL is R - a language created to tackle the difficulties of statistics and visualisation. Although AFAICT it has grown beyond it and is no longer a little language, but nonetheless, it has been created with a clear goal in mind and designed to facilitate the achievement of the goal in the best manner possible.

Although I am not Enterprise expert, but Camel calling itself route DSL seems to be a bit misleading - I expected it to be a request/request handler mapping, but it turned out to be a component connector (correct me if I'm wrong); from where I stand - quite powerful one.