There is an old saying among standards wonks: "The most wonderful thing about standards is that there are so many of them." And this truism is more applicable today than ever before. There are so many WS-* specifications, I've started referring to them as WS-Vertigo.

But there is a reason that there are so many of them. The Web Services Framework (WSF) relies on a composable architecture. One of the primary tenets of the WSF is to keep things as simple as possible. Therefore, if an application doesn't require security, reliability, or transactions, you shouldn't clutter up the infrastructure with these capabilities. But at the same time, if the application does require security, reliability, and/or transactions, then you should be able to add support for the specific set of capabilities you need.

Refactoring Specifications

In order to enable a pick-and-choose, plug-and-play infrastructure environment, the WSF architects approached the problem using refactoring techniques. Refactoring is a way of restructuring a software system to make it clearer, cleaner, simpler, and more elegant. The basic idea is that if you have two components within a system that do the same thing, you want to refactor the duplicate functionality into a separate component. (See Refactoring: Improving the Design of Existing Code by Martin Fowler, ISBN 0201485672, for more information on refactoring.)

The WSF architects have refactored infrastructure functionality into its most basic constituent parts, and as a result, there is a different specification for each bit of functionality. Figure 1 shows an overview of the WSF architecture, depicting a set of broad functional components. There are three categories of functionality: the core, the extensions, and management, represented by the colors blue, pink, and green, respectively. The core provides the foundation for the framework, the extensions provide pluggable infrastructure functionality, and the management components enable control of the environment. Figure 2 maps a number of WS-Vertigo specifications to each functional component.

Notice that many of the functional components support a variety of capabilities, and each capability requires a separate specification. For example, in the security component, there is a basic security framework (WS-Security), bindings for various types of security tokens (Username, X.509, SAML, REL, Kerberos, etc.), trust services for obtaining and exchanging tokens (WS-Trust), security session management (WS-SecureConversation), and security federation (WS-Federation). There are a bunch of other specifications related to security not listed in Figure 2 (such as SSL/TLS, XML Encryption, XML Signature, XKMS, XACML, etc.), but these other specification are general purpose specifications that apply to many different domains, not just to the WSF; so they aren't included in the WSF architecture. Nonetheless, the WSF security specifications often interact with or depend on these general-purpose security specifications, and unfortunately, at this stage in the game, a developer needs to be cognizant of most of them.

Also notice that in some cases, more than one specification addresses a particular capability. For example, there are three competing specifications for attachments:

• SOAP with Attachments (over MIME)
• WS-Attachments (over DIME)
• MTOM (over MIME)

The WS-I Basic Profile (BP) recommends using SOAP with Attachments (SwA), but unfortunately, .NET doesn't support SwA. Today, if you want to build interoperable Web services, you should use WS-Attachments. In the long run, the industry will switch over to MTOM, which is the attachment mechanism defined to work with SOAP 1.2, but currently very few products support either SOAP 1.2 or MTOM.

Other areas of contention include event notification (WS-Eventing versus WS-BaseNotification), reliable message delivery (WS-ReliableMessaging versus WS-Reliability), transaction management (WS-Transactions versus WS-Composite Application Framework), and service management (WS-Management versus WSDM).

To Be or Not to Be a Standard

Among all of the specifications that make up the WSF, only a handful of them are formal standards. In fact, the two most basic specifications in the WSF (SOAP 1.1 and WSDL 1.1) are not formal standards. Standardization is an important process because it involves analyzing, vetting, and testing the specification to ensure that it is consistent and that it can actually be implemented. The SOAP 1.1 and WSDL 1.1 specifications have not been through this vetting process, and it shows. These two specifications contain a number of inconsistencies, ambiguities, and errors, which have beenthe source of many interoperability issues.

The WSF specifications that have been standardized include:

• W3C SOAP v1.2
• W3C Message Transmission Optimization Mechanism (MTOM) 2005
• W3C XML Schema v1
• OASIS Universal Description, Discovery and Integration (UDDI) v2 and v3
• W3C XPath v1 and XSL Transformation (XSLT) v1
• OASIS Web Services Security (WS-Security) 2004
• OASIS Web Services Reliability (WS-Reliability) v1.1
• OASIS Web Services for Remote Portlets (WSRP) v1.0
• OASIS Web Services Distributed Management (WSDM) v1.0

Standardization doesn't necessarily imply industry acceptance and adoption, though. Support for some of these specifications is pervasive, including XML Schema, UDDI v2, XPath, and XSLT. Some of the newer specifications aren't yet pervasive, but they have strong industry support, and we should see wide deployments within the next year. These specifications include UDDI v3, WS-Security, WSRP, and WSDM. SOAP v1.2 and MTOM also have strong industry support, but it will probably take more than a year before we see them supplanting SOAP v1.1 and SwA or DIME. On the other hand, WS-Reliability has almost no industry support. Most vendors are implementing support for WS-ReliableMessaging (a non-standard alternative from IBM and Microsoft) instead.

So What's a Developer to Do?

The plethora of WSF specifications is enough to make a developer's head spin. But the average developer doesn't really need to concern herself with each and every specification. Instead, I recommend that developers stick with the basics and follow the guidelines defined in the WS-I profiles.

A WS-I profile is not yet another specification. A WS-I profile takes an existing specification and goes through it with a fine-toothed comb and finds any possible ambiguity - any place where the specification says MAY or SHOULD rather than MUST - or any place where some important behavior isn't completely specified, and it then constrains the specification and says, "Do it this way."

This type of profiling is particularly important when dealing with non-standardized specifications, such as SOAP 1.1 and WSDL 1.1, because these specifications have a lot of ambiguities. However it's also necessary with more formal standards, such as WS-Security, which offer a broad spectrum of options and choices, or with UDDI, which provides a basic registry, but doesn't define a standard model for registering services. The WS-I Basic Profile (BP) says register services this way. The WS-I Basic Security Profile (BSP) says secure your services using this constrained set of options.