Why we must have JMX...

[Jeremy Boynes <je...@coredevelopers.net>]

Because it says so ... [J2EE1.4PFD3 pp 87] [JSR77 pp82]

However, the requirement here is just that all J2EE components in the server
are manageable via the MEJB/JMX - it does not say anything about the
internal implementation of the J2EE server.

This does leave us free to choose the best tool for implementing the kernel,
so we should consider the different alternatives. Regardless of the final
decision though, we must support JMX for managing the J2EE components.

Given that, we should support JMX for managing all components in the server.
If an admin is using a JMX client, then they should be able to control the
entire server not just the JSR77 mandated bits; they should be able to do
everything through one UI. This means, regardless of the kernel
architecture, all components should expose a JMX management interface.

How the kernel routes application requests though is a different issue. One
solution is to expose an invoke operation on the JMX management interface
(this is essentially JBoss's implementation) with the result that all
application operations get routed through the JMX kernel. This is a simple
architecture based on the premise that the overhead of a JMX invocation is
negligible compared to processing the other aspects (security, txns,
persistence, ...) and seems to work.

Another solution is to use a different dispatch mechanism for application
requests (e.g. direct invocation or invocation though a different
micro-kernel like Avalon). This has the advantage that the two dispatch
mechanisms can be optimized separately (e.g. the app dispatch can be tuned
for performace, the management dispatch for flexibility). The downside
though is that there are two dispatch mechanisms.

One way to solve that is to have the micro-kernel implement the JMX
specification itself, allowing it to process both application requests and
mangement requests. Is there a JMX1.2 implementation available on top of any
of the other frameworks proposed?

Ultimately, this may be the best solution, but until that time I think it is
easier to work within the JMX framework as we know that it will always be
available.

--
Jeremy

Re: Why we must have JMX...

[Alex Blewitt <Al...@ioshq.com>]

On Tuesday, Aug 12, 2003, at 19:42 Europe/London, Jens Schumann wrote:

> On 8/12/03 08:00 PM Jeremy Boynes <je...@coredevelopers.net> wrote:
>
>> Because it says so ... [J2EE1.4PFD3 pp 87] [JSR77 pp82]
>>
>> "the best tool for implementing the kernel ..."
>
> .oO(is it just me who is already getting annoyed reading "the best" in 
> every
> second post? ;)

Tell you what, let's go for the second best solution then :-)

>> Given that, we should support JMX for managing all components in the 
>> server.
>> If an admin is using a JMX client, then they should be able to 
>> control the
>> entire server not just the JSR77 mandated bits; they should be able 
>> to do
>> everything through one UI. This means, regardless of the kernel
>> architecture, all components should expose a JMX management interface.
>
> Well, you should still differentiate between
>
> A) administration and
> B) operation.

And they both probably need different views of the application. 
Operations need things up/down (or attention when things are going 
wrong) whereas the administration/configuration probably needs a more 
detailed UI component to show all the information. How that's presented 
(web app, GUI whatever) probably doesn't depend on how it's found out 
(which may be JMX).

>> [... JBoss Micro Kernel ...]
>> [... Avalon Micro Kernel ...]
>> [... Homegrown JMX Kernel ...]
>
> As I said in another thread:
> Switching between JMX based and JMX enabled is painful, just ask the 
> tomcat
> guys. When I was looking the last time at the 5.0 CVS version you 
> could see
> the problems they were running into while moving towards a more or 
> less JMX
> based component architecture.

A Big Change Later would definately hurt. If we can use some of the 
ideas behind the Dynamic MBeans that were suggested earlier would give 
us the advantage in this respect.

> I would always vote for a home grown JMX Kernel from day no 1., which
> provides the configuration mechanism, the component architecture, 
> dependency
> resolution, timer service and monitoring. But please don't try using 
> it as
> an invocation bus.

I really concur with the last point -- JMX should definately not be 
used as an invocation bus. And if we're going with a JMXAsKernel 
initially, this is one of the things that really could run into 
difficulties/performance issues later.

I'm also (personally) happy with the idea of JMX being used to 
interrogate components/services, but just not necessarily with ramming 
JMX down everything. For example, though JMX supports configuration 
(don't know how though), I feel that using JNDI, or JNDI over LDAP, 
will provide an excellent configuration mechanism, especially for 
distributed systems. My understanding of how JMX works in a distributed 
system for distributed config is a bit vague; I thought the config only 
worked per-JMX-MBean-server?

Alex.

Re: Why we must have JMX...

[Jens Schumann <je...@void.fm>]

On 8/12/03 08:00 PM Jeremy Boynes <je...@coredevelopers.net> wrote:

> Because it says so ... [J2EE1.4PFD3 pp 87] [JSR77 pp82]
> 
> "the best tool for implementing the kernel ..."

.oO(is it just me who is already getting annoyed reading "the best" in every
second post? ;)
 
> Given that, we should support JMX for managing all components in the server.
> If an admin is using a JMX client, then they should be able to control the
> entire server not just the JSR77 mandated bits; they should be able to do
> everything through one UI. This means, regardless of the kernel
> architecture, all components should expose a JMX management interface.

Well, you should still differentiate between

A) administration and
B) operation.

Operations, the guys who usually maintain and observe the state of a system,
don't care about application internals. All they want to know is "Things are
up and running", or "down". Expressed by a green or red light in their
favorite SNMP tool. Correct me if I am wrong, but JMX support is still flaky
for HP OpenView, Tivoli etc. So you end up with an SNMP Adapter and MBeans
which expose standard types only (OpenMBeans) _including_ SNMP Trap support
(without management remains a toy).

On the other hand the administrator should be able to play with internals as
much as possible, the typical html console might be enough (however a
cluster view would be helpful).

> [... JBoss Micro Kernel ...]
> [... Avalon Micro Kernel ...]
> [... Homegrown JMX Kernel ...]

As I said in another thread:
Switching between JMX based and JMX enabled is painful, just ask the tomcat
guys. When I was looking the last time at the 5.0 CVS version you could see
the problems they were running into while moving towards a more or less JMX
based component architecture.

I would always vote for a home grown JMX Kernel from day no 1., which
provides the configuration mechanism, the component architecture, dependency
resolution, timer service and monitoring. But please don't try using it as
an invocation bus.

Just my 2 cents,

Jens