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/+.

InfoQ: SCA Interview

A recently published interview of SCA TC members by InfoQ covered many debated issues. Most of the issues are already debated outside and many like myself already commented on the same. However, it would be informative to read perspective from SCA drivers (just FYI I am too member of SCA-Assembly, SCA-BPEL and SCA-Binding TC). Some of the important issues discussed in the interview are: SCA and JBI, SCA and WCF, OASIS vs W3C, SCA and J2EE etc.

Here are some excerpts(verbatim from above InfoQ interview):
SCA & JBI:
Technically there is no overlap. SCA can be used on a JBI runtime, but it is also possible to use SCA without JBI and JBI without SCA. JBI is engine-to-engine. ...SCA looks at defining abstract notions of service invocations at design-time.

SCA & WCF:
Windows Communication Framework (WCF) has some of the features of the SCA service component model, but there is no real equivalent of the SCA assembly model for the composition of applications.

SCA & JEE:
SCA works with JEE rather than competing....(however)..in the context of SOA, or composite applications, there is a need for more facilities and capabilities than JavaEE provides, elements that are beyond the scope of JavaEE....Using SCA, The runtime might still use JMS and one of the JAX SOAP stacks, but their APIs would not be visible to the developer.

SCA-J not being in JCP:
1. SCA as a whole is not a Java specification
2. making liaison between the Java group and the other groups more difficult.
3. It also keeps all the SCA specifications available under one, easy to understand license.
4. the SCA-J team really is looking at how to map language independent notions onto Java

Choice between OASIS and W3C:
OASIS are about business and implementation standards more than W3C.

Spring apps on OSGI

In my post on April 6th, 2007 I mentioned about the availability of Spring OSGI’s first milestone. However, in that post I did not cover much of the details. Anyway, the specification of Spring-OSGI is now posted on Spring Framework’s site.



The specification mentions its goal to provide an “easier path to build Spring applications that can be deployed in an OSGi execution environment, and that can take advantage of the services offered by the OSGi framework”.

The Spring-OSGI effort targets to combine the best features of both OSGI and Spring. OSGI has its strength in providing a lightweight micro-kernel where modules (read “bundles” in OSGI) can be dynamically added or removed. OSGI also provides a better isolation. The isolation is useful to co-exist multiple version of the same service. It isolated the potential problems on class conflicts. Spring provides an easy to use framework based on DI and AOP powered with various services (Spring ecosystem). Thus the combination targets, (I am listing benefits listed in the specs into two separate buckets), to give benefits from both the worlds:

Benefits inherited from OSGI
· Better separation of application logic into modules
· The ability to deploy multiple versions of a module concurrently
· The ability to dynamically discover and use services provided by other modules in the system
· The ability to dynamically deploy, update and undeploy modules in a running system
Benefits inherited from Spring:
· Use of the Spring Framework to instantiate, configure, assemble, and decorate components within and across modules.
· A simple and familiar programming model for enterprise developers to exploit the features of the OSGi platform.
In a recent interview, Interface21’s CTO Andrian Colyer, elaborated a practical and interesting scenario of using the Spring-OSGI. If a service in use needs an upgrade, behind the scene, you can bring down the service and replace with the newer upgraded service without any glitch. Spring OSGI combination manages the switching of services in the background. Spring provides a stable proxy in this scenario while OSGI provides dynamic lifecycle and versioning.” SpringOSGI solves this problem not only for ‘stateless’ services but for ‘stateful’ services too.

We may see various service platforms leveraging this powerful combination. However, Spring-OSGi might not be the only app framework based on OSGI. e.g. OSGI based Microkernel servers currently offered by different vendors are not Spring based. In addition to Spring-OSGi combination, some independend work being done to map SCA and OSGI. Moreover, OSGI itself is going through further enhancement to support distributed case. Some ESB vendors may have a look at OSGI either for dynamic services. Anyway, With such different pieces working together, more powerful platforms may emerge. The combined platforms would be effectively used to build large and complex enterprise applications. (On a side note: There is another effort, JSR 312 for JBI 2.0, in java world to combine SCA and OSGI “like features” . I commented on the efforts in my earlier post )

Spring
OSGI
JBI

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)

ESB vendors’s response to SCA

Most of the key ESB vendors are already participating in finalizing SCA 1.0 specifications. The list contains on Oracle, IBM, BEA, Tibco, Sun, Iona, Progress (Sonic), Jboss (Redhat), CapeClear, and more. (You may find a latest list at http://www.osoa.org/display/Main/Service+Component+Architecture+Partners)

Most of them see a value in SCA as a promise to have standard for a simplified and powerful Component model to assemble SOA based applications/integrations. They understand a need of a common framework to connecte and assemble SOA components together so as to deploy on various middleware including their ESBs.

(http://www.osoa.org/display/Main/Partner+Motivations)

The commitments from different participants may vary significantly. Some may participate to provide inputs and be part of standardizations with two fold focus: one to influence the direction and another to align their products. Some of them may start implementations based on SCA specifications. The early participants like IBM, BEA and Oracle would offer solutions based on SCA earlier than others. Apache open source’s Servicemix allows deploying SCA composite in its container. Other vendors may work on aligning their products to support SCA. However, some vendors may play wait and watch to see a market adaption and provide a choice when customers demand.

Irrespective to their commitment, they may support SCA differently.

There are three broader possibilities.

1. Build a platform based of SCA foundation: A compatible to SCA in a way SCA as a first class citizen. Such platform can be a monolithic or a modular with different engines for different component types like BPEL, Java, etc. Such implementation would directly use SCA assembly metadata.
   
2. Deploy SCA on their container: support deployment of SCA composite in their container. In this model, as a part of deployment, a container would consume SCA composite but may transform to its own runtime metadata.
3. Integrate: Integrate with SCA based container but the SCA based container is outside the core platform.

Many of ESB vendors took one of these approaches (or a last one “do nothing”) for JBI. For example, ServiceMix is based on JBI while Oracle ESB 10.1.3 provides a JBI container to integrate with ESB.

Here, I am giving a reference to JBI as an example of ESB world’s response to a standard specification. JBI and SCA have some overlapping and some complementary functionality. JBI and SCA is another subject to discuss in detail. Since we are on the subject, I would make a passing note that JBI provides a framework and runtime specifications mainly for integration architects and middleware runtime platform (SPIs) so that runtime containers can be interconnected. SCA specification does not dictate a runtime implementation. One may enhance a JBI based runtime for SCA. There is a little overlap but a very good value addition.

In Summary, SCA is a very good specifications for ESBs to provide SOA platform. We may see some innovation from ESB vendors while implementing it.

SCA

ESB