Powerful Web Services Through Composition
This document shows how the web-calculus is derived from the REST architectural style that underlies the World Wide Web (WWW). The advantages of this approach to web services are highlighted.
The WWW has contributed powerful architectural principles to the problem of providing scalable, inter-organizational information sharing. The web-calculus is a web services model that applies the WWW's REST design principles to the problem of providing scalable, inter-organizational services. By conforming to the WWW's design, the web-calculus additionally leverages the existing WWW infrastructure. Unlike other web services models, the web-calculus turns existing WWW browsers into fully functional web services client software.
Presentation of the web-calculus begins by characterizing what the WWW is and what a web service is. With an understanding of the objectives of the WWW and web services, the common design challenges can be enumerated. This enumeration reveals that the difficult challenges arise from the realities of Internet-scale computing. Given that the WWW enjoys considerable success as an Internet-scale application, the design constraints followed by the WWW may be of value in the design of a web services model. Derivation of the web-calculus begins by identifying those REST design constraints that are also applicable to a web services model and motivating use of those constraints.
A primary motivator in applying REST design constraints is reuse of a successful architectural style. The growth of the WWW can partly be attributed to the success of composition as a means for managing complexity. Sophisticated web sites are composed of many individual resources that are linked together to form a cohesive whole. Composition, or linking, is a development style with which today's developers are very familiar and successful. By following in the footsteps of REST, the web-calculus extends this development style to the realm of web services.
The WWW is a shared information space. It provides users with a means to:
The great success of the WWW is its success at providing a "shared" space. Clients can retrieve information from the space in a way that is independent of the particular information provider.
A web service is a common command interface. It provides users with a means to:
The great hope for web services is that it will provide a "common" interface. Clients will be able to issue commands in a way that is independent of the particular service provider.
The WWW and web services are flip sides of the request-response interaction.
The WWW is primarily for "pulling" information. The primary focus of interest is the response that contains the requested information. The request is simply an identifier.
A web service is primarily for "pushing" a command. The primary focus of interest is the request that specifies the command. The response is simply an acknowledgement of the success or failure of the command.
The common requirement of processing requests and responses on the Internet gives rise to a number of common challenges.
In an Internet-scale application, potential participants independently make a decision to participate. In each case, the benefits of participation must greatly outweigh the costs. Success of the application depends upon low barriers to entry.
No central control over application deployment on the Internet exists. Changes in the application protocol will only be deployed slowly, if at all.
On the Internet, some participants are attackers. Independently developed implementations must interoperate without vulnerability.
Malice is not required to make an attacker of a participant. Independent implementation means that expected behavior cannot be relied upon. A vulnerability may be exploited by a bug or an attack.
The value of an Internet-scale application comes from the network effects that arise from impromptu collaboration. Impromptu collaboration requires that the parts produced by a participant support unforeseen composition with those produced by others.
In a large application, the mechanism for routing a request must scale to large numbers of clients and servers. Source routing is not a scalable solution.
A distributed application must cope with the realities of a physical network. A physical network is vulnerable to network partition and subject to high latency between sites.
The challenges of an Internet-scale application are formidable. The WWW is our best example of an application that has successfully coped with these common challenges. These successes can be duplicated for web services by adhering to the REST design constraints of the WWW. [REST]
In REST, interoperation is achieved through specification of the data transferred between the client and server. This data-centric approach enables independent evolution of the execution model on the client or the server.
Independent participation makes stability of the client-server interface crucial. Stability requires independence from changes in the execution model on either the client or the server.
In REST, a transaction that moves the server from one valid state to another is fully expressed in a single request.
In REST, a resource identifier embodies the information required to distinguish a request target from all others. This mapping is consistent across all contexts: an identifier has global scope.
The Uniform Resource Identifier (URI) is the basis for an extensible mechanism for configuring generic request routing infrastructure.
In REST, state is represented as a web of linked resources. A client navigates the web by fetching a resource representation and following contained links to other resources.
The WWW has demonstrated the power and accessibility of linking as a means for structuring complex information.
In REST, there is a uniform interface for interaction with any resource.
To be part of a uniform interface, an operation must not be specific to a particular type of resource. Being resource-independent requires that an operation be defined in terms of the resource web. The only commonality between disparate resources is their presence in a web of hypermedia resources.
The uniform interface constraint means that the resource web is primary: all interaction is expressed in terms of the web of linked resources. This pervasive model enables composition through the creation of webs.
The HTTP hypermedia web is composed of resources identified by URLs. Using a URL, a client can fetch a representation of the resource. The representation is a snapshot of the current state of the identified resource. The representation may contain links to other resources.
Figure 1 depicts an HTTP hypermedia web. A URL is depicted as an arrow. A representation is depicted as a circle. A resource is the point of contact between an arrowhead and a circle.
All HTTP methods are defined in terms of the hypermedia resource web.
Recognizing the primacy of the resource web in HTTP reveals that the WWW is a lambda-calculus
derivative. A resource is a closure. The
Understanding HTTP as a lambda-calculus derivative opens the possibility of using HTTP as a basis for distributed computation, not just distributed hypermedia. The lambda-calculus is a universal computing model that has been a focus of study since before the dawn of computers. Building a web services model atop an Internet-scale, lambda-calculus system is a promising approach.
A hypermedia web supports retrieval of bit streams by human clients. A web service must support exchange of data structures by programmatic clients. Extending the existing hypermedia web to support web services is simply a matter of supporting description. A programmer requires a description of the structure of the web to be manipulated. This description is used to write the static program code that will traverse the web to access a target resource. The programmer also requires a description of how a data structure should be serialized to a bit stream for delivery to a target resource.
In the web-calculus, each type of representation is identified by a URI. The schema identified by this URI gives a static name to each of the outbound links from such a representation. The meaning of each name is local to the defining schema.
A schema is used to describe both the structure of a representation and the structure of an argument. In the web-calculus, as in the WWW, an argument is itself a representation.
Figure 2 follows the same conventions as Figure 1. In addition, each representation is annotated with its schema URI. Each link is annotated with the corresponding name from the defining schema.
The web-calculus uses a subset of the HTTP interface. In particular, the
Using the WWW as a substrate for web services yields important benefits for deployment and synergy with existing development practices.
Since a web-calculus web is an instance of an HTTP web, the existing WWW infrastructure is leveraged.
The web-calculus reuses the URI-based web structure of the WWW. The existing WWW infrastructure for request routing is reused by the web-calculus.
The web-calculus reuses the generic interface of the WWW. Existing client applications can manipulate a web-calculus web in the same way they manipulate existing hypermedia webs.
An XML surface syntax can represent a web-calculus web, as can
Existing browsers, scripts, and CGI environments are valuable tools in a web-calculus application. The web-calculus breathes new life into the existing WWW infrastructure by creating new uses for these tools.
A web-calculus application is built through the creation of a web, the same model used to build WWW sites.
"Powerful Web Services Through Composition" means "Powerful Web Services Through Linking". Today's developers have succeeded in the creation of the WWW through the iterative process of creating small resources and composing (linking) them together to make a greater whole. The web-calculus enables the use of this same development style for the creation of web services.
The "View Source" command is an important learning tool for WWW developers. Using this command, a developer can learn how a sophisticated web page works by studying its composition. By adhering to the same web structure as the WWW, the web-calculus enables "View Source" for web services. A developer can learn how a high level resource works by studying its composition.
A typical application involves both information retrieval and command processing. By extending the existing WWW to support web services, the web-calculus provides a unified model. If competing models were used for information retrieval and command processing, difficult impedance mismatch issues could arise.
The web-calculus is a web services model that has synergy with the WWW.
The WWW provides a powerful substrate upon which to build a web services platform. By extending the WWW, the web-calculus gains:
This document provides an overview of the web-calculus. The finer details of the model are provided in a collection of specifications defining the document model and the web-calculus. See these document collections for more in-depth information.
Copyright 2003 Waterken Inc. All rights reserved.