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!

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.

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.

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: javaone javaone2008 jmx shoal bean_validation configuration poker CSPoker.]