Enter Web Services

Software Magazine, April, 2001 by Roger Sessions

E-commerce is moving to a new collaborative model

LAST CHRISTMAS I WAS IN THE NEIGHBORHOOD WAL--MAKF and noticed a woman--let's call her Kate--talking on a cell phone. Kate would I stop at an item, talk on her phone, and either pick up the item and put it in her shopping cart, or lose interest in the item and move on to the nextitem. What could she be doing?

I finally determined that Kate's husband was at the neighboring Kmart. The two had identical shopping lists and were comparing prices over their cell phones. If the item was cheaper at Kmart, her husband would buy it. If the item was cheaper at Wal-Mart, Kate would buy it. Then they would move on to the next item.

A great system, I thought, but limited. What if, for example, the item was cheaper at Toys R Us? They would never know.

If Wal-Mart, Kmart, and Toys R Us all had online catalogs of their current prices, Kate could have done her pricing in the comfort of her Web browser. This would have been an improvement in her cellphone system, but still slow. She would have had to determine which stores she wanted to check, found the Web sites of those stores, found each item on her shopping list, and planned her travel itinerary--a time-consuming process.

Optimal Shopping Experience

A simpler solution is to have some software product--let's call it SearchIt--do this automatically. Kate simply enters her zip code, how far she is willing to drive, and her shopping list. SearchIt queries each candidate store in her radius and creates for Kate the optimal shopping experience

It seems like it should be easy to create a program like SearchIt. After all, each store has an online catalog. That online catalog allows Kate to check prices. Obviously that online catalog must have some business logic buried behind it that conducts inventory searches. If Kate can access that business logic, why can't SearchIt?

Poor SearchIt is hobbled by today's e-commerce systems, which are typically based on a tightly coupled three-tier architecture (see Figure, p. 17). The first tier is the presentation tier, which accepts incoming HTTP requests from the browser acting on Kate's behalf. The middle tier is the business logic tier, which is what actually conducts the inventory searches. At the back end is the data tier, which stores the inventory information.

The data tier is connected to the business logic tier. And the business tier is connected to the presentation tier. The only entrance to this system, at least from the outside world, is via the presentation tier. The only requests the presentation tier understands are HTTP opes. And the only way it knows how to respond to those requests is with HTML pages. Great for Kate. Not so great for SearchIt.

The general solution to SearchIt's problem is a technology known as Web services. I define a Web service as a self-contained unit of business logic (such as inventory searching) that can be accessed programmatically over the Internet by another software system (such as SearchIt).

Web Services Architecture

Conceptually, a Web services architecture is a straightforward extension of the standard, tightly coupled three-tier architecture (see Figure, p. 18). The architecture "merely" adds a new layer of software that accepts programmatic search requests over the Internet. This layer then translates those requests into something that the native business systems (say an inventory system) can understand, and translates the results into something that can be sent back to the requester (say SearchIt) over that very same Internet.

In the Figure, this layer of Internet-friendly software is shown as a separate Web services tier, but it could also be considered an auxiliary function of the presentation tier (which already knows all about Internet-friendly protocols). Over time, I expect the requirements of the Web services tier to expand and increase in complexity (for example, with the addition of transaction coordination, security, and data translation functionality), until eventually its unique perspective on the world will warrant a tier of its own.

One reason Web services are appealing to businesses is that they are reasonably inexpensive to implement. At least the incremental cost of implementing a Web service is reasonably inexpensive. The business logic (inventory searches) can be quite expensive to develop, but this cost has already been absorbed into the overall cost of the Web site. Once that business logic is implemented, the incremental cost of making it available as a Web service is relatively low.

Web Services Standards

Web services need interoperability standards in order to become generally useful. Here are some of the major standards areas with which a product like SearchIt would be concerned:

* A standard way to determine what requests a given Web service will support.

* A standard way to find all the Web services that support certain capabilities.

* A standard Internet-friendly protocol to make those requests of Web services.

Web services standards are at a very early stage. There are many groups working in this area, and the politics are, as in most standardization activities, intense. The standards that seem most likely to influence this rapidly evolving area are: