9 Reasons to Consider Mule as your ESB

Mule ESB is a widely used open source enterprise service bus. In this post I'll give you 9 reasons why you should consider Mule ESB for your integration challenges.


1. Mule is Open Source


Wait, wait. Before you wave away this post as total bullshit, I really believe a Service-Oriented Architecture (SOA) and in particular a product like an ESB can benefit from open source. When you (or your company) decide to go for a SOA, a considerable amount of money is already invested in the current application landscape. To migrate this landscape to a SOA in one big bang is not do-able both in terms of investment and time. So the advice is to start small.


Start by implementing a couple of generic utility services, then connect one application, from one application to one department, etc. The same holds for investments. Why spend a huge amount on license costs when you only have a couple of services or applications connected to it? Especially in a time like this, where cost reduction seems to be priority number 1. Mule is highly scalable allowing you to start small and connect more applications over time.


Another advantage of open source, is of course no vendor lock-in. The ability to adjust or extend the code to your needs. I will come to that later.


2. Mule is Mature


Ross Mason started the project in 2003. Mule 1.0 was ready by 2005. The current stable release is Mule 2.2.1 and it's only a matter of time before Mule 3.0 will be released. Mule is running in production environments at thousands of customers. Of all the open source ESB initiatives, I dare to say that Mule is by far the most mature one.


3. Mule's Architecture


Mule ESB is based on a proven set of best practices. Mule implements many of the patterns described in Enterprise Integration Patterns, by Gregor Hohpe and Bobby Woolf.


Mule's core is designed as an event-driven framework combined with a unified representation of messages, so called Universal Message Object (UMO). The key idea behind the UMO API is to unify the logic and model representations while keeping them isolated from the underlying transports. This made it easy to build all the required features of the ESB: message routing, data transformation and protocol adaptation.

Mule adopted Spring 2 as its configuration and wiring framework. This makes integration with Spring and all of Spring features really easy.


4. Mule is based on Standards


Mule is based on standards and common frameworks. I will only mention a couple over here as the list is too long to mention totally.


Security - Mule allows you to authenticate requests via endpoints using transport-specific or generic authentication methods. It also allows you to control method-level authorization on your service components. The Security Manager is responsible for authenticating requests based on one or more security providers. All security is pluggable via the Mule security API , so you can easily plug in custom implementations. Examples of security implementations are Acegi, Spring Security, JAAS and WS-Security.


Transactions - Mule's transaction framework is agnostic to the underlying transaction manager. The transaction could be a JDBC transaction, XA transaction, or a JMS transaction or message acknowledgment. All transaction types can be handled the same way.


Monitoring - Mule comes with agents to check the health of your components through Java Management Extensions (JMX) technology.


5. Mule's different Messaging Styles


