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.