Mule Founder: JBI Missing the Mark

Posted by Masoud Kalali on May 05, 2008 03:36 AM

Community

Java,

SOA

Topics

ESB

About two weeks after Mule 2.0 release announcement, Ross Mason, founder of Mule, "a lightweight and highly scalable ESB", discussed how Java Business Integration (JBI) compares with Mule's architecture.

Ross mentioned several missing points in JBI 1.0 spec that made him go with his own architecture instead of implementing JBI. Among his points, his concerns about being very XML dependent, lack of re-usability of JBI artifacts (Binding Components, Service Engines), heavy set of APIs are the most notable items.

Ross Mason thinks that JBI’s wide scope is one of the reasons that reduce JBI artifacts re-usability:

By their nature, vendors need to differentiate themselves in order to compete. Because JBI attempts to define how everything should work vendors have to build in features and workarounds that go beyond the specification to differentiate their service container. This breaks the re-use story since, if I use a JBI Binding Component in one container does not mean it will behave the same way in another container.

Vendors within the JBI community try to differentiate their products from other competitors, as vendors always do, but each vendor will try to have better implemented artifacts in terms of performance, reliability and level of industry wide standards supports. JBI 1.0 is the first try to provide an answer for integration requirements and for sure it has some drawbacks which are supposed to be addressed in JBI 2.0.

Also, Ross expressed his concerns over JBI’s heavy API and more than necessary knowledge which developers should have about the JBI spec in order to develop JBI artiacts:

You need to implement a pretty heavy API to implement a service. This means the guys writing your services need to understand more about JBI than is necessary. Mule has always believed that services can be any object such as a POJO, EJB Session bean or proxy to another component…

James Lorenzen, a senior consultant with Accenture, replied to Ross’ opinion about JBI’s heavy API as follows:

I disagree that JBI users have to know more about JBI than is necessary, but then again it’s hard for me to play that person since I am also a component developer…

and

Again I have not had a hard time teaching non JBI users about JBI. However I skip the spec and jump straight to a demonstration of how you can use JBI.

Another important point in Ross’ blog post is the Normalized Message Router’s (NMR) XML centric nature:

XML messages will be used for moving data around. For some systems this is true, but for most legacy systems, XML did not exist when they were built and they use a variety of message types such as Cobol CopyBook, CSV, binary records, custom flat files, etc.

James Lorenzen explains how the NMR benefits from this XML centric nature:

Since everything is converted to XML to be passed over the NMR, the only transformation needed for that is XML. So what you [say] is true, but to a JBI user I guess it does not matter. I guess on the other side, if the NMR allowed for other message types, then yes I guess you would need more transformers, but I guess with JBI the transformers are the Binding Components.

Binding components should be able to simply interact with the NMR in a well known and well described format in order to make it possible to feed each binding components with information injected into NMR by the other components, otherwise it could be very complicated to make constant communication between binding components.

Ross Mason expressed his concerns on venders view of the problem space which causes the Open source to win :

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).

One might argue that specs are developed by community leaders from different vendors, joining to shape an specification for developing a new standard which each vendor will implement. Usually this group which forms the “experts group” are coming from the developer community, so there should not be that deep differences between a JSR which address a problem domain and a none-standard Open source product.

Both Ross Mason and James Lorenzen agree that JBI spec has shortages when it come to streaming content into the NMR and between JBI artifacts, specifically in that whatever that enters the NMR has to be converted into XML, which can be a resource consuming process.

1. Back to top

   JBI use of XML has benefits - downsides dealt with

   May 5, 2008 9:59 AM by Bill Miller

   The purpose of the XAware project has been to provide an easier, powerful, standards-based way to create composite XML views of multiple data systems handling access to and from legacy systems and web data resources with multiple formats. Using XAware capability deals effectively with the challenges of JBI/NMR requiring XML; including mapping, transformation, legacy system access, and streaming performance - leaving only the benefits of reusability and interoperability of having one common message type. While XAware has only been available for a short time in its open source project incarnation, an earlier commercial only incarnation has seen fairly wide adoption in a number of large and standardized enterprise SOA implementations. The open source project is showing early signs of success with more than 50,000 downloads so far and about 1,000 per day . Converting to and from XML doesn't have to be a limiter in use of JBI. Bill Miller, xaware.org

   Reply

2. Back to top

   Some observations from the speclead

   May 8, 2008 8:24 PM by Peter Walker

   Since my name was mentioned in the original blog by Ross Mason let me make some observations. First I welcome comments from the wider community, standards are not trivially come by and 1.0 versions frequently need revision. That said I personally don't think one can say that JBI "misses its mark" but I'd love to start a dialog on the points in the blog.
   
   First I'm surprised to see anyone say that JBI is too big. The Javadocs being half of the spec, the section describing key JBI concepts is only a few pages - indeed one of the criticisms is that we didn't spend enough time presenting JBI in context for a number of different developer roles, something we will fix in JBI 2.0. But in terms of our target of specifying a simple model of mediated message exchange I think JBI 1.0 hits the spot well. I'm not sure I understand the comment about a heavyweight API - the three mandatory and one optional SPIs described for components in the spec seems remarkably minimalistic. Perhaps Ross could clarify his comment.
   
   On our choice of XML for the definition of normalized messages I plead partly guilty. The use cases employed for JBI 1.0 led us to believe that developers of Enterprise Apps would be happy following the guideline that "normalizing at the edge" is a good thing. Indeed if you get to the next step of using canonicalized messages in the core of the Integration the better the results you will see. With more implementation experience it's clear that we need a better story for non-XML data. The 1.0 spec offers a solution using MTOM/XOP but more is needed.
   
   Regarding the list of components for JBI, I suggest a look at this
   
   Leaving JBI 1.0, I now come to JBI 2.0. JBI 2.0 was not started because 1.0 was broken and we don't expect to deprecate 1.0. 2.0 is called that because it reflects the relatively large scope of new capabilities we expect to implement and define. It didn't seem right to call it 1.1 or even 1.5!
   
   Our own work here at Sun is focussed on Project Fuji. At the core of Project Fuji is a lightweight micro-kernel based on JBI (JSR 208) and OSGi. Packaged as an OSGi bundle, the micro-kernel can be installed in any OSGi-compliant runtime. JSR 208 support allows all of your existing JBI components to run in Fuji and also introduces a robust, message-based service bus to the OSGi environment. Developer experience is a primary focal point in Fuji as evidenced by the level of flexibility and accessibility offered in the platform.
   
   On the JBI 2.0 JSR - the effort has recently been re-energized around the following manifesto: JBI 2.0: Community and Approachability.
   
   JBI 2.0 will be implementation oriented, community led project. These are capabilities we want to add to JBI, though not all will impact the specification:
   o Simpler programming model for a lower barrier to entry
   o Alternatives to using WSDL
   o Interceptors
   o Enhanced support for non-XML payloads and streamed data
   o OSGi
   o Standardize how Java EE technologies are integrated into a JBI environment
   o Incremental JBI 1.0 issues,
   
   I'm writing this from the JavaOne conference and the Expert Group had a face to face meeting this week to continue the work. Having discussed most of these 2.0 requirements with Ross a few months back I feel sure that the JBI community would welcome his participation going forward.
   
   I believe that JBI 1.0 hits its mark and is a significant first achievement in this technology space and with the widest support of the community we will make sure that JBI 2.0 scores a BULL'S EYE!
   

   Reply

• Older >