Of state handling, part II

This is a continuation of the post Of state handling, part I published last month.

In Orbeon Forms, the XForms engine is split between the web browser (client) and the server. Client and server communicate with each other through Ajax. The client is relatively simple and written entirely in JavaScript. The server is written in Java, is smarter and does most of the XForms processing. While the client keeps a few data structures in JavaScript, in addition to the HTML forms and HTML DOM which themselves contain some information, the server represents XForms document as Java objects, including a tree of controls, XML DOMs, and more.

So naturally with such an architecture you have two places where you could store state information between requests: the client, or the server. In fact, Orbeon Forms allows you to choose where to store the state. Each solution has benefits and drawbacks. Mainly, storing the state on the client require more information to travel between client and server; and storing the state on the server requires more memory on the server, typically linked to the user's session.

Client state handling is not a trivial thing to do:

• When sending state information from the server to the client, you can't just send Java objects out as is: you must "serialize" them, that is represent them as a string of characters.

• The data sent must be as small as possible, so you must be smart and try to send the minimal amount of information possible. For this reason, in Orbeon Forms we do not rely on Java serialization for this task. In addition, Orbeon Forms uses gzip to compress the resulting information.

• Data sent to the client must also be encrypted, so that nobody can crack into your application by sending the server tampered state information.

• In addition, when the client sends back state information to the server, the server may take time to deserialize or restore internal data structures therefore impacting responsiveness. To alleviate this issue, orbeon Forms uses a document cache which contains live XForms documents and which allows bypassing this deserialization in most cases.

In the next installment, we'll look at the challenges of session state handling.