Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40644882.4030003@apache.org>
Date: Fri, 26 Mar 2004 16:13:06 +0100
From: Gianugo Rabellino <gianugo@apache.org>
User-Agent: Mozilla Thunderbird 0.5 (Macintosh/20040208)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] On building on stone
References: <07258F4244D6F649B1A78993D070B7CA6F7830@ACSPMXE02>
 <41AF6667-7E80-11D8-9EBC-000393C27E0C@betaversion.org>
 <46A5A93C-7E94-11D8-824F-00039388DCEE@lunartek.com>
 <7CB1C412-7EB3-11D8-92A8-000A95984AEA@betaversion.org>
In-Reply-To: <7CB1C412-7EB3-11D8-92A8-000A95984AEA@betaversion.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/)