TheServerSide is pleased to announce that it will be hosting the Public Book Review of Manning's "JMX In Action", by Ben Sullins and Mark Whipple, which is scheduled for publication this Fall. Chapter 1, "Resource management and JMX" and Chapter 13, "Using JMX with the J2EE platform" are now available for public review.


Download and Review Chapters 1 and 13 from JMX In Action

I read of the first chapter, and lo! it was good.

I knew the "what" and the "how" of JMX, but the "why" and the "when" were a bit dubious. That cleared things up nicely.

JMX is a bit abstract, it's nice to have something concerete to get to grips with.

Kenny,

Are you familiar with "JMX: Manageing J2EE with Java Management Extensions", by Juha Linfors, Marc Fleury et al, published by SAMS? It is worthwhile.

Regards,

Bob

I've never paid much attention to JMX, really. Perhaps because I haven't seen the value in it.

I am intrigued by the idea of using JMX as the application backbone, though, like the JBoss guys did. It bears a resemblence to stuff I've done in the past (i.e. heavily reliant on plugins and dynamic class loading), and might be a useful starting point for future projects.

Kenny,

Our use of JMX is not as 'deep' as its use in the JBoss 2.x and 3.x architectures. We find that JMX provides us a generic way to define, configure, start, stop, monitor, manipulate, reconfigure, etc. any kind of service that must run inside a Java process.

To be a bit more specific, JMX provides us a general mechanism to support any architecture that requires pluggable services. Moreover, with JMX those services can be monitored, manipulated, and reconfigured both dynamically (i.e., while the process hosting them is running) and remotely (i.e., from outside the host process).

Let me give you one example of how JMX enabled us to do something that otherwise is fairly hard to tackle. Along XP lines, we write and run automated unit/module tests using the JUnit testing framework. The question we faced was how to do 'in-container' testing of our application units and modules--i.e., how to perform tests that can only be performed when our application is up and running inside a running J2EE application server.

One approach to this problem is that provided by Cactus (http://jakarta.apache.org/cactus/index.html). Frankly, we just don't like the Cactus approach to solving this problem--partly because it seems convoluted to us, and partly because we believe it is an incomplete solution.

So we decided to leverage JMX and design a fairly simple yet extremely powerful JMX-enabled JUnitService. Here is a sketch of this service...

For a given tier of our application--such as our EJB-based 'business tier'--the service starts whenever we start up the tier. We can configure the service to recognize any number of JUnit test cases, including, for instance, a test case that by design is the tier's entire JUnit test suite.

The JMX-enabled JUnitService can be utilized in one of two basic ways. First, it can be configured to automatically run a named set of test cases upon startup; note that because of the service's de-facto dependence, in this scenario, on other services, we start it last. We employ this strategy to accomplish 'continuous integration' testing whenever updates are committed to our master CVS repository; in this case the service email negative results to the engineering team.

Second, the service can be contacted and manipulated from a browser client to run any registered test case(s) on demand. Individual engineers do this to run unit/module tests specific to their current work; in this case the service reports results back to the client browser.

Thus our JMX-enabled JUnitService gives us an extremely simple way to perform ALL of our testing. We use it to run comprehensive suites comprised of (a) tests that are not dependent on any application server/container services or application context; (b) tests that are dependent on application server/container services; and (c) tests that require a running application context and associated application server/container services.

Perhaps this gives you a concrete sense of at least part of the JMX value proposition.

Regards,

Bob
--
Robert E. Newby
Principal Software Engineer
ViviPort, Inc.
500 Edgewater Drive, 3rd Floor
Wakefield, Massachusetts 01880 USA
781-224-3646 | Bob_Newby at viviport dot com | <www.viviport.com>

Thanks for those thoughts. However, it's worth pointing out that JMX doesn't provide anything that couldn't otherwise be done. It just provides an existing framework to make life a bit easier.

My last project had all the features you mention, and all of it was bespoke code. The same framework was then used for another application.

But JMX does give you a common ground to start with, saving time, and is worth using for that reason alone.

Robert,
  How did figure out how to use JMX? I've been searching for info but I can find little. Nothing real world. I usually can find info of figure things out but I am at a loss. Is it simpler than I think? Am I left with buying the current book or waiting for the next? I understand MBeans, but how to use them with a server?

I've download MX4J, TMX4J and the reference version - nothing but tidbits as far as I can tell.