[Editorial Draft] State in Web application design

Draft TAG Finding 15 February 2006

This version:
Latest version:
David Orchard, BEA Systems, Inc. <David.Orchard@BEA.com>


The purpose of the finding is to provide guidance to application developers on the use of State in applications in a Web context. .

Status of this Document

This document has been developed for discussion by the W3C Technical Architecture Group. It does not yet represent the consensus opinion of the TAG.

Publication of this finding does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time.

Additional TAG findings, both approved and in draft state, may also be available. The TAG expects to incorporate this and other findings into a Web Architecture Document that will be published according to the process of the W3C Recommendation Track.

Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org (archive).

Table of Contents

1 Introduction
2 What is State
3 State in applications
3.1 Browser State
3.2 Server State
4 Decisions
5 HTML examples
5.1 Abstract example
5.2 Example using HTTP Authentication
5.3 Example using URL Rewriting with session in the URL
5.4 Example using Cookies with client-side state
5.5 Example using Cookies with session ids
5.6 Stateful resource identifiers
6 XML interactions
6.1 XML example
6.2 Web service example
6.3 EPRs "on the Web"
6.4 Web services authentication state
6.5 Web services session
7 State decision factors
7.1 Ease of Application construction
7.2 Security
7.3 Scalability
7.4 Performance
7.5 Reliability
7.6 Network Performance
8 Conclusion
9 References
10 Acknowledgements

1 Introduction

This is a draft TAG finding on State. The purpose of the finding is to provide guidance to application developers on the use of Stateful or Stateless applications in a Web context. It examines a variety of designs for a canonical example application to illustrate the complex trade-offs in the designs. It uses HTML browser based and Web service based examples to show the similarities between the design decisions. The finding concludes with an analysis of the architectural property trade-offs between stateful and stateless applications.

2 What is State

State is the data that pertains to an entity at a particular point in time. A variety of software entities have state, ranging from applications to operating systems to network layers. The state of an entity changes over time triggered by some kind of event. The event could be a network message, a timer expiring or an application message. Entities that do not have state, that is there is no trigger that causes a transition, are called stateless. Most interesting resources have state of one sort or another, which is what allows them to provide interesting information when interacting with user agents on the Web. This finding concerns itself especially with the following kinds of state:

  1. Application state, which broadly is the state of a particular application;

  2. resource state, which is generally the state related to a resource identified with a URI. In the Web context, typically application state will align with resource state, that is the state of the resources is the state of the application. One aspect of resource state is sub-resource state, that is resources that do not (and arguably should have been) themselves separately identified by a URI...for example, a bank account that is identified by a bank account number stored in a cookie, rather than in a separate URI;

  3. per user or per session state, which can cause a resource to interact differently according to the user making the access or the network connection on which the request is received;

This finding starts from the perspective that truly stateless systems are uninteresting. Further, most systems that are advertised as stateless are actually incorrect characterized or they are doing state management someplace else in the system. The real questions of system design with respect to state is where and how the various types of state will be managed, and who has read/write access to the state. The decisions for state management are taken in the broader context of overall system design. This finding will look into how state, such as authentication information and application state, is exchanged in a Web and Web services context. It will examine the trade-off in properties between simplicity in server design versus simplicity in component design, and explore additional properties such as scalability, reliability, and performance.

3 State in applications

The state in an application may exist across a large variety of applications. A prototypical Web application will have a web browser communicating with a Web server. The Web server is the first point of contact for the application, which could consist static HTML pages, PHP generated pages from a mySQL database, a Java application running in an application server communicating with a high-end SQL database, and many more configurations. Despite many years of best efforts to insulate or abstract application design from the underlying components, it is a reality that the allocation of state to the components and the selection of components are directly coupled.

3.1 Browser State

