Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Sun, 28 Mar 2004 10:43:15 -0800
From: Thor Heinrichs-Wolpert <thor@lunartek.com>
Subject: Re: [RT] On building on stone
In-reply-to: <4067172C.2080503@apache.org>
To: dev@cocoon.apache.org
Message-id: <C63F0EAA-80E7-11D8-824F-00039388DCEE@lunartek.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <07258F4244D6F649B1A78993D070B7CA6F7830@ACSPMXE02>
 <41AF6667-7E80-11D8-9EBC-000393C27E0C@betaversion.org>
 <46A5A93C-7E94-11D8-824F-00039388DCEE@lunartek.com>
 <7CB1C412-7EB3-11D8-92A8-000A95984AEA@betaversion.org>
 <40644882.4030003@apache.org>
 <A21872B8-800C-11D8-824F-00039388DCEE@lunartek.com>
 <4067172C.2080503@apache.org>

I'll have to say yes I do know about sys admin work (if we're going to 
count years, mine is 22 years now).  Matter of fact one of the JMX 
products I mentioned is a IT management tool (monitoring SNMP, 
services, even SSH accessible shell scripts and the internals of our 
Oracle, MySQL and other databases, Cisco routers, Linux routers, and 
even slot machines *g*).

I know there is no love lost between the Apache and JBoss communities, 
but have a look at their kernel.  It is not entirely based upon JMX, 
but JMX forms a very integral part of their kernel and is pretty good, 
all things considered.  WebOS uses it as well, a little differently but 
the concepts are similar, although they use Jini protocols for 
inter-component messaging.  Sun's network monitoring product works with 
JMX and Jini, although their OSS replacement framework is all Jini and 
custom kernel while JMX is being reviewed to be brought back in.

I'll leave out the OOP discussions as even the father of Java still 
hasn't made up his mind if inheritance or interfaces, or what the 
correct valances should really be.  I think there's an easy Ph.D. in 
the works for anyone that can give a definitive answer there.

In the products I've built using JMX, like I stated earlier, I use JMX 
to load/unload and to manage the config of the components.  I think the 
last one we did was better in that the global configuration is held in 
a centralized database and the framework itself messaged the new 
configuration to the servers (nodes) and the JMX system was used to get 
the new component (via Jini calls, but JMX has no idea how it gets 
there) and then load it in with the IoC config and swaps out the old 
component, which is then GC, or can be dropped by kicking the 
classloader.

Have a quick look at those systems for ideas.  When you swap in a 
component, you also have to consider how all of the other components 
are talking to it.  Almost every system out there that attempts this 
uses the concept of a messaging bus between components, so that you can 
actually swap out a component, which becomes difficult and language 
dependent when using direct references.

The ability to swap in/out components and have the other components in 
the system use it without much in the way of hiccups is a more 
interesting design problem than the load/unload and config.

Thoughts?

Thor HW (who is really enjoying these discussions!!!)

On 28-Mar-04, at 10:19 AM, Gianugo Rabellino wrote:

> Thor Heinrichs-Wolpert wrote:
>
>> 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.
>
> Well, you have been missing a point in my reply, which was about ease 
> of configuration not being necessarily a good thing. Anyway, I'm 
> catching up on the whole JMX thing, reading specs and books. So far, I 
> must confess that I'm *horrified* about the tangled web of reflection 
> hacks that make up the spec, not to mention the xml support done 
> *wrong* and the horrible procedural and non-OOP approach that is 
> forced by MBeans interfaces (which quickly become huge switchboards 
> made of if/else statements): no wonder this stuff came from EJB 
> people.
>
> But in any case, for now, I'll refrain to comment further: I'm curious 
> to hear what is your plan of implementing/integrating JMX as a core 
> part of the container, since the more I know about this stuff, the 
> more I get convinced that we need to support it (given the goods it 
> would buy us and given that it makes no sense to use another 
> instrument manager) but as an external thing.
>
>> 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.
>
> I'm wondering if you've ever been on the other side of the fence, 
> which is made of sys/network admins who don't quite give a damn about 
> languages, OOP abstractions and design stuff (I've been there for 
> almost 7 years, so let me state that I know my kids): they have to 
> work with a web of multi-architectural, multi-language, 
> multi-environment stuff which has the growing tendency of working 
> badly together, and they don't want to know what a garbage collector 
> is.
>
> They need tools to give them an overview on how their IT system is 
> working, and they need standard and language neutral stuff to make it 
> work again. Their little world is made of Tivoli, OpenView, some MRTG 
> and, occasionally, a bit of shell scripting: they will know about the 
> problem domain and they will (possibly) have a clue on the generic 
> environment, but just don't ask them to understand dynamic loading 
> through proxies, it just isn't their cup of tea. See my point?
>
> 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/)
>