Shashi Velur’s blog

Web applications are the most common type of deployments on the application servers.

So, if OSGi is going to be a serious contender in the application server market, I would expect it to have great support for deploying web applications using WAR files. So, I looked through the existing documentation on eclipse.org and played with Equinox, Tomcat and Jetty. Here is what I have learned so far:

There are two ways to integrate Equinox’s implementation of OSGi into your server-side environment:

1. Embed your web application server within OSGi server
   • Native OSGi HTTP service implementation of Servlet API 2.4
   • Jetty-based implementation - Also requires the usage of the dynamic OSGi HTTP Service.
2. Embed OSGi server into your existing web application server
   • Equinox Bridge Servlet (Front controller servlet)
   • Dynamic OSGi HTTP Service using the Equinox Bridge Servlet

Option #1 means that the developer is forced to use OSGi HTTP Service. This is great for new web applications built from scratch. The user can programmatically register the servlets and add service listeners to listen for any events (if any one of these instances are started, stopped or updated, we are notified). But, this complicates the development effort required for making an existing WAR file work with this setup. Traditionally, Servlets have been considered “static” - They do not have to be installed/started/stopped dynamically. So, the “dynamic” OSGi HTTP service becomes an overkill in this particular case, IMO. The other disadvantage of this approach is that not all aspects of the Servlet spec are implemented here. For ex., Servlet Filters are not yet available in the native OSGi HTTP service implementation. I am not sure how clustering can be achieved here.

Option #2 uses the standard “Front-controller” pattern and uses the Bridge Servlet as a Front controller servlet. org.eclipse.equinox.servletbridge and the Servlet API are exported automatically to the underlying OSGi framework. So, the modules deployed in the OSGi server have access to the Servlet API to register/unregister servlets. This approach obviously uses the web.xml. So, you can add more servlet mappings for JSPs, if necessary. The other sub-options here revolves around using this Servlet bridge to provide the dynamic OSGi HTTP service.

So, I do not feel comfortable with both of the above options provided by Equinox OSGi implementations. Perhaps, other implementations might have better solutions.

No wonder the folks at SpringSource chose not to implement OSGi HTTP service in their SpringDM server platform for now. They support the standard WAR file deployment within their embedded Tomcat server. This seems like a pragmatic approach to me to support all the existing standard Web Application Archive (WAR) files.

Although I like the other dynamic services (Logging, Configuration, Event Admin Service, etc.) in the OSGi Service Compendium, I am not so sure about the HTTP Service, especially for existing web applications.

What do you think?

Technorati Tags: Equinox, Jetty, OSGi Compendium, OSGi HTTP Service, Servlet Bridge, SpringDM

Here are the things every Java developer working on OSGi-based middleware must know, IMO:

Essentials:

• Design-by-Contract & SOA
• Component/Package Versioning
• OSGi Bundle Lifecycle
• Bundle Manifest directives
• Core OSGi services
• Spring DM (especially for simplification of the usage of OSGi services and writing in-container tests)
• BND tool (I cannot think of a better way to create the OSGi manifest files than this)
• Basics of classloading in OSGi

Advanced Topics:

• HTTP Server options in OSGi (OSGi HTTP Service, HTTP Servlet Bridge, etc.)
• OSGi “uses” directive and the “type leakage” problem
• OSGi Services vs. Extensions/Extension points
• Service Trackers
• Concurrency gotchas in OSGi
• The Whiteboard pattern
• The “Extender bundle pattern”
• OSGi Declarative Services and Configuration Admin Service

Technorati Tags: OSGi, OSGi essentials, Whiteboard pattern

I think the Java developers (especially server side developers) have started looking at OSGi as the next-generation Java Middleware technology. This may not come as a surprise because of the adoption of OSGi by the JEE server vendors and Java (server, desktop and embedded Java) community in general.

OSGi technology:

1. Enforces better componentization (separation of concerns) than most existing techniques in JEE (Using one classloader per bundle).
2. Provides versioning of components and the ability to deploy multiple versions of the same components in the same VM, unlike JEE.
3. Unless you use one ”component” for your entire application/product, OSGi enforces SOA for components using dynamic services (or “Extensions”/”Extension points” for those wanting to use the old Eclipse standard).
4. Enforces loose coupling of components (using a publish/find/bind service model).
5. Forces the resolution of application dependency problems (requiring explicit declaration of dependencies between components).
6. OSGi ”fixes” Application server hot-deployment functionality (ability to deploy/undeploy software components without requiring the Server/JVM).
7. There are multiple opensource OSGi implementations available:
   • Equinox / Eclipse
   • Felis / Apache (Oscar)
   • Knopflerfish / Makewave
   • Concierge
8. OSGi implementations are quite stable with many applications/servers using or running on them.
   • Ricoh has been shipping Printers with OSGi since 2005.
   • BMW 5 series cars ship with OSGi.
   • JBoss, IBM WAS and BEA Weblogic servers are adopting OSGi.
   • Sun’s Glassfish uses OSGi
   • SpringSource dm server is built on top of OSGi.
   • Mule ESB
9. The OSGi implementations generally have a small footprint (With OSGi Jars that are less than 500 kb).
10. OSGi has proven itself in the embedded and desktop application world too. The open source Eclipse IDE has been based on OSGi since 2004.

Technorati Tags: Java middleware, next generation technology, OSGi, OSGi middleware

One of the projects that I am currently working on is a Dual-API SDK. This “Framework” has two APIs (or “sides”) - Client API and the SPI (Service Provider Interface) API.

The Client API provides the ability for the Client to deal with various kinds of Artifacts (Requirements, Tasks, CRs, etc.) without paying attention to which “Repository” they came from. Meanwhile, the SPI API provides the ability to ”implement” and “register” the “Providers” (corresponding to various “Repositories” that implement a subset of the SPIs).

Once these SPIs are “registered”, it becomes possible for the “Framework” to provide the “CRUD” operations for the appropriate Artifacts from the “Repositories” that support the given Artifact type(s).

The following requirements decided the backbone-technology to be used for this “Framework” product:

• Ability to dynamically register and un-register SPIs (corresponding to various “Repositories”).
• Ability to support multiple versions of the same SPIs co-existing in the same runtime environment.
• Support modularity of SPI implementations and loose coupling between various modules.
• A low cost (or possibly free) server with a license that allowed us to bundle it with our “Framework” product.
• A Java-based technology.

The most suitable technology for this turned out to be OSGi. This was a suprisingly easy choice. The only other option that came close was Mule 2.0.

Technorati Tags: Java Versioning, OSGi, SDK Development