What Is a Web Service?

A Web service is a business component that provides some useful facility to clients, or consumers. Just as Distributed Component Object Model (DCOM) is thought of as “COM with a longer wire,” a Web service can be thought of as a component with a truly global reach. Web services use a standard, accepted, and well-understood protocol called HTTP to transmit data, and a portable data format that is based on XML. HTTP and XML are both standardized technologies that can be used by other programming environments outside of the .NET Framework. So, you can build Web services by using Visual Studio 2005, and client applications (called consumers) that are running in a totally different environment, such as Java, can use them. The reverse is also true; you can build Web services by using Java, and write consumer applications in C#.

You can use several different languages with Visual Studio 2005 to build Web services. Currently, Microsoft Visual C++, Microsoft Visual C#, Microsoft Visual J#, and Microsoft Visual Basic .NET are supported, and it is likely that there will be others in the future. As far as the consumer is concerned, however, the language used by the Web service, and even how the Web service performs its tasks, is not important. The consumer's view of a Web service is of an interface that exposes a number of well-defined methods. All the consumer needs to do is call these methods by using the standard Internet protocols, passing parameters in an XML format and receiving responses also in an XML format.

One of the driving forces behind the .NET Framework and future releases of Windows is the concept of the “programmable Web.” The idea is that, in the future, systems will be constructed by using the data and services provided by multiple Web services. Web services provide the basic elements for systems, the Web provides the means to gain access to them, and developers glue them together in meaningful ways. Web services are a key integration technology for combining disparate systems together; they are the basis for many business-to-business (B2B) and business-to-consumer (B2C) applications.

The Role of SOAP

Simple Object Access Protocol (SOAP) is the protocol used by consumers for sending requests to, and receiving responses from, Web services.

SOAP is a lightweight protocol built on top of HTTP. It is possible to exchange SOAP messages over other protocols but, currently, only the HTTP bindings for SOAP have been defined. It defines an XML grammar for specifying the names of methods that a consumer wants to invoke on a Web service, for defining the parameters and return values, and for describing the types of parameters and return values. When a client calls a Web service, it must specify the method and parameters by using this XML grammar.

SOAP is an industry standard. Its function is to improve cross-platform interoperability. The strength of SOAP is its simplicity and also the fact that it is based on other industry standard technologies: HTTP and XML.

The SOAP specification defines a number of things. The most important are the following:

The format of a SOAP message
How data should be encoded
How to send messages (method calls)
How to process replies

For example, consider a Web service called ProductService.asmx (in the .NET Framework, URLs for Web services have the suffix .asmx) that exposes methods for accessing the Products table in the Northwind Traders database (you will build this Web service later in this chapter). One such method called HowMuchWillItCost allows a client to supply the name of a product and a quantity. The method queries the unit price in the database to calculate the total cost of buying the specified quantity of the product. The SOAP request sent by the client might look like this:

POST /NorthwindServices/Service.asmx HTTP/1.1
Host: localhost
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 579

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://
www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <HowMuchWillItCost
      xmlns="http://www.contentmaster.com/NorthwindServices">
      <productName>Chai</productName>
      <howMany>39</howMany>
    </HowMuchWillItCost>
  </soap12:Body>
</soap12:Envelope>

The request contains two parts: a header comprising everything up to the <soap12:Body> tag, and the actual body of the message in the <soap12:Body> tag. You can see how the body encodes parameters—in this example, the name of the product is Chai and the quantity is 39.

The Web server will receive this request, identify the Web service and method to run, run the method, obtain the results, and send them back to the client as a SOAP result, like this:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 546

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://
www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <HowMuchWillItCostResponse
      xmlns="http://www.contentmaster.com/NorthwindServices">
      <HowMuchWillItCostResult>529</HowMuchWillItCostResult>
    </HowMuchWillItCostResponse>
  </soap12:Body>
</soap12:Envelope>

The client can then extract the result from the body of this message and process it.

What Is the Web Services Description Language?

The body of a SOAP message is XML. The Web server expects the client to use a particular set of tags for encoding the parameters for the method. How does a client know which schema to use? The answer is that, when asked, a Web service is expected to supply a description of it-self. A client can submit a request to a Web service with the query string wsdl appended to it:

