MULE ESB: A Case Study

Eugene Ciurana (from wrote this article that you can find at The subject is ESB, more specifically MULE ESB. Version 1.3.3 is “fresh from the oven” with 27 issues/functionalities implemented since 1.3.2.

Eugene’s text starts with a simple question: “Why are ESB needed?”. After this there is an interesting comparation between the ESBs from TIBCO (Matrix BusinessWork), SUN (openESB), Progress Software (Sonic ESB), IBM (WebSphere ESB) and, of course, Mule ESB (open-source, MuleSource Inc.).

He points out some advantages of Mule ESB:

* Active open-source community and commercial support available
* State of the art implementation and ability to run under Java 5/6
* Number of relevant features out of the box
* Response time from vendors within 48 hours (average time for the winners was 2 hours)
* Ease of installation and deployment
* Ease of configuration and expansion
* “Codeless” integration with legacy, third-party, and commercial products
* Ability to drop in/pull out without incurring in lock-in or ancillary product dependencies
* Low total cost of ownership

And how Mule ESB enables two or more applications to communicate? Mule implements elegant protocols and standards based on well-defined patterns. Applications communicate with one another by implementing these patterns with a set of predefined components (see figure below):

Eugene continues:
“… – Applications interface with Mule over a transport.
- A transport carries service objects between components (some of the current documentation refers to service objects as “UMOs” or universal message objects; that term is deprecated now).
- The transport is any mechanism for exchanging data between two points
- Mule doesn’t implement or mandate use of particular transports. It offers instead a number of transport providers and the integration engineers or developers get to choose the appropriate one for a given application.
- A transport provider implements a message receiver or dispatcher, a connector that implements a protocol like JMS, TCP, etc., and an optional transformer.
- The transformer may be use to convert service objects from one format to another (XML to native Java, for example).
- Mule routes inbound and outbound data between transports through the service object component, which is responsible for managing component events to and from the component, and for managing pooled resources. …”

Good reading!

Category: ESB, SOA

One comment on “MULE ESB: A Case Study

  1. [...] sobre Mule veja estes posts deste blog: “Mule ESB: A Case Study“,  “Mule ESB(II): 500,000 Downloads and couting…“, “Open-source ESB: [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>