Powerful Web Services Through Composition -- web-calculus

developer

Web

REST

HP Talk

web-calculus

Powerful Web Services Through Composition

2003-10-01

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.

Abstract

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.

Introduction

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.

What is the WWW?

The WWW is a shared information space. It provides users with a means to:

structure information
reference information
retrieve information

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.

What is a web service?

A web service is a common command interface. It provides users with a means to:

describe a command
express a command
deliver a command

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.

Common challenges

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.

Voluntary participation

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.

Independent participation

No central control over application deployment on the Internet exists. Changes in the application protocol will only be deployed slowly, if at all.

Anarchy

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.

Impromptu collaboration

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.

Routing

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.

Physical network

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.

Common constraints

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]

Data-centric

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.

Stateless

In REST, a transaction that moves the server from one valid state to another is fully expressed in a single request.

Requiring a server to maintain transaction state across multiple requests increases the server's vulnerability to misbehaving client software and network partition.

Uniform resource identification

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.

Hypermedia

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.

Uniform interface

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 web

The Hypertext Transfer Protocol (HTTP) defines the uniform interface for manipulation of the WWW hypermedia web. [RFC 2616]

Structure

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: A target resource in the HTTP hypermedia web.

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.

Interface

All HTTP methods are defined in terms of the hypermedia resource web.

The GET method fetches a representation of the target resource. The HEAD method fetches only an abstract of this information.

The PUT method replaces the target resource with another.

The DELETE method deletes the target resource.

The OPTIONS, TRACE and CONNECT methods operate on the path that the request travels to the target resource.

The POST method submits information to be processed by the target resource.

A lambda-calculus derivative

Recognizing the primacy of the resource web in HTTP reveals that the WWW is a lambda-calculus derivative. A resource is a closure. The POST method is the "apply" operation. A web of resources is a web of closures. The key innovation of the WWW is the addition of introspection of the web of closures: the GET method.

The web-calculus web

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.

The web-calculus is derived from HTTP by adding a description mechanism. [web-calculus]

Structure

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: A web-calculus diagram.

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.

Interface

The web-calculus uses a subset of the HTTP interface. In particular, the PUT and DELETE methods are omitted.

Benefits

Using the WWW as a substrate for web services yields important benefits for deployment and synergy with existing development practices.

Implementation leverage

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 an application/x-www-form-urlencoded syntax. The latter syntax allows existing web browsers to be first class participants in a web-calculus application. Through compatibility with web browsers, the most widely deployed client software, the web-calculus has made itself the most widely deployed web services standard.

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.

Conceptual leverage

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.

Conclusion

The WWW provides a powerful substrate upon which to build a web services platform. By extending the WWW, the web-calculus gains:

the Internet-scale properties of the WWW
a proven and widely deployed request routing mechanism
a massive installed base of client software
a wide collection of tools for building servers
a popular and successful development style

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.

References

[REST] R. Fielding; "Architectural Styles and the Design of Network-based Software Architectures"; Doctoral dissertation, University of California, Irvine; 2000.

[RFC_2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee; "Hypertext Transfer Protocol -- HTTP/1.1"; RFC 2616; June 1999.

[web-calculus] T. Close; "web-calculus -- Calculus"; <http://www.waterken.com/dev/Web/Calculus/>; March 2003.

top