http://localhost/NorthwindServices/Service.asmx?wsdl

The Web service will reply with a description like this:

<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

      …
      targetNamespace="http://www.contentmaster.com/NorthwindServices"
      xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
  <wsdl:types>
    <s:schema elementFormDefault="qualified"
     targetNamespace="http://www.contentmaster.com/NorthwindServices">
      <s:element name="HowMuchWillItCost">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1"
                       name="productName" type="s:string" />
            <s:element minOccurs="1" maxOccurs="1"
                       name="howMany" type="s:int" />
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="HowMuchWillItCostResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="1" maxOccurs="1"
                       name="HowMuchWillItCostResult" type="s:decimal" />
          </s:sequence>
        </s:complexType>
      </s:element>
    </s:schema>
  </wsdl:types>
…
</wsdl:definitions>

This is known as the Web Service Description (a large chunk has been omitted to save space), and the schema used is called Web Services Description Language (WSDL). This description provides enough information to allow a client to construct a SOAP request in a format that the Web server should understand. The description looks complicated but, fortunately, Microsoft Visual Studio 2005 contains tools that can parse the WSDL for a Web service in a mechanical manner, and then use it to create a proxy object that a client can use to convert method calls into SOAP requests. You will do this later in this chapter. For now, you can concentrate on building a Web service.

Web Services Enhancements

Not long after Web services became a mainstream technology for integrating distributed services together, it became apparent that there were issues that SOAP and HTTP alone could not address. These issues include:

Security.How do you ensure that SOAP messages that flow between a Web service and a consumer have not been intercepted and changed on their way across the Internet? How can you be sure that a SOAP message has actually been sent by the consumer or Web service that claims to have sent it, and not some “spoof” site that is trying to fraudulently obtain information? How can you restrict access to a Web service to specific users? These are matters of message integrity, confidentiality, and authentication, and are fundamental concerns if you are building distributed applications that make use of the Internet.

In the early 1990s, a number of vendors supplying tools for building distributed systems formed an organization that later became known as the Organization for the Advancement of Structured Information Standards, or OASIS. As the short-comings of the early Web services infrastructure became apparent, members of OASIS pondered these problems and produced what became known as the WS-Security specification. The WS-Security specification describes how to secure the messages sent by Web services. Vendors that subscribe to WS-Security provide their own implementations that meet this specification, typically by using various encryption mechanisms and certificates.
Policy.
Although the WS-Security specification provides enhanced security, developers still need to write code to implement it. Web services created by different developers can often vary in how stringent the security mechanism they have elected to implement is. For example, a Web service might use only a relatively weak form of encryption which can easily be broken. A consumer sending highly confidential information to this Web service would probably insist on a higher level of security. This is one example of policy. Other examples include the quality of service and reliability of the Web service. A Web service could implement varying degrees of security, quality of service, and reliability, and charge the client application accordingly. The client application and the Web service can negotiate which level of service to use based on the requirements and cost. However, this negotiation requires that the client and the Web service have a common understanding of the policies available. The WS-Policy specification provides a general purpose model and corresponding syntax to describe and communicate the policies of a Web service.
Routing and addressing. It is useful for a Web server to be able to re-route a Web service request to one of a number of servers. For example, many scalable systems make use of load-balancing; requests sent to a server are actually redirected by that server to other computers to spread the load across those computers. The server can use any number of algorithms to try and balance the load. The important point is that this redirection is transparent to the client making the Web service request. Redirecting Web service requests is also useful if an administrator needs to shut down a computer to perform maintenance. Requests that would otherwise have been sent to this computer can be re-routed to one of its peers. The WS-Addressing specification describes a framework for routing Web service requests.

What does all this mean if you are developing Web services using Visual Studio 2005? Well, Microsoft provides its own implementation of the WS-Security, WS-Policy, and WS-Addressing specifications in its Web services Enhancements package (WSE). You can download this package free of charge from the Microsoft Web site, at http://msdn.microsoft.com/webservices/building/wse/default.aspx. When you install it, it integrates itself into the Visual Studio environment and adds additional project templates and assemblies that you can use. For Visual Studio 2005, you need to download WSE 3.0.

NOTE
None of the exercises in this chapter require you to install WSE 3.0.