WSDM: A Manageability Solution?
WSDM is a set of two standards, geared to providing management infrastructure in web services. The basic idea is simple:
- WSDM allows for equipping web services with management facilities.
- Management systems then use the management facilities.
Figure 2 illustrates the approach taken in the WSDM standard:
- The web service is equipped with a WSDM-compliant management interface.
- The manageability consumer (MC) then uses this interface to interact with the web service.
- The MC sends requests for information (reads) or configuration updates (writes).
- The MC receives responses to requests as well as events (significant occurrences).
)
Figure 2 Conceptual layout for WSDM.
Obviously, this approach is pretty much old hat to anyone involved with IT management. The OASIS standard seems to suggest that these are new ideas, but telecoms have wrestled with them for decades.
One of the problems with making WSDM a standard is that to make it real requires a wide range of underlying technologies. Let’s take a look at the rich palette of ingredients in WSDM.
WSDM: The Main Elements
WSDM provides a framework for web service management. It consists of two parts: Management Using Web Services (MUWS) and Management of Web Services (MoWS). As standards documents go, these are actually quite readable, so if you want to dive in you won’t disappear forever! Some of the terminology used in WSDM is a tad unwieldy, though:
- Manageability consumer. The management application (or manager) on the left side of Figure 2.
- Manageability web service endpoint. The bubble in the center of Figure 2.
- Manageability capabilities. The management attributes of the web service of interest.
- Composeability. The ability to join unrelated management capabilities for some purpose; for instance, representing a service end to end.
These terms are fairly easy to understand when you think about them. So what are the controversial dependencies that underpin WSDM?
WSDM Dependencies
The following elements can be seen as the foundations of WSDM. Some of them have become standards, while others represent work in progress.
- WS architecture
- XML
- XML namespaces
- XML schema
- SOAP
- WSDL
- WS-Addressing
- WS-Resource Properties
- WS-Base Notification
- WS-Topics
- XML Path Language
To my knowledge, all of the above are in widespread use in the industry, even if they’re still in the process of standardization.
So What’s the Big Deal Down at OASIS?
OASIS recently voted strongly in favor of making WSDM a standard. There were some interesting dissenters, such as Sun, who felt that the standard relies on other specifications that are not yet full standards. The fear is that the foundations are not yet strong enough to support the structure if we press ahead with WSDM standardization. Also, implementations might turn out to be incompatible as the underlying elements are eventually standardized. These are real concerns. Let’s look briefly at the way an older standard, SNMP, fared in earlier times. [2]
SNMP is a long-established IETF standard that has gone through at least three major revisions. (SNMPv3 is the most recent.) In tandem, vendors have been able to define manageability attributes for their products in the form of management information bases (MIBs). The addition of MIBs to vendor products has helped add value to those same products, by making them compatible with an international standard. This helped give rise to a kind of three-tier market:
- Product vendors (IP routers, switches, database engines, etc.)
- Network management system product vendors (such as HP OpenView)
- SNMP instrumentation vendors (for example, the pSOS embedded operating system)
There have been problems with SNMP, but this amazingly long-lived technology has found its way into a wide range of products from network hubs all the way up to commercial database engines (such as Informix). Only time will tell if WSDM will follow a similar path to that of SNMP.