Nailing Down .Net Web Services

This piece has been excerpted from a new O'Reilly book, "Programming .Net Web Services," available at www.oreilly.com/catalog/prognetws.

Developers looking to build .Net Web services need to first understand the different kinds of protocols to use to tie their applications together. There are three common protocols for accessing .Net Web services: HTTP GET, HTTP POST and SOAP. Each of these access methods uses HTTP as its underlying transport protocol. Although Web services can operate over just about any Internet protocol, HTTP is the preferred transport protocol for .Net Web services for at least four reasons:

1. HTTP is simple, consisting of a request and a response encoded in plain text. This simplicity makes HTTP a protocol that is easy to understand and, therefore, easy to implement.

2. HTTP is stateless. Once an HTTP message is sent, the connection between client and server is typically released. This approach helps to minimize usage of server resources, which, in turn, allows Web-services applications to scale more readily.

3. HTTP runs over port 80 by default, a well-known port that is open to public access on most firewalls for existing Web servers.

id
unit-1659132512259
type
Sponsored post

4. HTTP has gained common industry approval and, more important, has been put into use in Web servers all over the Internet. It is an ubiquitous Internet transport protocol.

HTTP does have its drawbacks, however, chief among them a lack of support for asynchronous messaging. Another limitation is it does not guarantee delivery of a message. HTTP does not support message-receipt confirmation and, as a result, does not provide any mechanism for retransmitting messages. This limitation is not a big deal for Web browsing,you may be annoyed if your page doesn't load properly, but you can always hit reload. But, depending on the nature of a Web service, this lack of guaranteed delivery can be a significant problem, such as in a banking application where you'd like transactions to reliably move around your network.

Web services communicate with their clients via XML-formatted messages. Simple Object Access Protocol (SOAP) is the messaging protocol of choice for Web services, mainly because, at its core, it can transfer information via XML formats. SOAP provides a much more tailored solution than HTTP GET and POST, but translating each Web method call to SOAP and then translating the results back to a native format is time-consuming and error-prone.

To insulate the developer from part of this process, various groups (including Microsoft) have released SOAP Software Developers Kits, which are sets of objects or scripts that automate much of the grunt work of sending and interpreting SOAP messages. For example, Microsoft's SOAP Toolkit 2.0 is an API and a set of tools for creating Web services using Visual Studio 6.0.

Comparing Protocols

So why is SOAP necessary for Web-services communications if the HTTP GET and POST methods do the trick by themselves? Although the HTTP GET and POST methods have been used in many applications for the past decade, both suffer from serious drawbacks when used without SOAP.

First, in an HTTP GET call, the request parameters are appended to the URL as a sequence of key/value pairs that are part of the query string. Information passed as part of the query string is restricted to a certain maximum length by both Web browsers and Web servers. For browsers, this limit varies depending on the browser and OS (Internet Explorer supports a maximum of 2,048 characters, whereas Netscape's limit is an operating-system-dependent number usually around the same). For Web servers, this value also varies, but is usually not more than 64 K or 128 K. This makes the HTTP GET request a poor candidate for use in Web-services systems that require the passing of large data sets. This restriction is also the primary reason HTTP GET is not commonly used as a transport for SOAP messages.

The HTTP POST method doesn't suffer from the same length limitations as GET; however, a POST request must pass its arguments as name/value pairs. This mechanism works well for passing simple data types associated with the elements on, say, an input form, but it was not designed to support complex data types.

You would think that a way around this limitation is to use XML to represent and format complex data structures. However, in order for the source and destination to be able to understand how to interpret the data, they must first agree on some rules related to its structure. There are also interoperability problems with using XML, such as state and transaction management, security and error management.

This is where SOAP comes in handy. SOAP is a protocol that codifies the process of sending XML documents over HTTP (or any other transport protocol for that matter). It also introduces rules that solve the problem of distributed method calls across heterogeneous systems, such as an XML vocabulary for parameters and return values and rules for exception handling. SOAP, alone, does not solve all of the problems listed earlier. But most developers agree that the SOAP specification constitutes a step in the right direction.

Two other reasons for choosing SOAP over HTTP are interoperability and security. While most non-Microsoft Web-services development tools support some version of SOAP, not all of them support HTTP GET or POST. Further, using HTTP GET for Web-services communication can result in security problems. This vulnerability occurs because Web browsers like Internet Explorer also use HTTP GET and POST for communication, and users could, therefore, be "tricked" into executing Web services by clicking a link on a site that has been set up by a malicious user.

Even with SOAP, you are still not out of the protocol woods completely: You have to manage the state of your application, add debugging and error-trapping, and provide for the security of your application and message structures. Still, SOAP will get you a long way toward your goal of programming .Net Web services.

------------------

Alex Ferrara is chief technology officer at U-Inspire, a provider of online business training and motivational services, and head of Boston Technical, a consulting arm of U-Inspire that specializes in .Net application development.

Matthew MacDonald is president of ProseTech, a software documentation consultancy, and a project manager at VoiceIQ, a provider of software for interactive voice-enabled applications and services.