What is Mule?

Mule is a light-weight messaging framework. It is a highly distributable object broker that can seamlessly handle interactions with other applications using disparate technologies, transports and protocols.
The Mule framework provides a highly scalable environment in which you can deploy your business components. Mule manages all the interactions between components transparently whether they exist in the same VM or over the internet and regardless of the underlying transport used.

Mule was designed around the Enterprise Service Bus architecture, which stipulates that different components or applications communicate through a common messaging bus, usually implemented using Jms or some other messaging server.
Mule goes a lot further by abstracting Jms and any other transport technology away from the business objects used to receive messages from the bus.

Key Features

• J2EE 1.4 Enterprise Service Bus (ESB) and Messaging broker
• Pluggable connectivity such as JMS (1.0.2b and 1.1), VM (embedded), JDBC, TCP, UDP, multicast, http, servlet, SMTP, POP3, file, XMPP.
• JBI Integration.
• Orchestration of services using WS-BPEL and Mule components and routers.
• Support for asynchronous, synchronous and request-response event processing over any transport.
• Web Services using XFire (STaX-based) Axis or Glue.
• Flexible deployment Topologies including Client/Server, Peer-to-Peer, ESB and Enterprise Service Network.
• Declarative and Programmatic transaction support including XA support.
• End-to-End support for routing, transport and transformation of events.
• Spring framework Integration. Can be used as the ESB container and Mule can be easily embedded into Spring applications.
• Highly scalable enterprise server using the SEDA processing model.
• REST API to provide technology agnostic and language neutral web based access to Mule Events
• Powerful event routing based on patterns in the popular EIP book.
• Dynamic, declarative, content-based and rule-based routing options.
• Non-Intrusive approach. Any object can be managed by the ESB container.
• Powerful Application Integration framework
• Fully extensible development model

But there are already frameworks out there

It is often misconstrued that Mule aims to be a replacement for existing application frameworks, but this is not the case. In fact Mule leverages many open source projects such as Axis, Spring, ActiveMQ, Plexus and PicoContainer. Mule fills a void in enterprise java development where an application requires complex interactions with a variety of systems on a variety of platforms. Mule makes light work of wiring these systems together in a robust decoupled environment and provides the necessary support to route, transport and transform data to and from these systems.

When to use Mule

The common scenario for using Mule -

• Integration projects where two or more existing systems need to communicate with each other.
• Applications that need to be totally decouple from their surrounding environment or where the ability to scale one more components in the system is needed.
• Single VM Applications where the developer wants to future-proof their application against unexpected distribution or scaling requirements. Mule works very well as a single VM application where interaction between components in the system is achieved in memory with no detectable degradation in performance.

Why not just use Jms?

Jms is a vital tool in the enterprise toolbox, but on its own it leaves a lot of additional work for the developer in order to use it. Mule provides a simple, consistent yet fully customisable way to work with Jms or any other messaging or transport technology. Components in Mule are wired together using a variety of technologies though this is totally abstracted away from the application.
How does Mule compare to JBI?

How do Mule and JBI relate?
Mule and JBI have some overlap in the problems they solve but under the covers they do it in different ways. JBI is XML and WSDL centric where as Mule makes do assumptions about the message type so that you can easily use Strings, binaries, Mime, Xml, objects, streams or a mixture without any extra development.

JBI uses a notion of Message Exchanges and a Normalized Message to communicate between components, where as Mule uses a flexible "POJO / Endpoint" architecture that allows you to develop sophisticated message flows between services using a very simple model.

JBI is a service container whereas mule is more of a ubiquitous messaging fabric that goes beyond integration to provide a solutions for translating, monitoring, routing and orchestrating all type of information around the organization and beyond in a secure, scalable environment.

It's still early days for JBI and the specification makes a lot of assumptions about the data being used (read: XML) and is based on WSDL which can be woefully complex for a lot of situations where it's just not necessary.

Goals

The goals of the Mule project and Universal Message Objects have been heard before a thousand times although not necessarily delivered together (or even delivered!) -

• Scalable Enterprise Service Bus framework that should handle most of the complexities of systems integration.
• Easy to use, yet powerful server that can operate over complex topologies.
• Simple Autonomous component development and deployment
• Code reuse. If all components are self-contained, independent units of work they can be plugged into any other system
• Rapid time to market. Using Mule will provide time-saving features and functionality and should certainly not result in any development or maintenance overhead
• Flexible a powerful configuration that should be easy to manage over a distributed environment.