Mule provides a platform to develop and host your integration solutions. Whether this is in an EAI environment, a SOA or an EDA. With the different messaging styles Mule supports, you can choose yourself how to best use Mule in your own environment. The following messaging styles are supported:


  • Asynchronous

  • Request Response

  • Synchronous

  • Async Request Response


  • The messages that are passed from endpoint to endpoint are not bound to XML. It can be anything from a POJO to a binary image files.


    6. Mule is Expandable


    Mule's core is designed with expandability in mind. These so called pluggable modules provide support for a wide range of transports or add extra features, such as distributed transactions, security, or management. Mule comes with a whole bunch of transports (CXF, Axis, HTTP, JMS, JDBC, Email, FTP, to name a few), transformers, routers (chaining, multicasting, filtering, exception-based, etc.) and filters. New modules become available regularly. As an example, this week a SAP transport has been implemented.


    If the transport, filter, transformer or router you need is not available it's easy to implement your own by implementing the required interfaces or extending one of the available ones.


    7. Mule's Tool Support


    Mule IDE 2.0 is a development and testing environment based on Eclipse. With Mule IDE it is easy to:


  • Create a new Mule project in Eclipse

  • Create and edit Mule configuration file

  • Running and debugging your Mule project in Eclipse


  • You can use Maven to quickly set up and configure your Mule project. Mule provides four archetypes that create template files, including all the necessary Java boilerplate and detailed implementation instructions in comments, helping you get started quickly:


  • Project Archetype for creating a standalone Mule application.

  • Module Archetype for creating a new module, such as XML or scripting support.

  • Transport Archetype for creating a new transport, such as JMS or CXF.

  • Example Archetype for creating a new example to help other users get up and running quickly.


  • Mule provides a Test Compatibility Kit to test various aspects of your Mule project, including integration tests of your Mule configurations. Components can be easily mocked.


    8. Mule is well Documented


    Normally the lack of documentation is an often heard complain about open source initiatives. Mule ESB provides an excellent User Guide describing all kinds of topics, from simple ones as how to configure a transport or router to the more advanced topics like performance tuning.


    If this is not enough, multiple books are available (among them Open Source ESBs in Action and the recently published Mule in Action) which provides you with hands-on examples and in-depth knowledge of the product.


    9. Mule has an Active Community


    All those transports, filters, routers and transformers can be a bit overwhelming when starting with Mule. Don't worry; mule can lean on a highly active community. When you have a question, drop it in the forum and you will get an instant solution to your problem or tips on how to solve it or where to look.


    So, do you agree with these reasons? Did I forget something? If so, please leave me a note.



    |

    • Digg
    • Del.icio.us
    • StumbleUpon
    • Reddit
    • Twitter
    • RSS

    5 Response to "9 Reasons to Consider Mule as your ESB"

    1. Unknown says:

      Hey,

      1. Mule is Open Source

      While I appreciate the PD sentiment, sometimes the capital expenditure on the software forms a commitment from the IT decision makers that is otherwise lost ("We paid $Xk for this...it will be implemented). Free is easy to abandon half way through or to not give a clear mandate to in the first place

      2. Mule is Mature

      Don't get me wrong, I like Mule, a lot. But with a SAP connector released "just this week" I cannot consider it mature. I feel comfortable saying log4j, jUnit or Spring are mature, since their uptake and adoption by the Java community is pretty much wholesale.

      3. Mule's Architecture

      ...is not really portable to the other ESB solutions, which have largely converged on BPEL/XML - like Intalio, Oracle Fusion, Tibco etc. So if you get hacked off with it you're stuck

      4. Mule is based on Standards

      Microsoft C# is a ratified standard. This statement rather begs the question - so what? Standards are there for two reasons:

      * Compatibility
      * Portability

      But as I understand it, (and I will doubtless be corrected if wrong) Mule projects aren't really good at porting over to other ESB solutions. For compatibility...can it talk to an Atari ST over MIDI? I very much doubt it - point being that it is compatible with only a limited subset of common contemporary systems - otherwise, you're on your own. For instance AFAIK there is no JCA feature...yet.

      5. Mule's different Messaging Styles

      Pretty limited compared with Message Queue solutions, and in any case, this is the base featureset of all ESB solutions?

      6. Mule is Expandable

      Indeed - as already alluded to, as soon as you have to go off the beaten track you're on your own.

      7. Mule's Tool Support

      Most ESB solutions out there have a free IDE (Oracle JDeveloper, Intalio Designer to name but two)...except MS BizTalk of course - you have to pay for their IDE (!).

      8. Mule is well Documented

      Here, we disagree. The "JavaDoc" documentation is, in my opinion, basic.

      9. Mule has an Active Community

      Yeah...but WHEN it comes to crunch time you'll have to pay the support fee same as you would have done for any of the other solutions

      Take it easy, and as I say - I like Mule; just skeptical by nature

      Regards

      Robert Gibbon
      http://www.linkedin.com/in/robertgibbon

    2. Mario Klaver says:

      Hello Robert,

      First of all thank you for your comment. It's good to be skeptical. Let me try to take away some of it.

      1. Mule is open source

      Getting commitment from the fact that you paid a lot of money for a product, is not the right reason.

      2. Mule is mature

      The mule core has proven itself at thousands of customers. I call that mature. Not that you have just that one SAP transport or not. As a matter of fact, I suppose it's also possible to connect to SAP using web services, but now you can connect to SAP using the SAP API.

      3. Mule's Architecture

      In my opinion an ESB and a BPEL engine are two different concepts. An ESB is an architecture/design pattern to facilitate the communication between different applications, using different message formats, protocols, etc. A BPEL Engine offers functionality to maintain and run business processes. Most ESB's offer BPM support and Mule also has a BPM transport that makes it possible to send and receive messages from a BPM engine. The currently supported BPM engine is JBoss JBPM that offers JBPM and BPEL support.

      As of XML, it's your own choice as the architect to only allow XML as your message exchange. Mule is not stuck with XML.

      Then your compatibility comment. I don't think any ESB is portable with another at the moment. The BPM engines are pretty much standardized (using BPEL), but they all have their own extensions. But the ESB's are not. I hope SCA will help with this.

      4. Mule is based on Standards

      See my previous comment.

      5. Mule's different Messaging Styles

      Most ESB's are focussed on XML and web services, Mule isn't. Mule can also be used in other scenario's, due to the fact that your transport and messages can be anything.

      6. Mule is Expandable

      I disagree here with you. Sure if you are making code changes in your Mule's core you are on your own. I always strongely disencourage to change the sources of open source products as you are not able to migrate to newer version without a lot of trouble.
      But Mule offers an API to create your own transport, filters, transformer, interceptors, routers, etc.

      7. Mule's Tool Support

      I agree, but in that case you are stuck with their IDE and you can't use your own favorite IDE. Maven is widely accepted for building project. As you probably already know, maven offers you the possibility to import your project in your favorite IDE. With the maven archetypes of Mule it is possible to create a project that is independant from any IDE. Oracle only offers you ANT build scripts.

      8. Mule is well Documented

      I was not refering to the "JavaDoc" documentation. I was refering to the Mule User Guide (http://www.mulesource.org/display/MULE2USER/Home)

      9. Mule has an Active Community

      That's your own choice. If you want support, MuleSource can offer that too.

      As I already said, this is not an offence to you. I just tried to take away some of your sketicism ;-)

      Regards,
      Mario

    3. Mario Klaver says:

      One more note about compatibility:

      SCA shall not entirely help to solve the compatibility issues between ESB, but when SCA is supported by different ESB's, at least SCA components can run on multiple platforms.

      JBI's goal was to overcome the compatibilty issues, but unfortunately it didn't take a flight.

      As of compatibility and standards: By adopting and supporting multiple standards, at least it makes it easy to fit into your application landscape. For example, a connection to your existing user store for authentication and authorization is easily made.

    4. Unknown says:

      Hi Mario

      I am new to Mule and require some help from you in this regards on the following points -

      1. Is SAP transport available in the Mule v2.2.1 community version.
      2. If yes, then some guidelines to implement the same as i do not find enough material on the subject.

      Regards

      Deepyaman

      deepyamanchatterjee@gmail.com

    5. Mario Klaver says:

      Hi Deepyaman,

      You can download the SAP transport from the following location. It will work with mule v2.2.1. In the downloaded transport you will also find some examples:

      http://www.mulesoft.org/display/SAPCPAL/Home

      HTH
      Mario

    Post a Comment