The OSGi ecosystem: a 'service' is not a 'service'

Update 2010-05-21: Peter Kriens has made a similar point about μservices some time ago. In a recent post, Kirk Knoernschild coined the notion of OSGi as an enabler for an ecosystem for software modules. While I do subscribe to this view in the long run, there is still some road to cover.

Current state

In the current marketplace, OSGi is still mainly an inside-business (some notable exceptions aside), providing a foundation to build applications, and if we're lucky, allowing some reuse of homebrew components.

Within the context of OSGi itself, reuse is actually rampant. For instance, hardly a project goes by in which I don't use an Event admin or Configuration admin, or one of the dependency management tools like the Apache Felix Dependency Manager.

Still, these either have a very broad range of usability, or are 'internal affairs'. What we in this ecosystem are reusable business services, and I don't mean general purpose libraries repackaged as a bundle. (Yes, of course we need those, but we should be able to go beyond that.)

Decoupling modules and services

OSGi has made the genius decision to decouple the notion of modules from the use of services as an architectural building block. I see this enabling three steps in the near future,

  1. Services as first-class citizens In my time working with OSGi, I notice I'm moving away from the regular notion of a service as 'something that can do stuff for me' to 'an architectural building block'. I believe the notion of services (loosely summed up as 'using interfaces to communicate, on steriods') goes far beyond this: it allows us to rely on the framework for wiring up the application, and reduces complexity of the design; all of this is subject of another post (I promise).
  2. Real service-orientation eases modularization Once we move away from 'services in the large' to services as a regular building block, we can start to use those in a more stringent way to insulate concerns: even when the landscape is dynamic, we can carve up our application along the boundaries of services, giving us modularization for free.
  3. Service-centric modularization Now we have centered our modularization around services, we can take the next step: in stead of thinking about modules, we can now start thinking again about large services, by which I mean a block of functionality defined by a set of OSGi-level services. At this point, the actual deployment model and modularization mechanism is of no importance anymore.

So, what will we be selling in this ecosystem? I believe it not to be modules, but rather 'services in the large' built up of 'services in the small', which happen to be deployed using modules.