Windows Systems Administrator Jupitermedia US-CT-Darien Post A Job | Post A Resume

Published: Wednesday, October 8, 2003

An Extensive Examination of Web Services Index

An Extensive Examination of Web Services is a multi-part article series spanning several months. Listed below are the current "parts," along with a very brief synopsis and the date published. Part 1 - Examines the basics of Web services, what Web services are, and the technologies and standards that serve as the underpinnings of Web services. (October 8th, 2003) Part 2 - Examines creating Web services using Visual Studio .NET. Looks underneath the hood of the code created by VS.NET. (October 15th, 2003) Part 3 - Examines creating a client application that consumes a Web service. Discusses the purpose and structure of a WSDL document, along with creating and using proxy classes to consume a Web service. (November 5th, 2003) Part 4 - Examines the utility of Web services and common scenarios where Web services make sense. A business-oriented look at Web services. (November 19th, 2003) Part 5 - Takes an in-depth look at XML serialization, which is the process of converting a data type, such as an integer, array, or custom class, into its XML representation, and back again. Every time a message is passed to or from a Web service, XML serialization transpires. (December 17th, 2003) Part 6 - Looks at sending metadata to a Web method through the use of SOAP headers. Examines defining and accepting a SOAP header on the Web service end, and looks at sending a populated SOAP header from the client. (December 31st, 2003) Part 7 - Examines how the incoming and outgoing messages to a Web service can be programmatically modified via SOAP Extensions. (January 21st, 2004) Part 8 - Learn about the Web Service Enhancements (WSE) and Microsoft's free class library for implementing the WSE standards. (June 30th, 2004) Part 9 - See how to implement UsernameToken authentication using the WSE 2.0 Toolkit. (July 14, 2004) Part 10 - Learn how to send large amounts of data as attachments using DIME and WS-Attachments. (September 8th, 2004) Part 11 - Create (and consume) client-side script-accessible Web Services using Microsoft's ASP.NET AJAX framework. (September 26th, 2007)

Introduction
Starting in April 2002, I began a long-running article series titled, An Extensive Examination of the DataGrid. This article series, which has currently spanned 15 installments, serves as a great place for ASP.NET developers to become intimately familiar with the ASP.NET DataGrid. (For those who are interested in learning even more about the DataGrid (and the Repeater and DataList as well), I invite you to check out my book ASP.NET Data Web Controls Kick Start.)

Due to the many positive responses I have received from readers of the DataGrid article series, I decided to start a new article series, this time focusing on Web services. Currently there are a handful of Web service articles here on 4Guys. They all, though, only briefly focus on Web services from a high-level view, and all demonstrate creating and consuming Web services using .NET. They talk about using the tools like Visual Studio .NET to utilize Web services, and leave off descriptions on what these tools are doing behind the curtains. Granted, such tool-related and implementation information is important, but I also think it is vital to have a good understanding of the entire Web services picture, as well as how things work in the nitty-gritty low-level side, behind the mask of the tools.

In this article, the first part of an article series I suspect will span several months, we will look at what Web services are from a high-level perspective. We'll examine the pieces that comprise Web services, and how these pieces work together to provide a platform-independent distributed architecture. Future articles will examine the pieces in more detail, look at implementing Web services, examine the Web Service Extension (WSE) specifications, and more.

Web Services - What Are They?
Web services are a standardized way for one application to invoke a method of another application. These applications may reside on different computers that are some way connected, such as by a local area network or, more commonly, by the Internet. With Web services you have two actors, a client and a server. The server makes some set of methods available. These methods, when called, will perform some action and/or return some data. The client invokes one of the available methods of the server. Like methods in a class library, the methods of a Web service can accept an arbitrary number of input parameters, and can optionally return a result. The Web services standard spells out in great detail how a client can invoke a Web service method from a server. The standard dictates how input parameters and return values are passed from one computer to the other, how faults are handled, and a myriad of other complications.

Before we delve into the specifics of the Web services standards, let's first think about what, exactly, a "service" is, and what fundamental properties are inherent to services. The fundamental properties of any service are:

• Medium by which the service is performed,
• The protocol by which the messages are sent to and from the service, and
• The protocol for the message formats.

To see how these fundamental attributes factor into every service, let's take a step back from the computer world altogether, and consider a telephone number directory service, like 411. (For those unfamiliar with telephone directory services, they are a specific phone number which anyone can call and ask for the telephone number of a particular business in a certain city and state.) This service is performed over the telephone, hence the telephone system is the service's medium. The protocol used to transport a message from your receiver to the operator's receiver is spelled out very thoroughly in books on telecommunications, but is far beyond the scope here. The protocol for message formats is not a very strict one since you typically are interfacing with another human, therefore the messages might include superfluous questions or information, inane chatter, small talk, and so on. But essentially you must specify the business name, the location, and city. The response of the service is the business's telephone number.

