Protocols

Protocols define how communication between systems takes place. ASP.NET supports three default protocols “ HTTP-GET, HTTP-POST, and SOAP “ but can be extended to support others.

The first two protocols, HTTP-GET and HTTP-POST, are implemented primarily as helper protocols, and for backward-compatibility, accepting parameters through GET or POST mechanisms, and returning an XML document. We will use these protocols to test web services and to provide a mechanism for existing ASP applications to build and immediately use ASP.NET technologies.

ASP.NET supports this exact same behavior, but in a more robust manner. If you're used to authoring ASP applications that emit XML, this should be a simple transition. However, for communication between applications, SOAP is the default protocol, and thus is the protocol that you need to be most familiar with. SOAP combines XML and HTTP to provide a simple but powerful mechanism, which allows developers to build applications that can communicate using strongly typed XML documents.

HTTP-GET

The implementation of the HTTP-GET protocol is the one that you see most often when building an ASP.NET Web service. That's because HTTP-GET is the protocol used in the page generated by DefaultWsdlHelpGenerator.aspx .

For example, when we built the Fibonacci Web service, viewed it through the browser, and called the method, the result received was a simple XML document as shown in Figure 19-6:

Figure 19-6:

However, this document has nothing to do with SOAP. Instead, parameters are passed on the query string in the form GetSeqNumber?fibIndex=6 . You can also modify the query string directly, and get different results.

Our web service help page only supports HTTP-GET (the default) and HTTP-POST. The reason for this is that a simple HTML form POST / GET mechanism cannot support the POST format used by SOAP. SOAP requires the body of the POST to be an XML SOAP document. However, an HTML form POST will attempt to send a name /value pair, which cannot be used to generate a valid XML document in the POST body.

HTTP-POST

The output from HTTP-POST is similar to HTTP-GET. The only difference is how HTTP-POST is input “ that is, how the data is sent to the endpoint. Rather than passing data in the query string, the data is posted as name/value pairs within the body of the HTTP request. You'd expect the result to be an XML document identical to the one we got through the HTTP-GET request earlier.

To use HTTP-POST in your web service description Help page, and have it provide an HTML form similar to that created for HTTP-GET, you can modify DefaultWsdlHelpPage.aspx by setting the showPost flag to true .

SOAP

We won't cover SOAP in great detail. Firstly because there are other great resources (such as the specification at http://www.w3 org/TR/soap12-part1/) for learning about SOAP, and secondly because it's a protocol and this chapter is about building solutions. To learn more about SOAP, you'll find some useful resources listed at the end of the chapter.

The W3C has officially created the XML Protocol Activity using SOAP 1.1, and updated it to SOAP 1.2. The XML Protocol Group has four deliverables:

• Protocol envelope

• Mechanism for serializing abstract data models

• Convention for use with RPC

• Binding to HTTP

Several companies have developed solutions using the SOAP 1.1 and 1.2 specifications, including Microsoft .NET, Microsoft Soap Toolkit Version 2, and the Apache Soap Toolkit (from IBM). The Microsoft Soap Toolkit v1 was intended to be an SDK. Version 2 is a supported solution, but with the availability of .NET you would be wise to use ASP.NET.

Implementation Details

A SOAP protocol message contains four parts :

• An envelope

• Encoding rules

• RPC representation

• Protocol bindings

The implementation of SOAP in ASP.NET uses HTTP as a transport, and thus is two-way “ you send a message and receive a response. This is a design feature of HTTP and not of SOAP.

The SOAP envelope is the basic unit of exchange between the listener and sender of the SOAP message. Envelopes can be nested, in which case the outer envelope is considered to be active to the receiving SOAP end-point.

Headers are one of the extensibility mechanisms of SOAP, and are used to pass additional information about the envelope, or data that pertains to the particular protocol exchange. A good example of using SOAP headers is for authentication. For example, rather than passing an identification token as part of the envelope, which would assume the token was part of a method in ASP.NET, the token can be passed as part of the header. You'll learn more about SOAP later in this chapter, and in Chapter 20 you'll see how you can use the header to pass authentication information, which can then be used to verify credentials and authorize actions. You've seen the supported protocols for web services, now let's look at the supported data types.