Web Services Overview

From:

Web Services (continued)Overview

There is no precise definition of a web service on which all agree. The meaning of the term sometimes depends on the context in which it used. For the purposes of this book, we define a Web Service as a software system that provides a programmatic interface over HTTP. Some people might add an additional restriction that the data exchanged between the client and server is formatted as XML documents. Still others might consider any short-lived application-to-application interaction over TCP to be a web service.

A common example of a web service is a payment processing service that is provided to commercial web sites. To understand how this works, imagine that a web application provides users with the ability to browse a catalog of items and place selected items into a shopping cart. At some point, the user decides to checkout. In a checkout page the application collects the credit card details from the user. When the user submits these credit card details to the application, the application makes a connection to a payment processing service and submits a request to charge the user's account with the amount he or she has agreed to pay for the items in the shopping cart. The payment processing service returns a result that indicates whether the payment has succeeded or failed. Typically, the messages sent between a web application and a payment service are transported over HTTPS. In this case, the payment service is called a web service.

There are different ways of implementing a web service. One method is to use the SOAP protocol in which XML data is placed inside a SOAP message and transported using HTTP. This approach is referred to as SOAP-based web services and is a method being strongly supported by Microsoft and other large companies. There is a multitude of web service specifications related to SOAP-based web services. Many developers choose to avoid using the SOAP protocol, claiming that its complexity is unnecessary in many or most application contexts.

Another method of implementing web services is to place data in XML documents and transfer them directly using HTTP. This approach is commonly referred to as REST-based web services, although the term REST is also used to refer to an architectural style for implementing distributed systems. REST stands for Representational State Transfer. REST-based web services are much simpler to understand and implement than SOAP-based services. In this book, we illustrate the REST-based web services.

In this chapter we build functionality into the publisher and wiki applications that allows the wiki application to be a web service client of the publisher application. Specifically, when the user of the wiki application wishes to publish a given web page as an item in the publisher news feed, the wiki application will submit a publish request to the publisher application. To remove the web page from the publisher's news feed, the wiki application submits an unpublish request.

The server side implementation of our 2 web services are done using servlets, so that management of sockets and sending of HTTP headers are performed by the web container. In contrast, the client side implementation that we provide shows the details of creating a socket and sending HTTP message headers to the service. In many cases, application developers can avoid the direct use sockets, and the direct manipulation of HTTP headers. However, these developers need to be aware of the HTTP protocol and need to write code that reads, adds or modifies HTTP headers on occassion.

In this chapter we extend the publisher application by adding a REST-based interface that lets clients publish news items to its RSS feed. Specifically, we add 2 web services to the publisher application: one that allows clients to publish a news item through its news feed and another that allows clients to unpublish news items (remove news items from the RSS news feed). Also in this chapter, we complete the implementation of the publish and unpublish operations that users of the wiki application can invoke so that users of the wiki application can publish and unpublish wiki pages to and from the RSS news feed of the publisher application. The following diagram illustrates the interactions between the various systems and their sub-components.

The stick figures above represent human access to the systems via browsers. When users of the wiki application invoke the publish operation on a given wiki page, the wiki application composes an XML document to serve as a web service request message and sends this message to the publish web service of the publisher application. The request message contains the link to the wiki page and the wiki page title. The publisher application generates a unique id to represent the new news item, and then adds this id, the link and title information to its database. The publisher application then places the id in a simple XML document to be used for a web service response message, which it returns to the wiki application. The wiki application saves the returned id in its record for the wiki page being published. This returned id can be used later to unpublish (or delete) the wiki page from the RSS news feed.

After a wiki page is published in the manner just described, users visiting the home page of the website application will see the linkable title of the wiki page. This is accomplished in the HomeServlet of the website application, which retrieves the RSS document from the publisher application.

If the website were to be a high volume destination, requesting the RSS news feed for each request fot the website home page would result in too many redundant requests for the publisher's news feed. In this case, the developer could cache the RSS document and construct its home page from the cache in order to reduce this outgoing traffic and reliance on the publisher site. There are many ways to implement this improvement. The website could rely on a simple periodic check in which it requests the fresh version of the RSS document. Another possibility is for the website to register itself as a downstream client of the publisher's news feed and wait for the publisher to deliver to it revisions to the RSS document. In this situation, we say that the publisher pushes content to its clients. The RSS 2.0 protocol provides a means to accomplish this push mechanism.