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.