geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 09:00:38 GMT

On Tuesday, Aug 12, 2003, at 07:07 Europe/London, 

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

Definitely concur with this one.

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

The only problem with this approach is that there isn't a suitable 
abstraction layer in the Geronimo kernel to allow for easy refactoring 
at a later stage. It would be much better, for example, to create an 
interface called 'Service' (for example) that implements MBean 
initially, but ensure that any code written for Geronimo doesn't depend 
on MBean. That way, refactoring at a later stage will be much easier.

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

I've not found the section in the spec that says this. What I've found 

J2EE.2.6.15 Management: The JMX API is also used to provide /some/ 
management support -- not that it must be implemented using MBeans.
J2EE 6.17 JMX requirements: The only JMX support is specified in hte 
J2EE Management specification. In particular, applications will not 
typically have the security permissions required to access or create 
MBean servers

And the JavaManagement pages say that it's used for management.

So I challenge the statement that MBeans are essential to J2EE -- I 
don't believe that they are according to the spec.

What the spec does say is that the JMX API is available, and that 
optionally, components may be managed through the JMX API. It doesn't 
say anything about them being implemented or managed as MBeans in a 

There also isn't any requirement for a J2EE server to be able to run 
MBeans out of the box. JMX was designed as a management interface to 
allow remote systems to be managed, in much the same way that SNMP was 
designed for.

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

I think the more services that are created sooner, the better. However, 
I would strongly suggest that we create an abstraction API that we can 
use in Geronimo to make the services available, that decouples the 
implementation of the services from JMX sooner rather than later. 
Otherwise, if we write and build heavily on the assumption that 
everything-is-an-MBean then it will be a lot more difficult to 
change/remove that assumption later on. A few abstract APIs would solve 
this problem immediately.

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

Absolutely. In fact, it would be great if there was an 'experimental' 
spike doing this now, either by having a set of packages in the 
Geronimo core, or a different module, or a different CVS tag to allow 
this to occur in parallel now. However, since most of us don't have 
commit privileges, (and thus can't control the experimental/head 
checkins) it might be more advisable to have an experimental 
package/module, which would then fit in with head

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

This still doesn't address the heavy coupling of the entire framework 
to MBeans/JMX, which is essentially the point I'm making. It would be 
more sensible, for example, to build an Avalon framework kernel that 
could allow legacy MBeans to be instantiated.

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

And one of the goals about refactoring is to set up easier migration 
paths. Importantly, refactoring can be done at any time, and 
abstracting/decoupling the implementation from JMX (wherever possible, 
not necessarily as a major rewrite) will aid in that. So I'd suggest 
creating abstract interfaces (Service, Container etc.) that developers 
can write to, and not MBeans. (However, the Service can initially 
implement an MBean to facilitate migration.)

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

Again, the J2EE spec in no way requires MBeans to be used as the 
container implementation. Indeed, the spec is specifically 
implementation agnostic on this and almost all other points regarding 
implementation of containers. I'd find it quite unlikely that an 
implementation of something built for one server (e.g. 
WebLogic/WebSphere) would stand a chance of running in another (e.g. 
JBoss, Geronimo).

Building everything now implementing MBean is a sure way to be tied to 
JMX. Building an abstract API for Geronimo is a sure way to allow 
things to be changed later.

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

Why do we need to support plugging in of MBeans? The JMX introduces it 
self as:

"The Java Management Extensions (JMX) technology represents a 
universal, open technology for management, and monitoring that can be 
deployed wherever management and monitoring are needed. By design, this 
standard is suitable for adapting legacy systems, implementing new 
management and monitoring solutions and plugging into those of the 

It's about management. It's about being able to talk to a service and 
manage/configure it remotely. It never said that everything needs to be 
built with JMX -- the 'deployed wherever management and monitoring are 
needed' is the /management/ that's deployed, not the implementation of 
the service.

I challenge the notion that MBeans are even a necessary part of this 
implementation. It should be an externalised API, using the 
Facade/Bridge patterns, not everything-must-be-an-mbean.

> Thoughts?

I agree with your main point of this message; that there is an initial 
code base, and that 'purist' views may not be helpful for moving the 
project forward quickly.

I also agree that the sooner there is a framework to allow new code to 
be written, the better.

I disagree that everything-must-be-an-MBean, and I also disagree that 
the J2EE spec has anything to say on implementational aspects using 

I disagree that a J2EE server must be an MBean container.

I believe that an approach where everything-is-an-MBean introduces 
unnecessary high coupling between the application server and the 
components within. I also assert that if many services are developed 
that directly are MBeans, then it will be much more difficult (to the 
extent that it becomes impossible) to refactor out these dependencies 
later on.

In short, I believe that to keep our options open for longer, and to 
support migration away from a JMX kernel later on, we should introduce 
abstract types/interfaces/classes to represent the generic components 
within Geronimo. Then services should be written entirely in terms of 
this abstract API and not depend on JMX at all.

This will allow initial code to be developed and the project moved 
forward, and alternative approaches for managing the Service or 
Container APIs can be developed in parallel, rather than a big 
refactoring initially that holds up the development of new services.


View raw message