With Web services, the medium used is a computer network, such as the Internet or a LAN. The messages are typically transported a client to a server using the HTTP protocol. HTTP, which stands for HyperText Transfer Protocol, is the protocol used to request/receive Web pages from a Web server to a browser. Web services can use other transport protocols, however, such as SMTP, but HTTP is used in the vast majority of cases. The message protocol used by Web services is SOAP. SOAP, or Simple Object Access Protocol, is an XML-encoded messaging protocol that is used to marshal the input parameters and return values of a Web service method.

If all of this talk of standards and TLAs (Three Letter Acronyms) has your head spinning, don't worry! We'll delve into these TLAs in more detail in this article, but first let's look at why Web services are needed.

Why Web Services?
Before we dive into the technological specifics of Web services, let's first take a moment to examine some important questions. Why should we use Web services? Why are they important? What were our options before Web services, and how are Web services an improvement over these other choices?

Web services allow a server to expose functionality that clients can utilize. For example, the Weather Channel might want to allow access to the current temperature for any specified ZIP code. This way, location-based Web sites, like sites for resorts in Florida, could boast of their lush weather by posting the current temperature on their site. Now, imagine you worked at the Weather Channel's Web site - how would you provide this functionality? There are a number of methods that were used in the past.

The simplest method is to provide a simple Web page that provides said data. That is, you could create a dynamic Web page that accepted the ZIP code in the querystring and returned in the temperature. To consume this service, a client Web page would have to make an HTTP request to your Web page. Oftentimes, developers who want to consume some data on a Web site use this approach, which is often dubbed screen scraping. Screen scraping involves downloading the entire HTML contents of a Web page and then using regular expressions or string functions to pick out the interesting data.

A more involved method, which is often used in enterprise-settings, is to use technologies designed for remote object invocation. Technologies like CORBA and DCOM. These rich technologies can allow applications on different platforms within an enterprise communicate with one another.

Given screen scraping and technologies like DCOM, you might be wondering why Web services are needed. First, let's examine the downsides of screen scraping. Screen scraping, while very simple to implement, can fail if even a slight change is made in the rendered HTML. For example, Google periodically changes the HTML returned in its Web results ever so slightly - the changes don't affect the visual aspect of the results, but make it harder for companies to screen scrape Google's results. Furthermore, screen scraping is not ideal if one needs to specify complex input parameters or a complex return value. With the Weather Channel example, a ZIP code is a simple input parameter, but imagine if we had a Web service where we had to provide a number of inputs of different types, with each type perhaps being an aggregate of other types.

Technologies like CORBA and DCOM have their disadvantages too. Primarily, these technologies are limited to the enterprise setting. That is, for a client to utilize a method on a remote computer, both the client and the server must both have the appropriate DCOM or CORBA libraries installed on their computers. Too, these technologies pass back their data as binary messages on non-standard ports. This means many firewalls will, by default, block such traffic, further impeding the use of DCOM and CORBA beyond the enterprise.

As discussed earlier, Web services transport their messages using HTTP, which means these messages are transmitted over port 80, an open port for Web server firewalls. Web service messages are transmitted as SOAP-formatted messages. SOAP messages are in XML format, meaning they are simply text, and not complex binary data. SOAP, as we'll see in a bit, is designed to serialize both simple and complex data types, meaning SOAP can be used to easily transmit complex data from the client to the server and back again. Finally, the protocols used by Web services - SOAP and HTTP - are open and well-known protocols, meaning Web services can be easily implemented on any platform. In fact, as we'll discuss later, one of the great benefits of Web services is their interoperability. A Web service created with the J2EE platform can be consumed by a client created with the .NET platform, and vice-a-versa.

Due to their interoperability, in enterprises Web services are commonly used as a unified means to access disparate systems. For example, a large enterprise may have data in a variety of systems, accessible through various platforms. HR data might be stored in an Oracle database and accessed via a J2EE application; sales data may be in a MS-SQL Server database accessed by a VB6 application; employee data may be in a DB2 database and accessed by a legacy software system. Clearly, it would be advantageous to be able to access all of this data uniformly from a single application. One option would be to rewrite all of these old applications so that a common data store and access program is used. This approach is undesirable for a number of reasons, such as the cost and time it would take to replace the legacy software with new software. Rather, it might make more sense to provide Web service "front-ends" to each of these data stores and application interfaces. Then, a new application can uniformly access data from disparate resources all through a simple, standard Web service interface.

A High-Level View of Web Services
Web services provide a means for a client application to invoke a service of a server application. The challenges surrounding this process are as follows:

1. How is the service invoked? That is, how does the client specify the Web service method he wished to call?
2. How are the input parameters serialized? That is, if the input parameters involve complex data types, how are these data types represented in the message?
3. How is the method's response serialized?

The answer to these questions are spelled out in the SOAP specification. Recall that SOAP is the message protocol used for Web services. We'll dive into SOAP in a bit, but for now just realize that a SOAP message is an XML-formatted message. The diagram to the right shows a high-level view of the interaction between a client and a Web service. That is, a client begins the interaction by sending an XML-formatted message to the server specifying the function he wants to invoke, along with the input parameters. Upon receiving this information, the server invokes the specified method, and then returns the methods result in an XML-formatted message.

