Thursday, December 10, 2009

We chose Mule for our ESB

After careful consideration of multiple open-source ESB products, Mule made the most sense for implementation into our data information infrastructure. The other major competing providers were OpenESB(GlassFish v3), FUSE (Apache stack) as having an open-source solution was a very strict requirement. Mule is very component oriented and can be quickly setup for integration with existing services (of which we have several). Furthermore, it is Spring-based and supports Maven -- which fits right into our existing application development

Mule has many strong points, the most relevant for our decision being:

  • very mature, years of development and major deliveries

  • a solid installation base across many significant enterprises

  • well-documented with excellent examples and diagrams

  • is open-source (CPAL 1.0)

  • a commercial support model with additional tools (service registry,monitoring)

  • flexible configuration and instantiation options

  • wide-array of built-in and downloadable modules

  • a top-choice in DTS of Utah ESB comparison

  • excellent testing framework

I read a lot on OpenESB, watched presentations and then checked out tutorials. Simply put, OpenESB appears quite overkill for our specific needs. Furthermore, I'm not a fan of vendor lock-in and OpenESB appears to be very heavily biased towards NetBeans (which isn't really a surprise).

As for the Apache side of things, I spent a fair amount of time reading comparisons on ServiceMix and Mule. The favor was typically weighted on Mule's behalf and the one major viable commercial support option for ServiceMix was through
Fuse. Fuse appears to have some good documentation, but it wasn't nearly as in-depth as Mule. Also, going this route appeared to require more "gluing" using Camel and ServiceMix is also more specifically oriented to JBI--a shared trait among both OpenESB and ServiceMix.

Mule made it very easy to get up and running quickly. Within minutes I had implemented a REST service component using an existing endpoint. After some time reading more documentation I recognized a good case for using the template URI pattern and exposed another two REST endpoints in a separate service. Finally, with a Maven archetype, it was very easy to generate a Mule project and tweak it to support multiple environment deployments (dev,test,beta,prod, etc). I created a simple bootloader to start up the Mule context and register a shutdown hook with the JVM. This approach leverages Maven's capabilities in property filtering and distribution assembly. Thus, we can now create standalone distributions with full Maven dependency support (avoiding the hassle of updating MULE_HOME/lib/user), integrated testing, custom property filtering, and artifact assembly for multi-enviroment support.


andy said...

"I created a simple bootloader to start up the Mule context and register a shutdown hook with the JVM. This approach leverages Maven's capabilities in property filtering and distribution assembly. "

You're running Mule w/in another JVM process, then, correct (i.e. not standalone)? Interesting. Was planning on using Maven assembly to deploy the whole bit and just start via batch file, but this may be a good option as well.

RR said...

Andy, you got it. It made sense to to manage the additional mule modules, and whatever dependencies come along, via Maven--in addition to deploying to multiple environments. Very happy with the setup.

andy said...

RR, Thanks for confirming.
For now, I'm using the standalone approach w/ a mvn assembly created .zip file that contains dependencies. Then, my .bat/.sh file has to list the .jar's I require as part of a MULE_LIB environment variable. Which is the part I don't really care for, I'd rather get one large .jar as you are doing.

Wondering if you could post the java main that starts your mule context, or maybe the mvn assembly section? I'm pretty sure I know how to do what you are doing, but an example might help. Thanks!

RR said...

Andy, apologies for the delay in getting back to you. Check out the assembly here: . Note that I changed the include/exclude entries to anonymize the data.

The Mule java bootloader is here:

andy said...


No worries - thanks for the help!
OK, I was pretty sure I knew what was going on with your Java main() but the term "custom BootLoader" threw me off a bit.

Thanks for posting those, though, will definitely help if that's the way we go...

RR said...

Glad to help. The pastebin stuff contains just the relevant bit of Java I figured you might reference--I found a lot of old Mule docs that steered me off in the wrong direction so the "custom" description I used in my post really has more to do with other elements of the bootloader that I didn't copy into pastebin (shutdown hooks and some other property stuff).