Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Tue, 12 Aug 2003 07:07:06 +0100
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: [services] getting service developers started - the initial component
 model
From: jastrachan@mac.com
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
Message-Id: <335647DA-CC8B-11D7-A504-000A959D0312@mac.com>

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

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

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

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

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


So in summary

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

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

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

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

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

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

Thoughts?

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