Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 65666 invoked from network); 26 Aug 2009 07:33:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Aug 2009 07:33:24 -0000 Received: (qmail 29415 invoked by uid 500); 26 Aug 2009 07:33:24 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 29300 invoked by uid 500); 26 Aug 2009 07:33:24 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 29291 invoked by uid 99); 26 Aug 2009 07:33:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Aug 2009 07:33:23 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of greensight@gmail.com designates 209.85.222.190 as permitted sender) Received: from [209.85.222.190] (HELO mail-pz0-f190.google.com) (209.85.222.190) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Aug 2009 07:33:15 +0000 Received: by pzk28 with SMTP id 28so2576703pzk.27 for ; Wed, 26 Aug 2009 00:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=hUekz+3xO8cp/Q+RVwziA+8PnY5bvPYctsIXnTgiHlM=; b=BxKsjoofsIUzwGsk7RIX2ycmT94ULWdZy/112oGp2k+WcW6utIwdxckGjB3VuGHZGd Mrf4cC9NdbH4+gscGTzhPwc4hcgXpVyf+l+78NcvWgPAJACRDxcMdribfRWrJA2Mk+hK bm4CVoLzwOERZWCrMT+Cm5EadkTmOuM+KpL64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=J5t0EXh2cUZHBdmzeOEipY/3f730g2l41gEUctypxfiGB3FMPh4Mtx/QxHM+gmCIrR YRyl/kNNsgZJZOamrO+4DgvyX1mWU+a05SioiazrSkkJfiBfOzPZ5GWDgC2opHKAhM6c kPIT3JAmsEzxBIO5Fp9WvhbRhBd+HvycWRyys= MIME-Version: 1.0 Received: by 10.115.66.24 with SMTP id t24mr9181948wak.39.1251271975466; Wed, 26 Aug 2009 00:32:55 -0700 (PDT) In-Reply-To: References: <4A940695.8000204@gmail.com> Date: Wed, 26 Aug 2009 15:32:55 +0800 Message-ID: <5e7fd1eb0908260032w799beb60rec6b2ba242452655@mail.gmail.com> Subject: Re: Some thoughts about enabling for OSGi From: Jack Cai To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=0016e648f3769d785304720675f3 X-Virus-Checked: Checked by ClamAV on apache.org --0016e648f3769d785304720675f3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. -Jack On Wed, Aug 26, 2009 at 12:59 PM, Rex Wang 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 > > 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 >> >> > --0016e648f3769d785304720675f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the direction that Rick is picturing is to support the OSGi program= ming model in addition to the Java EE programming model. This makes sense a= s OSGi is gaining increasing momentun in the enterprise computing space.
-Jack

On Wed, Aug 26, 2009 at 12:59 P= M, Rex Wang <rwonl= y@gmail.com> 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 w= ill 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 try= ing 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 serv= er beyond just adopting an OSGi classloading model. =A0That 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? =A0Ok, to start with, most (all?) real OSGi platforms have some = concept of a bundle repository. =A0The bundle repository is where installed= bundles are stored and there is generally some sort of loading/provisionin= g strategy associated with the repository that eliminates the need for an a= pplication to manually install and start each of its dependent bundles. =A0= I think the characteristics of how the Geronimo bundle repository is a disc= ussion topic all of its own, so for now, I'll just assume this piece is= there. =A0As part of server bootstrap, there will be a configured startup = of bundles from the repository that are necessary to bring up the server. = =A0This will be similar to the module bootstrapping the server already goes= through. =A0There will also need to be a mechanism for adding bundles to t= he repository, probably both as a command line tool and via the console.
The Geronimo server will need to provision the framework with an initial se= t of services that will be available for installed bundles to use. =A0Some = of these services will interact with other portions of the Geronimo server,= while others are platform-agnostic, but provide important bundle-managemen= t services. =A0Looking through the OSGi compendium specifications, the foll= owing look like a good recommended set:
=A0 * EventAdmin service (generalized Event broadcast service). =A0This is=
=A0 =A0 fairly self contained, and we can probably just use the Felix
=A0 =A0 reference implementation.
=A0 * Logging service. =A0This is a standardized OSGi logging API. =A0The<= br> =A0 =A0 reference implementation is just a circular queue and does not
=A0 =A0 actually log entries to any persistent storage. =A0The Geronimo OS= Gi
=A0 =A0 logging service should be integrated with the general logging
=A0 =A0 support. =A0The PAX logging service looks like a good starting poi= nt
=A0 =A0 for this. =A0I understand that the Geronimo Blueprint service
=A0 =A0 implementation is already using this version.
=A0 * Config Admin. =A0This is a persistent store for configuration data. = =A0 =A0 I think this one will be an general expectation for many bundles =A0 =A0 that are installed on Geronimo, so we'd need to provide an
=A0 =A0 instance of this.
=A0 * UserAdmin service. =A0This is an interface to an authentication
=A0 =A0 system associated with a platform. =A0I believe this would be fair= ly
=A0 =A0 simple to map to the Geronimo authentication services.
=A0 * Declarative services. =A0The ability for bundles to declaratively =A0 =A0 publish services to the services registry. =A0We'd need to sup= port
=A0 =A0 this to allow bundles to be used portably across framework host =A0 =A0 environments. =A0This should not require any special integration =A0 =A0 with the rest of Geronimo.
=A0 * Blueprint services. =A0A more sophisticated component assembly
=A0 =A0 model. =A0This also should not require any special Geronimo
=A0 =A0 integration. =A0 * Preferences Service. =A0Allows bundles to pers= istently store
=A0 =A0 preference information. =A0This is a bundle-driven capability, whi= ch
=A0 =A0 is a bit different than the config admin service. =A0I'm not s= ure
=A0 =A0 how prevalently this is used, so this one might not be a requireme= nt.

Interestingly, this diagram of Karaf architecture has quite a bit in common= with what I've just described once you replace "Spring DM" w= ith "Blueprint Service". =A0There could be an advantage to levera= ge prior experience with this environment here.

One key aspect to all of this is deployment and administration. =A0The Gero= nimo server will need to provide the conduit for deploying new bundles to t= his environment, as well as administrative function. =A0The OSGi Enterprise= Expert Group (EEG) is working on a specification for using JMX for managin= g OSGi environments. =A0The reference implementation for this specification= includes a framework neutral set of MBeans for tracking installed bundles,= registered services, config admin, etc. =A0These look like a good model to= follow and can be the basis for providing console-like administration capa= bilities. =A0There may be additional MBeans we'd like to provide for ot= her services, such as the Blueprint service.

This is probably a good staring point for the discussions. =A0There are lik= ely other facilities we'll need to add here, but I think this is probab= ly a good starting point for the discussions. =A0
Rick



--0016e648f3769d785304720675f3--