Conceptually, ServiceMix and Mule are quite similar in that they allow services to be integrated through different APIs and across different transport technologies. Service Mix and Mule provide similar features, and both solutions enable a simple, lightweight POJO-based deployment model that uses the Spring framework to integrate services.

Both ServiceMix and Mule are designed as integration solutions whose capabilities are independent of the transport. ServiceMix achieves this through its JBI-based architecture, while Mule is based on a services container and configuration of message endpoints.

Compared to Mule, the major difference for ServiceMix is its architectural design, which is fundamentally based on the Java Business Integration (JBI) standard. Mule provides a JBI binding so that Mule components can interact with JBI containers, including the ServiceMix JBI container. However, the internal Mule APIs are not based on the JBI standard.

While JBI support is a very good thing, ServiceMix provides not only external APIs to support JBI-based integration, but also internal APIs based on JBI, to give agility and flexibility not only with respect to the integration capabilities at the endpoints, but also to the functionality of applications executing across the fabric of the integration environment.

For example, because JBI supports a standard deployment unit format, you can hot deploy any JBI-compliant BPEL engine (or set of BPEL files into a BPEL engine), rule engine, transformation engine, scripting engine or other integration component (such as specific JBI binding components) directly into ServiceMix. Also ServiceMix contains a number of WS-* implementations built on JBI, such as WS Notification.

Even though the JBI standard and the Mule messaging platform look very different at the API level, conceptually they are trying to do similar things. Like Mule, JBI is based on the idea of both component and container based routing. However, JBI provides a standard for the integration of any commercial or open source component. Equally important, the JBI standard supports a very high level of integration functionality. A JBI component can perform smart routing to endpoints. A JBI component can just communicate with its default service, letting the container do the routing for it. Or a JBI component can give the JBI container a hint of which endpoint to use (such as providing a service QName to use or specifying an operation QName) and then the JBI container can, if there are many available services to choose from, use some kind of policy negotiation or load balancing algorithm to choose which physical endpoint to choose. Lastly, JBI is a cleaner abstraction for working with both logical and physical web service endpoints, WSDL and the standard WSDL defined message exchange patterns (MEPs).

While ServiceMix supports a lightweight deployment model similar to that of Mule, ServiceMix is also fully integrated into Apache Geronimo, bringing JBI functionality into Apache's J2EE container. This allows Apache Geronimo to hot-deploy any JBI component or service using its standard deployment tooling (JSR 77/88 compliant). This difference between the two products also originates in our focus on agility. Some ServiceMix implementations will be endpoint-centric, like Mule. Others may leverage the capabilities of an application server. ServiceMix is designed for either integration scenario, or some combination of the two.

Today's Open Source ESB solutions are increasingly focused on interoperability, and despite their differences in architecture and design philosophy, this principle of interoperability applies to ServiceMix and Mule. The Mule JBI binding enables Mule components to interact with the ServiceMix JBI container. Also, Mule transports, components and transformers can be used inside the ServiceMix JBI container. Likewise, ServiceMix has full support for Mule; so if you already have an investment in some Mule configuration or code, you can reuse it inside ServiceMix along with any other JBI components.

  • No labels

