geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James deGraft-Johnson" <>
Subject RE: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 11:51:06 GMT
I agree with this.

By structuring the kernel architecture like JMX/MBeans we will simplify the
design task, have less changes (refactoring) to make to existing kernel,
which is based on JMX/MBeans. However it is important not to tie the design
tightly to JMX/MBeans, (or implement the kernel strictly as JMX/MBeans) as
pointed out). Note that JMX/MBeans is meant to be a feature (management
extension) of the J2EE container not an architecture for design of the J2EE
kernel. By not tightly coupling kernel architecture to JMX/MBeans we can
incorporate design ideas from outside JMX/MBeans and also allow the
component to be changed later.

James deGraft-Johnson
Software Engineer - IT
Verizon Information Services
Tel:         (240) 456-7018
Fax:        (240) 456-7072
Mobile:   (240) 475-1444 <>

-----Original Message-----
From: Alex Blewitt []
Sent: Tuesday, August 12, 2003 7:35 AM
Subject: Re: [services] getting service developers started - the initial
component model

> My understanding of the JMX/MBeans idea from SUN is so that it is
> possible
> to create MBeans (Management Beans) as part of a J2EE application to
> support
> administration, management and monitoring of the J2EE application.
> This is a
> very powerful idea, which ideally will be supported by Geronimo.

Absolutely. I have always been for there being a JMX /interface/ to
Geronimo, but not as an /implementation/ of the kernel.

> The use of a JMX/MBeans model for Kernel framework shouldn't
> jeopardize the
> above. In fact I assumed that the discussion of the MBeans as a service
> component model was actually MBeans-like, i.e. basing the component
> model on
> the MBeans design. (We can structure the Geronimo kernel like JMX
> without
> actually making the kernel a JMX implementation, so as to incorporate
> into
> the kernel the ability for J2EE application developers to create and
> install
> actual MBeans.) Because of the above, this is what makes sense for this
> approach.

I think there should be a distinction between the kernel and a
JMX/MBean container -- they're not necessarily the same. Granted, that
it may be desirable for MBeans to be incorporated in at a later stage,
but by starting off with the doctrine 'everything is an MBean' then
it's very difficult to be innovative and come up with ideas outside of
the JMX spec.

For example:

public abstract Service {
   public abstract String getName();
   public abstract void start();
   public abstract void stop();
   public MBean getMBeanInterface() {
     return new ServiceMBeanInterfaceAdapter(this);

public ServiceMBean implements GenericMBean {
   private Service instance;
   public ServiceMBean(Service instance) {
     this.instance = instance;
   public void start() { instance.start(); }
   public void stop() { instance.stop(); }

That way, you can create subcomponents of Service that are entirely
independent of JMX, whilst still providing a JMX interface to the same.
Indeed, subclasses can provide their own specific JMXBean
implementations if the default is not desirable.

Additionally, if there is a move from using MBeans to another component
architecture, then this will allow the same representation to be used.


View raw message