Web Services’ Idées Fortes

Many people ask us at ZapThink what’s really so special about Web Services. We’re the first to admit that Web Services are more evolutionary than revolutionary, building upon earlier Service-oriented technologies and approaches to distributed computing. Sure, Web Services are standards-based, using XML and XML-based protocols like SOAP to act as a common basis for communication across different vendor implementations. But open standards are really only the price of admission. The true power of Web Services lies in three related powerful ideas (idées fortes) that in combination describe how Web Services will change the fundamental nature of distributed computing.

Idée Forte #1: Asynchrony
Communications between distributed systems fall into two basic categories: synchronous and asynchronous. Synchronous communications consist of round-trip messages in which the sender waits for a reply. Submitting a Web page form and waiting for a confirmation page is a familiar example of a synchronous operation. In contrast, with an asynchronous message, the sender can submit a request, and then go about its work. If a reply does come, then the original sender can pick it up when it wants. Email works asynchronously, for example.

When two computers talk to each other, the exchange is typically a synchronous form of communication known as a remote procedure call, or RPC. With an RPC, one computer actually executes a program on the other computer as if it was a local application. Now, many of today’s applications of Web Services are for RPCs, and Web Services are reasonably well suited for this task. However, Web Services are equally well suited for asynchronous messages. The fact that Web Services offer a standard way of sending and receiving both synchronous and asynchronous messages is our powerful idea — our idée forte.

The reason that this fact is powerful is because the ability to exchange both kinds of messages is essential to the ability to perform long-running transactions. Typical transactions — say, transferring money from checking to savings — must take place very quickly and reliably, because the various systems involved must wait to make sure the transaction was successful before they go about their business. Such ordinary transactions are therefore constrained by the fact that they must be synchronous. However, a transaction might have multiple steps, for example, company A submitting a purchase order to company B, who fulfills the order and then submits the invoice to company A, who pays it. Such a transaction might take weeks, and thus must be handled asynchronously. Web Services are particularly suited for handling such long-running transactions, because of their support for asynchrony. Unfortunately, many of today’s Web Services implementations leverage only the synchronous aspects of Web Services, limiting their power.

Idée Forte #2: Loose Coupling
Traditionally, getting RPCs to work between different systems has never been easy. Even when the boxes at either end are speaking the same language, the architect must carefully plan each side of the RPC so that they can find each other, understand each other, and figure out what to do if there’s a problem communicating. Furthermore, when the two systems speak different languages, getting them to communicate is notoriously difficult — so difficult, in fact, that the entire system integration industry has sprung up to solve this one problem.

The fundamental problem with such architectures is that they are tightly coupled, which means that the architect must design each component system with the other systems in mind. As a result, making changes to one part of a tightly coupled system often affects the whole architecture, requiring expensive and difficult reworking. Web Services, on the other hand, are loosely coupled. Each Web Service has a WSDL file which describes how other systems, known as Web Service consumers, can connect to it and exchange information with it. Therefore, the consumers need have no knowledge beforehand about a Web Service, other than where to find it and that it is based on the common Web Services standards. As a result, a developer can make changes to a Web Service without breaking the Service-oriented architecture.

Loose coupling is an idée forte, not only because it dramatically lowers the cost of system integration, but also because it enables the federation of systems. Instead of shoehorning heterogeneous systems into brittle, tightly coupled architectures, the Service-oriented approach is to allow them to interact on their own terms, without requiring substantial changes on each system. This federation of systems lowers the integration cost and also provides new ways of getting value out of legacy systems without having to rework or replace them. Current Web Services implementations that offer little more than the simple wrapping of components with SOAP interfaces are missing the key feature of loose coupling: they are still tightly coupled and brittle.

Idée Forte #3: Coarse Granularity
The traditional approach to getting information in and out of an enterprise application (such as an ERP system) is via an application programming interface, or API. An API is little more than a set of method calls in a particular programming language that distributed systems can execute to exchange data with the application. Such APIs are typically fine grained, which means that each method call is a detail-oriented, technical construct for use by programmers. For two systems to communicate a complex business task via an API, they typically must exchange many of these fine-grained messages. Not only does this approach generate large amounts of network traffic, but developers must program extensive business logic into the calling system.

As a matter of fact, Web Services are actually not very good at sending fine-grained messages, because XML is an inefficient way of sending and receiving small amounts of information. Many Web Services detractors point this limitation out, but they’re missing the point. Web Services are in fact much better suited to building coarse grained interfaces. A coarse grained interface rolls up the functions of many different API calls into a small number of business-oriented messages.

To illustrate the difference between fine and coarse granularity, let’s compare placing an order over the phone with mailing in a catalog order. An order over the phone might go like this:

YOU: Do you have any sweaters?
STORE: Yes we do.
YOU: What colors do you have?
STORE: Well, in Brand A, we have blue and brown, but in Brand B, we only have brown.
YOU: Well, I want blue. What sizes does Brand A offer?

…and on like that, until the order is complete. Such a conversation is fine grained, because the requestor asks for a small amount of information each time, requiring an extensive back-and-forth conversation between the two parties.

Ordering via mail, however, is a coarse grained process. You ask for and receive the catalog. Then you go off, read the catalog, make your decisions, and fill in the order form. You mail in the order form, and the store processes it. The request (“send me a catalog”) is coarse grained, because it is a business request, and the response contains a large amount of structured information (namely, the catalog). Your response — your order — is also coarse grained, because you can order many different items, provide information about each item, as well as including your payment and shipping information, all in the same form.

Web Services are at their most powerful when they are used to exchange coarse-grained information between systems. Instead of large numbers of arcane API calls, an enterprise application can expose its functionality as coarse grained, business-oriented Web Services, with functions like “place order,” “get catalog,” or “get customer information.” Coarse granularity clearly depends on loose coupling, because the Web Service consumer does not care how the Web Service puts together the information it needs.

Coarse granularity is an idée forte because it is the key to business process automation. For companies to automate their processes, they must be able to work with business concepts from a business perspective. Business managers couldn’t care less about API calls; they want to work with coarse-grained business concepts like customers and orders. Web Services are the key to making this coarse granularity possible. Many current Web Services implementations are missing this point entirely by performing direct one-to-one translations of existing APIs into Web Services interfaces. Companies will realize a much greater ROI and business benefit by not only implementing Web Services, but by making them coarse grained.

Idées Fortes: Most Powerful in Combination
The mail order example of coarse granularity requires loose coupling, and is also an asynchronous process. It would be absurd to have to wait by the mailbox until your sweaters came, and likewise, it would be equally absurd if every small change at the sweater store required a rewrite of the order form. Web Services take these common-sense notions of how people and businesses interact and puts them into software. What’s so amazing isn’t that Web Services enable a new approach to distributed computing, but rather, why it took so long to incorporate such fundamental idées fortes into software!