Avalon and JMX redux

[Pratik Patel <pr...@metalab.unc.edu>]

Hello,
I have been lurking on the list for a while now and have been following 
the conversation about JMX and Avalon.
I've been learning Avalon slowly, and I would like to use Avalon for 
what I'm working on, but would like to do some things with JMX; anyhow, 
enough about me.

Here are some thoughts. Please feel free to set the record straight if 
something is incorrect and of course all comments, suggestions, flame 
welcome.


First, I would like to say that integrating JMX at the "Component" level 
into Avalon is the wrong thing to do:
* Avalon is far ahead of managing components in the true sense of the 
component compared to JMX
* JMX is flat in terms of relationships between MBeans, whereas Avalon 
components can be hierarchical
* JMX seems more geared to managing Blocks rather than smaller components

Integrating JMX at the "Block" level is the better thing to do. Given 
this assumption, here are the options I think we should think about 
w.r.t JMX integration into Avalon:

1) Extend MBeanServer to use Avalon Phoenix
    - config files to initialize, stop, start blocks
    - MBeanServer and Phoenix are one-in-the-same
    - MBeanServer is the main[]
    - Phoenix is started by MBeanServer
    - Native Avalon Blocks are loaded via a wrapper MBean that is aware 
of all of the control interfaces for Blocks
    - Phoenix is 'JMX aware' so it can call the MBeanServer and fire up 
MBeans or Blocks (which are wrapped around an MBean)
    - The MBeanServer can load MBeans as normal BUT  (MBeans) must 
implement some of Avalon's interfaces for blocks via a 3rd party 
WrapperMBean
            - 3rd party MBeans will be wrapped using the 
AvalonMBeanWrapper (ex: JettyMBeanWrapper implements AvalonMBeanWrapper)
            - This JettyMBeanWrapper will know how to define roles, 
dependencies, configuration etc for Jetty in relation to how Jetty fits 
into Avalon

2) Bootstrap Phoenix into an MBean
    - MBeanServer and Phoenix are completely independent (almost(?))
    - MBeanServer is the main[]
    - entire kernel is only start/stop able from the master MBeanServer
    - All Avalon blocks are loaded by Phoenix as normal
    - The MBeanServer can load MBeans as normal, with no control by Phoenix

3) MBeanServer is made into a block
    - create a new class called AvalonMBeanServerBlock
    - This block performs the normal duties of an MBeanServer but it 
itself managed by Phoenix
    - Configuration of loaded MBeans can be passed down from the normal 
Avalon configuration/assembly files
    - Example: This block can load Jetty without any additional work 
required (using Jetty's MBean interface and native configuration)
    -  Example: This block can load *and* configure Jetty if Avalon's 
configuration of blocks is tranlated into Jetty configuration (XML 2 XML 
transformation, or discrete setting of Jetty MBean attributes at 
init/runtime)


I have some diagrams but haven't had time to move them from my notebook 
to e-copy.
I'd be happy to write some code, as long as some people promise to help ;)


cheers
Pratik


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: Avalon and JMX redux

[Peter Donald <do...@apache.org>]

On Sat, 29 Sep 2001 00:38, Pratik Patel wrote:
> Hello,

hiya,

> I have been lurking on the list for a while now and have been following
> the conversation about JMX and Avalon.
> I've been learning Avalon slowly, and I would like to use Avalon for
> what I'm working on, but would like to do some things with JMX; anyhow,
> enough about me.

welcome!

> Here are some thoughts. Please feel free to set the record straight if
> something is incorrect and of course all comments, suggestions, flame
> welcome.

;)

> First, I would like to say that integrating JMX at the "Component" level
> into Avalon is the wrong thing to do:
> * Avalon is far ahead of managing components in the true sense of the
> component compared to JMX

for lifecycle management - yep.

> * JMX is flat in terms of relationships between MBeans, whereas Avalon
> components can be hierarchical

yep.

> * JMX seems more geared to managing Blocks rather than smaller components

Agreed - almost. The one problem being things like logging. In this case it 
would be useful for JMX to manage logging (so individual LogTargets and 
categories).

> Integrating JMX at the "Block" level is the better thing to do. 

Yep. I would also like to wrap some kernel components as MBeans ... actually 
thats what I started doing yesterday ;)

However there is one thing to note. At this stage I am a little nervous of 
integrating JMX tightly into the core of Phoenix due to licensing issues. The 
RI requires the standard things but it also has an advertising clause. 
However to advertise that you are JMX enabled requires that you seek for your 
apps to be verified by Sun ... which costs money ;) 

There is a clean room implementation (or there was) in enhydra but I was told 
that because of the licensing of the spec you still required validation from 
Sun if you use any trademarks (ie say it is JMX enabled) and it may cost you 
to implement agents. 

