As we've discussed in the previous installments of this article series, Web services are comprised of a number of core standards, including:
- XML - XML serves as a universal data format, and is the means by which data passed to and from a Web service is encoded. XML was the chosen data format because of its platform-neutrality and expressiveness.
- SOAP - SOAP is a standard that defines how to exchange structured information in a distributed environment. The messages sent to and from a Web service are formatted according to the SOAP specification.
- WSDL - WSDL is an XML-formatted description language used to formally describe a Web service's interface in a machine-readable format. When creating a client to consume a Web service, we first create a proxy class, which can be autogenerated with information from the Web service's WSDL contract. These core standards spell out how to accomplish the simple, required tasks inherent to all Web services: how to format data, how to encode the messages sent between client and Web service, and how to formally define a Web service's functionality. What these core standards don't provide, however, is a means for accomplishing common business tasks with Web services. Developers can create their own techniques for accomplishing any complex tasks built on top of the core standards, but ideally there would be a standardized technique for accomplishing common tasks. Fortunately, there are a number of standards being drafted by industry titans on how to accomplish a variety of common business tasks. These extended standards, dubbed by Microsoft as the Web Service Enhancements (WSE), spell out standardized techniques for things like authentication, encryption, sending binary attachments, routing SOAP messages among intermediaries, establishing trust between a Web service and a Web service client, and many more. Additionally, at TechEd 2004, Microsoft officially released the WSE Toolkit 2.0, a set of classes for the .NET Framework that make working with the WSE standards a breeze. In this article we'll take a high-level look at the WSE standards and the format of SOAP messages that utilize these extended standards. We'll then take a sneak peek at the WSE Toolkit 2.0, and see how the WSE Toolkit simplifies working with these standards. In the next installment of this article series, Part 6 that SOAP headers are an optional component of a SOAP message that are present for sending along metadata with the SOAP request or response.) If we wanted to send the username and password in the SOAP headers we could create an appropriate class on the Web service side. In fact, in            xmlns:xsd="http://www.w3.org/2001/XMLSchema"            xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">     <soap:Header>       <AuthHeader>       <Username>username</Username>      <Password>password</Password>     </AuthHeader>    </soap:Header>    <soap:Body>     <WebServiceMethodName xmlns="Web Service Namespace" />    </soap:Body> </soap:Envelope> While this approach works, the main disadvantage is that the technique is not standardized. That is, another Web service provider might want to also enable authentication, but might decide to use a SOAP header named <LoginInfo> rather than <AuthHeader>, or might decide to use property names Login and Pwd rather than Username and Password. Since each Web service provider might implement authentication using different techniques, each client must be customized to handle the Web service provider(s) specific authentication technique. If a standardized technique for authentication is used, however, all clients can use the same code base for authenticating themselves with Web service provides that implement the standard. Furthermore, introducing standards enables vendors like Microsoft to add support for the standards in the tools we developers use, thereby making utilizing the standards that much easier. An Overview of the Web Service Standards The Web Service Enhancements aim to define standardized techniques for implementing many common business needs not addressed by the core standards. The WSE standards begin as drafts coauthored by a variety of industry leaders. For example, the OASIS. There are an array of proposed WSE standards, broken down into various categories. Some of the more mature WSE standards include:
- WS-Security (an OASIS standard as of April 2004) - UsernameToken Authentication - specifies a standard for passing username/password tokens for the purpose of authentication. - XML Encryption - defines a standard for encrypting the contents of a SOAP message. - XML Digital Signatures - defines a means for digitally signing a SOAP message. A digital signature ensures that the contents of the SOAP message have not been altered in transit. - WS-SecureConversation - provides a technique for a Web service and a client to have an encrypted message exchange. - WS-Trust - defines how to establish trust between disparate actors involved in a Web service interaction.
- DIME and WS-Attachments - specifies a technique for attaching large amounts of binary data outside of the SOAP envelope. Useful for sending large documents to or from a Web service, such as images, PDFs, or other large files.
- WS-Addressing - defines a standard for encapsulating addressing information within the SOAP message. WS-Addressing adds information such as the Web service endpoint, the client's endpoint, the method to invoke, and other such information, in the headers of the SOAP message, as opposed to having it out of band in the HTTP headers.
- WS-Eventing - specifies a standard for Web services to send an event notification message to clients who have subscribed. All of the WSE standards work in roughly the same way - by adding a predefined set of headers to the SOAP envelope. For example, the standards under the WS-Security umbrella are implemented with the addition of a <Security> SOAP header. The UsernameToken authentication standard adds a <UsernameToken> XML element under the <Security> SOAP header, with children elements <Username> and <Password>, as shown below:
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
          
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Header>
   
<wsse:Security soap:mustUnderstand="1">
    
<wsse:UsernameToken namespaces>
     
<wsse:Username>username</wsse:Username>
     
<wsse:Password Type="type info">password</wsse:Password>
     
<wsse:Nonce>nonce</wsse:Nonce>
     
<wsu:Created>date created</wsu:Created>
    
</wsse:UsernameToken>
   
<wsse:Security> </soap:Header>
   <soap:Body>
   
<WebServiceMethodName xmlns="Web Service Namespace" />
   </soap:Body>
</soap:Envelope>
We'll discuss the specifics of UsernameToken authentication in http://msdn.microsoft.com/webservices/building/wse/.
The WSE Toolkit provides an assembly with a set of classes that can be used to programmatically work with the WSE standards. From a developer's standpoint, you will need to only work with the appropriate classes in the WSE Toolkit, and not concern yourself with crafting the SOAP message and its intricate headers. For example, for a client to authenticate itself with a Web service that uses UsernameToken authentication, a .NET client using the WSE Toolkit can simply create an instance of the UsernameToken class, set the Username and Password properties, and then add the token to the proxy class's Security object's Tokens collection.
Under the covers, the WSE Toolkit works using SOAP Extensions, which we discussed in Part 9) in this series we'll see how to install the WSE Toolkit 2.0, as well as how to use the WSE Toolkit to implement UsernameToken authentication. Until then, Happy Programming!
4GuysFromRolla.com, has been working with Microsoft Web technologies for the past five years. An active member in the ASP and ASP.NET community, Scott is passionate about ASP and ASP.NET and enjoys helping others learn more about these exciting technologies. For more on the DataGrid, DataList, and Repeater controls, check out Scott's book ASP.NET Data Web Controls Kick Start (ISBN: 0672325012). Read his blog at : http://scottonwriting.net
No comments yet. Be the first to comment!