Starting in April 2002, I began a long-running article series titled, An Extensive Examination of the DataGrid. 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. SOAP, or Simple Object Access Protocol, is an 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 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: How is the service invoked? That is, how does the client specify the Web service method he wished to call? 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? How is the method's response serialized?
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
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:
, 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, )
4 Guys From Rolla.com
4GuysFromRolla.com, has been working with Microsoft Web technologies for the past five years. An active member in the ASP and ASP.NET community, Scott is passionate about ASP and ASP.NET and enjoys helping others learn more about these exciting technologies. For more on the DataGrid, DataList, and Repeater controls, check out Scott's book ASP.NET Data Web Controls Kick Start (ISBN: 0672325012). Read his blog at : http://scottonwriting.net
No comments yet. Be the first to comment!