The Web browser is one half of the design of state in a Web application, and it has specific state items that it can manage. It is important for our analysis to state that a client that stores data related to an application, such as username/passwords for URIs, is considered a stateful application. Web browsers are stateful clients because they store state, despite being typically mislabeled as "stateless". It is even more useful to analyze the type of state that browsers store and manage. Typically the web browser state is roughly related to the amount of information that the user has typed in or configured, which has natural limits. We find that generally the state managed by the web browser (aka web browser state) is not what one would consider large in today's computing terms. For example, web browsers are not storing multiple megabytes of data (like a digitized signature) per URI. There are additional state aspects of browser interactions that may be stored. There is a modestly popular firefox extension that will store and allow reload of the entire browser session, such as all the open windows. The pages being viewed is another application specific type of state that can be stored and managed. An incomplete list of state managed by web browsers is: cached pages; username/password per realm; cookies; form auto-complete data; previously viewed pages (history); currently viewed pages; home page; configuration settings such as text sizes, colors, fonts, etc.. This is a fairly extensive list of state being managed.

In addition to state that the application directly understands and manages, there is state that may be managed by the browsers but that is evaluated or interpreted at the server. A primary example of this is HTTP cookies. The state inside a cookie, including the variation where a session id is in the cookie, is opaque to the browser. It is the server application that has read/write access to the state.

3.2 Server State

Probably the primary entity that manages state is a server, from ftp to web to application server. [FOLDOC] provides a useful and interesting definition of stateful versus stateless servers. "A stateless server is one which treats each request as an independent transaction, unrelated to any previous request. This simplifies the server design because it does not need to allocate storage to deal with conversations in progress or worry about freeing it if a client dies in mid-transaction. A disadvantage is that it may be necessary to include more information in each request and this extra information will need to be interpreted by the server each time. An example of a stateless server is a World-Wide Web server. These take in requests (URLs) which completely specify the required document and do not require any context or memory of previous requests. Contrast this with a traditional FTP server which conducts an interactive session with the user. A request to the server for a file can assume that the user has been authenticated and that the current directory and transfer mode have been set.". This definition, while true, is very easily open to misinterpretation. Many of the Web applications that are built on top of a Web server are very stateful. They may have log-on sessions, application sessions like shopping carts, etc. that all use context or memory from previous requests. The design decision of a stateful application over a stateless connection (aka Cookies with Session IDs or EndpointReferences with Reference Parameters) versus a stateful application over a stateful connection (aka FTP) is a very detailed decision, and not nearly as obvious as it might seem.

This definition, and the subtleties contained therein, touch on the heart of this finding, which is that design state in systems is part of a complex task that requires detailed analysis.

4 Decisions

We now quickly go through the various decisions that are made in application design.


1. Is there application state


2. Where is application state stored?


3. Is there session state?


4. If no session state, does the client store any data, ie is it stateful?


5. If there is session state, does the client store the session state or an identifier for the session state that is stored on the service.

It is possible to never store the data on the client or the server. However, we almost never choose completely stateless clients and servers. In a browser based application, it would be very frustrating to enter username and password for every request. This is why the browser stores username/passwords, as well as cookies. Realistically, the choice is whether to store the data used to create the state, such as username and password, on the client or whether there is session state, such as "logged-in".

