ESB through Muleframwork


What is Mule?

What is an ESB?

Is Mule an ESB?

Why use Mule?

Is Mule a JBI Container?

How does Mule compare to JBI?

Do Mule and JBI compete?

Can I use Mule with JBI container X?

Why not just use JMS?

How does Mule fit in with my webapp?

Do we need another framework?

Where do I go to learn more?

How can I ask questions about Mule?

I found a bug, what do I do?

I thought of this really cool feature, how can I get it added?

Mule Framework

Why is Mule called Mule?

What do you mean by Lightweight and Event-driven?

How does Mule provide Scalability?

How does Mule enforce decoupling?

What is an UMO component?

What is zero code intrusion?

What about Endpoints, Connectors and Transformers?

Implementing mule framework through eclipse

If you want to build mule framework in eclipse and want to deploy the built in examples

provideded by the mule framework follow this link

Service provisioning through ESB

A complete business scenario example through which you can understand the ESB in mule

framework follow this link

What is Mule?

Mule is an ESB (Enterprise Service Bus) and integration platform. It can be thought of as a lightweight.

Messaging framework and highly distributable object broker that can seamlessly handle interactions with other applications using disparate technologies such as JMS, Http, Email, and Xml-RPC.

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 ESB (Enterprise Service Bus) enterprise integration pattern, which

Stipulates that different components or applications communicate through a common messaging bus,

Usually implemented using JMS or some other messaging server.

What is an ESB?

ESB or "Enterprise Service Bus," refers to a range of functions designed to offer a more flexible and

manageable way to enable a disparate range of applications to work together. The central element to any

ESB is a message bus that is used as the communication medium or "wire" between different components

or applications on the bus. Java Message Service (JMS) is typically used as the message backbone, but

any other message server implementation could be used, such as MSMQ, IBM MQ Series or Tibco


See the Articles page for further reading.

For an example see the Loan Broker ESB sample application.

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. Mule allows

service applications to be developed using different deployment topologies such as ESB, pipeline, peer

network, client/server, and more.

Why use Mule?

There are currently several commercial ESB implementations on the market. However, many of these are

Either vapor-ware or built on top of an existing application server or messaging server in a closed way,

which means that inevitably you'll be locked in to that vendor.

The philosophy of the Mule project is to leverage existing standards and be flexible enough to embrace

New standards as they emerge. Another requirement was that the developer should be able to leverage

many disparate standards using mule in a consistent and simple way. So regardless of whether a

Message is received as a JMS, Email or SOAP message the process of receiving and sending information

over these protocols should always be the same.

Mule provides a simple framework for setting up an ESB and leveraging your existing development

investment and reducing new development costs -

1. The ESB construct inherently provides an easy route to streamlining enhancing and automating


2. Any kind of component can be configured in Mule, that is to say, to run a component in Mule there

is no need to implement any Mule specific code, the object can be anything from a Java Bean, POJO

or a component from another framework.

3. Mule and the ESB model enable significant component reuse and unlike other frameworks it allows

you to use your existing components without any changes.

4. Mule can dramatically decrease time to market and increases productivity for projects to provide

secure, scalable applications that are adaptive to change.

Is Mule a JBI Container?

Mule itself is not a JBI container, but there is Mule JBI which is a JBI container built from the ground up

That adheres to the JSR-208 specification.

How does Mule compare to JBI?

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 no assumptions about the message type so that

you can easily use Strings, binaries, MIME, XML 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 "Bean to Endpoint mapping" architecture that allows you to

develop sophisticated message flows between services.

JBI is targeted specifically at application integration 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


Do Mule and JBI compete?

There is crossover between Mule and JBI, but JBI addresses a subset of messaging problems. Mule

addresses the basic need to enable services that deal with all kinds of data (not just Xml) and objects

around an organisation.

Mule also addresses the needs of smaller applications that just need to obtain or send information to

disparate sources. Mule was designed from the outset to scale down as well up.

Can I use Mule with JBI container X?

Mule works with any JBI container so that Mule components, routers, endpoints and transformers can be

executed in a JBI container.

The reason Mule integrates with other JBI engines and provides it own JBI container is that one

integration solution will never satisfy all messaging needs. ? Mule levels the playing field allowing you to

pick and choose which technologies to integrate with.

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, transport or repository technology. Components in Mule are wired together

using a variety of technologies though this is totally abstracted away from the application.

How does Mule fit in with my webapp?

Mule can easily be embedded in a webapp or any other Java application and can be used to handle

complex interactions with external sources and applications. Mule also provides powerful routing

capabilities for request/response processing to allow your webapp to execute actions across the network

concurrently and Mule manage the collating the results before returning a response.

You can invoke Mule components from Jsp pages or servlets using the Mule Client or you can use the

REST interface by using the Servlet transport provider

Do we need another framework?

We think so. We know there are a lot of other very good frameworks out there, so why do we need

another one? When Mule was conceptualised it was designed to be a lightweight ESB framework. While

there are plenty of other lightweight frameworks, none of them were designed around ESB model. As you

might expect, there is a lot of crossover between existing frameworks, so rather than adding to this

overlapping of concerns Mule set about to leverage the best features of other frameworks by using those

frameworks in it's design. So Mule provides the wiring to use the features of other frameworks together

while adding features of it's own to make a very powerful ESB server. For example, you can use IoC

containers such as Spring, Plexus or PicoContainer or Jndi to construct your Mule application and even the

Mule server itself can be created from an IoC container.

Why is Mule called Mule?

Ross: "After working on a couple of bespoke ESB systems, I found that there was a lot of infrastructure

work to be done before you can really start thinking about implementing any logic. I regard this

infrastructure work as 'donkey work' as it needs doing for every project. I preferred Mule over Donkey

and Ass just didn't seem right . A Mule is also commonly referred to as a carrier of load, moving it

form one place to another. The load we specialise in moving is your enterprise information."

What do you mean by Light-weight and Event-driven?


You don't need a big server to run a mule instance, in fact it's memory and disk footprints are very small.

One example of this was a custom application configured to run over 8 machines that had to process

hundreds of thousands of events. With Mule they could run a respectable demo of the whole system on

an outdated laptop.


This simply means that all data transitions in Mule are treated as events, and that information entering

the system, say from a customer request over the web, are events.

How does Mule provide Scalability?

Scalability is the ease by which the application can be altered in response to higher demands on the


Mule uses the SEDA processing model to increase the performance and throughput of events. Mule allows

pooling of UMO objects and Providers to allow multiple threads to process events concurrently.

How does Mule enforce decoupling?

Decoupling refers to having each component in system totally independent (and oblivious) to other

components in the system. The advantage of decoupled systems is that components can be added

enhanced or removed causing little or no disruption to other components. Decoupled systems built on

messaging are inherently fault tolerant due to the autonomous nature of the components and the fault

tolerance of the underlying message server, such as persistent queues, durable subscribers and

replication using load balancing.

Mule decouples your components from the complex infrastructure details of your application. Your

components can concentrate on core business functionality while Mule handles all the details of

transforming, routing and delivering business data around your application.

What is an UMO component?

Any object can be registered with the mule server as a UMO component such as Beans, EJBs, MBeans,

Servlets, JoesComponents or POJOs. The only 'sort of' requirement that mule needs is a public method on

the object to pass events. This method is dynamically resolved at runtime depending on the type of event

received and any transformers configured for the event.

What is zero code intrusion?

Mule does not impose any restrictions or preconditions on the objects you wish Mule to manage. Mule

uses discovery to determine which method should be executed when an event for the component is

received. The discovery method used can be overridden to change the way the event method is resolved.

What are Endpoints, Connectors and Transformers?

Endpoints enable connections to external systems or other components in Mule. These provide an

instance of a transport channel between external systems into Mule and vice versa. Providers can be

registered for a UMO so that it can send and/or receive information from the external system without

ever knowing about the system, the format of the data it expects or the transport mechanism used to

communicate with it.

Connectors actually do the logic of sending and receiving to an external system. And transformers are

used to convert data to and from formats expected by the different external systems. The conversion is

usually trivial such as creating a javax.mail message from a message payload on properties for from, to

and subject fields.

For more information about Using Mule and Mule components please see the User Guide

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 of Mule and how to get started.

User Guide - covers all areas of Mule including usage, configuration and support for other frameworks

and applications.

Architecture Guide -

provides a reference to workings of the Mule Server describing the features of

each element in the system.

Mailing Lists Archives

a good place to find answers to previously asked questions

How can I ask questions about Mule?

You can subscribe to one of the Mailing Lists and post your questions there. The User list is suitable for

most people.

Also, you can catch the Mule developers and users on the Mule IRC Channel . Pop in and say hello.

I found a bug, what do I do?

If you find a bug you can report it on the Mule issue tracker. You will need to sign in as a new user so

that you can create issues. Please include as much information as possible when creating the issue. If you

fix the bug yourself you can include a cvs patch or zip of the code and include that in the issue.

Once you have created the issue it will get published to the Mule Developer list, so there is no need to

post it directly to the list as well.

I thought of this really cool feature, how can I get it added?

If you want a new feature in Mule you can either -

1. Write the code yourself and submit the code to the Mule Issue Tracker (and I'll buy you a beer next

time I'm in your neck of the woods ).

2. you can post the idea on the Mailing Lists and also log it on the Mule Issue Tracker . This will kick off

a discussion of the idea and some one may pick it up and code it for you, or you can code it