Cloud Comedy, Cloud Tragedy

This Network World article provides a pretty good overview of what the value of a well-used CMDB is. The statement that CMDBs are “enabled by open interfaces among management systems” is giving us (management system vendors) a bit more credit than we deserve at this point, but there is plenty of work in progress to make this be true (example 1, example 2, example 3).

I am a little late in pointing this out but we are half-way through the (hopefully final) public review of the WS-Notification family of specs (WS-BaseNotification, WS-BrokeredNotification and WS-Topics). You have one more week to review the specs and send your comments. Many of the changes in WS-BaseNotification and WS-BrokeredNotification relate to lifecycle management and how these specs relate to WS-ResourceLifetime. There is only one change to WS-Topics but I think it is a pretty major improvement. It cleans up how extension topics appear in a TopicSet document. All the links and information on how to comment are in this announcement.

WS-Management came out of the working group and has been published by the DMTF as a preliminary standard. Read it here.

Dave Orchard is having some fun with the spec names in the convergence roadmap. I think he stumbled onto the second way that Web services specifications are composed. It goes something like this:

• if the specs don’t overlap, compose them by putting their SOAP headers side by side
• if the specs overlap, compose them by concatenating their names

Let’s consider ourselves lucky that others were more imaginative than us, otherwise WSDL might be called WS-NasslScl and BPEL might be called
called WS-XlangWsfl. Some of Dave’s predictions are scary though. I just hope we don’t wake up one day to realize that the foundation
language for Web services is not XML anymore but CamelCase…

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.

Since the convergence roadmap was introduced last week I have explained it to a few people. I found that a graphical representation of how all the specifications mentioned in the roadmap relate to one another helps a lot. So, in case other people can use it, here is the animated powerpoint description of the proposed converged stack. It has to be shown in slideshow mode so the animations work.

Creating this slide reminded me of the (much nicer) animated slides that Jay Unger from IBM created for the introduction of WSRF. Those who were around at the time will surely remember them. For all the luck they brought to WSRF. Fortunately, I am not superstitious.

[UPDATE on 2007/11/27: the  link to the roadmap on hp.com doesn’t work anymore, but you can still find the roadmap on the IBM site. Also, it was brought to my attention that the animations in the powerpoint slide don’t work with powerpoint 2000 (i.e. version 9.0 that is part of Office 2000). I know they work on powerpoint 2003 (version 11.0, part of Office 2003) since it’s what I used to create it. Not sure about powerpoint 2002 (aka version 10.0 that was part of Office XP). Without the animations, this slide doesn’t make much sense.]