5 Comments

  1. Unknown User (rossmason)

    There are some other points that you've missed (wink)

    • Mule hosts standard POJOs which can be managed from IoC containers such as Spring, Pico, Plexus, classpath or any other source. Mule doesn't expect that objects it manages to implement any Mule API interfaces. In fact Most Mule users only interact with the API when writing transformers.
    • Mule has a JBI interface underway. This will compliment not compete with ServiceMix, but the benefit for Mule users will be that we already have a well-tested container with robust routing features and transaction management. This will give Mule users the chose of Using the current Mule style which is very quick and easy to set up or Use the standard JBI approach with the added benefit of using existing JBI components for ServiceMix, Celtix, etc

    As for your endpoint routing comments above, Mule provides sophisticated routing capabilities where one or more endpoints can be dispatched to depending on content, type, rules, etc. This is all managed by the container not the services or client code. Mule's routing is based on the routing patterns defined in the Enterprise Integration Patterns book http://www.eaipatterns.com. So we support message splitting, aggregation, re-sequencing and more.

    I hope going forward we consolidate our efforts to provide a truly groundbreaking open-source integration platform.

    Cheers,

    Ross Mason

  2. James Strachan

    Thanks for your comments Ross. Here's a few responses...

    • ServiceMix can also host POJOs managed via an IoC container such as Spring (pretty much everyone can (smile). To bind any old POJO to the JBI bus we use a reflection binding, or ActiveSOAP, or XFire or WSIF or Lingo depending on requirements. Since both ServiceMix and Mule can work with POJOs I didn't feel it warranted being mentioned on this FAQ entry
    • ServiceMix already has JBI bindings for Mule; which you're welcome to use, though it looks like you're writing all your own JBI plumbing inside Mule for some reason.

    Sure I totally understand that the Mule container does the routing - ServiceMix also supports all the patterns in Gregor's EIP book and the same level of robust routing features. The main difference is ServiceMix allows standard JBI components to perform routing as well as the container (e.g. any JBI compliant BPEL engine or routing engine can take over the routing capability, or a component can delegate this back to the container) whereas in Mule the container does the routing.

    JBI is designed to let components take part in routing, whether explicit or indirectly by exposing policy based metadata which can be used with things like WS-Policy - or they can just let the container do it. So with JBI there is a much richer routing model; based on standards like WSDL, WS-Policy and so forth. So the Mule routing approach is a subset of the routing capabilities in JBI and ServiceMix.

    I'm glad to hear you're looking to consoliate efforts - we've tried to do everything we can to ensure a consolidation in this space (we've integrated Mule and provided Mule JBI bindings for you). Though I was surprised to see an attempt at a JBI container in Mule's CVS repo the other day - hardly consolidation eh Ross? (smile).

  3. Unknown User (rossmason)

    Hey James, The reasons Mule has its own JBI API implementation -

    • is to take advantage of our already well tested ESB framework rather than use a new container which still in development and hasn't been tested in the real world.
    • there is loads of functionality already integrated into Mule that has been tried, tested and works. It seems pointless to re-implement routing, transformation, transaction management, container, etc in a new project when Mule already does this.
    • To allow existing Mule customers to switch between JBI and Mule seamlessly. We fully intend to support out existing API but also provide a JBI API. The advantage of the Mule API is that there's less of a learning curve to get a project up and running and setting up fully functional prototypes is a breeze.

    I think consolidation should have began by approaching existing open source ESB products such as Mule before embarking on a new implementation so we could join our efforts, eh James (smile). Obviously, the Mule team want to maintain the success and ongoing efforts with Mule, but working on a new container such as ServiceMix doesn't make sense when we can reuse our own technology and give our existing customers and users the option of the JBI or Mule API.

    Regarding consolidation from this point forward, I would like to see coordination between Mule, ServiceMix and Celtix to ensure that we don't duplicate JBI component implementations and so that the components and bindings we provide are assured to work with each other, thus providing a broad range of components that work together. As we know from past J2EE experiences, a standard API does not mean components are interchangeable due to specification misinterpretations and implementation quality.

    As for your efforts so far: "we've integrated Mule and provided Mule JBI bindings for you"
    Before you push features of a project its good practice to implement them (smile). The Mule support in ServiceMix right now is not functional because the required methods are just TODO statements. I'm happy to help you out with this.

    Cheers,

    Ross

    1. James Strachan

      I think consolidation should have began by approaching existing open source ESB products such as Mule before embarking on a new implementation so we could join our efforts, eh James .

      We obviously considered it Ross. We've been doing this open source thing for quite a while and know a thing or two about reuse - we reuse a lot of code.

      However we didn't feel the core abstractions and APIs in Mule were right for JBI - we felt to do JBI justice requires a new container built from the ground up on JBI principles, patterns and abstractions rather than tacking JBI onto the side of a quite different model (UMO). So we didn't feel there was much code in Mule we could reuse - other than Mule in itself - which we did by providing a JBI component to Mule. So we are reusing Mule, as a JBI component - but it doesn't add much value when implementing a JBI container IMHO (e.g. your own JBI container implementation is pretty much all new code).

      Whats more surprising is given that JBI is very different from Mule's abstractions, you never considered reusing any of ServiceMix's JBI container but have started down the road implementing it all yourself. That's clearly not reuse in action Ross (smile).

      Creating a proper JBI container with management, deployment units and Ant tasks is alot of work - so I'm surprised you're not reusing ServiceMix given how there's heaps of JBI code there which is tried and tested and in the process of being certified with Geronimo at Apache.

      Obviously, the Mule team want to maintain the success and ongoing efforts with Mule, but working on a new container such as ServiceMix doesn't make sense when we can reuse our own technology and give our existing customers and users the option of the JBI or Mule API.

      It'd certainly make sense to try package your Mule components as JBI components so folks can use Mule components in any JBI container. However writing your own JBI container still doesn't make much sense to me - but hey do whatever you like Ross.

      Regarding consolidation from this point forward, I would like to see coordination between Mule, ServiceMix and Celtix to ensure that we don't duplicate JBI component implementations and so that the components and bindings we provide are assured to work with each other, thus providing a broad range of components that work together. As we know from past J2EE experiences, a standard API does not mean components are interchangeable due to specification misinterpretations and implementation quality.

      Agreed.

      As for your efforts so far: "we've integrated Mule and provided Mule JBI bindings for you"
Before you push features of a project its good practice to implement them . The Mule support in ServiceMix right now is not functional because the required methods are just TODO statements. I'm happy to help you out with this.

      Good catch (smile) Those methods are now implemented; though I'm not sure if its right - any chance you could take a look please?

  4. Unknown User (rich.petersen@logicblaze.com)

    I just updated the comparison - kept a lot of the original content, but tried to shift the tone from being critical of the design of Mule to the intended benefits of JBI.