geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: Some thoughts about enabling for OSGi
Date Wed, 26 Aug 2009 04:59:26 GMT
I am a little confuse on the direction of Geronimo, you know OSGi Alliance
is still working on some enterprise spec integration, such as JNDI(rfc142),
JPA(rfc143), Transactions(rfc98), web container(rfc66).. I believe there
will be more from Java EE features.
That seems make our future Geronimo like an "enterprise" assembly of OSGi
platform, which complys the Java EE specification?

-Rex

2009/8/25 Rick McGuire <rickmcg@gmail.com>

> 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
>     integration.   * 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.
> Rick
>
>

Mime
View raw message