The Web Services Distributed Management (WSDM) Standard

Date: Feb 3, 2006

Is WSDM just another management standard? Or a significant step in the direction of producing manageable web-based systems, software, and networks? Software consultant Stephen Morris looks at the various aspects of the argument.

What Is Manageability?

Some big players, such as IBM, are pushing the Web Services Distributed Management (WSDM) standard. [1] Others, such as Sun Microsystems, are holding back. Sun recently voted against WSDM becoming an OASIS standard, while IBM voted in favor of standardization—a large majority carried the vote.

Before we look in detail at what’s up with WSDM (pronounced wisdom), let’s briefly consider the problem it seeks to solve, namely the knotty issue of manageability. Surprisingly, manageability is a little like quality—concepts that we all know well, but difficult to describe! So let’s bring manageability down to earth by looking at how we all manage the software we use every day.

Email Management

When you use one of the standard email packages, such as Microsoft Outlook (technically known as a message delivery agent), the entities of interest are mostly email messages. You can also schedule appointments, make journal notes, and so on, but for this discussion let’s just consider email messages. You can typically expect to do most of the following in any given day:

Read messages in your inbox.
Ignore or delete irrelevant messages.
Reply to important messages.
Store messages you’ll need in the future.
Forward messages to other people.
Watch for (and carefully delete) unsolicited messages with suspicious attachments from strangers.

The words in bold type above represent actions. These are the ways in which you manage your email.

Big Brother, Email, and Manageability

None of us lives in a vacuum these days. Sometimes, organizational business policies (rules, in other words) can also have an impact on your email. For instance, if your inbox exceeds a certain size in megabytes, you may be prevented from sending mail until you clean up and reduce the space consumed. Likewise, if you become the unlucky user who inadvertently opens a virus-laden attachment that infects other machines, you can expect a visit from an irate system administrator. Figure 1 illustrates some of these important aspects of email management. The host organization in Figure 1 is called Enterprise X; email users in this organization employ an email package, and the normal management operations are listed on the right side of Figure 1.

Figure 1 Management actions for email.

User actions in Figure 1 are prompted by both normal daily use and IT rules and regulations.

The important point to remember about enterprise software in general is that once you use a machine that’s plugged into a LAN, you’re interacting—for better or worse—with a wider architecture. Your email messages consume resources:

Host (that is, your own machine) disk space
Server disk space
Network bandwidth
Your time
Other people’s time

Some companies even go so far as to assign a dollar amount to every email message. So we can begin to see the importance of conserving these precious resources.

Management of Other Software Packages

As discussed for the simple case of email, any package that consumes host and network resources must be managed. If you create a document and place it on a server, it’s important that that document not contain viruses. Once the file is stored on the server, it’s consuming remote resources (relative to your machine). That issue is underlined when other users access your file—even though this isn’t a big issue on bandwidth-rich LANs, it’s a real pain when you have to download a 20MB document over a dial-up link! The important point is that we live in a finite world where resources tend to be scarce, so all software, systems, and networks have to be carefully managed.

Many organizations adopt human-centered ad hoc measures to manage their IT infrastructure. Some aspects are automated—Windows updates, antivirus software updates, and so on—but overall the effort is largely driven by IT staff. It’s unlikely that this approach has a reasonable future; it’s no big surprise to see companies such as IBM putting their weight behind management-related initiatives such as autonomic computing and more recently WSDM.

Two things should now be clear: IT management is a big topic, and it’s mostly achieved by manual effort. Given that the news channels are indicating that cyberterrorism (attacking infrastructures such as power grids) is still only a remote possibility, it’s likely that the drive to automate IT is not yet pressing.

The Web Service Dimension: All the World’s a Service Provider

The advent of web services poses an even greater challenge to organizations desperately trying to stay on top of their IT infrastructures. Web services are the new kid on the IT block. They provide a model for organizations to allow web-based access to important software services. The scary part about web services from the viewpoint of IT managers is that they provide access to computational resources inside the firewall. This is a very different proposition from simply serving up HTML pages to remote users.

With web services, you allow users to consume potentially multiserver computational resources. You could argue that specialist firms such as web-based share traders (Ameritrade, for example) have been providing web services for years, but these applications tend to be narrowly focused on a specific core area, with new software rolled out in a carefully phased fashion. This is not to say that such organizations don’t provide excellent software and value for money. The point is that they’re providing an online version of a well-established offline business.

Because telecom service providers are generally used to selling their wares in a highly regulated environment, web services deployment may not be so difficult for such organizations, with their service-based heritage. However, corporations are generally unused to providing this type of service. In a sense, any organization deploying web services becomes a "service provider," with all the associated headaches—none greater than manageability, one of the primary concerns of all service providers. Organizations that are not service providers may no longer be able to ad hoc manage their resources in a web services world.

A management solution is more essential than ever before.

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.

Conclusion

We haven’t covered every nuance of WSDM in this article. That’s impossible, but I’m sure you’ll agree that we’ve seen enough to make the associated OASIS documents at least comprehensible in terms of the problem WSDM seeks to solve and the way in which the standard goes about solving it.

It’s too soon to say whether WSDM is just a solution looking for a problem—I don’t think so—or whether its foundation is not strong enough because it depends on other work in progress. I think it’s better to have a standard for web service management than to have nothing. The absence of a standard leads to proprietary management approaches, with the consequent problems of vendor lock-in and lack of interoperability—a problem that has bedeviled the telecom sector, where very often even different vendors’ IP routers can’t talk properly to one another. At least with a standard such as WSDM, there’s greater scope for interoperability between different vendors’ products. Maybe the standard has been informed by thinking along those lines? Let’s hope so.

WSDM has a pretty small footprint, so it’s possible that it may be used for managing a wide spectrum of entities: from small resource-constrained devices such as mobile phones and PDAs, to high-end elements such as operating systems and application servers. This might facilitate a simple management model that will allow for ease of implementation, deployment, and utilization.

References

[1] WSDM Standard (zip file).

[2] Network Management, MIBs and MPLS: Principles, Design and Implementation includes lots of information about the manageability of networking infrastructure.