Maintaining State in 
Enterprise Systems

 

One of the fundamental characteristics of the World Wide Web and HTTP is that it is a stateless architecture.  Neither the protocol nor the original specifications for Web servers included provisions for preserving information about a user or a previous interaction from one request to another. The primary reason for this limitation seems to have been simplicity, and it may have been one of the factors that was responsible for the early, broad acceptance of the Web.

However, as developers began to incorporate dynamic content into Web pages, particularly content derived from databases, the need to include information from an earlier transaction in the current one became apparent.  One of the most obvious is the notion of a session associated with an identified user, e.g., a subscriber or someone authorized to view certain data.

The problem and the need for increasingly flexible mechanisms is greater for enterprise systems in which the WWW serves as a common interface and distributed systems framework for a broad range of distributed services rather than a simple data delivery system.

The goal of this discussion is to stimulate thinking and discussion about the different kinds of state enterprise systems may need to maintain.  In turn, it addresses different locations in the architecture where state may be preserved and different approaches and tools for doing so.

Motivation

What types of state can you infer are being maintained by this sometimes available server?

Generic Enterprise Architecture

 

 

Types of State (Information) to be Maintained

UserID

SessionID

WindowID

User Preferences

Multi-Valued Transactions

Persistent Data

Questions

  1. Which of these types of state will need to be maintained in your project or in an identifiable enterprise system?
  2. Where in the architecture could each be preserved?
  3. Where is the best place to preserve it?
  4. What techniques or tools could be used for each?

Tools and Techniques

Hidden Fields in Forms

Perhaps the simplest and lowest overhead approach for maintaining state by passing information back and forth between the enterprise system and the client on each interaction.

Servlet Sessions

An approach similar in strategy to hidden fields but based on Java supporting classes and on cookies passed back and forth on each interaction.  Dependent upon user's browser accepting cookies.

Application Maintained Object

Maintains state on the server side, rather than passing back and forth to client.  May be used in conjunction with additional state passed back and forth.  Useful for maintaining retrieved data that is not immediately sent to client and for maintaining expensive resources such as database connections for multiple accesses.

Stateful Session EJBs

Stateless EJBs are likely to function similar to static methods, be implemented as pooled objects, and be created as needed by clients.  By contrast, stateful EJBs are likely to be created once by a client, who maintains a persistent connection to the EJB for the lifetime of the client, and to serve a single client.  One use is to accumulate multiple values needed to complete a transaction before invocation of that transaction.

WebSphere Sessions

Since a given WebSphere system may include multiple nodes and multiple servers, approaches that assume user interactions will come through the same server may not hold.  Consequently, WebSphere includes internal support for session management that can be accessed from any node.  See Brown, et.al., Chapter 8 for additional information, and stay tuned.

Entity EJBs

Old Hat.  You know about this as the technology for maintaining long-term data, generally implemented in some DBMS, defined and accessed through a Java object.