Skip to main content

JavaOne report: JMX Technology

Posted by emcmanus on May 28, 2008 at 8:43 AM PDT

This is the fourth installment in my summary of the sessions I
attended at JavaOne this year.

The previous installments
covered Java
futures
,
Java
programming practice
, and
concurrency.
This one covers JMX stuff.

Once again, the titles here are not always the ones that appear
in the conference programme. I tried to undo the mangling that
the Trademark Police typically impose on talk titles, so let me
just state up front that Java, JMX, and JVM are trademarks of
Sun Microsystems, Inc., and any other abbreviation beginning
with J has a sporting chance of being one too.

Here are the talks summarized in this installment:

JMX Technology Update

Practical JMX Security Options

Designing Manageable Java EE Applications in a
Clustered Environment

In the remaining installment, I'll cover all the other stuff
that didn't fit into any of my neat categories.


TS-5199, JMX Technology Update, Jean-François
Denise, Éamonn McManus. Hey, that's us!


width="260" height="281"
title="Eamonn at the podium (photo by Yuichi Sakuraba)">

Jeff
(Jean-François) and I have been a double act for the last
few JavaOnes and we repeated that here. I
presented JSR
255
, the JMX 2.0 API, much of which I have described to
death elsewhere on this blog. Jeff
presented JSR
262
,
the Web
Services Connector
.

Since Jeff is a bit of a poker fiend he had the idea that this
year's demo could be based on poker somehow. He found an
open-source poker server
called CSPoker,
created by students at
the Katholieke
Universiteit Leuven
. He encouraged them to create a JavaFX GUI
for the server.


width="240" height="159"
title="JavaFX poker table (photo by Yuichi Sakuraba)">

Then he concocted a scenario where I was an evil poker cheater
found out through JMX instrumentation. Thanks to the Web
Services Connector, this JMX instrumentation was accessible
through the same web server that players use. Once my cheating
was discovered, the Web Services Connector also allowed Jeff to
write
a VBScript
program
that would access the JMX instrumentation to detect
my cheating and kick me off.


width="452" height="216"
title="Jeff and Eamonn play poker (photo by Yuichi Sakuraba)">

We rehearsed this demo until nothing could go wrong, and
foresaw every possible problem. Notice the yellow cable linking
the two laptops - no way were we going to rely on the conference
centre's network to function as it should. But of course
something did go wrong. There was much less light in the room
than when we rehearsed there earlier, and I couldn't see the
keyboard with my sunglasses! Well, that was pretty minor as
problems go, and I even got an audience laugh out of it.

We were pleasantly surprised at how well received this simple
sketch was. Actual applause when I showed my cheater's hand of
four aces! We'll be thinking about another instructive demo for
next year's talk, if it's accepted.

(The photos here are
from hundreds
taken by Yuichi
Sakuraba
at the conference.)

BOF-5698, Practical
JMX Security Options
, James Gould, David Smith. This was
a very good introduction to JMX security from people who have
obviously worked closely with it. Unlike the technical
sessions, I don't think the slides from the BOFs will be
available on the JavaOne site, but if they show up on the web
somewhere I'll certainly link to them.

The message I took away from this BOF was probably different
from most attendees. Configuring JMX security is too hard. We
designed everything around standard Java security, using a
SecurityManager, policy files, and so on. But almost nobody
uses a SecurityManager, and although we also provide ways of
configuring security without one, they are either too basic or
too hard. An area for us to work on.

BOF-4945, Designing
Manageable Java EE Applications in a Clustered
Environment
, Jens Jensen, Peter Kristiansson. Jens and
Peter are at Ericsson, and I've had some contact with them
before on this subject. Peter (presenting alone) described
their solution for handling configuration in a clustered app
server.

In their solution, each instance (JVM) has an MBeanServer that
exposes a read-only MBean view of a tree of configuration
elements. These MBeans get their data from a configuration
provider in each JVM. One of the configuration providers is the
master and the others are replicas. Updating the configuration
involves a console or other management client updating the
configuration in the master provider, which transactionally
updates the persistent store and forwards the changes to the
other providers. When a configuration provider (master or
replica) gets a change, it informs the corresponding MBean so
the MBean can send a notification.

They use Shoal to
manage the cluster of configuration providers. They
use JSR 303
(Bean Validation) to express constraints on configuration
items.


In the next and final installment I'll cover the remainder of
the sessions I attended.

[Tags:






.]

Related Topics >>

Comments

We're working on it. Stay tuned!

really interesting....when could we try a jmx 2.0 first rel? thanks!

For me, 4945 was a rather disappointing presentation with very promising title. I was very much hoping for a demo. But if the corresponding JSR sees a light of day, hey, trying it out could be fun :)

ok, I visit almost every day wonderful jmxTeam blogs !!