Exposing Web Services

Web Services, in theory, aren't a new concept. They allow distributed applications to share business logic over a network. For example, the classic Web Service scenario is a stock quote service: one company provides a service that can accept requests for stock symbols and respond with stock quote details.

A company building an investing site can then use the application logic provided by the stock quote company to retrieve stock quote detail. This problem sounds relatively simple, but it has been quite difficult to solve in the past. That's due largely to proprietary protocol formats, such as RMI, and the lock-down of open ports to only port 80 and port 443 (for HTTP and HTTPS traffic only).

However, what is new is the use of XML and HTTP, rather than proprietary serialization formats (DCOM, RMI, or CORBA – OK, CORBA isn't "proprietary", but we've included it here since each vendor's CORBA implementation is "unique" to that vendor).

Microsoft's Web Services use standard web protocols such as HTTP, and data description languages such as XML, to exchange data over common ports, utilizing the ubiquitous HTTP infrastructure support already in place.

The technical definition of a Web Service is programmable application logic accessible via standard web protocols. Behind this definition are two important points:

• Programmable application logic. A Web Service is implementation-non-specific. The application logic can be implemented by components, by PERL scripts, or by any other mechanism that supports XML.
• Standard web protocols. Web Services use Internet transport protocols such as HTTP or SMTP.

The union of XML and HTTP forms one of the new industry buzz words: Simple Object Access Protocol (SOAP). SOAP is a W3C submitted note (as of May 2000) that uses HTTP and XML to encode and transmit application data.

Consumers of a Web Service don't need to know anything about the platform, object model, or programming language used to implement the service; they only need to understand how to send and receive SOAP messages.

ASP.NET makes building Web Services easy, and since it continues the ASP "just hit save" development model, ASP developers already have the necessary skills to build Web Services with ASP.NET. Although a Web Service makes use of XML and HTTP as part of the plumbing, ASP.NET abstracts this for us and makes building SOAP based end-points as simple as coding application logic. Of course, the plumbing is also accessible if we wish to work with the transport or serialization mechanisms.

Here's what we'll cover in this chapter:

• Web Services Overview. We'll start with an overview of what a Web Service is, look at some of the common problems associated with building distributed applications, and briefly discuss the public specifications used for building Web Services.
• ASP.NET Web Services Programming Model. We'll look at how we build Web Services with ASP.NET, starting with some simple application logic that we'll enable.
• Protocols and Data types. ASP.NET Web Services support three protocols for exchanging data through a Web Service: HTTP GET and POST and SOAP. In this section we'll take a look at these protocols and the supported data types.
• Attributes. In the ASP.NET Web Services Programming Model section we'll look at how we can build a simple Web Service using only the required set of classes and attributes. In this section we'll look at the additional attributes and classes we can use when creating ASP.NET Web Services.
• Designing ASP.NET Web Services. In this section we'll look at some strategies for building Web Services and tracing Web Service requests, as well as how we can build services that operate asynchronously on the server. Additionally, we'll look at some of the general ASP.NET features we can leverage.

Let's get started with an overview of what a Web Service is.

Web Services Overview
Today the most common way to access information on the Internet is through a browser sending and receiving messages that contain HTML markup via HTTP. This HTML markup is then parsed in a web browser to render the user interface.

The web browser only begins to scratch the surface of what can be done with Internet when it comes to building applications. Already we're seeing a migration to other Internet applications, which use a similar set of underlying protocols, but don't always rely on HTML to control the user interface or exchange data. Examples here include PDAs, cellular phones, blackberry devices, and other rich-client peer-to-peer applications such as Napster or gaming applications.

Web Services are designed to facilitate the move to this next generation of the Internet. Using Web Services it's simpler to enable scenarios such as peer-to-peer and distributed application development, by providing the common protocol that connected web applications can share. It's very easy to envision applications using a broad set of Web Services for authentication, e-mail, buddy lists, etc.

The protocol format is standardized, so any application that understands SOAP can take advantage of Web Services. For example, if E-Bay built an auction Web Service, or Hotmail built an e-mail Web Service, SOAP-aware applications would be able to utilize each together or independently. It should be noted, however, that various implementations can "interpret" the meaning of the SOAP 1.1 specification differently. Microsoft is working extremely hard to ensure that ASP.NET Web Services are compatible with other common SOAP implementations.

As great as all this sounds, there are obviously some common issues and questions surrounding Web Services.

Common Issues
Solving the problem of exposing application logic or details through XML and HTTP isn't difficult. In the past we could have used languages such as ASP, Java, or Perl to write a simple application that exposed data via XML. For example, we could use ASP to write a simple application that accepts values passed on the query string, and generates an XML return document representing a specific database table. Applications could simply make calls against an end-point – say a URL exposing our database tables – and fetch, parse, and derive values from the document.

However designs like this are tightly coupled. The client is expecting a highly structured XML document, and if the application providing this document changes, the client implementations will most likely break. In the majority of cases this can be addressed by using public XML schemas, but maintaining and managing a disparate set of schemas for each application can be cumbersome. Also, the XML document will be dependent upon the server implementation.

Typically, even minor changes to the application logic can become large changes in the code used to expose that application logic as an XML document. The classic example of this problem is encountered with screen-scraping, where the HTML of a site is parsed for specific values. As long as the HTML remains static the known values can easily be extracted. If the HTML changes, it usually completely breaks the application consuming the HTML.

Other common issues include: