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