What Are Web Services?

Web services represent a new architectural paradigm for applications. Web services implement capabilities that are available to other applications (or even other Web services) via industry standard network and application interfaces and protocols. An application can use the capabilities of a Web service by simply invoking it across a network without having to integrate it. As such, Web services represent reusable software building blocks that are URL addressable. The architectural differences between monolithic, integrated applications and Web services-based applications are depicted in Figure 1-1.

Figure 1-1. The architectural differences between (a) a monolithic application with integrated capabilities, and (b) a distributed application using Web services-based capabilities.

The capabilities provided by a Web service can fall into a variety of categories, including:

• Functions, such as a routine for calculating the integral square root of a number.

• Data, such as fetching the quantity of a particular widget a vendor has on hand.

• Business processes, such as accepting an order for a widget, shipping the desired quantity of widgets and sending an invoice.

Some of these capabilities are difficult or impractical to integrate within third-party applications. When these capabilities are exposed as Web services, they can be loosely coupled together, thereby achieving the benefits of integration without incurring the difficulties thereof.

Web services expose their capabilities to client applications, not their implementations. This allows Web services to be implemented in any language and on any platform and still be compatible with all client applications.

Each building block (Web service) is self-contained. It describes its own capabilities, publishes its own programmatic interface and implements its own functionality that is available as a hosted service. The business logic of the Web service runs on a remote machine that is accessible by other applications through a network. The client application simply invokes the functionality of a Web service by sending it messages, receives return messages from the Web service and then uses the results within the application. Since there is no need to integrate the Web service within the client application into a single monolithic block, development and testing times, maintenance costs, and overall errors are thereby reduced.

Assume you want to build a simple calculator application that determines the appreciation in stock price for any company given its corporate name and the date the stock was originally purchased. The application must do the following:

• Determine the stock ticker symbol for the company based on the company name.

• Determine the latest price of the stock based on the ticker symbol.

• Determine the historical price of the stock for the given date based on the ticker symbol.

• Calculate the difference between the two stock prices and present it to the user.

This seemingly trivial application is in fact enormously complex. Right from the get go there are problems. We have to build a database with the names of all the companies in the country and their associated stock ticker symbol. More importantly, we must maintain this database as companies are newly listed, become delisted, change their names or their ticker symbol, or merge. To access the real-time price of a stock, we must have a relationship with a financial or brokerage firm. The legal complexities and hassles in architecting such a relationship is bad enough, not to mention the IT infrastructure that must also be put into place.

Unless you work for a brokerage firm or are in the business of maintaining stock information, the time and costs necessary to build the infrastructure necessary to support the stock appreciation calculator are enormous and, in most cases, prohibitively so. Until a brokerage firm itself decided to provide such a calculator, customers would have to make do without it.

Web services simplify and in many ways eliminate the need to build for yourself the support infrastructure both legal and technical. The calculator can be developed by simply passing messages between the calculator application and the appropriate set of Web services. Figure 1-2 graphically depicts the flow of messages, and the fundamental architecture of a Web services-based stock price appreciation calculator.

Figure 1-2. Sending and receiving Web service messages to build a stock price appreciation calculator.

Messages are sent between the calculator application and the following three Web services:

• StockTickerNameToSymbolConverter, which accepts a company's name and provides the ticker tape symbol.

• RealTimeStockQuoteLookup, which provides the latest price of a stock based on its ticker tape symbol.

• HistoricalStockQuoteLookup, which provides the historical price of a stock based on its ticker tape symbol and the desired date.

Since each of these three Web services is provided, hosted, and managed by another company, the developer of the calculator application has only to focus on his key insight or contribution alone. Complex, domain-specific issues such as the fact that Hewlett-Packard's ticker tape symbol was HWP and only recently became HPQ are (or should be) handled by the Web services directly. Using these three Web services, the application can easily determine the stock price appreciation for Hewlett-Packard from August 15, 2002, to be $17.51 - $15.00 = $2.51. Based on the data from the Web services, the calculator application can provide further analysis, such as the percentage appreciation, and present all of the information in an easy-to-understand, graphical manner.

Assuming the required capabilities exist and are available as Web services, developers can focus on their unique value-added piece and utilize third-party Web services for the remainder of the functionality. The benefits of using Web services are clear:

• Dramatically cut application development costs by focusing on your own value-added contribution and using third-party Web services for everything else.

• Integrate both data and business processes with market constituents and business partners that have desired domain expertise or capabilities.

• Reduce or eliminate many errors born out of complex and large monolithic applications.

• Simplify application maintenance and customization by segmenting an application into the client application and each of its consumed Web services.

• Significantly reduce time-to-market.

As we take this idea further, and more and more companies expose some of their internal capabilities as Web services, the real value of Web services lies in the composition of a set of Web services. Consider the following two companies. One is a traffic service company that monitors automobile traffic on major roads and highways and predicts expected travel times. The second is a taxi reservation service company that allows customers to reserve taxis for pickup at a specified location and time. Each of these companies and their products are compelling in and of themselves. However, if these companies exposed their capabilities as Web services, these services can be composed together into a single, more compelling and useful service either by one of these two companies themselves or by a third company.

As an example, consider taking a taxi to the airport before catching a flight for a meeting. By leveraging the capabilities of both companies through their respective Web services, a traveler can reserve a taxi and rest assured that if an accident or other traffic conditions cause an unexpected increase in her travel time, the taxi reservation can be held and an alert sent to the traveler advising her of the updated taxi schedule as well as the traffic situation that caused the change. By simply and intelligently combining the individual services of the two companies, we are able to create a more compelling and useful service for travelers. The composition of Web services from different enterprises is depicted in Figure 1-3. The technologies that form the foundations of Web services are SOAP, WSDL, and UDDI.

Figure 1-3. Composing together services exposed by multiple corporations to create a separate service offering.

SOAP

Simple Object Access Protocol (SOAP) is an XML-based mechanism for exchanging information between applications within a distributed environment. This information exchange mechanism can be used to send messages between applications and, more specifically, can be used to implement remote procedure calls (RPCs). RPCs allow one application to invoke and use a procedure (or capability) of another, possibly remote, application.

SOAP does not specify any application implementation or programming model. Instead, it provides a mechanism for expressing application semantics that can be understood by applications no matter how they are implemented. Accordingly, SOAP is application language- and platform-independent. SOAP is typically used in conjunction with HTTP, which supports easy traversal of firewalls and is sufficiently lightweight to be used within mobile and wireless environments.

WSDL

Web Services Description Language (WSDL) is an XML-based language for describing Web services. Through a WSDL description, a client application can determine the location of the remote Web service, the functions it implements, as well as how to access and use each function. After parsing a WSDL description, a client application can appropriately format a SOAP request and dispatch it to the location of the Web service.

WSDL descriptions go hand-in-hand with the development of a new Web service and are created by the producer of the service. WSDL files (or pointers thereto) are typically stored in registries that can be searched by potential users to locate Web service implementations of desired capabilities.

UDDI

Universal Description, Discovery, and Integration (UDDI) is a specification for a registry of information for Web services. UDDI defines a means to publish and, more importantly, discover (or search for) information about Web services, including WSDL files.

After browsing through an UDDI registry for information about available Web services, the WSDL for the selected service can be parsed, and an appropriate SOAP message can be sent to the service. Figure 1-4 graphically illustrates the relationships between SOAP, WSDL, and UDDI.

Figure 1-4. The relationships between SOAP, WSDL, and UDDI.

Now that we have a glimpse into what Web services are and how they can be used to build interesting applications and systems, we next discuss why this new technology is important.