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 <[email protected]> > 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 > >
