Enterprise Integration Patterns in Java using a DSL via Apache Camel

For those of you who missed me rambling about this at JavaOne I thought I'd introduce Camel to you.

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 Domain Specific Language means that Apache Camel can support type-safe smart completion of routing and mediation rules in your IDE using regular Java code without huge amounts of XML configuration files; though Xml Configuration inside of Spring 2 is also supported.

A good way to get started is to take a look at the Enterprise Integration Patterns catalog and see what the Java code of an example looks like. For example, try the message filter, content based router or splitter.

Apache Camel is heavily influenced by the fluent APIs or Java DSLs used in projects like jMock for testing mock objects and LiFT for testing web applications (both of which are great frameworks BTW), where Camel's primary focus is on the easy creation of routing & mediation rules (and all the Enterprise Integration Patterns) together with testing them.

One of the things I'm most proud of is the Mock endpoint support which makes it very easy to test that your routing and integration rules do what you think they do; rather like with jMock you can create expectations up front (things that at the end of the test you expect to happen) then fire in some messages to some endpoints; then assert that things arrived at the mock endpoints as you expected. This includes adding jMock/LiFT style assertions on things; such as the second message received on a specific mock endpoint has a header called "foo" of value "bar". This can be expressed as

endpointA.message(1).header("foo").isEqualTo("bar")

All with nice Java IDE smart completion. I've really wanted something like Camel for a while; a nice easy way to configure EIP rules without having to resort to reams of XML - plus being able to test things in a distributed message based system easily is very useful.

Incidentally if you're curious of the name, here's why we called it Camel