Jack Cai wrote:
I think the direction that Rick is picturing is to support the OSGi
programming model in addition to the Java EE programming model. This
makes sense as OSGi is gaining increasing momentun in the enterprise
computing space.
My intention here was to define the things required for Geronimo to
create a platform on which the OSGi programming model can be supported
at all. Once we have the base support, it is a fairly simple step to
add in additional services. In many cases, the services are really just
wrappers around components that Geronimo already uses. Some of these,
such as the RFC 66 Web Container are likely to require some tighter
integration with the server environment. However, until the base OSGi
story is defined and available, there is very little that can be done
with those. Add in the fact the specifications are not final yet, and
it make sense to focus the attention now on getting the base support
correct.
Rick
-Jack
On Wed, Aug 26, 2009 at 12:59 PM, Rex Wang <[email protected]
<mailto:[email protected]>> wrote:
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] <mailto:[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
