sorted by: recent | see :
popular
Content Tagged EIP
Apache Camel on OpenESB
|
Srinivasan Chikkala reports that support for Apache Camel has been added to OpenESB via the Camel Service Engine (SE) and shows how to use it in this screencast. |
Apache Camel can be used for routing and mediation rules and adds one more option for defining the interactions between services to OpenESB by using a Java domain specific language (DSL), Spring based XML configuration, or the (work in progress) Scala DSL.
Louis took the new capability for a test drive with a detailed "how-to" write-up and his impressions in his quest to replicate the demo scenario shown in the Project Fuji preview at JavaOne this year.
The standards based pluggability of OpenESB allows this new component to leverage and be combined with any of the other 30+ components now part of the OpenESB community.
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
XPath based splitter in one 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 :)
