Home > Java, SOA > ServiceMix vs Mule ESB

ServiceMix vs Mule ESB

As our applications have grown, we have created one off interfaces to external systems. Each has been a carefully crafted hack. We’ve known all along that this is not sustainable in the long term; but like all shops we didn’t have the business case to spend time creating something more elegant. That changed today, the collective weight of all the interfaces finally caught up with us. So we are going to pay off our technical debt and implement an ESB.

We start looking by looking at a variety of them. Most cater to some form of web services, so they are out (most of our interfaces are not web services per se). I ran across ServiceMix from Apache and it looked promising. It is very easy to download and follow the examples and tutorial to get up and running. I really like the hotdeploy functionality. There is a lot of maven support to create projects and different configuration files for what they call a service unit.

However, once I got beyond the tutorial example, I hit a brick wall.  Or more importantly ServiceMix put a smack down on me that I haven’t gotten up from yet.  For my first test I wanted to create a service that took an http post file, did a transformation on it and saved the result to the filesystem.  Easy enough.  Turns out this is really tough to figure out.  I’m sure if I was more familiar with ServiceMix this could be created in a few minutes.  But after a day and a half of reading source code and googling I couldn’t figure it out.  The docs on the website leave a lot to be desired – at least for new users.

So I turned my attention to other options.  Next up was Mule ESB.  I’m not done; however I can tell this is what we will implement.  The docs are good.  I was able to get the sample up and running (in Eclipse) in about 10 minutes.  After taking my time and reading a lot and working through the tutorials/examples, I was able to create my first service that executed my first use case in about 4 hours.  I could have done it quicker; but I wanted to take my time and understand more than just the simple items.

Mule also provides the Mule IDE which helps create new services and the icing on the cake is we can run Mule ESB services in Eclipse — which means debugging just became a whole lot easier.

Next up will be finishing (error handling, etc) my first service and then configuring Mule to run as a standalone application (not via Eclipse).

Categories: Java, SOA
  1. Zamoyski
    October 7th, 2009 at 03:08 | #1

    Try Spring-Integration – for 90% of scenarios it’s much better (simpler, cleaner) than Mule. These 10% are the case for providers available in Mule and not available in Spring-Integration

  2. Chris Hane
    October 7th, 2009 at 11:36 | #2


    Thanks for the pointer. I just spent some time looking over the Spring Integration documentation. Looks very useful. However, it seems to tackle a slightly different thing that what we want to do. My probably gross simplification is: Spring Integration seems best geared towards including messaging inside an application; where Mule works better as a standalone application that provides an interface between different systems.

    Thanks again for the good info…

  3. cjiang
    October 7th, 2009 at 12:20 | #3

    how about the Mule license? It is not open source in the real sense.

    • Chris Hane
      October 7th, 2009 at 13:12 | #4


      Is it the attribution clause you object to or something else? I read the license quickly but INAL, I probably need to go back and read it again to see if I missed something.

  4. October 7th, 2009 at 12:31 | #5

    I think Apache Camel hits the target for your simple example – and you can take an XML definition of an Apache Camel route and drop it directly into a running ServiceMix 4 container deploy directory too. If you don’t want to use XML, then you can write a short piece of Java to get it done.

  5. October 7th, 2009 at 14:17 | #6

    I think you definitely want to look into Apache Camel and indeed maybe Spring Integration (haven’t played with it yet, but heard some good stories) before deciding on Mule ESB.

  6. cjiang
    October 7th, 2009 at 16:52 | #7

    I thought Mule license works similar to Alfresco. There are 2 versions: community version and enterprise version. For Enterprise version, you have to pay for support subscription. I guess the code base between community version and enterprise version are different.

    But I am not sure about all my statements. This is just the impression I got.

  7. October 7th, 2009 at 19:09 | #8

    +1 for Apache Camel

  8. October 7th, 2009 at 21:06 | #9

    I can see how you arrived at the conclusion that Spring Integration is focused on messaging within an application. However, the fact that you don’t see Spring Integration as a “standalone application” is probably a *Good Thing*. We have quite consciously designed it to be embedded within a Spring ApplicationContext and to work seamlessly with other Spring components. That means you can run it in any environment/server, and it is as lightweight as possible.

    (disclaimer: I lead the Spring Integration project)

  9. October 9th, 2009 at 02:15 | #10

    For this simple use case[1] and also for more complex use cases[2] its quite simple to create a service using JBoss ESB. Thanks to 80 odd examples[3], I am sure you can find one that fits your needs. JBoss ESB also comes with rich set of eclipse plugins that allow you to create, deploy and debug ESB projects. Also comes with an editor for creating service definitions.

    In JBoss ESB a service follows the chain of responsibilities pattern (or a chain of actions), where an action is a reusable unit of work, so adding functionality like security, transformation, routing, orchestration etc… is just a matter of adding an out-of-the-box action to the action chain.

    - Uday
    (Disclaimer: I am JBoss Solutions Architect)

    [1] http://anonsvn.jboss.org/repos/labs/labs/jbossesb/tags/JBESB_4_5_GA/product/samples/quickstarts/helloworld_file_action/
    [2] http://anonsvn.jboss.org/repos/labs/labs/jbossesb/tags/JBESB_4_5_GA/product/samples/quickstarts/smooks_file_splitter_router/readme.txt
    [3] http://anonsvn.jboss.org/repos/labs/labs/jbossesb/tags/JBESB_4_5_GA/product/samples

  10. October 9th, 2009 at 11:35 | #11

    Have a look on the integrated jmx-agent and mx4j implementation. you are able to start deployed services online….

    just add

    to your config and the mule management schema to your namespaces

    Best wishes


  11. Gordon Spoelhof
    October 13th, 2009 at 19:13 | #12

    Having used them all it really depends WHAT you are trying to do.

    Need some simple code to composite something with fixed address endpoints – try camel in java space. Especially if you don’t want queueing. Lots of endpoints,
    but not everything you want implemented.

    Have a small queue based model you want to wrap around your spring – SI works fine
    as long as you want in memory messages. Some endpoints, but plan on extending them
    if you want weird functionality.

    Need to GLUE systems togehter, proxy them, do mediation, transformation – use a standalone Mule instance; the old UMO like paradigm Mule works from most things hands down. Mule gets you to solution with the least code IHMO – and binary support is rather good. Newer features around REST seem promising. PS the license issue people raise is nonsense – it works and nobody is harping on any of the users.

    Having used servicemix, JBI is not the hotest and servicemix:eip is the worlds
    worst thing you can do to business logic. I am waiting for ServiceMix 4.2 which
    promises more.

    Bottom line Mule supports more integration scenarios than you can shake a stick at, but I have found that if you are building systems from scratch, try sticking
    with something more spring like – Spring Integration blends real well with Spring Batch and other parts.

    What remains to be seen is what Camel 2.0 will do with more dynamic endpoints.

  12. March 13th, 2010 at 06:15 | #13

    Cjiang, thanks for the FUD. Mule is licensed under CPAL which is OSI approved and used by folks like Facebook and SocialText. See http://www.opensource.org/licenses/alphabetical

  13. March 13th, 2010 at 06:22 | #14

    Just a heads up that myself and the Mule team or working on Mule 3.0 where the focus is simplicity. We’re doing this in a few ways: 1) Make Mule itself easier to configure via XML and through code. 2) We’re also adding a deployment model and hot deployment to support the developer during development. 3) We’re working on a new project called iBeans that focuses on the plethora of simple integration problems where ESBs like Mule and Camel may not be such a good fit. you can find out more here: http://mulesoft.org/ibeans

  1. No trackbacks yet.

Spam Protection by WP-SpamFree