cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thor Heinrichs-Wolpert <t...@lunartek.com>
Subject Re: [RT] On building on stone
Date Sat, 27 Mar 2004 16:34:35 GMT
I think a big point (and that may be from never having used JMX) that 
is being missed.  When I was saying JMX and its style form part of a 
good kernel candidate, you have to look at how JMX is used.  It uses a 
standard reflection mechanism to talk to components.  Just to say it 
supports an MBean interface is missing quite a bit.  The main things it 
does it load, unload, start, stop and manage the config of components.  
It does this all by reflection, which isn't a big deal, other than the 
method calls are standardized.  There are some basic lifecycle states 
that can determine a components current state.

You can do reflection calls in many many styles.  It is sometimes nice 
to pick up and use one that is already well understood, and because of 
dynamic proxies can have extra behaviours added in.  You can't actually 
use JMX as a back plane for communication between components.  But you 
can follow the same style it uses throughout (consistency is sometimes 
a nice thing when there is no reason to alter it).

I'm not sure that there is an "other-side of the fence" where you don't 
need to make things work in real life if you are actually  a long-term 
living in this industry.  I'm going to assume that my JMX projects, 
others that are successful and the JBoss kernel argue the opposite of 
your "other side of the fence" comment.

These projects all focus on using standard interface, that any 
compatible, swappable component must implement.  They use reflection 
style calls to keep weak references between components so that the 
internal JVMs wont cache a method binding between components.  There is 
a small first time lag when the JVM has to get the lookup loaded for 
the reflection calls, but there are ways of speeding that up (by using 
something like BCEL) and after that the speed difference should be 
negligible.

Cheers,
Thor HW


On 26-Mar-04, at 7:13 AM, Gianugo Rabellino wrote:

> Pier Fumagalli wrote:
>
>> On 25 Mar 2004, at 19:40, Thor Heinrichs-Wolpert wrote:
>>> Hmmm ... I've never used JMX for remote loading as the security just 
>>> isn't there for my tastes and there other mechanisms that work so 
>>> much better.  It does do a fine job of loading/unloading components 
>>> though.
>> Gianugo and I spent an hour on the phone (he paid the international 
>> rate :-) talking exactly about it...
>> He has a lot more practical experience on JMX than I have, and I 
>> believe that we got down to a pretty good rationale on how it can all 
>> work...
>
> Who, me? Actually I have very little real life JMX experience, but 
> indeed I've been for quite some time on the other side of the fence, 
> where you have to really make things work (which is your situation as 
> well, I reckon). Since I come from a network background, I consider 
> myself an SNMP diehard, and I think there is a very good analogy here.
>
> SNMP has three basic functionalities:
>
> 1. gather informations about a device (read an SNMP value);
> 2. configure a device (write an SNMP value);
> 3. handle anomalies and alarms (SNMP traps).
>
> Of such functionalities, #2 is really never used in real life, and 
> this is because of separation of concerns: SNMP is an _invaluable_ 
> tool for people who need to keep things running, but such people 
> aren't the ones configuring such things. Skills of monitoring are 
> horizontal, while configuration skills are much more vertical. This is 
> basically why the Cisco guy and the Apache guy operate on a CLI much 
> better than on an OpenView console.
>
> I think that the same applies to JMX, which really should be nothing 
> more than an object oriented and Java aware SNMP (oh yes, it can do 
> more than that, but it looks like forcing the paradigm to me).
>
> Now, there _might_ be some goodies that are best managed via JMX, but 
> overall I think that generic configuration tools are not the way you 
> want to go since they'll give you a tool to, say, set an integer value 
> but they won't tell you *why* and *how* you should do that, which 
> makes it even more dangerous. A configuration system should be as 
> complex as the needs it's solving: it should be usable and 
> comfortable, but not necessarily "easy" per se.
>
> So, bottom line, I'd say that JMX should be used for health monitoring 
> and alarms. Activation/deactivation of components might be another 
> issue that fits in JMX, but not much than that.
>
> This said, the real issue is where to put JMX. There are three 
> candidates:
>
> 1. The container itself
>
> 2. The block itself, as a whole;
>
> 3. The components inside a block.
>
> I have very little doubt that the container should expose a JMX 
> interface. I would like to see even blocks to expose some kind of JMX 
> behaviour for resource management (something like a generic health 
> status monitor, the number of times this block has been called, and 
> the like). As per components, I used to think that it would have been 
> great to design them as Mbeans, but Pier convinced me that there are a 
> number of cases where this doesn't make sense and might just bring 
> overcomplications.
>
> Pier, did I summarize well what we've been up to?
>
> Ciao,
>
> -- 
> Gianugo Rabellino
> Pro-netics s.r.l. -  http://www.pro-netics.com
> Orixo, the XML business alliance - http://www.orixo.com
>     (Blogging at: http://www.rabellino.it/blog/)
>


Mime
View raw message