Java Web Services: Up and Running, 2nd Edition

What Good Are Web Services?

This obvious question has no simple answer, but the benefits and promises of web services can be clarified with examples. The first example underscores how the distinction between websites and web services continues to blur: the data and functionality available at one can be available at the other. (One web framework that emphasizes the blurring is Rails, which is discussed in more detail later.) The second example focuses on how web services can be used to integrate diverse software systems and to make legacy systems more widely accessible.

A visit to a website such as the Amazon E-Commerce site is often interactive: a shopper uses a browser to search the Amazon site for desired items, places some of these in a shopping cart, checks out the cart, finalizes the order with a credit card or the equivalent, and receives a confirmation page and usually an email. Pioneers in web services, such as Amazon, expose the information and functionality of websites through web services as well. Searching and shopping against Amazon, as code examples in later chapters illustrate, are tasks that are automated readily because Amazon makes a point of coordinating its websites with its web services. In any case, here is a sketch of how a search-and-shop experience might be automated.

1. A shopper has a database table or even a simple text file, wishList.txt, that contains items of interest such as books, movies, or any other search-and-shop category that Amazon supports.
2. The database table or text file, which acts as a wish list with constraints, provides pertinent information such as the ISBN of a desired book, the maximum price the shopper is willing to pay, the number of items to order, and so on.
3. The shopper programs a client, in whatever language the shopper prefers, that reads the database table or text file, opens a connection to Amazon, searches Amazon for wishlist items, checks whether the items are available under the constraints in the wishlist, and orders the items that meet the constraints.
4. The client program checks an email account for the confirming email; if all goes well, the client places confirmation information in a data store such as a database table or another simple text file.

An interactive shopping experience thus gives way to an automated one. Of course, some shoppers derive as much pleasure from the activity as from the outcome. The point is not that shopping should be automated but, rather, that web services open up this possibility for many tasks, shopping included. At one time, HTML screen scraping was a popular way to have applications other than browsers hit a website, download HTML documents, and then parse the HTML for its informational content. As more sites follow the Amazon practice of exposing the same or, at least, nearly the same data and functionality as both websites and web services, this screen scraping becomes increasingly unnecessary. Later chapters illustrate, with code examples, the close relationship between websites and web services.

The second example of what makes web services attractive focuses on a major challenge in modern software development: systems integration. Modern software systems are written in a variety of languages—a variety that seems likely to increase. These software systems will continue to be hosted on a variety of platforms. Institutions large and small have significant investment in legacy software systems whose functionality is useful and perhaps mission critical; few of these institutions have the will and the resources, human or financial, to rewrite their legacy systems. How are such disparate software systems to interact? That these systems must interact is taken for granted nowadays; it is a rare software system that gets to run in splendid isolation.

A challenge, then, is to have a software system interoperate with others, which may reside on different hosts under different operating systems and may be written in different languages. Interoperability is not just a long-term challenge but also a current requirement of production software. Web services provide a relatively simple answer to question of how diverse software systems, written in many languages and executing on various platforms under different operating systems, can interoperate. In short, web services are an excellent way to integrate software systems.

Web services address the problem of interoperability directly because such services are, first and foremost, language- and platform-neutral. If a legacy COBOL system is exposed through a web service, the system is thereby interoperable with service clients written in other currently more widely used languages. Exposing a legacy COBOL system as a web service should be significantly less expensive than, say, rewriting the system from scratch. Legacy database systems are an obvious source of data and functionality, and these systems, too, can be made readily accessible, beyond the local machine that hosts the database, through web services.

In the past, data sources for applications were usually data stores such as relational database management systems (RDBMS) or even local filesystems. Nowadays web services also serve as data sources, at least as intermediate ones that are backed up ultimately with persistent data stores. Indeed, web services integrate readily with RDBMS and other data storage systems as frontends that are easier conversational partners than the data storage systems themselves—because web services, at least well-designed ones, have APIs that publish their functionality in high-level, language-neutral, and platform-independent terms. A web service thus can be viewed as a uniform access mechanism for divergent data stores. A web service can act as the frontend of a database system, a frontend that exposes, through a published API, the data and the functionality of the database system (see Figure 1-2).

Figure 1-2. A web service as the frontend of a data store

Web services are inherently distributed systems that communicate mostly over HTTP but can communicate over other popular transports as well. The communication payloads of web services are typically structured text, usually XML or JSON documents, which can be inspected, transformed, persisted, and otherwise processed with widely and even freely available tools. When efficiency demands it, however, web services can also deliver compact binary payloads. Finally, web services are a work in progress with real-world distributed systems as their test bed. For all of these reasons, web services are an essential tool in any modern programmer’s toolbox.

The examples that follow, in this and later chapters, are simple enough to isolate critical features of web services such as security but also realistic enough to illustrate the power and flexibility that such services bring to software development. The main service examples have an accompanying Ant script to compile and then publish the web service on a production-grade web server such as Tomcat or Jetty; many of the Java clients against web services are packaged as executable JAR files in order to reduce hassle.

As noted earlier, web services come in different flavors: SOAP-based and REST-style. SOAP and SOA, though related, remain distinct. The next section goes into detail about the relationship between SOA and REST-style and SOAP-based web services.