Section 15.2. Protocols and Standards

15.2. Protocols and Standards

Various protocols are mentioned throughout this chapter and the next . While going into detail about the various protocols is beyond the scope of this book and also not necessary for an understanding of how web services work, a general overview will help with understanding the web services architecture.

A protocol is a set of rules that describe the transmission and receipt of data between two or more computing devices. For example, Transmission Control Protocol/Internet Protocol (TCP/IP) governs the low-level transport of packets of data on the Internet.

15.2.1. HTTP

Layered on top of TCP/IP is the Hypertext Transfer Protocol (HTTP), which is used to enable servers and browsers on the Web to communicate. It is primarily used to establish connections between servers and browsers and to transmit HTML to the client browser.

The client sends an HTTP request to the server, which then processes the request. The server typically returns HTML pages to be rendered by the client browser although, in the case of web services, the server may instead return a SOAP message containing the returned data of the web service method call.

HTTP requests pass name /value pairs from the requesting browser to a server. The request can be of two types: HTTP-GET, or HTTP-POST.

15.2.1.1. HTTP-GET

In GET requests, the name/value pairs are appended directly to the URL. The data is uuencoded (which guarantees that only legal ASCII characters are passed over the wire) and then appended to the URL, separated from the URL by a question mark.

For example, consider the following URL:

 http://localhost/StockTicker/Service.asmx/GetName?StockSymbol=msft 

The question mark indicates that this is an HTTP-GET request, the name of the variable passed to the GetName method is StockSymbol , and the value is msft .

GET requests are suitable when all the data that needs to be passed can be handled by name/value pairs, there are few fields to pass, and the length of the fields is relatively short. GET requests are also suitable when security is not an issue. This last point arises because the URL is sent over the wire and is included in server logs as plain text. As such, they can be easily captured by a network sniffer or an unscrupulous person.

The .NET Framework provides a class, HttpGetClientProtocol (shown in Figure 15-4), for using the HTTP-GET protocol in your clients .

Figure 15-4. WebClientProtocol hierarchy

15.2.1.2. HTTP-POST

In POST requests, the name/value pairs are also uuencoded, but instead of being appended to the URL, they are sent as part of the request message.

POST requests are suitable for large numbers of fields or when lengthy parameters need to be passed. If security is an issue, a POST request is safer than a GET request since the HTTP request can be encrypted.

As with GET requests, with POST requests only name/value pairs can be passed. This precludes passing complex data types (such as classes, structs, or datasets).

The .NET Framework provides a class, HttpPostClientProtocol (see Figure 15-4), for using the HTTP-POST protocol in your clients.

15.2.2. XML

eXtensible Markup Language (XML) is an open standard promulgated by the World Wide Web Consortium (W3C) as a means of describing data. (For more information visit www.w3c.org.) The latest version of the XML protocol is Version 1.1, recommended by the W3C in February 2004. However, the version of XML currently in widespread use, including in VS2005, is Version 1.0.

XML is similar to HTML. In fact, both XML and HTML are derived from Standard Generalized Markup Language (SGML) . Like HTML documents, XML documents are plain-text documents containing elements. However, though HTML uses predefined elements that specify how the HTML document will display in a browser, only XML allows elements to be defined by the document developer, so that virtually any data can be conveyed.

XML documents are human-readable text files. However, they typically are not meant to be read by humans , except developers doing programming and debugging. Most often XML documents are "read" by programs, and .NET provides extensive support for creating and reading XML.

XML documents are generally much larger than binary files containing the same data, but binary files must use proprietary encoding; the point of XML is to be a platform-neutral and language-neutral standard. In any case, file size , per se, is rarely an issue since the difference in transmission time over the Internet is usually negligible at today's speeds, especially when data compression is taken into account.

An XML schema is a file used to define the elements and how they relate to one another within a given XML document or set of documents. In the schema, both the element names and content types are specified.

One significant difference between HTML and XML: Most HTML readers (web browsers) are tolerant of coding errors; XML readers are not. XML must be well- formed . (For a complete discussion of well-formed XML markup, see the XHTML sidebar in Chapter 3.) For example, though browsers generally do not care if elements are uppercase or lowercase, in XML they must be lowercase or an error will be generated.

15.2.3. SOAP

Simple Object Access Protocol (SOAP) is an XML grammar that's tailored for exchanging web service data. In a .NET web service, you'll usually send SOAP messages over HTTP. SOAP is a simple, lightweight protocol for the exchange of information over the Internet. Like XML, the SOAP standard is promulgated by the W3C.

A SOAP message consists of the message content, plus one or more header blocks, all wrapped within the so-called SOAP envelope. The SoapEnvelope class derives from the System.Xml.XmlDocument class, so all the functionality provided by the .NET Framework for dealing with XML applies to SOAP.

SOAP uses XML syntax to format its content. It is, by design, as simple as possible and provides a minimum of functionality. Therefore, it is modular and flexible. Since SOAP messages consist of XML, which is plain text, they can easily pass through firewalls , unlike many proprietary, binary formats. At the time of this writing, the latest SOAP version is 1.2 (recommended by the W3C in June 2003). The SOAP protocol was originally developed by Compaq, HP, IBM, Lotus, Microsoft, and others.

SOAP is not limited to name/value pairs as HTTP-GET and HTTP-POST are. Instead, SOAP can be used to send more complex objects, including datasets , classes, and other objects.

One drawback to using SOAP to pass requests back and forth to web services is that SOAP messages tend to be verbose because of the nature of XML. Therefore, if bandwidth or transmission performance is an issue, you may be better off using HTTP-GET or HTTP-POST.

The .NET Framework provides a class, SoapHttpClientProtocol (see Figure 15-4) for using the SOAP protocol in your clients.

15.2.4. Web Services Enhancements (WSE)

Several firms, such as Microsoft, IBM, Intel, Oracle, Hewlett Packard, and others, have been collaborating and formulating platform-independent specifications aimed toward a more flexible, interoperable, and secure web service infrastructure. These specifications are collectively referred to as WS-* .

For example, WS-I, the Web Services Interoperability Organization (www.ws-i.org) promotes interoperability. It promulgates a Basic Profile (of which 1.1 is the current version as of the initial release of VS2005), which provides guidance on interoperability issues related to SOAP, WSDL, messaging, and serialization.

A partial list of other frameworks recommended for use with web services includes the following:

• WS-Policy (http://schemas.xmlsoap.org/ws/2004/09/policy/)

• WS-ReliableMessaging (http://schemas.xmlsoap.org/ws/2004/09/policy/)

• WS-Addressing (http://xml.coverpages.org/ni2004-08-10-a.html)

• WS-Security (http://www-106.ibm.com/developerworks/ webservices /library/ws-secure/)

As industry-wide initiatives, the timing of WS-* specifications may not correspond to Microsoft's product release schedule. Though Microsoft's stated intent is to conform to these industry-wide specifications, it could not tie the release of products or versions of products, such as VS2005, to WS-* release schedules. Therefore, it created Web Services Enhancements . WSE is a framework of classes and functionality that can be layered on top of Visual Studio to provide compliance with WS-*.

Prior to the release of VS2005, WSE was a separate download that could be installed alongside Visual Studio. Initially there was WSE 1.0, which was superseded by WSE 2.0. ASP.NET Version 2.0 and VS2005 incorporate WSE 3.0 directly.

You will see evidence of WSE 3.0, for example, in the new properties ConformsTo and EmitConformanceClaims of the WebServiceBinding attribute (described in this chapter). This attribute, along with these two properties, is inserted by default when VS2005 is used to create a new web service.