Wanna try our Apache Camel developer tools for Enterprise Integration Patterns?

When I first created Apache Camel one of my design goals was to let folks describe the Enterprise Integration Patterns as easily as possible using concise and declarative domain specific languages instead of reams of confusing opaque bean configurations.  So whichever the developer prefers, a DSL in Java, XML, Scala, Groovy, Ruby etc. It was always part of the plan to actually have a visual domain specific language too and we've finally created one.

We're just starting the public beta of Fuse IDE for Camel, our Eclipse tool suite that lets you visually create, edit and configure Enterprise Integration Patterns easily using Apache Camel and its huge selection of patterns and components.

If you use Apache Camel or have always meant to give it a try then please install it, take it for a spin and see what you think. We'd love to hear your feedback on the tool & how we can improve it!

We've lots of things planned for the tool; this is just the beginning...

Enterprise Integration Designer preview

From Oisin's blog.

Thanks to Enterprise Integration Patterns, architects have a clear and succinct way to describe integration within complex systems. It certainly beats a lot of MS-Word documents and monster integration architecture diagrams. And, with Apache Camel, we’ve got an open source runtime that allows us to create routes by chaining EIPs together, using Spring XML or Java fluent builders. That’s fantastic, but EIPs are as much about sharing pictures as creating message routing graphs, and where are the pictures?  

We’ve made some tools that will allow you to load up Camel Spring XML files into Eclipse for visual inspection and editing. You can also create EIP diagrams in your Workbench and save them as Camel configurations. Finally, we’ve put in some debugging capabilities to allow you trace through the paths a message will take through your EIP graph.  

We are earnestly seeking feedback - check out the FUSE Integration Designer Preview page to download the Eclipse plugins, or check out the video links under the Training Videos at the bottom of the page.

Looks great! Feedback greatly appreciated

XPath based splitter in one line of Java code

This came up in a recent thread & thought I'd mention it here for those not on the list. If you want to implement the Splitter Pattern from the Enterprise Integration Patterns using XPath then you can use the following line of Java code...

from("activemq:my.queue").
 splitter(xpath("/invoice/lineItem")).
 to("file://some/directory");

Pretty neat eh. Use any language you like for the expression such as XQuery, SQL, Groovy, Ruby etc.
It sure beats programming in XML :)

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