JSR262 (JMX over WS-Management) public review

If you care about exposing or accessing MBeans via WS-Management, now is a good time to read the public review draft of the JSR262 spec.

JSR262 is very much on the “manageability” side of the “manageability vs. management integration” chasm, which is not the most exciting side to me. But more commonality in manageability protocols is good, I guess, and this falls inside the WS-Management window of opportunity so it may help tip the balance.

There is also a nice white paper which does a nice job of retracing the history from JMX to JMX Remote API to JSR 262 and the different efforts along the way to provide access to the JMX API from outside of the local JVM. The white paper is actually too accurate for its own good: it explains well that models and protocols should be orthogonal (there is a section titled “The Holy Grail of Management: Model, Data and Protocol Independence”) which only highlights the shortcomings of JSR262 in that regard.

In a what looks from the outside like a wonderful exercise of “when you have a hammer” (and also “when you work in a hammer factory” like the JCP), this whole Java app management effort has been API-driven rather than model-driven. What we don’t get out of all this is a clearly defined metamodel and a set of model elements for Java apps with an XML serialization that can be queried and updated. What we do get is a mapping of “WS-Management protocol operations to MBean and MBean server operations” that “exposes JMX technology MBeans as WS-Management resources”.

Yes it now goes over HTTP so it can more easily fool firewalls, but I am yet to see such a need in manageability scenarios (other than from hackers who I am sure are very encouraged by the development). Yes it is easier for a non-Java endpoint to interact with a JSR262 endpoint than before but this is an incremental improvement above the previous JMX over RMI over IIOP because the messages involved still reflect the underlying API.

Maybe that’s all ok. There may very well not be much management integration possible at the level of details provided by JMX APIs. Management integration is probably better served at the SCA and OSGi levels anyway. Having JSR262 just provide incremental progress towards easier Java manageability by HP OVO and the like may be all we should ask of it. I told some of the JSR262 guys, back when they were creating their own XML over HTTP protocol to skirt the WS-Management vs. WSDM debate, that they should build on WS-Management and I am glad they took that route (no idea how much influence my opinion had on this). I just can’t get really excited about the whole thing.

All the details on the current status of JSR262 on Jean-Francois Denise’s blog.

6 Comments

Filed under Everything, JMX, Manageability, Mgmt integration, Specs, Standards, WS-Management

6 Responses to JSR262 (JMX over WS-Management) public review

  1. Hi 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

  2. vbp

    Hi William L. This makes sense, but it’s more applicable to JSR255 (version 2.0 of the JMX API) than to JSR262. BTW, Eamonn and JF Denise will be speaking about both of them at the upcoming JavaOne, so that would be a good place to bring up these questions if you are going to be there.

  3. Well every year I submit a one or two sessions to JavaOne on software performance engineering, resource metering (probes), and runtime state diagnostics for improved production problem resolution and each year this get pushed aside for the latest fade not even in reach of a production server. I did speak at two previous JavaOne conferences on EJB and Java EE when that was the thing to do but I seem to be in a field now that seems boring to most who just want to attend 10 sessions or more on scripting in Java with another language. Also I think being a Sun employee seems to guarantee slot irrespective whether you JSR is actually designed well (I could not stand to see another mbean type or server connection interface whilst the model issues are not addressed).

    Kind regards,

    William

  4. Pingback: People Over Process » links for 2008-02-20

  5. William,

    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

  6. vbp

    Thanks for the insight Éamonn, this is very helpful in understanding what is going on with JSR262.