Web Services are moving toward the heart of today's complex applications. They've proven to be an efficient mechanism for bridging disparate and distributed systems, using point-to-point SOAP messaging with an easy-to-parse XML payload. Certainly, the past several years have demonstrated the efficiency, and ease of development, of Web Services-based applications. Now it's time to move to the next level, past the common request/response model messaging commonly found with SOAP and the original set of Web Services specifications to accommodate more complex message payloads, policies and routing mechanisms. For that, the recommended technology of choice within the .NET world is Microsoft's Web Services Enhancements, newly updated this summer.

(For information on how to acquire WSE 2.0, pronounced "wizzy," see the sidebar "Downloading Web Services Enhancements 2.0.")

The problem that WSE 2.0 addresses is that the core Web Services specs of SOAP as a messaging construct-- WSDL for determining the methods available for a SOAP-based remote procedure call, and XML for the payload--are constrained by that request/response model and by the need for authenticating users against enterprise access policies.

Within that model, one application (or part of an application) sends a request for an RPC to another system. That second system catches the request, processes the XML-based parameters and payload according to in the specific SOAP call, and returns the results via another SOAP message with an XML payload. That's great for simple, single-phased transactions, but doesn't scale to accommodate the more complex structures handled by messaging-queuing or other advanced infrastructures such as load balancing, multi-step transactions with rollback, or externally managed role-based authentication based on system policies.

WSE 2.0 builds on the core Web Services specs by adding Microsoft's implementation of additional open standards, such as Kerberos security and WS-Addressing. The new version of WSE also works with OASIS version of WS-Security—a change beyond the preliminary version of WS-Security at the foundation of WSE 1.0, which unfortunately creates a compatibility issue: SOAP messages constructed with WSE 1.0 don't work with WSE 2.0, and vice-versa. So you'll have to implement both stacks if interoperability is necessary. (Hint: Use two full qualified namespaces to handle references, such as Microsoft.Web.Services.SoapContext for 1.0, and Microsoft.Web.Services2.SoapContext for version 2.0.)

Let's look at what WSE does for authentication and security. Then we'll look at message addressing, and how WSE makes it easy to build complex, multi-stage Web services transactions.

Tokens and Policies
The cornerstone of WSE's security mechanism is defined by WS-Security's UsenameToken. This token is defined within the SOAP message header, and replaces the HTTP-based authentication mechanism used by standard Web Services. Remember, the version of WS-Security used by WSE 2.0 is defined by OASIS; this isn't a Microsoft-proprietary extension to Web Services.

In fact, as mentioned earlier, this is a change from the original implementation of WSE, which was released before OASIS had completed the spec. Because Microsoft is basing its work on industry standards, UsernameToken implementations should be interoperable with Web Services created by any other OASIS-compliant version of WS-Security.

What's the benefit of using UsernameToken over standard HTTP or HTTPS-based authentication? Well, for one thing, you may not want to use HTTP or HTTPS to convey your message. You may also want to use persistence stores or other mechanisms to work with the SOAP message, and they may not have direct access to the HTTP/HTTPS header. Having the authentication encapsulated within the SOAP header itself ensures that the authentication remains associated with the SOAP packet and its payload, no matter how the SOAP message is transmitted, routed, or stored.

An alternative to using the WS-Security UsernameToken is to use a Kerberos token. That's another improvement with WSE 2.0: native support for Kerberos. The Web service application (presumably a client) can pick up and transmit the Kerberos token directly, meaning that the operating system—and not your application—can take responsibility for the user credentials. One way to realize that benefit is to leverage Active Directory, which natively uses Kerberos, and let a security policy handle all the security plumbing.

Security policies are a major focus of WSE 2.0. A policy is implemented as an XML file, which is automatically generated by a wizard by the WSE plug-in to Visual Studio. (You can edit the policy, if you'd like to customize it beyond what the wizard produces.) The policy file specifies mappings between specific policy rules (such as "only allow this incoming message to be processed if the user is a member of the Administrators group") and different methods of the Web service application. The policy mechanism defined by WSE ensures that the appropriate security tokens—that is, either a WS-Security UsernameToken or a Kerberos token—are attached to the message.

Let a policy handle the job for you—that's a lot easier than programming all those low-level security details yourself.

Moving Beyond Request/Respond
In the old days—well, the era of WSE 1.0 and the WS-Routing specification—developers had to worry about how SOAP messages got from Point A to Point B. That's, like, so five minutes ago! Applications built to those earlier specifications were brittle not only to changes in network and server implementation, but also to jitter and delay. That's because unless the developer home-brewed a complex routing mechanism that could discover alternative paths, or installed a separate Web Services routing server, there was no flexibility.

WSE 2.0 makes the developer's life much simpler, because the new basis of message routing, the WS-Addressing specification, does away with predefined message paths. Instead, the SOAP header contains simple clauses like To and From, as well as ReplyTo and FaultTo to use in case the response shouldn't go to the original requestor.

Where the extra flexibility comes in is that the To, From, ReplyTo and FaultTo fields can be either uniform resource indicators (URIs) or endpoint references. An endpoint reference is a more flexible construct that can include policies and rules for determining the end URI. That allows the recipient of a Web service request to be determined either programmatically, by the developer, or by policies set by administrators. You can imagine systems where such as multi-stage transactions would be enabled and managed by setting the appropriate policies in Web Services endpoint references.

Helping you develop multi-stage transactions is another type of field available in the WS-Addressing header: RelatesTo. This new field can be used to allow members in a Web Services engagement—either requesters or responders—to deliver a complex chain of messages between two, three, or more services by positively indicating that they're part of the same thread. By using the RelatesTo field carefully, developers can design systems where messages are processed either synchronously or asynchronously, an important option when dealing with applications that might involve message queuing, off-line participants or manual intervention.

In other words, with the power of WS-Addressing, and in particular the RelatesTo field, Web Services have grown up.

Advanced Web Services
Web Services have come a long way over the past few years, from a lightweight construct capable of simple point-to-point messaging, to today's toolkit for building complex and secure transaction systems and widely distributed applications. New specifications like WS-Security and WS-Addressing are making Web Services more scalable and interoperable than ever before; Microsoft's Web Services Enhancements 2.0 is making them easy to develop.

For a code-centric view of WSE 2.0, see "Programming with Web Services Enhancements 2.0" or Microsoft's Web Services Developer Center.

ISVs can get an intense one-day technical dive into WSE 2.0 and its use in the Microsoft roadshow, "Learn to Build .NET Connected Apps for Service Oriented Architecture (SOA)," taking place in two dozen U.S. cities through October.