Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of rwonly@gmail.com designates
 209.85.216.196 as permitted sender)
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=xS9tmMQ5iuzm98nDz0vrqYDCRSN+Tha+F2P5r6dfTupwlgXu7/Xw993j8mTMioey5G
         xL8pTA4FhEDJ2h1Ff0hWzGO74aAb9jZkOFN58BXwmXi3acruYYgOiZVm+1juCz03rG01
         c3vJMDdoszAQ9ahek15Id/6jqUMbACUGeWK4I=
MIME-Version: 1.0
In-Reply-To: <4A940695.8000204@gmail.com>
References: <4A940695.8000204@gmail.com>
Date: Wed, 26 Aug 2009 12:59:26 +0800
Message-ID: <fbab58220908252159r1639939fxec058ab9c1111be1@mail.gmail.com>
Subject: Re: Some thoughts about enabling for OSGi
From: Rex Wang <rwonly@gmail.com>
To: dev@geronimo.apache.org, rickmcg@gmail.com
Content-Type: multipart/alternative; boundary=000e0cd171e2bce4b20472045075

--000e0cd171e2bce4b20472045075
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 <rickmcg@gmail.com>

> 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
>
>

--000e0cd171e2bce4b20472045075
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.<br>
That seems make our future Geronimo like an &quot;enterprise&quot; assembly=
 of OSGi platform, which complys the Java EE specification?<br><br>-Rex<br>=
<br><div class=3D"gmail_quote">2009/8/25 Rick McGuire <span dir=3D"ltr">&lt=
;<a href=3D"mailto:rickmcg@gmail.com">rickmcg@gmail.com</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I&#39;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&#39;d also want to make Geronimo into a real OSGi=
 application platform.<br>

<br>
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&#39;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.<br=
>

<br>
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: <br>

 =A0 * EventAdmin service (generalized Event broadcast service). =A0This is=
<br>
 =A0 =A0 fairly self contained, and we can probably just use the Felix<br>
 =A0 =A0 reference implementation.<br>
 =A0 * Logging service. =A0This is a standardized OSGi logging API. =A0The<=
br>
 =A0 =A0 reference implementation is just a circular queue and does not<br>
 =A0 =A0 actually log entries to any persistent storage. =A0The Geronimo OS=
Gi<br>
 =A0 =A0 logging service should be integrated with the general logging<br>
 =A0 =A0 support. =A0The PAX logging service looks like a good starting poi=
nt<br>
 =A0 =A0 for this. =A0I understand that the Geronimo Blueprint service<br>
 =A0 =A0 implementation is already using this version.<br>
 =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<b=
r>
 =A0 =A0 that are installed on Geronimo, so we&#39;d need to provide an<br>
 =A0 =A0 instance of this.<br>
 =A0 * UserAdmin service. =A0This is an interface to an authentication<br>
 =A0 =A0 system associated with a platform. =A0I believe this would be fair=
ly<br>
 =A0 =A0 simple to map to the Geronimo authentication services.<br>
 =A0 * Declarative services. =A0The ability for bundles to declaratively<br=
>
 =A0 =A0 publish services to the services registry. =A0We&#39;d need to sup=
port<br>
 =A0 =A0 this to allow bundles to be used portably across framework host<br=
>
 =A0 =A0 environments. =A0This should not require any special integration<b=
r>
 =A0 =A0 with the rest of Geronimo.<br>
 =A0 * Blueprint services. =A0A more sophisticated component assembly<br>
 =A0 =A0 model. =A0This also should not require any special Geronimo<br>
 =A0 =A0 integration.  =A0 * Preferences Service. =A0Allows bundles to pers=
istently store<br>
 =A0 =A0 preference information. =A0This is a bundle-driven capability, whi=
ch<br>
 =A0 =A0 is a bit different than the config admin service. =A0I&#39;m not s=
ure<br>
 =A0 =A0 how prevalently this is used, so this one might not be a requireme=
nt.<br>
<br>
Interestingly, this diagram of Karaf architecture has quite a bit in common=
 with what I&#39;ve just described once you replace &quot;Spring DM&quot; w=
ith &quot;Blueprint Service&quot;. =A0There could be an advantage to levera=
ge prior experience with this environment here.<br>

<br>
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&#39;d like to provide for ot=
her services, such as the Blueprint service.<br>

<br>
This is probably a good staring point for the discussions. =A0There are lik=
ely other facilities we&#39;ll need to add here, but I think this is probab=
ly a good starting point for the discussions. =A0<br><font color=3D"#888888=
">
Rick<br>
<br>
</font></blockquote></div><br>

--000e0cd171e2bce4b20472045075--