An interesting convergence is taking place in the IT management world, toward Web services-based management protocols. One of the driving factors in this convergence is the effort to improve the agility of enterprise IT, such as HP's Adaptive Enterprise, IBM's On Demand Computing, and Microsoft's DSI.

The convergence also derives from the effort of the Grid community, as seen in Global Grid Forum, where the goal is to build support for large and distributed computing systems. At the lower end of the spectrum, the convergence comes from manufacturers of devices such as printers and phones that acknowledge improved management as a key customer demand. Finally, the traditional IT management community, such as the companies working inside the Distributed Management Task Force (DMTF), is also compelled to use Web services for management.

The reasons for wanting to use a Web services-based standard are multiple, but those most often cited are:

• Interoperability, especially in heterogeneous environments
• Desire to comply with service-oriented architecture (SOA) principles
• Reuse of the large (and increasing) number of Web services tools available
• The need to build efficient, large-scale distributed systems that leverage the increasing number and diversity of nodes on the network
• Protection of investment through the use of industry standards
• Access to the features of other composable Web services specifications in domains such as reliable messaging, security, transactionality, etc.
• Desire to get rid of the need for multiple agents bolted on resources in order to provide manageability for the resource for multiple management products
• Integration of some management functions in business-driven interactions for improved alignment of business and IT

Out of this industry push, two main efforts have emerged. The OASIS WSDM (Web Services Distributed Management) technical committee produced the WSDM MUWS (Management Using Web Services) 1.0 specification as an OASIS standard in March 2005. In August 2005, the WS-Management specification was submitted to the DMTF, which subsequently chartered a new subgroup to produce a standard based on the WS-Management submission. WSDM MUWS and WS-Management largely overlap in scope. More important, while the attention is often focused on the differences, there are significant similarities in the two specifications.

Both specifications assume that resources are represented by an XML document and make this document available through SOAP-based mechanisms (allowing the entire document or only parts of it to be retrieved). In addition, both specifications consider that resources are individually addressable and assign to them a WS-Addressing Endpoint Reference (EPR). In doing so, the specifications don't assume that accessing each resource directly is the only way to manage them, but allows the XML representation of several resources to be accessed at once as part of a system. Both specifications also make use of a SOAP-based eventing mechanism to allow managers to subscribe for and receive events of interest. The actual SOAP messages used to execute these actions are different, preventing interoperability across the specifications, but the concepts and approaches are very similar.

The key difference between the specifications comes from the somewhat different perspective under which they were developed. The focus of WS-Management was to optimize for small, well-understood systems, such as the components of a computer or the services inside an operating system. WSDM's focus, as illustrated by the "D" in the acronym, was on allowing and managing distributed systems, composed of resources of very dissimilar types. This division in approach materializes in the only considerable architectural difference between WSDM MUWS and WS-Management: the fact that WS-Management specifies the structure of the EPR while WSDM MUWS doesn't put any constraint on how EPRs are created. The value of treating EPRs as opaque is that it promotes loose coupling between the service and the consumer. The addressing details are hidden in the EPR and never show up in the implementation of the consumer. The consumer only needs to find the EPR to know how to access the service, and if the service changes its addressing mechanism, an updated EPR will work and require no change on the consumer.

On the other hand, this requires that the consumer first find the EPR of the service, which costs an extra step in the interaction. In management scenarios, an additional aspect to consider is the fact that the invoker usually knows and understands the model of the resource. In this case, if we assume that the addressing mechanism is based on elements of the model (a requirement that WS-Management unfortunately does not impose but that implementers of the specifications would be wise to obey), then exposing this addressing mechanism to the invoker doesn't really add much tightness to the coupling. This is the approach that WS-Management takes, and it is the same one that WSDM MUWS has avoided. In addition to the risk of more brittle systems, this approach creates somewhat of a barrier between manageability Web services and other Web services, even though integrating them is one of the explicit benefits of using Web services for management interactions.

The fact that the specifications have so much in common bodes well for the prospect of gradual alignment, and efforts to make this happen are taking shape, for example in DMTF. Many of these efforts are outside of the control of the DMTF though, since at the XML level most of the content of the different protocols comes from more general specifications, such as WS-Eventing and WS-Notification for events and WS-ResourceProperties and WS-Transfer for defining the messages used for retrieving the XML representation of resources. For these specifications too, the difference is often more in the realm of XML syntax than architecture, such that implementers of either stack should be able to think in terms of having to eventually support a new version of their stack of choice rather than a new stack if and when they rejoin. Once again, those who implement their protocols with versioning in mind will harvest the benefit of their design efforts.