geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <jer...@coredevelopers.net>
Subject Why we must have JMX...
Date Tue, 12 Aug 2003 18:00:03 GMT
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


Mime
View raw message