Khanderao on Emerging And Integration Technologies

Tuesday, May 08, 2007

JSR-312 launched to provide JBI 2.0 : (Too?) ambitious to deliver in the given time fulfill all goals?

A technical committee (experts group) has been formed for JSR-312 to define the next version of JBI, version 2.0. Though software vendors like Sun, Borland, Iona, Tibco, Redhat, Webmethods (now Software AG) are participating in writing this specification, most of the major Application Server as well as ESB vendors are missing from the list. BEA and IBM were not in the camp of the supporters of JBI 1.0 too. Some other vendors from the JBI 1.0 are also dropped out because of their focus on SCA (now OCSA). Without a critical support from key vendors, a survial of such technologies becomes difficult(if not irrelevant). However, let me not prematurely declare a death. I would be happy to see some good results, like bridging gaps between various technologies, coming out of this JSR and such efforts.

I noticed many desired features in the wish list of this JSR. As noted in the JSR draft, the JBI 2.0 intends to be a target runtime for SCA. I had mentioned a possibility of such architecture in my previous posts. However, OSGI may too target to provide a runtime for SCA. There are some overlaps between OSGI’s Admin wire - DS specifications and metadata with SCA. Additionally OSGI provides features like lifecycle management, class loading, etc. Hence, the die-hard supporters of OSGI see OSGI to be evolving not as a runtime for SCA but replacing a need of SCA. However, OSGI's DS specifications still need to be enhanced to support enterprise features in multi-JVM environment. Interestingly JBI's JSR too mentions OSGi as “Enhancements to support full compatibility with OSGi, without necessarily requiring OSGi”. Since the Experts group is yet to meet and flush out the details, I do not give more information.

Coming back to the JBI2.0, it seems that the specification may add much wanted integration features like XSL, integrations with orchestrations (BPEL), Rules, etc to keep whatever limited i momentum it has in the market of ESB vendors where JBI1.0 got some traction with atleast few of the implementations supporting it. However, the scope and lack of technical clarity to provide a platform for some conflicting and some overlapping standards, (JBI1.0, SCA, OSGI, WS-CDL, BPEL,) and goals concerns me about a feasibility of this JSR to provide a “simple architecture in a timely manner” (as stated in JSR). I hope that in F2F meeting the expert group can have a clarity of realistic goals and a higher level architecture. If I could not participate in this JSR, I would at least keep a close watch on its technical direction.

JBI 2.0 would be targeted both for J2SE and J2EE. Leaders of JSR-312 and JSR-313 are yet to align their plans. I already raised this concern to both of both to Ron+Peter and Bill Shannon (leaders of the two JSRs)

Labels: , , , , , ,

Add to Technorati Favorites

Save This Page on


  • Khanderao,

    A brief clarification on our (Paremus) currently view on OSGi, SCA and JBI standards.

    OSGi and SCA are fundamental to our long term product strategy. Infiniflow is built from the ground up leveraging these standards; and is, we believe, the first adaptive distributed runtime SOA framework to do so.

    We are also actively participating in the OSGi Enterprise working group on a number of activities.

    Paremus currently have no plans to implement JBI; JBI1.0 not being relevant . I've not had time to review the new JBI2.0 proposal, so will reserve judgement.

    Happy to post an update once I've got around to it.



    By Blogger Richard Nicholson, at 8:58 AM  

  • Richard, Thanks for your clarification...I would remove the reference of Paremus supporting all the three.

    By Blogger Khanderao, at 5:48 PM  

Post a Comment

<< Home