Search content within the blog

Monday, April 20, 2009

Web Services - Part I

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.

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.

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 Envelope contains the SOAP Header and 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 .

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 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>

No comments:

Post a Comment