project page, javadoc, install, mailing list, news

WaterkenTM Server

Asynchronous messaging between event loops, such as used in AJAX, is a great model for building distributed applications. The asynchronous messaging allows an application to remain responsive in the face of network latency and event loops allow multiple activities to be pursued, without many of the dangers inherent in multi-threading. This computing model is made even better with the addition of promises, a kind of reference that can refer to the result of future computation, such as the response to an asynchronous message. For example, promises make it a lot easier to express an algorithm that sends additional asynchronous messages depending on the results of past messages. The Waterken server provides a platform for building such applications in Java and making them accessible to HTTP-based clients.

Server-side Java code is written to the ref_send API, which defines the asynchronous invocation interface. The Waterken server implementation of the ref_send API provides orthogonal persistence and across-the-network transport of asynchronous invocations. Each invocation is sent as an HTTP request: either a POST for an update, or a GET for a query. The request URL fully identifies the invocation target and any arguments are carried in the request body, encoded in JSON. A JavaScript implementation of the ref_send API facilitates interaction with server-side objects from within the browser. For an example interaction, see the Bang Tutorial.

The Waterken server supports use of capability-based security to control the actions of both server-side objects and remote clients. The ref_send API is designed for use by code that passes the Joe-E verifier. Using this verifier, capability-based auditing techniques can be applied to bound the possible effects that can be caused by a server-side object. The Waterken server implementation itself also passes the Joe-E verifier. A remote client can only access a server-side object via a cryptographically protected capability URL, called a web-key. By reasoning about what web-keys a remote client may come to possess, the possible effects on server-side objects can be bounded. Though the Waterken server is designed for use with the Joe-E verifier, it can still be used with code that does not pass the verifier.

Concepts

A tour of the ref_send API

Advanced play with the ref_send API

Working with the Waterken server