One of the main differences between Apache Service Mix and Mule ESB is the JBI implementation. Apache Service Mix is a full implementation of the JBI standard. However, you can plug in Mule to a JBI container by using the JBI transport from Mule. I personally love Mule, because it's extremly lightweight and Mule 2 fits ideally with Spring application, finally that Mule 2 is based on Spring 2.x. Up to now I didn't have a deeper look to Apache Service Mix. But based on Alex information, the combination of Apache Active MQ, Camel and Service Mix is a solid basis provided by Apache.
The last couple of years Ross Mason the founder of the Mule Project often discusses why he decided not to adopt JBI for Mule. In his blog "JBI misses the mark" he mentioned the basic idea of Mule:
"[...] Mule was designed around the philosophy of 'Adaptive Integration'. What this means for Mule users is that they can build best-of-bread integration solutions because they can choose which technologies to plug together with Mule. [...]"
About JBI he points the following assumptions and there consequences:
- XMLmessages will be used for moving data around
- Data Transformation is always XML-based
- Service contract will be WSDL
- No need for message streaming
- You need to implement a pretty heavy API to implement a service
- It’s not actually that clear what a service engine is in JBI
"[...] JBI seems to be a 'standard' written by middleware vendors for middleware vendors. This 'vendor view' of the world is one of the main reasons Open Source has done so well. Traditionally, Open Source has been written by developers much closer to the problem being tackled. These developers can deliver a better way of solving the problem using their domain knowledge, experience and the need for something better. This was the ultimate goal Mule and given the success of the project I believe that goal has been realized with the caveat that things can always be improved (which we continue to do). [...]"
3 comments:
Well, you want a comment, here comes :-)
Actually, I think that he is making some valid points. I myself have mixed emotions. As you know, we use Mule ourselves in internal projects with good success, so it is not the case, that I have a problem with Mule.
Having said that, I believe, that component based development and enterprise integration surely rely on standards. And JBI is a pretty lightweight and easy to understand standard. They did not re-invent the wheel by relying on WSDL for example.
I think that JBI as the base technology for reusable business components is a good idea (and is uses already for components like process engines, rule engines...).
I think a certain way of standarisation can do good in the integration business. Why use Mule, ServiceMix...? To get a cleaner architecture. Then why stop with the own modules? By JBI we allow module developers to use a clean, well known standard like WSDL to provide new modules for the ESB. These integrate into the life-cycle management, deployment, configuration management. That's how it should be, no? This is also the reason why I do not understand why projects like Tuscany rather go the OSGi path then wrapping their stuff into a JBI component.
On the other hand it is true that WSDL... is a little heavy weight for simple problems. ServiceMix offers the possibility to either use JBI-standard conform components or Spring beans. Additionally there are Scripting Components. There should be something for every taste :-)
About the XML based communication, I think this concern is grounded. Sure it is nice and easy going to just send objects between components. But also here: in an integration scenario I personally see rather the advantage then the possible limitation.
A few days ago you blog about the new SCA standard. These days the Java One takes place and there are some sessions concerning SCA and one session illustrates the combination about SCA and JBI. In this short blog you can read more about this: http://www.infoq.com/news/2008/05/sca-jbi-together
When you look in mailing lists of open source frameworks, including spring and mule, the SCA standard will be also interesting to them.
Well, then I am probably not completly wrong with my idea, that JBI and SCI should better work together... Maybe the Tuscany/ServiceMix Team will see the benefits as well and will make an integration layer for their projects.
Post a Comment