If the client is stateful (yes to question #4), then the data that is stored in the client is sent to the service for each request. If the decision is to store the state ( rather than data used to create the state), the next decision (#5) is whether the state is stored on the client or the server. Note that applications where the client stores data, beit data for recreating state or the state itself, are typically (and erroneously) called stateless applications, even though there is state on the client.


6. If session state stored on the server, how does client send the state identifier?

For Web messages, the location of the state id can only be in the URI, in an HTTP header or in the message body. We exclude the possibility of expressing state in the protocol operation or method.

A number of examples will show a variety of decision combinations for Web, XML and Web service technologies.

5 HTML examples

This section introduces an abstract example and various web browser designs to implement the abstract example.

5.3 Example using URL Rewriting with session in the URL

Dirk decides that a customized security screen is needed. A new page with the entry of username and password is inserted in the application, after the "show item" page in the state flow. At first, Dirk was going to have the URL contain the username and password. From a state analysis perspective, there is no significant difference between storing a username/password per URL or a URL that contains a username/password.

A key difference is security, so the URL containing username/password was rejected for obvious security reasons. Upon successful completion, the URL is rewritten to contain the state that the user has logged on. After the security page, any URLs in pages returned are rewritten to contain the state and the state is encrypted to prevent tampering and guessing. Dirk has quickly moved into a decision that the application will have session state.

The URL with session id approach has a significant downside as it is unlikely that URLs with a particular users login state need to be exchanged or bookmarked. From a modeling perspective, the resources that would likely be identified are accounts and particular transactions, not login state. If the user ever forwarded or bookmarked the URL, the login state will be useless at best and confusing and inefficient at worst. Also, it may be difficult for the application to have full control over the URL and do the rewriting, and it may be difficult for the application to parse the URL to extract the state. Stepping back a bit, the issue is that the application state (the account) and the session state( login state) may need to be independent for a variety of reasons.

5.6 Stateful resource identifiers

The previous examples explored the issues and designs related to session identification and transmission. As described in the URL rewriting example, the session information is probably not a stateful resource that requires an identifier. However, a particular user's account view, particular bank account or particular transaction is intuitively a stateful resource where the identifier could include the particular account or transaction identifier.

In the banking application with account state - moving on from the log-in state - there are 2 different account balance URI designs: one URI for all users or URI per user. The first design does not have distinct URIs for each of the user account balances. Rather, there is a "dispatch" URI and the particular user account requested is encoded in the request message or headers. For example, after logging in, the http cookie contains the user id. When the user requests the generic page, the particular user id is sent in the HTTP POST data.

The second design has a distinct URI for each of the user ids. The user clicks on the login, and this redirects them to a unique URI for their account. The URI per account design, sometimes called "deep-linking", has all the network effect advantages that the web has to offer: the users account is bookmarkable, exchangeable, etc.

It does suffer from potential increased complexity as it may be easier to populate and parse the data from someplace other than the URI, such as FORM POST or cookie data. Another problem with selecting a URI that takes them to say 'cleared checks for my savings account' then if the website is redesigned (a frequent event, at least on the back end) then that URI will break. Either that or the website has to maintain complex mapping tables to handle versioning URIs across multiple versions of the website. Hence many websites would rather just force users to come in through a well defined home page and then focus on making navigation as easy as possible to get them quickly to where they want to be.

It is worth noting that the application has 2 different types of state information that are being identified: the account balance and the session state. By putting the account id in the URI and keeping the session id separate, the application has achieved a separation and the different benefits achievable from the transient session information and the network effect of re-usable URIs.

6 XML interactions

The previous examples showed how browser based technologies support stateful clients and session based interactions. There are also the same issues in XML interactions.

6.1 XML example

Dirk is tasked with making the banking application available as a Web service rather than HTML pages. He uses XML to do this. All the possibilities shown in the previous HTML example are available for returning XML. For example, he could use HTTP Authentication to return an XML document with the balance.

However, XML gives him the option to also send XML in the HTTP Body. He steps back and decides that the banking application is a service with an interface containing two operations:log-in and getBalance. The first operation is a log-in operation. If successful, it returns an XML document containing a session ID that client should use for requesting the account information.

TBD need WSDL. Need more motivation on this part, related to WSDL.

A request to the service, such as "GetBalance", might have a fragment like:

Dirk must know the "choreography" of these interactions, particularly that the sessionId in the loginResponse is used for a following GetBalance request.

Alternatively, the session Id could be represented as an HTTP Content-Location header

TBD. Lots of notes on this design.

6.2 Web service example

Dirk is tasked with making the banking application available using SOAP and WS-Addressing technologies in addition to XML and WSDL. The first operation is a log-in operation. If successful, it returns a WS-Addressing "ReplyTo" containing an EPR that client should use for requesting the account information. The EPR contains a reference parameter that contains the session id and a reference parameter that contains the account id.

A request to the service, such as "GetBalance", might have a fragment like:

Alternatively, the CustomerKey could be encoded in the address property in the EPR

7 State decision factors

The decision on where to place the state in the distributed application and how to identify the state are affected by numerous factors. Some of the key considerations are scalability, reliability, network and application performance, security, ease of design and promoting network effects on the World Wide Web, I.e. leveraging and contributing to a single, global information space

Roy Fielding argues in his REST dissertation [REST] that stateless server has the benefits of increasing reliability, scalability, visibility and while potentially decreasing network performance. However, I believe the trade-offs from an application developers perspective are somewhat different, and need to be examined from a holistic perspective.

7.1 Ease of Application construction

There are two primary types of designers that are relevant: the network administrator that controls the deployment of applications and publication of URIs, and the application developer that controls the contents of messages including http headers. The application developer can develop the application without affecting the URI with the state id information and so avoid a potential conflict with the administrator.

Many, if not most, applications are built to exchange state information that is not "identifying" information, such as session ids. This is evidenced by the widespread use of HTTP Cookies. In the cases where these applications are also exchanging identifying information, the application development is simpler when the same mechanisms are used for exchanging both types. Examining the Web example, the application developer can easily insert and parse information in the cookie header, rather than rewriting the URI that is sent.

In the Web services example, it is very easy to do dispatch based upon a soap header block, which is an XML QName. The tree-like structure of XML and use of SOAP and SOAP Header blocks means that an application developer can use widely available tooling, such as JAX-RPC handler chains, that makes it easy to use the XML QNames. On the converse, there are no standards available for inserting or parsing a QName(s) into or from a URI.

It is worth explicitly noting that there is a trade-off between the control over the URI versus other parts of the message body, and a trade-off between the ease of updating/parsing URIs and the other parts of the message body.

7.4 Performance

Performance is the time to complete a given request for a given load on a system. Performance and scalability are often coupled together into the notion of "availability". The performance/scalability trade-off is whether the cost of acquiring the necessary resources for a request is best served with the state on the client or on the server, and that completely depends upon how the resources are freed up and then re-allocated.

In the simplest case, it may be that not freeing up the resources for an amount of time (aka caching) is the most scalable. Keeping the state in memory, with a time-out optimized for typical client latency, can scale better than release resources when the time-out is set correctly and the resource acquisition/freeing is significant. Anecdatally, Jim Gray has observed that 5 minutes has been a historically accurate cut-off time for caching in memory rather than persisting to disk.

In other configurations, it may be that it is "cheaper" to free up resources by responding with the session id in the response and persisting the data to the database rather than responding with the entire state to the client because the "cost" of transmitting to the client is more expensive than the cost of sending to the database. Likewise, it may be "cheaper" to reify the session by acquiring it from the database than from the client.

However, the cost of freeing up state and recovering state is based on a variety of factors, specifically the system architecture and the connections to the client and database, the middleware software, the database software, and hardware/software platforms used for the system.

The optimum performance/scalability curve is flat, that is the performance of a request does not vary with the # of requests. However, this is typically impossible so a linear curve is the most desirable. The usual difficulty in scalability is the performance under heavy load. Typically the performance, which is very undesirable, is for an exponential decay in performance as the systems scalability limits are reached.

TBD: slight discussion on clustering with session ids?

A goal of high end systems is to provide high performance, high scalability, and linear decay in performance. This may be only possible with a stateful configuration with components like a "write-through" cache.

TBD: elaborate a bit on stateless going to the DB vs stateful perf. elaborate on modern load balancing/session mgmt doesn't mean state is "pinned"

7.5 Reliability

Reliability of Stateful applications has two distinct aspects: reliability of the machines and reliability of the network. The reliability of the network is not typically a factor in the design of the application style, as it is typically assumed that the network is unreliable. The aspect of reliability that concerns this writing is machine reliability. For a given client, the two time periods of interest are during a request and in between requests.

In a stateless application design, a machine can fail between a request without affecting the clients view of the system. They send a request and it is dispatched to an available machine. If a machine has crashed in between requests, there is no disruption.

In a stateful application design, the systems can be designed to handle failures between a request. Common techniques are duplicating the state _ RAID disks, back-up nodes _ and hardening the system _ UPS, memory checksums, etc. For example, an application server can have a primary and backup node. If a machine fails, then the backup node is used for subsequent requests.

Stateful and stateless application design must deal with the situation of where a machine crashes during a request. In stateless applications, typically the request is lost. Let us make a simplifying assumption that the request is "atomic" and is either completed or aborted. This allows us to avoid the problem of determining application state where the problems of meaning of reliability in a synchronous environment arise. Many systems are designed to handle machine failure during processing by having a stateful "dispatcher" that has tracked the request and can replay the request to a different machine if one fails during a request.

Related to Reliability is manageability, as systems are often managed for reliability. For example, a component may be starting to behave erratically and the administrator wishes to replace the component. Stateful and stateless systems would probably be designed for this task by letting the requests "drain" off of the system that is due for maintenance. A stateful system has the downside that the states may be long-running and hence take longer to "drain". Advances in application server technology provide for managing these by supporting "transferring" state from one machine to another.

The discussions so far have not discussed "client" reliability. Web based systems typically have a simplifying assumption that browsers are for a single user, are unreliable, and responses must be received within about 30 seconds for good HMI design. We have made a simplifying, but erroneous assumption that systems where the client has the state are "stateless". The state always exists somewhere, and in many EAI and B2B systems, the web based simplifying assumptions are not true. The system, whether it is the client or the server or the network, must contain the state. Imagine a system where the client keeps the state for long periods of time, it must deal with reliability of the state information. If a machine crashes, the system can't lose the state.

Stateful systems can deliver virtually the same reliability as stateless systems, it is more appropriate described as a matter of cost. A stateful system may require more costly infrastructure in the form of components selected to achieve the same reliability. On the other hand, the difference between the reliability for a stateless system versus a stateful system may be small given the overall reliability desired.

TBD: Improve text to hit the point that many systems are not like the human-centric web wrt state that is cached..

8 Conclusion

This Finding describes a number of questions, decisions and rules for using state in Web and Web service architecture and design. The main goal of the finding is to describe the choices facing developers with a describing of the properties of interest and some of their trade-offs

9 References

Free Online Dictionary of Computing (See http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=stateless&action=Search.)
Henry's EPR example. (See http://lists.w3.org/Archives/Public/www-tag/2005Nov/0008.html.)
REST dissertation, Dr. Roy Fielding (See http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_4 .)
TAG Nov f2f EPR discussion. (See http://www.w3.org/2001/tag/2005/12/06-Afternoon-minutes.html#item05.)
RFC 2616, HTTP. (See http://www.ietf.org/rfc/rfc2616.txt.)
RFC 2617, HTTP Authenticaiton. (See http://www.ietf.org/rfc/rfc2617.txt.)
SOAP 1.2
W3C Recommendation, SOAP 1.2 Part 1: Messaging Framework (See http://www.w3.org/TR/SOAP/.)
WSDL 1.1
W3C Note, WSDL 1.1 (See http://www.w3.org/TR/WSDL/.)
XML 1.0
W3C Recommendation, XML 1.0 (See http://www.w3.org/TR/REC-xml.)
XML Namespaces
W3C Recommendation, XML Namespaces (See http://www.w3.org/TR/REC-xml-names.)
WS-Security (See http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.)
WS-Security Username Token Profile (See http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf.)
WS-SecureConversation (See http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf.)

10 Acknowledgements

The author thanks the many reviewers that have contributed to this document, in no particular order: Mark Baker, Dan Connolly, Alexander Macaulay, Noah Mendelssohn, Gilbert Pilz.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.