Web Services: Definition and Implications

For something as simple as Web Services, there seems to be a lot of confusion even at the definition level. Here are some representative definitions:

• David Rosam: "Web Services are reusable software components based on XML and related protocols that enable near zero-cost interaction throughout the business ecosystem. They can be used internally for fast and low-cost application integration, or made available to customers, suppliers or partners over the Internet."^[95]

• Hailey Lynee McKeefry, ZDNet: "Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. They perform functions that range from simple requests to complicated business processes."^[96]

• The Stencil Group: "Loosely coupled, reusable software components that semantically encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols."^[97]

• W3C Glossary: "A Web service is a software system identified by a URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols."^[98]

Web Services Defined

Here is a simpler and more operational definition:

Web Service

A Web Service is a remote invocation method. It is different from other remote invocation approaches in that it uses XML for its binding, and it can support both asynchronous and synchronous interaction.

A typical example is a Web Service that returns a stock quote. The calling program formats an extensible markup language (XML) request containing the symbol for the stock, and the Web Service returns an XML message with the current price per share.

There are several implications to this simple definition:

• Platform independence—The caller and receiver need not share a technology base, as long as each is able to send and receive an XML message over a network.

• Internet scope—These calls can be made across the Internet, including to computers that are behind firewalls, which is difficult for other approaches.

• Loose coupling—Using XML has a double benefit: Because it is "just" text, there aren't any binary compatibility issues to deal with, and XML has features that allow both participants to pick the parameters they are interested in out of a potentially larger and changing message.

• Promotion, or at least possibility, of asynchronous interaction—For most other distributed architectures, it involves considerable extra effort to get the interaction to be asynchronous. As we'll discuss, this is much easier with Web Services.

Before Web Services, if you wanted to invoke some functionality on another computer, you had to have a mechanism to bind to that other functionality. These mechanisms, such as CORBA or DCOM, were closed (i.e., a CORBA object called another CORBA object) and did not operate well over the Internet, especially in the presence of firewalls.

People avoid seeing the simple definition because there is so much marketing hoopla around Web Services that they have a tough time believing that that is all there is to it. Simple as it is, though, there are many implications to it, and much more technology is being built up around it to make it work reliably. These things are in the Web Services ecology, but they aren't Web Services. To understand how to plan your semantic-based Web Services strategies requires mapping the current ecology's likely evolution. This evolution will include both technical and organizational changes.

End of the Platform Wars

Before the advent of Web Services we were in the midst of the "platform wars." Vendors of computer hardware, operating systems, middleware, and database management systems all believed that the only logical outcome of the trend for distributed processing would be a "winner take all" scenario, where one platform would dominate. Because it was far easier to intercommunicate between homogeneous platforms, they believed that one would prevail.

Web Services potentially renders this moot, because there will be competition at the add-on or tool level by vendors who will try to make their tools the easiest on-ramp for Web Services. However, Web Services are built on open standards and any platform can invoke Web Services from any other platform.

Distinction from Component Architectures

People sometimes liken Web Services to component-based architectures. A component-based architecture is focused on building and using "reusable" chunks of program logic to construct a solution. At some level that is what Web Services do. The difference is that in a component-based architecture the components are brought to the problem. The components become part of the product that delivers the solution. In the Web Services world, the service stays where it is and delivers the information or side effect requested.

Web Services and Firewalls

One of the great strengths of Web Services is their ability operate over the Internet, including their ability to tunnel through firewalls. Many consider this also to be one of the great weaknesses of Web Services. This technical capability enables wide-scale deployment, attracting many people to the idea. However, in the short term there are many impediments to actually using Web Services over the public Internet, because of the lack of the contracting infrastructure. This in turn restricts the options for producers of services. As a result, most of the early work with Web Services is at the intranet level.

Consumers and Producers

One way to think about Web Services is to distinguish "producers" and "consumers" of the service. The consumer is the process that invokes the service and gets the result. The producer is the owner of the service that handles the request. The advantages for consumers are obvious—they receive some value-added service without having to build or support the system that delivers it.

However, the business model that ignited the World Wide Web— advertising—is available only to a very limited degree in the Web Services model. Web Services are designed for application-to-application (A2A) communication, rather than the application-to-human (A2H) model of the Web. As a result there is no one to read the advertisements. (The consuming application will consume the stock quote, put it in a spreadsheet or graph, and ignore any ads, if there were any, that accompanied it.)

In the absence of the advertising model, three other models may entice producers to play:

• The producer and consumer are owned by the same entity. (This is the intranet scenario, in which a company may shift processing from one system to a service where it can be shared and reap the benefit purely from the sharing). This is where the early adopters are putting their efforts now, but this model will not scale out to the broader Internet.

• The producer is paid to deliver the service. This is where Web Services ultimately must go. As we'll discuss in the section on contracts, a great deal of infrastructure must be built to make this work. In the short term, people will try to work out the financial arrangements separately from the service invocation. This is similar to the application service provider (ASP) arrangements that were much promoted but little used over the last 5 years.

• The service directly contributes to the producer's mission. For example, Amazon.com has a Web Service interface that allows people to access books, prices, reviews, and so on. The Web Service also allows users to put books in their Amazon shopping carts and can execute a purchase. Amazon doesn't need to get paid for delivering the service, as long as it contributes to selling more books. Another example would be companies that use the service to increase their own internal efficiency; for example, the U.S. Post Office could supply a Web Service to normalize addresses and supply nine-digit zip codes, knowing that every time it gets used their ability to deliver mail more efficiently would increase.

Enterprise Application Integration

Given the prerequisites for producers on the public Internet, we expect that most of the activity in the short term will be on intranets. In particular, people will be looking to solve their enterprise application integration (EAI) problems (see Chapter 12).

Web Services is a two-edged sword for EAI. On the plus side, the platform neutrality is a great feature. All that's needed to be a producer is to set up an XML adaptor for some piece of functionality on a legacy system.

The main negatives (all of which can be overcome) are as follows:

• Performance—As we'll discuss in the section on service-oriented architecture, there can be a steep penalty for using Web Services, especially for high-volume transactions. Many companies may not want to incur this penalty.

• Polymorphism—The ability to get a varied response, depending on the specific nature of the item interrogated, is generally considered to be a big plus. For example, if a stock ticker encounters a stock symbol for an American Depository Receipt (ADR; these are shares of foreign companies traded in U.S. dollars on U.S. exchanges) in addition to the current price on the U.S. stock market, it might return the foreign stock symbol, market, and current price in the foreign currency. This might be useful on a modern system, but it confuses most legacy systems that expect a fixed-format response. If we had set up our application to display the results generically, based on the XML it receives, it would be able to handle this gracefully.

• Point to point—The default topology for Web Services is point to point: A single consumer calls a single identified producer. The rest of this chapter examines how to overcome this, but we need to start by realizing that "out of the box" default behavior for Web Services is point to point. Point to point refers to the caller knowing the presence and identity of the receiving program, there being only one receiving program, and the caller blocking and waiting for a response. (Blocking and waiting means cutting in half program execution and waiting for the responses before proceeding.)

All of these issues can be resolved with a combination of tools and standards already available, as well as a more rigorous application of the semantics of the service to be delivered. Let's start with some of the mechanics.

^[95]From http://www.dangerous-thinking.com/stories/2002/02/16/webServicesDefined.html.

^[96]From http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2803166,00.html.

^[97]From http://www.stencilgroup.com/ideas_scope_200106wsdefined.html.

^[98]From http://www.w3.org/TR/ws-gloss/.