| <div class="wiki-content maincontent"><p>Apache ActiveMQ is a messaging provider, with extensive capabilities for message brokering. Mule is described as an ESB, in that it defines and executes the brokering of message exchanges among integrated software components.</p><h4>Architecture</h4><p>Mule provides an accessible programming model for integration, designed to work well with - and leverage - other middleware technologies. For this reason, Mule does not provide a native messaging system, and it is therefore frequently used with Apache ActiveMQ.</p><p>If you use Mule to define an integration based on Apache ActiveMQ, you would use a distinct framework, (the Mule Component Model) to define interfaces for connectivity, as well as mediating activities such as transformations and exception handling. (Note that the Mule framework model presumes a SEDA process model.)Used in this manner, you could think of Mule as a library for defining the interactions among components, with the advantage that it is loosely coupled to both the integrated components and the messaging infrastructure.</p><p>If you have made the choice to use Apache ActiveMQ for messaging and such loose coupling to the messaging infrastructure is not required, you can also configure ActiveMQ directly or through the <a shape="rect" href="http://activemq.apache.org/camel/">Apache Camel container</a>. This may give you access to message handling features not defined in the Mule framework, while still providing connectivity to non-JMS clients through ActiveMQ's numerous options for client connectivity. Working with ActiveMQ directly also allows you to take advantage of clustering and failover capabilities that lie outside the scope of the Mule Component Model.</p><h4>Points in Common</h4><p>The Mule framework is quite user-friendly, is Java-based (Mule components, called Universal Model Objects, are essentially POJOs), and is both flexible (deploys to virtually any Java environment) and lightweight (can be deployed in Spring). These are advantages that it shares with ActiveMQ, so it's not surprising that the two technologies were often used together, before the advent of <a shape="rect" href="http://activemq.apache.org/camel">Apache Camel</a></p><h4>"ESB" versus "Messaging"</h4><p>Mule supports a number of integration capabilities that go beyond the scope of messaging, such as BPEL-based orchestration and (SOAP-to-Java) Web Services support. These are rightly described as ESB features, in that they are more than what one would expect from a messaging platform alone. For environments with these requirements, Camel or Mule provides a good extension to the capabilities of ActiveMQ.</p><p>Additional ESB requirements, such as support for a distributed architecture and a native JBI container and components, are not supported by Mule. If you require these capabilities, we encourage you to investigate other open source ESBs that also integrate Apache ActiveMQ, such as <a shape="rect" href="http://servicemix.org/">Apache ServiceMix</a>, and even the <a shape="rect" href="http://incubator.apache.org/cxf/">Apache CXF</a> service framework.</p><h4>Commercial Support, Copyright and License</h4><p>Both Mule and ActiveMQ have commercial support available from companies dedicated to the technologies. The commercial support corporation for Mule (MuleSource) holds the copyright to Mule, and licenses it under an open source license adapted from the Mozilla Public License (an "MPL+" license). Apache ActiveMQ is an open source project at the Apache Software Foundation, and as such is available under the Apache License 2.0. Commercial support for ActiveMQ is provided by <a shape="rect" href="http://open.iona.com/">Iona plc</a>.</p></div> | |