Category Archives: JMX

RESTful JMX access from someone who knows both sides

Anyone interested in application manageability and/or management integration should read about Jean-Francois Denise’s prototype for RESTful Access to JMX Instrumentation. Not (at least for now) as something to make use of, but to force us to think pragmatically about the pros and cons of the WS-* stack when used for management integration.

The interesting question is: which of these two interfaces (the WS-Management-based interface being standardized or the HTTP-centric interface that Jean-Francois prototyped) makes it easier to write a cross-platform management application such as the poker-cheating demo at JavaOne 2008?

Some may say that he cheated in that demo by using the Microsoft-provided WinRM implementation of WS-Management on the VBScript side. Without it, it would have clearly been a lot harder to implement the WS-Management based protocol in VBScript than the REST approach. True, but that’s the exact point of standards, that they allow such libraries to be made available to assist implementers. The question is whether such a library is available for your platform/language, how good and interoperable that library is (it could actually hinder rather than help) and what is the cost to the project of depending on it. Which is why the question is hard to answer in absolute. I suspect that, even with WinRM, the simple use case demonstrated at JavaOne would have been easier to implement using straight HTTP but that things change quickly when you run into more demanding use cases (e.g. event notification with filters, sequencing of large responses into an enumeration…). Which is why I still think that the sweetspot would be a simplified WS-Management specification (freed of the WS-Addressing crud for example) that makes it easy (almost as easy as the HTTP-based interface) to implement simple use cases (like a GET) by hand but is still SOAP-based, which lets it seamlessly enter library-driven territory when more advanced features are added (e.g. WS-Security, WS-Enumeration…). Rather than the current situation in which there is a protocol-level disconnect between the HTTP interface (easy to implement by hand) and the WS-Management interface (for which manually implementation is a cruel – and hopefully unusual – punishment).

So, Jean-Francois, where is this JMX-REST work going now?

While you’re on Jean-Francois’ blog, another must-read is his account of the use of Wiseman and Metro in the WS Connector for JMX Agent RI.

As a side note (that runs all the way to the end of this post), Jean-Francois’ blog is a perfect illustration of the kind of blogs I like to subscribe to. He doesn’t feel the need to post all the time. But when he does (only four entries so far this year, three of them “must read”), he provides a lot of insight on a topic he really understands. That’s the magic of RSS/Atom. There is zero cost to me in keeping his feed in my reader (it doesn’t even appear until he posts something). The opposite of what used to be conventional knowledge (that you need to post often to “keep your readers engaged” as the HP guidelines for bloggers used to say). Leaving the technology aside (there is nothing to RSS/Atom technologically other than the fact that they happen to be agreed upon formats), my biggest hope for these specifications is that they promote that more thoughtful (and occasional) style of web publishing. In my grumpy days (are there others?), a “I can’t believe United lost my luggage again” or “look at the nice flowers in my backyard” post is an almost-automatic cause for unsubscribing (the “no country for old IT guys” series gets a free pass though).

And Jean-Francois even manages to repress his Frenchness enough to not take snipes at people just for the fun of it. Another thing I need to learn from him. For example, look at this paragraph from the post that describes his use of Wiseman and Metro:

“The JAX-WS Endpoint we developed is a Provider<SOAPMessage>. Simply annotating with @WebService was not possible. WS-Addressing makes intensive use of SOAP headers to convey part of the protocol information. To access to such headers, we need full access to the SOAP Message. After some redesigning of the existing code we extracted a WSManAgent Class that is accessible from a JAX-WS Endpoint or a Servlet.”

In one paragraph he describes how to do something that IBM has been claiming for years can’t be done (implement WS-Management on top of JAX-WS). And he doesn’t even rub it in. Is he a saint? Good think I am here to do the dirty work for him.

BTW, did anyone notice the irony that this diatribe (which, by now, is taking as much space as the original topic of the post) is an example of the kind of text that I am glad Jean-Francois doesn’t post? You can take the man out of standards, but you can’t take the double standard out of the man.

[UPDATED 2008/6/3: Jean-Francois now has a second post to continue his exploration of marrying the Zen philosophy with the JMX technology.]


Filed under Application Mgmt, CMDB Federation, Everything, Implementation, IT Systems Mgmt, JMX, Manageability, Mgmt integration, Open source, SOAP, SOAP header, Specs, Standards, WS-Management

JSR262 public review ballot

The Public Review Ballot for JSR #262 that took place in the Executive Committee for SE/EE has closed. I am not familiar enough with the JCP process to know exactly what this milestone represents. But the results are interesting in any case.

The vote narrowly passed with 6 yes, 5 no and 1 abstain.

The overiding concern listed by the “no” voters (and several of the “yes” voters) is the fact that JSR262 uses WS-Management (a DMTF standard) which itself makes use of specifications that have been submitted to W3C but are not currently in the process of standardization (WS-Transfer, WS-Eventing, WS-Enumeration). And that it uses an older version of a now-standard specification (WS-Addressing).

SAP makes the most insightful comment: that this is not really a JCP problem but a DMTF problem. Hopefully the DMTF (and Microsoft, since it controls the fate of the specifications in question) will step up to the plate on this. This is likely to happen. Even if the DMTF and Microsoft didn’t care about making the JCP happy (but they do, don’t they?), they will run into similar issues if/when they push WS-Management towards ANSI/ISO standardization.

Next to this “non-standard dependencies” issue, there is only one technical issue mentioned. As you guessed, it’s IBM whining about the lack of a WSDL to feed their tools. This is becoming so repetitive that I may eventually stop making fun of it (but don’t hold your breath, I am not known for being very good at ending long-running jokes). It is pretty ironic to hear IBM claim that without that WSDL you can’t implement the spec on JAX-WS when you know that the wiseman reference implementation by Sun and HP is based on JAX-WS…

Comments Off on JSR262 public review ballot

Filed under Application Mgmt, Everything, IBM, Implementation, ISO, IT Systems Mgmt, JMX, Manageability, Microsoft, Specs, Standards, WS-Management, WS-Transfer

Between skinny and bloated

Spring’s Rod Johnson writes today about the future he sees for Java Bloatware (his unkind term for Java EE middleware). Of course, as Mr. Spring, he is far from neutral. Of course he is focusing on a certain class of applications (web-centered, mostly greenfield, which is a huge – and sexy – segment, but not in any way the only kind of applications). Of course he underestimates how established technology that works remains used long after it may have ceased to be the optimal solution for new developments. But even taking all that into account, he makes some good points about the proliferation of rarely-used capabilities in Java EE and the associated cost. Most of those points are well understood and are driving the more modular approach taken by Java EE 6. As well as the adoption of OSGi (see here and here for BEA’s example). In addition, as Rod mentions, the JCP now has to share the playground with other framework standardization efforts like SCA.

The most interesting part of Rod’s post from my perspective, is this prediction:

“The market will need to address the gap between Tomcat and WebLogic/WebSphere. Currently an important part of the market is neglected. The majority of Java web applications are most at home on Tomcat. A minority actually want some of the more esoteric functionality of a full-blown application server, such as JCA, or specialized capabilities such as distributed transaction management. But a larger minority need some of the operational and management features of those products, but are not interested in the esoteric APIs and the bloat they bring along with them. As more and more end user companies look to phase out legacy application servers in favor of better suited technologies, there will inevitably be a response to market demand, with products that hit the sweet spot and bridge this gap.”

Right on. This is the second time in a week that we see an acknowledgment of the importance of application manageability coming from SpringSource. Whether this mid-point demand will be met from the top down by a more modular Java EE stack or from the bottom up by building on top of Tomcat (or some non-Java HTTP server) remains to be seen. The two aren’t exclusive either.

I expect that the hosted application frameworks like the recently announced Google App Engine will also aim at that “more than Tomcat, less than J2EE” sweetspot. But the cost/benefit formula of a more full-featured (or “bloated” if you prefer Rod’s terminology) environment might turn out to be different in a “hosted framework” situation.

1 Comment

Filed under Application Mgmt, Everything, IT Systems Mgmt, JMX, Manageability, Spring, Tech

SpringSource Application Management Suite

SpringSource has made some recent announcements, in an effort to build up its commercial offering on top of the open source Spring framework. There is now a SpringSource Enterprise subscription which gives you access to an “enterprise” edition of the framework, some support and the SpringSource Performance Suite.

The first two components (enterprise edition and support) are common approaches to commercial open source.

The performance suite is a new product, comprised of the Tool Suite (for development), an Advanced Pack for Oracle (for better use of Oracle RAC features) and the Application Management Suite (AMS). Application and middleware management is what I care most about, so AMS is the part of the announcement that caught my attention.

The only publicly-accessible source of meaningful information about AMS that I could find is this blog post by Jennifer Hickey. AMS is built on Hyperic. The monitoring is based on collecting, through instrumentation, entry and exit times for monitored methods. The agents then reports this to a server. Add to this some discovery capabilities and the console can then report observed metrics on the discovered/selected resources.

The blog post ends by saying that “we’d like to make it as powerful and easy to use as possible for both Developers and Operations staff”. At this stage, I think it’s a lot more likely to be used for development than for operations. The instrumentation overhead is supposed to be “very slight” but, as always with monitoring, this warrants more precise data. Also, it is not clear if/how AMS can integrate with other management tools.

In any case, it’s encouraging to see an open source application development framework which doesn’t entirely focus on ease of development but also acknowledges the full lifecycle of an application (and concerns such as monitoring, as addressed here, but also configuration management, governance, business activity management…). That’s the difference between “the best framework to create an application” and “the best framework to create an application that is expected to be used”. Before open source became a business strategy, a defining characteristic was that the developers where also users of the product. Which naturally meant that it was heavily biased towards developers and development tasks.

From an operations perspective, the AMS team should focus its efforts on application modeling, metric collection and management integration rather than the dashboard. A simple specialized console is great for application developers. The ability to discover, model, configure and monitor applications in conjunction with the other elements of the IT system (e.g. underlying infrastructure, end user experience, business processes and other forms of application integration, etc) is what operators really need.

In any case, it will be interesting to test the practical value of “Spring-aware” application management, above and beyond generic Java application management.

Bonus question: the enterprise edition of the Spring framework is “warranted to be virus-free”. Since the enterprise version includes the base framework, to the extent that the enterprise version is virus-free then mustn’t the base logically be “virus-free” as well? And what does “virus-free” mean anyway?


Filed under Application Mgmt, Everything, IT Systems Mgmt, JMX, Mgmt integration, Spring

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.


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