Shashi Velur’s blog

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