When the Mule project started there seems to be a gap in the market for a simple and lightweight way to write components that do something to data without needing to worry about the sender or recipient of the data, the format of the data or the technology being used to send/receive the data. I emphasis simple because although many brokering and integration technologies offer ways of connecting to disparate data sources, you often have to do extra coding to get it to behave the way you want and to deliver the data where you want it to go. Mule allows you to quickly develop components and then change the way they behave through configuration instead of coding.

Not Just an ESB

Mule has been designed to provide a simple, powerful model of wiring POJO services together using endpoints and make no assumptions about the message or interfaces being used. Mule's ultimate goal is to be the "Swiss-army knife" of integration. It is adaptive to its surrounding technology rather than prescribing it. There are no hard and fast rules on how your integration service layer should behave when using Mule; you can pull in JBI, EJB, Mainframe apps, Messaging, web services, sockets and file systems and interact with them all in simple consistent way.

The ESB model is just one topology that Mule supports others include Client/Server, Enterprise Service Network and Peer to Peer, Hub and spoke and embedded. These can also be mixed and matched to model complex enterprise messaging and service requirements. For more information see Topologies.

Mule Flexibility

From the ground up Mule has been designed to be as flexible and extensible as possible. This means that Mule can use services from other frameworks just through configuration. An example of this is the Mule container itself. With a single line of configuration Mule can be set to use Spring, Pico or its own container to obtain Mule managed components. This means that your application can make use of all the functionality of these applications as well as the additional features of Mule.

Spring Framework Integration

Mule has full support for Spring and its even possible to have the whole Mule server instantiated by Spring as well as using the spring container to obtain managed objects. This ability exposes every object in Mule including the server itself to Spring's transaction management, aop and jdbc/dao framework.. Mule and Spring are a powerful combination. You can also levage Mule eventing capabilities in you Spring application by uing the Mule Event Multicaster for Spring. This plugs into the Spring Apllication Context allows your components to send and receive Mule events via the Application context.

Components in Mule

A component is a business or application object which is managed by Mule. Being managed by Mule means that Mule will handle all the interactions to and from the component leaving the component code only need to concern itself with application specific code, i.e. the job its supposed to do.

Mule will manage the following aspects of a component -

• Message delivery - receiving incoming messages to your component will be handled transparently.
• Message transformations - ensuring that the data received is of the type required by the component, the component would receive an PurchaseOrder bean instead of a Jms message.
• Dispatching messages - Once the component is finished with the current message mule will by default handle any further transformations and interactions with other components. Of course the developer the option to override the default configured behaviour at any time.
• Pooling and threading - components can be implicitly pooled and threaded by mule for increased throughput and scalability. This is fully customisable at the component level.
• Exception Handling - all exception handling can be left to Mule. You can define custom Exception handlers for any component to change the way the application behaves when an error occurs.
• Transaction Management - all transaction behaviour including batch commits and rollbacks on exception can all be handled by Mule.
• Lifecycle Management - Mule provides fully customisable support for lifecycle events on a business object. Lifecycle methods are optional.
• Inversion of Control - Using Spring or Pico business objects can be created and initialised by an IoC container.

Mule provides a host of services to enable components to send and receive events over a messaging technology without ever needing to know about the transport, delivery or format of the data, whilst handling all transaction, lifecycle and exceptions transparently.

Non-intrusive approach

There is no requirement by Mule to have your business or application objects extend or implement any classes. Mule also has powerful and customisable Lifecycle support for components. This means that you can have almost any kind of object managed by Mule whether it be a POJO or a component from another framework.
One of the principals of Mule was to make no assumptions about components managed by Mule or how they should behave. Instead Mule provides default functionality with the ability to override the default behaviour.

Where do I go to learn more?

This document provides an overview of some of the aims and features of Mule. To find out more have a look at -

Introduction Introduces the core concepts and the best way to get started.

Mule FAQ A good place to get some of your questions answered plus get the answers to questions you havent thought of yet.

User Guide Provides documentation about the various Mule components, how to use them and how to configure them.

Architecture Guide Provides a reference to workings of the Mule Server describing the features of each element in the system.

Mailing List Is a good place to ask any questions about using mule.