You are right that the JSR 262 standard really only proposes another plumbing possibility for JMX instrumentation. The JSR is chartered to produce a “connector”, which in JMX terminology means a way for a remote client to see essentially the same JMX interface as a local client. This is of interest for several reasons, some of which you mention. One is simpler configuration in the presence of firewalls. A second is the ability to reuse a web server configuration (ports, security, and so on) that may already be present in an application. And a third is access from non-Java languages, notably scripting languages. (Imagine a perl script that needs to grab the value of a JMX attribute, for example.)

You are also right that the JSR doesn’t go as far as it might, and in particular it doesn’t address how one might go about linking a JMX agent into a management infrastructure where the management interfaces are not primarily defined through JMX MBeans. For example, one where the interfaces are defined through CIM. In JMX terminology, that is where you would use an “adaptor” rather than a connector. An adaptor converts from a protocol that is unrelated to the JMX world, such as SNMP or HTML/HTTP or WS-CIM, into requests on JMX MBeans. With a WS-Management adaptor, you would be able to use JMX as an implementation technology to create a WS-Management agent that respects a pre-existing model.

Defining an adaptor is beyond the scope of JSR 262, but in fact we include one with the Reference Implementation, which you can download from http://ws-jmx-connector.dev.java.net . That defines an API that you can use to construct a JMX implementation of a pre-existing model. In particular we’ve prototyped its use for WS-CIM. There might be another JSR in there somewhere.

Regards,
Éamonn McManus, JSR 262 Specification Lead

Kind regards,

William

From an instrumentation perspective I am very disappointed that we have an API that really does not know which world it wants to be in – old or new. Whilst it offers a simplistic, generic (and rarely contextual) management interface to remote system management tool vendors it offers very little to the developer and performance engineer trying to understand how metrics are (or should be) constructed and related. This appears to be left to a string description in the MBean attribute and for each MBean developer to write his own metric aggregation code again and again. JMX to metric monitoring is like Java Logging to CEP. But the worse mistake is that performance of the local call interface JMX makes it unsuitable for local agent fine grain correlation with relatively small event (request, transaction, invocation) intervals ensuring the system monitoring model and software execution models stay worlds apart when this should not be the case.

I understand your focus is on the integration and control surface and mine on the instrumentation to construct a model with the ability to comprehend and reason.

I have previously written up some thoughts on this area on my blog.

Benchmark Analysis
http://blog.jinspired.com/?p=211

JXInsight 6.0 Metrica
http://blog.jinspired.com/?p=209

A Good Metric is Transparent
http://blog.jinspired.com/?p=147

William Louth
JXInsight Product Architect
CTO, JINSPIRED

“Performance monitoring and Problem diagnostics for Java EE, SOA, and Grid Computing”
http://www.jinspired.com