What is Mule?

What is Mule?

Mule is a messaging platform based on ideas from Enterprise Service Bus (ESB) architectures. An ESB works by acting as a sort of transit system for carrying data between applications within or outside your intranet. The ESB defines a series of stops, or "endpoints", through which applications can send or receive data onto or from the system. The heart of the system, the messaging bus, is what routes messages between endpoints. The messaging backbone of the ESB is usually implemented using JMS, but any other message server implementation could be used, such as MSMQ, IBM WebsphereMQ (and earlier versions know as MQ Series) or TIBCO Rendezvous.

Mule, in fact, goes beyond the typical definition of an ESB. We prefer to define Mule as a light-weight messaging framework that contains a distributable object broker for managing communication between applications. The point of the object broker is to manage service components. These components are called Universal Message Objects or UMOs, and are basically just plain old java objects (POJO). UMOs can exist in the same VM or can be scattered around your network and the Internet. The object broker itself follows a Staged Event Driven Architecture or SEDA design pattern. All communication between UMOs and other applications is made through message endpoints. These endpoints provide a simple and consistent interface to vastly disparate technologies such as JMS, SMTP, JDBC, TCP, HTTP, XMPP, file, etc.

The diagram below shows a common scenario with Mule. Mule applications usually consist of many Mule instances across the network. Each instance is a light-weight container that hosts one or more UMO component. Each UMO component will have one or more endpoints that it will send and receive events through.

Is Mule an ESB?

Mule was designed around the concepts of ESB, but evolved the design to provide greater flexibility in the way in which services can communicate with each other. ESB standardizes on the notion of a message bus, whereas Mule services can communicate over a whole range of communication channels. Think of an ESB as a topology - a way to organize components and their interactions. Where Mule differs from an ESB is that it supports the ESB topology but also others: pipeline, peer network, client/server, hub-and-spoke, embedded and more. These can also be mixed and matched to model complex enterprise messaging and service requirements. For more information see the Topologies page.

Mule has been designed to provide a simple, powerful model of wiring POJO (Plain Old Java Object) services together using endpoints and makes 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.

Why Mule?

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 messaging 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 with no development or maintenance overhead
* Flexible. A powerful configuration that should be easy to manage over a distributed environment.

When the Mule project started there seemed 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. The key feature here is "simple"; although many brokering and integration technologies offer the ability to connect 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.

Mule is in no way a replacement for existing application framework. 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.

How do I get started?

That couldn't be simpler! The quickest way to get started is to follow the links under the "Getting Started" menu, which are listed here as well.

1. Downloading Mule :http://www.mulesource.com/download/
   
2. Installing Mule
3. Running Mule
4. Using Mule Samples