OSGi and JSRs

We did not want to elaborate on issues between JSRs and OSGi in a recently published article.
OSGi specification started with JSR-8 which was intended to be based on Sun’s Java Embedded Services 1.0. However when the JSR-8 was withdrawn And the work was carried out by OSGi,a non-profit alliance. Over a period of time, OSGi’s work directly or indirectly influenced many of the JSRs (e.g. 232, 239, 246 (Mobile Specs)) and thus J2ME. However, OSGi and JSRs have not always been in good friendship. For example, Sun introduced JSR-277 to define a competing (overlaps in packaging/deployment but differs in dynamics/lifecycle) model to provide a new distribution format, a repository, discovery, loading, and integrity mechanisms at runtime. Though a couple of OSGi folks were members of this JSR-277, this JSR largely was viewed by OSGi community as an act of ignoring their 8 years of experience. In contrast to JSR-277, the recently approved JSR-291 for Dynamic Component support is a direct adoption of OSGi’s R4 specification. Similarly JSR-294 would add a VM level modularity support in Java 7. However, the recently introduced JSR-316 for J2EE 6 defers the adoption of JSR-277 and does not comment on adoption of JSR-291. Similarly, a JSR for JBI 2.0 (JSR-312) acknowledges a need to add OSGi features but stays away from embracing it (Specific comments: “Enhancements to support full compatibility with OSGi, without necessarily requiring OSGi.”). I hope that future releases of J2SE / J2EE does directly adopt OSGi R4/+.

JSR 314 for JSF2.0 started

This JSR got approval in review ballot. http://jcp.org/en/jsr/detail?id=314

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)