geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Some thoughts about enabling for OSGi
Date Tue, 25 Aug 2009 15:43:17 GMT
I've been trying to pull together some thoughts about what it might mean 
for Geronimo to enable itself for OSGi applications and what needs to be 
added to the server beyond just adopting an OSGi classloading model.  
That sort of change would be primarily transparent for most existing 
applications, but to make the change worthwhile, we'd also want to make 
Geronimo into a real OSGi application platform.

So, beyond just having the framework environment, what would be the 
require elements?  Ok, to start with, most (all?) real OSGi platforms 
have some concept of a bundle repository.  The bundle repository is 
where installed bundles are stored and there is generally some sort of 
loading/provisioning strategy associated with the repository that 
eliminates the need for an application to manually install and start 
each of its dependent bundles.  I think the characteristics of how the 
Geronimo bundle repository is a discussion topic all of its own, so for 
now, I'll just assume this piece is there.  As part of server bootstrap, 
there will be a configured startup of bundles from the repository that 
are necessary to bring up the server.  This will be similar to the 
module bootstrapping the server already goes through.  There will also 
need to be a mechanism for adding bundles to the repository, probably 
both as a command line tool and via the console.

The Geronimo server will need to provision the framework with an initial 
set of services that will be available for installed bundles to use.  
Some of these services will interact with other portions of the Geronimo 
server, while others are platform-agnostic, but provide important 
bundle-management services.  Looking through the OSGi compendium 
specifications, the following look like a good recommended set: 

    * EventAdmin service (generalized Event broadcast service).  This is
      fairly self contained, and we can probably just use the Felix
      reference implementation.
    * Logging service.  This is a standardized OSGi logging API.  The
      reference implementation is just a circular queue and does not
      actually log entries to any persistent storage.  The Geronimo OSGi
      logging service should be integrated with the general logging
      support.  The PAX logging service looks like a good starting point
      for this.  I understand that the Geronimo Blueprint service
      implementation is already using this version.
    * Config Admin.  This is a persistent store for configuration data. 
      I think this one will be an general expectation for many bundles
      that are installed on Geronimo, so we'd need to provide an
      instance of this.
    * UserAdmin service.  This is an interface to an authentication
      system associated with a platform.  I believe this would be fairly
      simple to map to the Geronimo authentication services.
    * Declarative services.  The ability for bundles to declaratively
      publish services to the services registry.  We'd need to support
      this to allow bundles to be used portably across framework host
      environments.  This should not require any special integration
      with the rest of Geronimo.
    * Blueprint services.  A more sophisticated component assembly
      model.  This also should not require any special Geronimo
    * Preferences Service.  Allows bundles to persistently store
      preference information.  This is a bundle-driven capability, which
      is a bit different than the config admin service.  I'm not sure
      how prevalently this is used, so this one might not be a requirement.

Interestingly, this diagram of Karaf architecture has quite a bit in 
common with what I've just described once you replace "Spring DM" with 
"Blueprint Service".  There could be an advantage to leverage prior 
experience with this environment here.

One key aspect to all of this is deployment and administration.  The 
Geronimo server will need to provide the conduit for deploying new 
bundles to this environment, as well as administrative function.  The 
OSGi Enterprise Expert Group (EEG) is working on a specification for 
using JMX for managing OSGi environments.  The reference implementation 
for this specification includes a framework neutral set of MBeans for 
tracking installed bundles, registered services, config admin, etc.  
These look like a good model to follow and can be the basis for 
providing console-like administration capabilities.  There may be 
additional MBeans we'd like to provide for other services, such as the 
Blueprint service.

This is probably a good staring point for the discussions.  There are 
likely other facilities we'll need to add here, but I think this is 
probably a good starting point for the discussions.  


View raw message