As we look to the New Year we might look in hope at the promise of JBI to solve our organization's integration woes. JavaTM Business Integration (JBI) is yet another integration silver bullet and yet again coming from the community that brought us Java - arguably the business world's de facto standard computer software language. Or as I like to say "COBOL for the new millennium!"
I do like Java. It is a wonderful language. It is loved generally because it gives you all the benefits of OO without all the headaches of memory management. I mean that's the bottom line right? The other benefit argument is that while C++ and CORBA went through laboriously tedious standards processes, Java had a much more streamlined process (because it wasn't completely open) and it took all the benefits from what was learned from C++ and CORBA.
But as we look into the New Year with hope and see further off into Christmas future we should surely look to lessons learned from Christmas past.
First of all the funny thing about the Java community is that for a long time it said that J2EE could and should be used for integration. Then it decided that really you needed JCA ... inside of J2EE of course. It insisted for a long time that this was the case. Customers finally got through the fact that they didn't want a heavy costly J2EE container everywhere they had an integration problem and they also didn't want to route everything thing through a hub (even a J2EE hub). They got this message across by deploying plain old java objects (POJO) at some of the integration points to get the job done. It was cheap, light weight and had better performance.
So the Java community came up with JavaTM Business Integration (JBI) or affectionately called JSR 208 by hard core Java geeks.
JBI has some cool features. I was part of a team at JavaOne this year that demonstrated some really cool Java and .Net interoperability using Artix and JBI. I learned a lot.
The main cool thing about JBI is that it allows you to integrate Java with other non-Java based applications in a standard Java way - without having to use a JCA (which was more about databases and DB based applications like popular CRMs etc.) and therefore J2EE which is a heavyweight container for deploying applications into (or as I like to say "CICS for a new millennium!")
JBI uses Binding Components (BC), for things such as transports and protocols, and Service Engines (SE) where you can deploy business logic drivers - functionality like orchestration or transformation etc. JBI also uses Normalized Message Router (NMR) to route messages between service consumers and providers.
So without giving a JBI tutorial, you can download the specification here, I'd like to explain where I see the dangers.
- JBI has a very Java centric view of the world, which is natural as it comes from the Java community. JBI was developed for Java developers. This will work well for larger primarily Java development shops - and I mean where the large majority of the technology is Java based. However many large organizations have been around a lot longer than Java and have integration needs that Java will not solve on its own. I'm a big fan of using "natural" forms of integration and not forcing unnatural acts.
- Although the specification was developed for both J2SE and J2EE developers, there is an emphasis in the JSR on J2EE. I get a sense that many implementations of JBI will require J2EE containers. Indeed Sun's reference implementation, that I and my colleagues used at JavaOne, required using Sun's App Server 8. Therefore, for many, JBI will become JCA all over again. Requiring a heavy container in order to deploy integrations points for applications. I'm sure that there will be several JBI implementations that will not require J2EE.
- The most important danger for JBI is that it will become an EAI like hub-and-spoke technology - even without the J2EE problem mentioned above. I promised in a previous post that I'd outline my issues with EAI, I'll do that soon. Assuming that you already recognize that EAI has lots of issues, then you should see the danger with JBI. The JBI architecture with it's canonical form like normalized message (routed using NMR), and inbound-to-NMR-to-outbound type approach, could become yet another EAI hub. Indeed the specification's introduction summary actually opens with the term "Enterprise application integration (EAI)".
In summary:
JBI is a valuable new specification from the Java community. It finally says that for business integration needs J2EE and JCA just don't really make the cut. The latter are for housing application logic and for getting data in and out of your favorite applications and databases.
JBI's components, Binding Components and Service Engines, are a good architectural approach to the problem for Java developers separating out the transport/protocol problem from the transformation/orchestration etc. problem.
However if you are not a fan of EAI, and some of you may be, then be careful how your architects, designers, and developers use JBI in your organization. Demand from them a more distributed architecture - deploying JBI at integration endpoints rather than in a hub-and-spoke topology. There may be a case for a JBI based router here or there but that usage should require a strong case.
Have a Happy New Year.
IP Babble is the personal blog of William Henry.