- Start the message broker
- Create a CamelContext, either in Java or Spring configuration
- Add all required Camel rules to the context
- Start the context
The Java class for implementing this route looks like this:
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.
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.