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 12:34:45 +0100
Subject: Re: [services] getting service developers started - the initial
  component model
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Alex Blewitt <Alex.Blewitt@ioshq.com>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <000a01c360c3$f13f69e0$47c2f1a7@vis.verizon.com>
Message-Id: <F91BFBA2-CCB8-11D7-A6C3-0003934D3EA4@ioshq.com>

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

Alex.