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.
5 Comments
Unknown User (rossmason)
There are some other points that you've missed![(wink)](/confluence/s/p9b4rx/8804/1naq7q0/_/images/icons/emoticons/wink.svg)
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
James Strachan
Thanks for your comments Ross. Here's a few responses...
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?
.
Unknown User (rossmason)
Hey James, The reasons Mule has its own JBI API implementation -
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
. 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"
. 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.
Before you push features of a project its good practice to implement them
Cheers,
Ross
James Strachan
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
.
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.
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.
Agreed.
Good catch
Those methods are now implemented; though I'm not sure if its right - any chance you could take a look please?
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.