Guillaume Nodet wrote:
On Tue, Aug 25, 2009 at 17:43, Rick McGuire <rick...@gmail.com
<mailto: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.
The Blueprint impl uses an OSGi logging service if available but has not
dependency on the implementation.
* 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.
How about just extending the existing Admin Console support in Felix?
We'll still need a web ui, but it should always be optional, like it is
in Felix and Karaf today.
* 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.
Karaf has switched to Blueprint services some time ago (I guess I need
to update the web site I suppose). So there's no Spring-DM dependency
anymore, though it can be easily deployed using "karaf features".
Are there are maven plugins for using Karaf in a junit environment or to
help build custom Karaf assemblies?
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.
Karaf embeds the RI for JMX management of OSGi.
I really think it would make sense to see if we can Karaf and Geronimo
can collaborate together. I always have in mind Karaf becoming a TLP at
some point. Improvements to Karaf would be very welcomed, I'm sure.
Karaf goal was really to be a minimal, but yet usable, OSGi runtime for
server side applications, such as ServiceMix, ActiveMQ. So I don't
really see why it would not be a good fit for Geronimo. And if it isn't
yet, it might make sense to see how it can become so ...
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
