geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@mortbay.com>
Subject Re: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 12:32:37 GMT
I would have thought that we'd want to support JSR077 management for 
J2EE from the outset. JSR077 describes lifecycles, events and 
performance statistics for all J2EE components (everthing from ejbs, 
datasources, jca through to web containers and servlets) that can be 
modelled by mbeans.

It would be by far the simplest if geronimo's services were directly 
based JSR077 mbeans, because:

1. we need to support JSR077 anyway
2. the simplest way to support it is directly, without extra layers of
    adaption code
3. there's nothing in the service lifecycle that cannot be encompassed
    by JSR077 mbeans

Jan

Alex Blewitt wrote:
>> 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.



Mime
View raw message