18.1. Introduction to Web Services

The Web Service architecture is a service-oriented architecture that enables applications to be distributed across a network or the Internet to clients using any language or operating system. As shown in Figure 18-1, Web Service communications are implemented using existing technology and standards that require no proprietary vendor support. This technology either formed the basis of the Internet or evolved from it. HTTP and XML have been discussed in earlier chapters, but let's take a brief look at them—from a Web Services perspective—along with TCP/IP and SOAP:

• TCP/IP (Transmission Control Protocol/Internet Protocol). A communications protocol suite that forms the basis of the Internet. It's an open system that governs the flow of data between computers by breaking data into chunks that are easily routed over a network. A Web Service user or developer rarely has direct contact with this layer.

• HTTP (Hypertext Transfer Protocol). Technically, this text-based protocol is a Remote Procedure Call (RPC) protocol that supports request/response communications. The .NET Framework as well as most production Web Services use it because it has wide support and generally allows information to sail unimpeded through firewalls. Both the HTTP POST and HTTP GET methods are supported in .NET as a way to call a Web Service. Most applications use POST, because it packages the request inside the request body (in a SOAP envelope), rather than as part of a less secure query string.

  Core Note

  The rules that describe how a message is carried within or on top of a protocol is referred to as a binding. The default protocol binding used by .NET for Web Services is HttpSoap, which should be used to access Web Services that understand SOAP. It is specified inside the System.Web section of the machine.config file.

  
  

• XML (Extended Markup Language). We have seen in earlier chapters how data can be serialized into XML format for storage or transmission. The fact that it is text based makes it easy to work with. Just about every programming environment supports tools for encoding and decoding XML formatted data. Its inherent flexibility, extensibility, and validity checking make it attractive to Web Services that must deal with simple data types such as strings, as well as more complex data structures. There are currently two XML-based protocols used for delivering Web Services: XML-RPC and SOAP. Because .NET supports SOAP, this chapter focuses on it. After you understand SOAP, you should have no difficulty with XML-RPC if you encounter it.

• SOAP (Simple Object Access Protocol). SOAP is defined as "a lightweight protocol for exchange of information in a decentralized, distributed environment."^[1] It is not designed specifically for Web Services, nor restricted to HTTP; but its RPC specifications define a model for invoking methods on a specified target machine, passing parameters, handling faults, and receiving a method response. We will look at SOAP in detail later in the chapter. For now, keep in mind that the details of XML and SOAP are typically handled transparently by .NET. The provider code only needs to focus on implementing the method that returns the desired data; the requestor code simply places a method call and processes the returned data.

  ^[1] Simple Object Access Protocol (SOAP) 1.1—W3C Note, May 8, 2000.

Discovering and Using a Web Service

To use a Web Service, a client must have a description of how to access the service. This information is provided by a Web Services Description Language (WSDL) document that provides the name of the service, the signature of the method(s) that can be called, the address of the service (usually a URL), and binding information that describes how the transport operation will occur. In practical terms, the WSDL information contains the methods that actually call a Web Service. We implement these methods in our client code (as source or a DLL reference) and use them as a proxy to access the service. Section 18.2, "Building an XML Web Service," provides a concrete example of using .NET to retrieve WSDL information and incorporate it into a client application.

Introduction to UDDI

Web sites are identified by a domain name and IP address that are maintained by a distributed network service known as the Domain Name System (DNS). Servers in this network are responsible for controlling e-mail delivery and translating domain names into IP addresses. The combination of DNS and Web search engines enables users to quickly locate Web content. However, neither DNS servers nor search engines provide a formal way of identifying Web Services.

To organize Web Services into a publicly searchable directory, a public consortium (www.uddi.com) comprising hundreds of companies has defined a standard known as Universal Description Discovery and Integration (UDDI). This standard defines a SOAP-based interface that can be used to publish a service or inquire about services in a UDDI-compliant registry. The registry has a business-to-business flavor about it—containing information about a company, its services, and interface specifications for any Web Services it offers. Importantly, there is no single UDDI registry. IBM, SAP, and Microsoft maintain the most prominent registries. Users may query each separately by entering a business name or service as a search term. Figure 18-2 provides an overview of the inquiry process.

The dialog between the client and UDDI registry server is conducted using SOAP messages. Overall, UDDI defines approximately 40 SOAP messages for inquiry and publishing.

UDDI Discovery Example

To demonstrate how to use UDDI, w'e'll look at the SOAP messages sent between client and server as we seek to discover a Web Service that can provide a stock quote. A Web-based UDDI browser (described shortly) sends and receives the messages.

Step 1: Send Discovery Request

For our example, we'll search the UDDI registry provided by Microsoft:

http://uddi.microsoft.com/inquire

An inquiry may request business information or tModel information. The former contains information about a business, including contact information and a description of services. The tModel structure is much simpler: It consists of a unique key, optional description, and a URL or pointer to a Web page where information for using the service is described. The following message requests a list of tModel keys for companies whose service includes providing a stock quote.

<Envelope>

   <Body>

      <find_tModel generic="1.0" maxRows="100">

         <findQualifiers/>

         <name>stock quote</name>

      </find_tModel>

   </Body>

</Envelope>

Step 2: Registry Service Responds with List of Services Matching Request

A list of tModel keys is returned. These keys are used for the subsequent query:

<soap:Envelope>

  <soap:Body>

    <tModelList generic="1.0" operator="Microsoft Corporation" >

      <tModelInfos>

        <tModelInfo

          tModelKey="uuid:7aa6f610-5e3c-11d7-bece-000629dc0a53">

          <name>Stock Quote</name>

        </tModelInfo>

        <tModelInfo

          tModelKey="uuid:265973ab-31cb-4890-83e0-34d9c1b385e5">

          <name>Stock Quotes and Information</name>

        </tModelInfo>

      </tModelInfos>

    </tModelList>

  </soap:Body>

</soap:Envelope>

Step 3: Retrieve Overview Document Containing WSDL

Send a request for tModel details for the service with the specified tModelKey:

<Envelope>

   <Body>

      <get_tModelDetail generic="1.0">

         <tModelKey>uuid:7aa6f610-5e3c-11d7-bece-000629dc0a53

         </tModelKey>

      </get_tModelDetail>

   </Body>

</Envelope>

The response message includes the OverviewURL element that points to a WSDL document. This document contains the information needed to create an application to access the service.

<overviewDoc>

   <description xml:lang="en">

      Get Stock quote for a company symbol

   </description>

   <overviewURL>

      http://www.webservicex.net/stockquote.asmx?WSDL

   </overviewURL>

</overviewDoc>

You can display the WSDL by pointing your browser to this URL. To invoke the Web Service, remove the query string (?WSDL) from the URL, and navigate to it with your browser.

How to Communicate with a UDDI Service Registry

To interact with a UDDI registry—whether to publish or inquire—you need a way to generate SOAP requests and interpret responses. One option is to write your own application using the Microsoft UDDI 2.0 SDK. It contains excellent C# examples that demonstrate the API and can be run against a test UDDI registry hosted by Microsoft.

For making registry inquires, Web-based UDDI browsers are available. A publicly available one—as well as a wealth of accompanying UDDI information—can be found at

http://www.soapclient.com/UDDISearch.html