Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "James deGraft-Johnson" <jdegraft@digaman.com>
To: <geronimo-dev@incubator.apache.org>
Subject: RE: [services] getting service developers started - the initial
 component model
Date: Tue, 12 Aug 2003 03:47:10 -0400
Message-ID: <003c01c360a5$f047bf10$2502a8c0@CINDERELLA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <335647DA-CC8B-11D7-A504-000A959D0312@mac.com>

HI,

I am joining this effort with the hope of being a code contributor.

I think this (MBean component model) is a good idea. It would be helpful =
if
a sketch or example MBean can be created, so those of us who are new to =
open
source development and MBean development can understand exactly what =
this
component model entails. (This example does not have to be throw-away as =
it
could be a live component.)

There are two other suggestions I would like to make. One is that a =
decision
on the base (kernel/framework) code be made and moved to CVS assuming it
hasn't already. Also, whatever this MBean component model involves, it
essential that we move ahead to porting the existing containers/services =
to
this model to identify any risks in the approach we are taking.

James deGraft-Johnson
3419 Hampton Hollow Drive, Apt G,
Silver Spring MD 20904.
Tel:        (301) 847-1694
Fax:        (301) 847-8025
Mobile:  (240) 475-1444 (jdegraft@verizon-uc.com)


-----Original Message-----
From: jastrachan@mac.com [mailto:jastrachan@mac.com]=20
Sent: Tuesday, August 12, 2003 2:07 AM
To: geronimo-dev@incubator.apache.org
Subject: [services] getting service developers started - the initial
component model

I'm sure we could all debate the perfect container framework and=20
compare and contrast the intricacies of the various flavours of Avalon=20
containers, PicoContainer, JMX & Java Beans until the cows come home.=20
However what is really important right now is we start writing=20
lightweight, pluggable services ASAP to start filling in the J2EE stack=20
for Geronimo.

Up to now the Geronimo codebase has assumed a JMX micro kernel,=20
following in the footsteps of JBoss, Tomcat 5 and Jetty. I'm sure this=20
can be improved with time though this strategy has been proved to work.=20
Before we get bogged down in months of upfront design for what the=20
perfect container should be - I'd like us to be able to make good=20
progress integrating the various services - of which there are many.=20
Then we have some real use cases that can help us as we refactor the=20
Geronimo container.

What I'd like to do as an initial step is choose a default component=20
model for service developers to follow as they write Geronimo services.=20
For some time most of the main services in Geronimo are going to be=20
fairly course grained (web container, Axis, JMS provider, JTA etc). In=20
addition at the time of writing Geronimo can deploy MBeans.

So initially I think the component model should be JMX MBeans. These=20
are simple, lightweight components that have no compile time=20
dependencies on anything. The MBeans themselves should follow the=20
Inversion of Control pattern - i.e. the container instantiates &=20
configures the MBean. In addition we should try follow the MBean=20
interface pattern such that we can do efficient interception easily=20
with dynamic proxies - also note that MBeans do not need to use JMX at=20
all - any container mechanism can be used to configure & wire together=20
the components.

Already today Geronimo can handle MBeans. It must always be able to=20
handle MBeans. Indeed whatever Geronimo's container framework becomes=20
it should be easily cable of working with the plethora of J2EE MBeans=20
that are out there. (MBeans are essential to J2EE).


So in summary

* lets start writing J2EE services as MBeans that we can plug into=20
Geronimo today.

* in parallel to this activity folks can help improve & innovate inside=20
the Geronimo kernel - without adversely affecting the progress of the=20
component authors - we can all work in parallel

* those Avalon fans could package up one or more Avalon containers as=20
MBeans then any Avalon components could be easily deployed inside an=20
actual Avalon container inside Geronimo. Ditto for PicoContainer too.=20
i.e. this strategy allows for a diversity of containers to be deployed.

* once all the required deployment options are available (EAR, WAR,=20
SAR) and the ClassLoader stuff is working along with the interceptor=20
stack; folks can then refactor the container using some real J2EE=20
services to improve the manageability & codebase - based on real=20
refactoring of working code rather than too much up front design.=20
Indeed we can take a TDD approach to refactoring the container. So=20
rather than guessing what a J2EE container should look now, we can=20
refactor as we get there to improve it.

* we should make great progress, getting J2EE coverage fairly soon -=20
yet we won't really be tied to JMX at all - the MBeans could be used in=20
any container implementation.

* if in the future we come up with some other component model to be=20
supported, it should be trivially easy to plugin MBeans anyway, or a=20
simple refactor to support them

Thoughts?

James
-------
http://radio.weblogs.com/0112098/