Creating an ASP.NET Web Service

Transport Protocols and Bindings

The Securities Web service can be accessed by the client only over HTTP because HTTP is the only transport protocol supported by ASP.NET. However, by default the Securities Web service supports three styles of binding to the HTTP protocol: SOAP, HTTP GET, and HTTP POST.

All ASP.NET Web services support the SOAP binding. Of the three binding styles, SOAP is most often preferred because data contained within the messages is strongly typed using XML Schema. In addition, XML datatypes can be mapped fairly well to .NET datatypes.

Support for the HTTP GET/POST bindings is more limited than for SOAP. Some factors that limit the ability of the ASP.NET runtime to support the HTTP GET/POST bindings are the following:

• Required SOAP headers The HTTP GET/POST bindings do not provide a means of sending and receiving header information. If a Web service's WSDL document states that a header must always be included in a message exchanged between the client and the server, the message must be encoded using SOAP.

• Complex input parameters ASP.NET does not support encoding complex types encoded within the name/value pair on the query string or in the body of the HTTP request.

• Multiple parameters returned to the client Only the return parameter can be passed back to the client. ASP.NET does not support encoding in/out or out parameters within the message returned to the client as a result of an HTTP GET/POST request.

If the Web service exposes relatively simple interfaces, it can also be exposed via HTTP GET and HTTP POST. These bindings are simpler than SOAP, so they might make it easier for developers using less-sophisticated toolsets to interface with the Web service.

For example, it would be relatively straightforward to interface with the Securities Web service using the XML Document Object Model (DOM). To get the current price for Microsoft stock, you load the DOM with the results of the Web method call by passing http://localhost/Calculator.asmx/InstantQuote?symbol=MSFT to the load method. The DOM will be initialized with the following XML returned from the Web service:

  <?xml version="1.0" encoding="utf-8" ?>    <double xmlns="http://tempuri.org/">197.75</double>

Once the XML DOM has been initialized, you can navigate the DOM to obtain the value of the double element.

You can easily specify which protocol bindings your Web service will support. ASP.NET provides a flexible means of configuring Web applications via a hierarchical structure of XML configuration files. The machine-wide configuration file is located at C:\WINNT\Microsoft.NET\Framework\version\CONFIG\machine.config. The machine.config file contains the default configuration for all Web applications on the machine.

A web.config file, which you can optionally create within the root directory of the Web application, extends or overrides the configuration settings within machine.config. You can also place a web.config file within a subdirectory of the Web application to extend or override the configuration settings within the Web application's web.config file.

By default, the machine.config file is configured to support all three protocols. You can modify the machine.config or web.config file for the particular application to disable any one of the three bindings. For example, you can add the following webServices section to your web.config file to disable HTTP POST and HTTP GET:

<configuration>   <!-- Portions of the configuration file removed for clarity -->   <system.web>     <webServices>       <protocols>         <remove name="HttpPost"/>          <remove name="HttpGet"/>        </protocols>     </webServices>   </system.web> </configuration>

The protocols added to the machine.config file by default are HttpSoap, HttpPost, HttpGet, and Documentation. I discuss Documentation in the next section. Unfortunately, in this version of ASP.NET the supported protocols are not extensible.

Valid child elements for the protocols element are add, remove, and clear. The add and remove elements add and remove a particular protocol specified by the name attribute, respectively. The clear element clears all settings that are inherited from parent configuration files. For example, the following configuration file ensures that only HttpSoap and Documentation are supported, regardless of what was set in parent configuration files:

<configuration>   <!-- Portions of the configuration file removed for clarity -->   <system.web>     <webServices>       <protocols>         <clear/>         <add name="HttpSoap"/>          <add name="Documentation"/>        </protocols>     </webServices>   </system.web> </configuration>

First I clear any configuration settings that might have been set by a parent configuration file. Then I explicitly add HttpSoap and Documentation to the list of protocols supported by the Web service.