OSGi in Enterprise Application Servers: A latest PR

In our, article on OSGi in SOA World Magazine, we (Dave Chappell and I) had predicated increasing uptake of OSGi in Enterprise Application Servers. Following PR from OSGi confirmed the prediction.

“With the lion’s share of the enterprise application server market deploying OSGi technology, the alliance has created the dynamic module system for Java™ technology,” said Stan Moyer, president of the OSGi Alliance. “The OSGi Service Platform delivers universal middleware for Java to providers and their customers, modularizing and componentizing the Java platform and allowing applications to be adapted remotely and in real time.”

Leading vendors using OSGi technology include IBM’s WebSphere, Oracle’s WebLogic, Paremus’ Infiniflow Service Fabric, ProSyst’s ModuleFusion, Red Hat’s JBoss, SpringSource’s SpringSource Application Platform and Sun Microsystems’ GlassFish Enterprise Server. Both Oracle and SAP AG have announced that they will use OSGi technology as the foundation for their next-generation application servers.

These leaders note the distinct value OSGi technology provides, or will provide, to their individual enterprise application server offerings.

“As a founding member and key contributor to the OSGi Alliance since its inception in 1999, IBM is pleased to see OSGi technology gain such significant traction with customers and other vendors,” said Craig Hayman, vice president, IBM WebSphere. “IBM was one of the first vendors to realize the value that OSGi technology brought to client devices and has been shipping WebSphere Application Server built on OSGi technology since 2006. As a result, IBM clients benefit from a modular platform built with proven components and the ability to automatically use only the components required by their application.”

“Oracle WebLogic Server is a great example of the customer benefits of modularization, with its reduced footprint, improved startup time, and flexible configuration options,” said Steven G. Harris, senior vice president of product development at Oracle. “OSGi technology provides the standards-based foundation for delivering and reusing proven WebLogic server modules in multiple ways across the larger Oracle Fusion Middleware product, helping us bring innovations to market more quickly and enabling robust integration with the full Oracle stack.”

“OSGi technology has been fundamental to the Infiniflow Service Fabric since 2005,” said Richard Nicholson, CEO for Paremus. “Infiniflow, which is often regarded as a next-generation distributed application server, is built from OSGi bundles and provides a distributed OSGi technology-based runtime for applications dynamically constructed from a repository of re-usable components. By fusing Cloud resource abstraction, Grid load balancing and dynamic composite SOA, Infiniflow sets new standards for robustness, dynamic scalability and adaption.”

“ProSyst has been working with OSGi technology since 1999,” said Roman Roelofsen, lead architect of ProSyst’s Enterprise OSGi solutions. “In a few days we will officially launch ModuleFusion, our first enterprise OSGi open source initiative. The goal is to help programmers using the OSGi Service Platform as their underlying runtime environment. ModuleFusion contains a full stack typical for Java enterprise applications. This stack currently consists of best-of-breed open source frameworks from the Java ecosystem. Additionally, ModuleFusion contains the necessary glue code to easily use these frameworks within OSGi and therefore provides the next-generation, pure OSGi model for enterprise applications.”

“Running OSGi technology in JBoss Enterprise Middleware Solutions enables our customers to deliver safer services and applications in a more dynamic runtime environment,” said Sacha Labourey, vice president of engineering for Red Hat’s Middleware Business Unit. “We are pleased to have helped the OSGi Service Platform reach the level of industry standard for application servers and are looking forward to continue working with OSGi technology and the other members of the OSGi Alliance.”

“Today, SAP NetWeaver is the technology platform of choice for thousands of customers running mission-critical SAP and non-SAP applications with a wide range of complexity and functionality,” said Prasad Kompalli, senior vice president of SAP NetWeaver Composition, SAP AG. “Continuing the focus on modularization, flexibility and lower TCO, the next-generation SAP NetWeaver Java Application Server will be based on OSGi technology, allowing our customers and partners to benefit fully from further improvements in ease of consumption, flexibility in deployment, and optimized resource consumption.”

“OSGi has become a critical technology for enterprise Java. Demand for modular application architectures, dynamic updating and reloading, flexible version control, and intelligent, granular, dependency management is breaking down the traditional concepts of an application server,” said Adrian Colyer, CTO for SpringSource. “That is why we have chosen OSGi technology as the central standard for the SpringSource Application Platform. Enterprise customers and developers can be freed from legacy constraints and develop next-generation applications that are ready to take advantage of more dynamic compute environments such as those created through virtualization and cloud computing.”

“Sun has seen strong demand for OSGi technology within the GlassFish community,” said Tom Kincaid, executive director, application platforms at Sun Microsystems, Inc. “The GlassFish community will be able to take advantage of the modularity and dynamic extensibility implemented via an OSGi technology-based microkernel in the upcoming GlassFish v3 Prelude release. This modularity is also being used in the Open Enterprise Service Bus (Open ESB) community where the next-generation Open ESB v3 will provide developers with a flexible and easier-to-use platform for the creation of integration and composite applications.”

OSGi technology is a component integration platform with a service-oriented architecture and lifecycle capabilities that enable dynamic delivery of services. OSGi technology is shipping in millions of units worldwide, and is deployed by Fortune 100 companies in home, automotive, mobile and enterprise markets.

OSGi Alliance members develop and facilitate the deployment of OSGi specifications, which serve as the platform for universal middleware in server and embedded environments. Deployment of the open standard greatly increases the value of a wide range of computers and devices that use the Java platform.

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

My recently published SOA World article covering OSGi's state of art and future

SOA World recently published another article co-authored by me. In this article on OSGi, we, Dave Chappell and me, cover some basics of OSGi and discuss its relationship with other emerging technologies and frameworks like SCA, Spring, etc. We also cover some work in the area of distributed OSGi and future direction of OSGi.

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)

SpringOSGi M1 available for download...

This week SpringOSGI reached the first milestone. The availability to download it, added another OpenSource to OSGi(different than OGSI which is Open Grid Services Infrastructure) list of opensources.

http://sourceforge.net/project/showfiles.php?group_id=73357&package_id=227224

The list now goes on..Apache Felix, Equinox OSGi, KnopherFish OSGI, OXSA, Newton, and many others.

This year seems to be a good year to OSGI. Recently IBM and Cisco announced to develop Unified Communications and Collaboration(called UC2) platform based on OSGI. UC2 would not be an open source. So to increase the adoption by developers and industry, these companies would make UC2 freely available.

Anyway, coming back to OSGi which now has many mobile-telecom device vendors on its board. OSGIs start in 1999, it started with JSR-8 ( which was withdrawn). However, quite a few Mobile related JSRs like 232, 239, 246 (Mobile Specs) have come up based on works/concepts from OSGI ( and some JSRs like JSR 277 partially specified features thus became controversial) and some more are coming up JSR291 (Dynamic components) etc

Some of the concepts related to versioning, lifecycle managements, and various other services may find way beyond devices related to Web Services. Off-course, Webservices being stateless, there is already a debate whether 'lifecycle' management makes sense to Webservices or not. However, it all depends on what we makes sense as lifecycle management in the domain.