project page, javadoc, install, mailing list, news

Waterken^TM 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

• web-key: Mashing with permission
• Joe-E: A Security-Oriented Subset of Java
• upgrade: Live fast, die young and leave a good-looking corpse
• clickjacking: The Confused Deputy rides again!
• ACLs don't: The ACL model is unable to make correct access decisions for interactions involving more than two principals…

A tour of the ref_send API

• org.ref_send: Document-oriented design
• org.ref_send.promise: An introduction to promises
• org.ref_send.promise.Eventual: The eventual operator
• Beat.java: An introduction to eventual operations in Java
• web_send: JSON shell for the browser
• Bang Tutorial: An introduction to eventual operations in Javascript
• web_send wsh: JSON shell free from Same Origin Policy

Advanced play with the ref_send API

• Factorial.java: tail recursive factorial
• A FIFO queue, where elements can be removed before they've been added.
  • Series: an infinite series interface
  • PopPushN.java: using an infinite series
  • Serial.java: an infinite series implementation

Working with the Waterken server

• subclipse setup: Using Subversion with the Waterken server under Eclipse
• deploy: Deploying the Waterken server
• debug: Debugging a Waterken application