In december 2007 the Apache ActiveMQ community released version 5.0 of their message broker. A couple of new features have been added to the broker. One very interesting feature that has been implemented is the complete integration of Camel into ActiveMQ.Camel is a subproject of ActiveMQ, developed by the same community which provides an implementation support for enterprise integration patterns. Patterns can be used by either coding them with a specific Java DSL or by using Spring XML configurations. The Camel project website provides a full list of supported patterns and coding examples for them.
Before the release of ActiveMQ 5.0 the following procedure had to be went through when deploying Camel rules:
- Start the message broker
- Create a CamelContext, either in Java or Spring configuration
- Add all required Camel rules to the context
- Start the context
But now it is possible to configure all rules directly in ActiveMQ. The configuration file (conf/activemq.xml) contains an element camelContext where one can specify rules in XML or a package which contains all rules written in Java DSL. When using Java DSL all routes have to be put into a jar file which has to be copied into the lib folder of ActiveMQ.
A simple routing configured in XML could look like this:
The Java class for implementing this route looks like this:
In the ActiveMQ configuration this class can be referenced by using the package XML Tag in the Camel configuration. Thus, there are two ways to configure Camel rules directly in the ActiveMQ configuration file.
I think the prefered way should be to use Java DSL for coding all routes as it is more readable than long complex XML statements. Furthermore the usage of Java DSL splits the configuration of the broker and the implementation of patterns apart which leads to a better clearness as the configuration is not blown up with long Camel XML routes. However for very simple rules the XML approach is faster to configure and to deploy than writing a Java class. But as soon as rules are getting more complex the Java approach should be prefered.
Conclusion
The integration of Camel adds routing and mediation capabilites to ActiveMQ which one would usually expect from an enterprise service bus, but not from a message broker. Thus for business cases where only routing and transformation of messages are needed, ActiveMQ can replace an ESB framework like Mule or ServiceMix.
However if orchestration or choreography are required the use of ActiveMQ alone is not enough. Nevertheless the new release of ActiveMQ makes it a good player in the EAI domain because not only messaging- but also capabilities of an ESB are provided.
I think the prefered way should be to use Java DSL for coding all routes as it is more readable than long complex XML statements. Furthermore the usage of Java DSL splits the configuration of the broker and the implementation of patterns apart which leads to a better clearness as the configuration is not blown up with long Camel XML routes. However for very simple rules the XML approach is faster to configure and to deploy than writing a Java class. But as soon as rules are getting more complex the Java approach should be prefered.
Conclusion
The integration of Camel adds routing and mediation capabilites to ActiveMQ which one would usually expect from an enterprise service bus, but not from a message broker. Thus for business cases where only routing and transformation of messages are needed, ActiveMQ can replace an ESB framework like Mule or ServiceMix.
However if orchestration or choreography are required the use of ActiveMQ alone is not enough. Nevertheless the new release of ActiveMQ makes it a good player in the EAI domain because not only messaging- but also capabilities of an ESB are provided.
Article by Robert Thullner, edited by Alexander Schatten
No comments:
Post a Comment