Infrastructure for Stateful Web Applications

1 Introduction 2 Horizontal Scaling 3 Stateless Applications 4 Stateful Applications 4.1 Sessions 4.1.1 Stickies 4.1.2 Session Sharing and Replication 4.1.3 Client Side State 5 Recommendation

Introduction
This describes the different web infrastructure that could be used to support stateful web applications and the implementation strategy that is recommended by the Web Support team. A stateful web application maintains states between pages over a period of time. These applications typically have logins and/or are required to keep track of the state the web session. Examples are applications that does flight booking, muliple page flight searches, multiple page finance computations and shopping carts. Stateless applications are generally less complex and easier to implement. They also tend to be easiser to scale horizontally. While it is desirable to have less complexity associated with an application, business requirements will ultimately dictate the need to have stateful applications. The objectives of this paper are 1. Informational - to enable better design decisions in development, to help management make resource decisions and business impacts. 2. Provides a guide for implementation - helps the implementers to understand the underlying design concepts 3. Support - enables better support decisions that will help evaluate impact of restarting of multi-noded statless web applications.

Horizontal Scaling
Scaling a web application refers to the ability to add resources to enable the application to meet its performance requirements. When an application is deployed there are 2 ways to meet its initial resource requirements. One way is to provide sufficient resources locally to the deployed node. Example of which are added more memory or CPU. This method is also commonly call vertical scaling. The other way is to have it scale horizontally by having more servers for the application. This requires that the service be distributed across multiple machines. Horizontal scaling could easily be achieved if the application is stateless. It can be done by simply having a load balancer in front to distribute requests to the service across the configured servers. In theory horizontal scaling is only limited by how many machines you have available for the application. It is is massively scalable, quick to add or reduce the system capacity with minimum or no impact to business continuity. It is also robust because it provides multiple points of failures. For these reasons horizontal scaling is the preferred way over vertical scaling.

Stateless Applications
If at all possible an application should be stateless as it will be simply deployments and configurations. but maily it works really well with horizontal scaling. A stateful application can usually be made to behave like a stateless application. This can be done by example by keeping the states on the client (browser) of the web application by using application cookies. Encryption could be used to make it more secure. This is the client side state describe below. Basicaly state is kept in some sort of user cookies on the client (see diagram). .

Stateful Applications
Sessions
Application states are usually kept in session objects provided by the application container. E.g Jave provides sessions objects which provides the abstraction into the container session objects that Tomcat, Weblogic, Jboss or WebSphere provides. There are basically 2 ways to implement a multi-node stateful application. One way is session sharing the other is to use sticky sessions.

Stickies
Sticky sessions is the simplest way to implement a stateful application. Normally the load balancer in front of the application node will either select the node to send the request to based on whatever algorithm that is configured for it. Since there is no garantee that the same node will be used each time a new request is made, any context or state that is kept on the node could potentially be lost. Using sticky sessions (implemented by cookies), the same end node or any intermedia nodes will be used each time a request is made. This enables state to be kept in the nodes between muliple requests. The down side to sticky sessions is that when a node goes down, the user will loose states stored in the node sessions. E.g. A User hat to relogin when a node is restarted.

Session Sharing and Replication

Session sharing is another way to support stateful applications. Session sharing can be achieved by application server level clustering or having persistent data store for the sessions. Sessions are replicated across the clustered nodes to provide a single application view of the session. Session replication is inherently plagued with complexities (square) and susceptble to underlying instabilities. It should be avoided whenever possible. Persistent sessions/states basically means a copy of the "session/state" is stored in either a shared file system or database and will be accessed by all the application nodes. It can either be implemented in the application or by the application container. In general it would be better to use the persistent service provided by the application container. Unfortuately the current implemenation of session persistance by tomcat/(and likely Jboss) is inadequate. There are issues related to stale session state accross nodes.

Client Side State

Alternatively, the state of an application can kept on the client side by storing data in user cookies. This can be made more secure by encyption.

Recommendation
None of the implementation strategy by themselves are adequate to support seamless stateful application. The recommened approach is to use a combination of sticky sessions and persistent sessions for 1) application that requires totally seamless stateful nodes. 2) sticky session for stateful nodes that could tolerate short temporary loss of service.

Persistent session places additional coupling and resource requiements and should be a avoided if seamless stateful nodes are not required.