2009/8/26 Guillaume Nodet <gno...@gmail.com> > > > On Tue, Aug 25, 2009 at 17:43, Rick McGuire <rick...@gmail.com> wrote: > >> 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. > > > In addition, and related to Config Admin, support for meta type information > could be useful. This allows describing what the configuration should look > like, and this allows automatic generation of UI for configuration for > example. This is what the Felix web console does. > > >> >> * 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. > > > I think there is a need for integrating the UserAdmin with JAAS at some > point. I'm not aware of such a thing yet, but that's something I had in > mind. > > >> >> * 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. > > > Not sure if there is a need to support both by defaults. If we rely on > Blueprint for example, DS could only be installed if users need that, as an > optional add-on maybe. > Agree, I guess there won't be so much app based on it after blueprint shipped. If we use blueprint, the 3-party plugin developer should also rely on it. Otherwise, he need install the DS add-on.
> > >> >> * 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 >> >> > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > >
