It’s always nice to get some sympathy. When Tim Bray writes “I can’t help but feel for the H/I/I/M staff who are going to have to do the work”, I think I am included. And even thought the rest of the message is mostly ironic, I don’t think he means this sentence ironically. By “H/I/I/M” he of course means HP, IBM, Intel and Microsoft who recently published a roadmap for convergence of Web service standards for resources, events, and management, on which Tim shares his thoughts.
This kind word of support made me think back for a minute about where we are coming from in this long-winded effort to establish an interoperable way to use Web services for management.
The first instance I am aware of came from HP and WebMethods. It was the OMI work, released back in 2001. The goal was to “provide an easy, open way for systems management vendors and other interested parties to access and manage the resources associated with an integration platform, together with associated business processes.” At the time, putting Web services on simple resources was a bit of a stretch, but using Web services to manage integration platforms and the underlying business processes was already in OpenView’s agenda.
In 2002, a few of us in HP created the Web Services Management Framework (WSMF). It’s not exactly how I would write it today, but it does the job well and reliably. Especially, if you include the note on dynamic attributes and meta information that we published a few months later. This note introduces a generic GET operation qualified by an XPath statement to retrieve a portion of the XML representation of the resource. Hum, where have I seen this lately… It also provides a way to retrieve metadata associated with the entire resource, or to a given operation, attribute or notification. To this day, we integrate with several partners using WSMF.
As a side note, WSMF didn’t suffer from not using WS-Addressing. What we did need that wasn’t available at the time, was a way to subscribe for events and deliver them using Web services. So we wrote WS-Events to do just this. Not being in the messaging business, we didn’t really want to write it and wanted to let the messaging vendors drive it, but at the time there was nothing like WS-Notification or WS-Eventing available. These days, I often hear people use the name WS-Events to mean WS-Eventing, so at least I have the satisfaction to know that by being first we got to pick the more intuitive name. Maybe we should have done the same thing with WSMF and called it WS-Management…
The goal of course was to have industry-wide interoperability so in 2003 we submitted WSMF to the OASIS WSDM technical committee. Along the way, we picked up WS-Addressing, WSRF, WS-Notification (as a way to merge our foundation with that used by the Global Grid Forum) and WS-Manageability (a submission from IBM, CA and TalkingBlocks for the management of Web services, for which WSMF also had a subcomponent called WSMF-WSM). The result is WSDM 1.0, now an OASIS standard.
But the quote from Metropolis provided by Tim (“Nobody cared about the slaves who died laboring to raise the Tower of Babel”) is especially relevant here, not just because non-one cared about the slaves (many people on the planet do a much more painful work for much less reward than the engineers involved in these specifications, so am I not too sorry for us), but because, as in Babel, someone up in the clouds (or rather, up North where the weather is often cloudy) didn’t like the looks of the tower we were building and created incompatible languages, preventing the tower from reaching the heavens.
I am of course referring to the publication of WS-Management. But our goal of industry-wide interoperability hadn’t changed, so off we went again. Along two threads actually (yes, it gets worse before it gets better). Since the submission of WS-Management to the DMTF we’ve been working there on fixing it up. The spec is expected to soon come out of DMTF. And at the same time, as is now well-known, HP, IBM, Intel and Microsoft have been working on a convergence of the two stacks, which is what the roadmap published last week describes.
So, anyway, here is my brief personal history, to this day, of Web services for management. From a very HP-centric viewpoint, one way to look at it is that HP was the very first to create a spec to use Web services for management, then we had to bring IBM on board so we did another iteration, and now we have to bring Microsoft on board so here we go with yet another iteration.
Yes, there is more work to come. Thank you Tim for your support. I, for one, am ok, really. I am actually more worried about the consumers of our specs. The developers of course, including those who spent a lot of time implementing these specs, for example for Apache or for CDDLM. And our partners and customers, who make planning decisions based on the industry landscape. It’s for these people that we wanted to publish this roadmap as soon as possible and make it specific enough that people can extract useful information to plan accordingly. From my perspective at least, they are the reason why it made sense to publish the roadmap even though we are not yet ready to provide the actual specifications being developed. And also to provide Tim with some pinata practice just before Easter.
Tim also ironically notes that some of the vendors participating in the convergence are “supporting the existing to-be-superseded and to-be-amended specs in the interim, and are apparently suggesting, straight-faced, that it might be sane for customers to use them”. From HP’s perspective, we are only listed as planning to eventually support the converged specifications. For the rest, in such a context every situation is unique when determining the smartest way to use available information about the convergence and available specifications. One needs to find the most appropriate way to move forward today (the benefits of applying SOA principles and Web services technologies to management are reachable today and many customers are seizing them) while protecting the investment in the long run. We are working with our customers and partners on this.
All in all though, I am not quite sure what to make of Tim’s message. Calling the roadmap a WS-Pinata clearly illustrate his eagerness to hit it hard. But those hitting a pinata tend to be blindfolded and the pinata also contains candy. I am probably pushing the analogy further than Tim intended but, irony aside, he doesn’t seem to disagree with the value of having the industry standardize on a set of specifications rather than having competing stacks.