This simple interaction between a client and a server sums up what Web services are in a concise manner. Of course, there are more involved interactions possible, as we'll see in future articles, but for now let's focus on the simpler and more common cases.

Understanding SOAP
SOAP is a standard that specifies the format of messages used in Web services. SOAP messages are messages formatted in XML - the SOAP standard specifies what XML elements must be present, in what order, and what data types they can contain. A SOAP message is comprised of the following parts:

• A SOAP Envelope,
• An optional SOAP Header, and
• A SOAP Body

The SOAP Body and (optional) Header are contained within the SOAP Envelope, as shown in the diagram to the left. As aforementioned, a SOAP Header is an optional piece of a SOAP message, and for simple Web services is rarely used. We'll save a discussion on SOAP Headers for a later article. For now, let's focus on the SOAP Envelope and SOAP Body.

The SOAP Envelope merely consists of the XML root element, which specifies the namespaces used in the SOAP message. (If you're unfamiliar with XML and namespaces, consider checking out the XML Tutorials at XMLFiles.com.) The root element of a SOAP message is <soap:Envelope>.

Realize that in a Web service interaction there is a total of two messages: first, the client sends a SOAP message to the server, invoking some method. After this method has executed, the server returns a response, which includes the return value of the method. For the first message, sometimes referred to as the SOAP request message, the SOAP Body contains the name of the method the client wishes to call, along with the method's input parameters. In the second message, the SOAP response message, the server sends back in the body the return value of the method. (Even if there is no return value, a message is still sent back if, nothing else, to verify that the method executed.) The SOAP Body is signified by the <soap:Body> element.

The following is a sample SOAP request message:

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <WebServiceName xmlns="Web Service Namespace"> <inputParameter1>input parameter value</inputParameter1> <inputParameter2>input parameter value</inputParameter2> ... <inputParameterN>input parameter value</inputParameterN> </WebServiceName> </soap:Body> </soap:Envelope>

And here is a sample SOAP response message:

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <WebServiceNameResponse xmlns="Web Service Namespace"> <WebServiceNameResult>result value</WebServiceNameResult> </WebServiceNameResponse> </soap:Body> </soap:Envelope>

The elements specific to the SOAP standard are in bold. Notice that the SOAP message begins with a <soap:Envelope> element, which contains a <soap:Body> element. Inside the <soap:Body> element of the SOAP request message is XML that specifies the Web service method to invoke and its input parameters. Inside the <soap:Body> element of the response SOAP message is the XML specifying the method that was called and its response, if one exists.

To help hammer home the concepts, let's imagine that a server contains a Web service method called Add, which takes two integer inputs named a and b and returns their sum (as an integer, of course). Now, imagine that a client wanted to invoke this service passing in values of 5 and 8. To do so, it would need to send the following SOAP message to the server:

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <Add xmlns="Web Service Namespace"> <a>5</a> <b>8</b> </Add> </soap:Body> </soap:Envelope>

Note that the sole child element of the <soap:Body> element is the <Add> element. This specifies what Web service method to call. Furthermore, the <Add> element contains two children elements, <a> and <b>, which contain the values we want to add. (A fair question at this point is, "How do we know that we should be using XML elements named <Add>, <a>, and <b>? Why not use some other names?" As we'll see in a future article, when a Web service is created, so is a WSDL document. A WSDL document provides a formal definition of the Web service, which includes information on the required names of the XML elements in the <soap:Body>.)

The response SOAP message would look something like:

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <AddResponse xmlns="Web Service Namespace"> <AddResult>13</AddResult> </AddResponse> </soap:Body> </soap:Envelope>

Recall that earlier we saw a very high-level diagram illustrating the interaction between a client and a server participating in a Web service. In this previous diagram, we simply indicated that XML data was passed between the client and server. With a more in-depth understanding of SOAP, we can now enhance that diagram to show more precisely what is passed back and forth for the Add method example:

It's Easier Than It Looks
At this point we've taken a look at Web services, and examined what they provide (a distributed architecture using open standards available over the Web), their predecessors (screen scraping, CORBA, DCOM, etc.) and how Web services are an improvement over these legacy applications. We've examined, rather quickly, what SOAP is, and how SOAP messages are formatted to invoke Web services.

At this point, things might look a little complicated. If I were to ask, "How do you call a Web service method?" you might think you have to craft your own SOAP message and make your own HTTP request. Fortunately, the .NET Framework makes it an absolute cinch to create and consume Web services, requiring only a few lines of code!

In our next article we will turn our attention to creating Web services with Visual Studio .NET. We will then explore WSDL, a standard for formally defining a Web service. Finally, we'll see how to utilize this WSDL document to easily consume a Web service from a client application. If you can't wait for this exciting information, you can get a sneak peak by reading Creating and Consuming a Web Service.

Happy Programming!