Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3F339200.5020003@apache.org>
Date: Fri, 08 Aug 2003 14:05:20 +0200
From: Leo Simons <leosimons@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: JMX as a kernel (was: Re: geronimo and avalon?)
References: <A4DB1658-C977-11D7-8B91-000A9566A360@coredevelopers.net>
In-Reply-To: <A4DB1658-C977-11D7-8B91-000A9566A360@coredevelopers.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jason Dillon wrote:

>> Yes, I could explain.
>
> Okay, well then explain... the abridged version please :-P

Why JMX Is Not A Very Good Kernel
------------------
top-of-head stuff. Can't find my old notes. IMVHO.

1) bloat. The JMX specification is over two hunderd pages I think. The JMX
API is dozens of classes. Too big. NanoKernel is better than MicroKernel.
MicroKernel better than BigKernel.

2) no isolation. Services running in a kernel should be very much seperated
from each other. JMX has domains, but those are just a namespacing
convenience last time I checked.

3) bad security. 2 leads to holes. You don't normally want to run untrusted
code directly inside the JBoss kernel. You can run untrusted code inside
a servlet or an EJB, but not inside the core.

4) big ugly wrappers. DynamicMBean and similar require client code to do
all sorts of introspection, and often require beans to declare all sorts of
information (through the XXXInfo stuff).

5) lack of transparency. Beans running inside a JMX envoriment usually need
some sort of knowledge that they are in that environment.

6) bad seperation of concerns. JMX acts as a component registry, as a
reflection tool, as a management tool, as an event/messaging mechanism, and
each of those is intertwined with the other.

7-25) I am sure I had 25 distinct similar complaints at one point. I 
can't find
the list.

Now, each of those issues can definately be addressed, and the success
JMX is having in precisely this role shows that they can be addressed
pretty well, and with JMX 1.2 and 1.3. things have improved a lot. But by
inverting the JMX setup (control over the system rests with the kernel,
not the other way around) the code becomes leaner, meaner, cleaner, simpler
and more secure. Moreover, "non-core" concerns (to a bean) such as
management and messaging can become fully transparent. And since JMX
was designed to be an extension, it is still easy to extend the lean machine
you've just coded to fully import/export everything it cares about over
JMX.

I guess that's enough talk for an abriged version :D

cheers,

- Leo