I am not sure on these legal matters so until I look further I guess I would 
prefer to be paranoid ;)

> 1) Extend MBeanServer to use Avalon Phoenix
>     - config files to initialize, stop, start blocks
>     - MBeanServer and Phoenix are one-in-the-same
>     - MBeanServer is the main[]
>     - Phoenix is started by MBeanServer
>     - Native Avalon Blocks are loaded via a wrapper MBean that is aware
> of all of the control interfaces for Blocks
>     - Phoenix is 'JMX aware' so it can call the MBeanServer and fire up
> MBeans or Blocks (which are wrapped around an MBean)
>     - The MBeanServer can load MBeans as normal BUT  (MBeans) must
> implement some of Avalon's interfaces for blocks via a 3rd party
> WrapperMBean
>             - 3rd party MBeans will be wrapped using the
> AvalonMBeanWrapper (ex: JettyMBeanWrapper implements AvalonMBeanWrapper)
>             - This JettyMBeanWrapper will know how to define roles,
> dependencies, configuration etc for Jetty in relation to how Jetty fits
> into Avalon

This is one strategy that it would be interesting to try, however I don't 
think it is appropriate just yet (and besides it is a lot of work). The main 
reason I don't like it is that it removes all the advantages of using a 
kernel. It in effect adds a few layers on with little apreciable advantage 
and in this case I would prefer to just directly write MBeans rather than 
Blocks.

> 2) Bootstrap Phoenix into an MBean
>     - MBeanServer and Phoenix are completely independent (almost(?))
>     - MBeanServer is the main[]
>     - entire kernel is only start/stop able from the master MBeanServer
>     - All Avalon blocks are loaded by Phoenix as normal
>     - The MBeanServer can load MBeans as normal, with no control by Phoenix

I actually did this as an experiment by loading parts of Phoenixs kernel via 
MLet and it works great. It essentially replaces Phoenixs Embeddor with a JMX 
Embeddor implementation. This sort of thing has a bit more overhead but it is 
much more flexible because you could add arbitrary MBeans in (like aggregate 
JBoss/Jetty and anything else as needed).

> 3) MBeanServer is made into a block
>     - create a new class called AvalonMBeanServerBlock
>     - This block performs the normal duties of an MBeanServer but it
> itself managed by Phoenix
>     - Configuration of loaded MBeans can be passed down from the normal
> Avalon configuration/assembly files
>     - Example: This block can load Jetty without any additional work
> required (using Jetty's MBean interface and native configuration)
>     -  Example: This block can load *and* configure Jetty if Avalon's
> configuration of blocks is tranlated into Jetty configuration (XML 2 XML
> transformation, or discrete setting of Jetty MBean attributes at
> init/runtime)

This is the way that I think is best todo. The issue is how do we safely pass 
the MBeanServer down to the appropriate applications. The few ways I have 
been thinking about doing it is

1. If we have a Block com.biz.Foo then we search for a com.biz.FooMBean and 
if present it is expected to be a MBean and to have a constructor that takes 
one argument (namely Foo). So max 1 MBean per Block.
2. Similar to (1) but it acts at Service level. ie If we have a Block that 
implements service com.biz.Foo then we search for a com.biz.FooMBean and if 
present it is expected to be a MBean and to have a constructor that takes one 
argument (namely Foo). So many MBeans per Block (as many MBeans as Services).
3. Enhance BlockContext to expose MBeanServer and let Blocks have their way 
with it
4. Enhance BlockContext so that they can register arbitrary interfaces for 
management
5. Enhance BlockContext so that they can register arbitrary MBeans for 
management
6. Make kernel automagically detect Manageable interfaces and export them. 
This detection can be by extending some interface or by specifying Manageable 
interfaces in BlockInfo.
7. Enhance BlockContext and/or assembly descriptor so that Blocks can be 
marked as "privlidged" which means they get access to the kernel interfaces 
... including MBeanServer

1, 2, 4, 6 and 7 have the advantage that we don't require the presence of JMX 
but if present it will be used.

7 has the advantage that we can add extra "special" Kernel services if the 
infrastructure is general enough.

Currently I tend to like (1) + (7) or (6) + (7). However I am not really sure 
at this stage. I don't know enough about it - what do you think?

> I have some diagrams but haven't had time to move them from my notebook
> to e-copy.
> I'd be happy to write some code, as long as some people promise to help ;)

kool. I will help but I am a bit of a JMX weenie so I am not sure how much 
help I will be ;)

I actually went and had a look at Jettys JMX stuff and found out they had a 
class similar to what I have just spent a few hours implementing - dammit ! 
;) Though they do have a few interesting ideas that I think I can correct in 
my implementation ;)

-- 
Cheers,

Pete

-----------------------------------------------------
First, we shape our tools, thereafter, they shape us.
-----------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org