Last month, Pymma had a stand at the Devoxx exhibition Paris 2012 and made evangelisation on OpenESB. Even if delegates were more web pages development oriented, the exhibition was interesting since we had the pleasure to discuss with kind people who expressed unexpected thinking and point of view on ESB and integration. In our stand, we received many people working with ESB competitors like Mule or ServicesMix and consorts. They asked us information about OpenESB and naturally we started our presentation by talking about JBI which is the basis layer of OpenESB. The main part of our visitors never heard about JBI and the others told us that they thought that JBI did not exist anymore or at least it is a legacy technology is close to death.
Since I had this conversation 2-3 times, I asked them from where they get that opinion? They replied that many ESB gurus announce JBI’s end and its replacement by X and Y technologies. I had to confess that I had no expertness on these X and Y technologies and I was not able to estimate if they are better or not than a JBI implementations like OpenESB. So, I was very interested in understanding reasons for JBI’s death and the same day, I typed “JBI dead” on Google and I found papers and forums on that topic. I cannot detail here all the arguments provided but two often came across on Internet.
· The first is that there is no JBI version 2
· Companies and editors supporting JBI are migrating to other technologies
Replying to the first argument is very easy since you can note that XML itself is in version 1.x and 99% of wsdl found on the market follow the specification 1.1 (event if V2 exists). High version number for a specification is not proof of maturity. Regarding the JBI supports number, it is true that when Sun Microsystems disappears, the main JBI support disappears as well. However, I never think that developers or end users are really concerned about internal architecture. They evaluate tools easiness and their impacts on development and organisation more than tools internal architecture. Who takes care about SCA when it uses Oracle SOA suite or Websphere products? Very few!!!
So in this blog, I will not talk about JBI architecture benefits but just provide the reader with our feedback on JBI impacts on development and maintenance improvement. As you certainly know, JBI defines many technical concepts and the most famous is the bus named NMR (Normalized Message Router). From my point of view, JBI key feature is not The NMR but the way it constraints people to use WSDL. “JBI defines an architecture that allows the construction of integration systems from plug-in components that interoperate through the method of mediated message exchange. The message exchange model is based on the web services description language 2.0 [WSDL 2.0] or 1.1 [WSDL 1.1]”.
Figure 1: In JBI partners are known through their WSDL
In other words, JBI forces any entity which wants a connection to the bus (NMR), to define first a WSDL which describes the services it proposes. This constraint has always been seen as a burden by developers since it forces them to follow external definitions and proposes a way of thinking different from the one the developers are used to. A simple proof is the number of WSDLs found in integration applications generated by Java or C# tools which mimic Java or C# classes’ behaviour and workaround WSDL handmade definition. WSDL specifications require effort for a good understanding and XSD knowledge to be efficient. So we can understand that some people are reluctant to read pages of specification before starting wsdl definition.Using standard, clean WSDL documents designed from business specifications defines a strict relationship stable and understandable between partners. It fixes messages exchange patterns, message content, etc...Consequently, partner’s knowledge and understanding is limited at the technical level, to one or more WSDLs which define boundaries between partners.
When components, applications are defined by a WSDL interface, it reinforces encapsulation, decreases dependencies and consequently makes easier parallel designs, developments and reduces dramatically the maintenance cost. During the two last years, I had the opportunity to work on large OpenESB projects. These projects took a great advantage from strong components and applications encapsulation which had a beneficial impact on IT teams and development process too. When development tasks are limited by boundaries, it’s easier to assign precise agenda and objectives to the teams. When focusing on contract fulfilment only, the developer shrug off others team progress or delay and follow their own ways without pressure from the other teams. In very few cases, this way of working is obtained by a clever management who has to impose a strict respect of limit and boundaries in during specification, design and development stages. Since JBI forces development teams to define contracts and boundaries, it made the project manager work easier. This is the key advantage of JBI!!!
Figure 2: JBI virtuous circle
Moreover, we also observed that when development teams mention the word “contract” hundreds times a day and WSDLs become a referent for they works, this has a great influence on other teams. Very quickly business analysts understand that functional contract definitions between internal and external partners cannot just be fixed by technical teams who have not a business understanding of the business processes. Very quickly, BAs make effort to move from literal to service oriented business specifications. When service definition and reusing are understood at the business level, companies take a great benefit from Service Oriented Technologies since the services reusing is really efficient when business makes its own SOA concepts. This evolution to services orientation at the company level seen in many projects is not complete in one day or event one month and takes time to be mature. Each time this evolution has been initiated by development teams forced by OpenESB and JBI to use WSDL. Once convert to service orientation they push their colleague to adopt it.
I spent now many decades in IT environment and I saw many technologies waves disrupt IT development without impacting business way of thinking IT specifications. Neither distributed architecture nor object oriented technologies change literal business specification. For the first time service and contract orientation technologies impact the way companies have thought about their processes.
Cancelling such architectures would a major loss for Service Oriented Technologies adoption.