Enterprise Open Source Magazine editor-in-chief, Mark Hinkle, interviewed Mulesource (www.mulesource.com) CTO Ross Mason and founder of the Mule Enterprise Servive Bus (ESB) project (http://mule.mulesource.org) about the usefulness of this technology and its recent success.

EOSM: What is Mule, and what led you to create it?

Mason: A few years ago, I was working for a middleware vendor, and we were doing a very early ESB implementation for an investment bank in London. We only integrated six systems, but it took us a year and a half, and we really hit a wall in terms of technology challenges. We had to build a lot of the infrastructure architecture ourselves, which meant lots of code to test and maintain. During that time, I realized that there really wasn't anything out there to help developers integrate applications in a clean, easy, and consistent way.

The vision for Mule (http://mule.mulesource.org) was an adaptive integration platform with a very simple architectural model. I wanted to make it possible for developers with standard Java skills to integrate their services in a flexible manner. And I wanted to create a mechanism that masked API complexities from the user, without restricting the underlying technology, and also didn't lock them into any specific standards or approaches.

It was obvious to me that the market was ready for an open source approach to software integration. People were and still are tired of paying exorbitant licensing fees for existing applications, only to have to pay additional fees when they integrate something new into their environment.

You can't even use most of the proprietary integration technologies without getting a consultant; professional services costs are usually high and ongoing.

EOSM: What is it about the proprietary integration technologies that contribute to their complexity?

Mason: Most of the time, if you use their technology, you also have to learn their methodology, their toolkit, etc. Even if they're "standards-based," they overlay a set of proprietary tools that generate reams of code and Web Services Definition Language (WSDL) that is very difficult to customize, sometimes impossible. Vendors often assume they thought of everything, but in integration that is just not realistic. Most developers experience frustration with the fact that if you use one of these proprietary approaches, you also have to start using their messaging systems and their SOAP (Simple Object Access Protocol) stacks. There are so many degrees of complexity, many of which seem to be in there for the express purpose of bewildering the user and creating professional services and sales opportunities for the vendors.

Another inherent disadvantage to the end user with proprietary integration approaches is how prohibitively complex they are to test drive. They're heavy and difficult to deploy and configure and most of them require developers to write a lot of code just to get something running. These factors make the technology very inaccessible to many developers who only have a short time to evaluate a product. Add the fact that their licensing is expensive and per CPU, and that they're often fundamentally at odds with the users' need to prove ROI within so many months of a new project, just to get that project funded.

By contrast, Mule was specifically designed to simplify the process of integration. For starters, it's extremely lightweight - Mule as a core server is very small. Developers can actually build applications on their laptop or workstation, test them, and then later deploy them across their network just by changing a few lines of configuration. The other major benefit to Mule is that it's based on "plain old Java objects" (POJOs); anyone who can use Java can use this platform. Most people can get something running within half an hour of installing the application.

Finally, we don't inject any Mule-specific APIs or processes into the ways you build your applications. So developers have maximum flexibility in how they approach their own unique integration challenges.

EOSM: What sort of end-user traction has Mule experienced out in the market so far?

Mason: The traction really took off after the version 1.0 release in 2005. Since then, we've had more than 200,000 downloads. We know of at least 100 major production users, we have around 1,000 developers active on our mailing list, and we have 12 core committers.

The Mule use case that we typically talk about is ESB. This is a term the market seems to understand best, so that's how we first describe the platform even though Mule can be used in many different ways (ESB is just one topology). But there are a lot of organizations using Mule without the bus itself. They're just wiring components together over the network, without the underlying message bus , because in their particular environment, Web services, FTP, HTTP, RMI or something else may be appropriate. That's one of the best things about Mule - we don't prescribe how people should build applications, and we don't inject any Mule-specific APIs or processes.

Some organizations today are using Mule as the backbone for data transport in financial transactions. Others are integrating J2EE applications that weren't originally designed to be services-oriented that they want to bring into an SOA. They're trying to move away from the world in which their apps are tied together with brittle one-to-one interfaces, and every time they touch something in the middle, they risk breaking the contracts between systems. There are many other types of use cases in which developers use Mule as the glue to connect different services using pipeline, peer network, or even hub n' spoke topologies.

During development, Mule users tend to wire their services together on s single box using just VM transports between services, with no network.

They're able to quickly construct the application, to build a skeleton of their application to make sure that the event processing is correct, i.e., to check event routing and transformations are configured correctly. When it's time to deploy, they can simply change the endpoints, and then Mule handles the data load transparently when they distribute the services.

We also have some emerging growth areas for the technology. A major VoIP vendor is doing proof-of-concept work on what it would look like to embed Mule inside a call center application. We know of several very large service providers that are working with Mule in production. We're having early discussions about how Mule could be embedded into routers on the network to allow intelligent networks to handle some of the software integration functions at the network level. We know of several large retail end users that are interested in Mule as a way to enable a common infrastructure between the core datacenter and tens of thousands of individual franchise locations.

EOSM: What sort of licensing model are you using for Mule?

Mason: We're using the Mozilla Public License (http://www.mozilla.org/MPL/), the same model as Sugar CRM (www.sugarcrm.com) and Zimbra (www.zimbra.com).

We plan to keep the code 100% open source.