Let me first describe the context a little bit more for those who are not familiar with JBI or are not attending JavaOne. If you are at JavaOne, chances are very high that you heard of JBI. Its all over the place.
JBI is a new Java specification that was released as Public Final Draft very recently (Jun 20, 2005). You can get more info and download the spec from http://jcp.org/en/jsr/detail?id=208.
SAP has been very actively involved in development of this specification right from its inception. Its been couple of years now come to think about it! I have been on the Expert Group and have witnessed the many ups and downs of this JSR (Java Specification Request). Since this is the first focused attempt to standardize business integration in Java and since most of the Expert Group (EG for short) members are either vendors or users of integration products, there were lots of different perspectives about how and what needs to be standardized. For example, whether JBI should require J2EE, whether JBI should define its own thread/work management, timer services, etc, whether and how much should JBI align itself with other existing and emerging relevant Java technologies such as JCA, JAX-WS, JSR 265 ( SAPs first JSR Java API for Web services policy utilization), so and so forth.
It is interesting and quite exciting to see that the specification has finally made it and is now publicly available right in time for bringing it to the attention of the JavaOne attendees. JBI has been promoted and discussed a lot at JavaOne. There were references to JBI in the key note speeches, and there quite a few dedicated technical sessions on JBI. There is also going to be a panel discussion on JBI tomorrow (Thu Jun 30, Session ID: TS-5238) at noon. I will be representing SAP on this panel. Come and meet us there for any hard questions you may have.
So if you are wondering what JBI is all about? In my presentations at the SAP booth, I am answering this question from a business perspective, that is, what business problem does it solve. My answer is three fold
A> JBI can be used by customers to avoid vendor lock-in. Today customers with integration requirements shop around and purchase some integration product that meets their current needs. However for any complex future integration needs, there is now a tight dependency upon the vendor providing that product (its release cycle, architecture, API, so and so forth) for their existing and future needs. On the contrary, the goal of JBI is to allow you pick and choose (and even substitute in future if you are unhappy) different integration components from different vendors.
B> Right-sizing of the solution. Today if you purchase an integration product from a vendor, you will typically get a lot more than what your current needs are. With the flexibility of JBI, it should be possible to assemble an integration platform that is just the right size for your needs. Moreover, each component may come from a different vendor who has proven core competency in that particular problem domain.
C> Minimal learning curve. By embracing Web services as the design center, JBI minimizes the learning curve and also assists greatly in implementing SOA.
The common generic questions I am getting are With so many Web services specifications around, why do we still need JBI? I already have an integration solution in place that is working fine. So why should I care about JBI now? What runtime does JBI need? Does it run in one JVM or can JBI be distributed?
Specifically in the context of SAP, the questions are Whether and how does JBI relate to NetWeaver Business Process Platform? How would support for JBI in NetWeaver look like? Would XI become a JBI container and provide interfaces compliant with JBI?
I have to now run and get in time at the Moscone Center in San Francisco to give the JBI presentation today.