State and Session Management

All Uniface server pages are stateless and therefore need to explicitly store and manage state information so that it is available for the duration of the HTTP session. To understand session and state management in Uniface, it is useful to examine what happens with state information in the course of an HTTP session.

HTTP Sessions

The HTTP protocol used by all web browsers is stateless, meaning that each HTTP request from the browser to the application is processed on the server with no knowledge of the previous request. Once the response has been sent back to the client, all data that the server had while processing, is lost.

An HTTP session provides a way to identify a user across more than one page request (or visit to a web site), and to store information about that user. Typically, a session starts when the user first submits the URL of an application. This is the first step in the first HTTP request-response cycle of the session. The following illustration

Session Life Cycle with HTTP Requests

HTTP Request-Response Cycle

  1.  The browser send the first HTTP request-response cycle of the session.
  2.  The Web Request Dispatcher (part of the WASV) interprets the HTTP request, and because it is the first request from this browser instance, it generates a session ID and dispatches the page request to the Uniface Server to process (the UServer request).
  3.  The Uniface Server activates the server page and returns the response (Userver response) to the WRD.
  4.  The WRD dispatches the HTTP response back to the browser, along with the session ID, which it places in a cookie, as well as optional state information.
  5.  When the user submits another request, the session ID and user state information is included in the new request. This enables the Uniface Server to restore the server page with the required state. At a minimum, this is the session ID.
  6.  The HTTP response that is returned includes the session ID and updated state information.
  7.  The HTTP session ends when the browser is closed, when the session expiry time is exceeded, or when the user logs out (assuming a logout mechanism is provided).

State Information

When developing web applications, you need to decide what state information is required, and how it should be maintained. Most state information can be managed or accessed using $webinfo.

Note:  Dynamic server pages (DSPs) support more types of state information than static server pages (USPs).

Types of State Information
Type of State Description Access DSP USP
Session ID Session identifier generated by Uniface the first time it receives an HTTP request for a server page from a browser. The session ID is unique to the browser instance, so if a browser remains open, the next user to use the browser has the same session ID. It is used to bind state information to the current session.

The session ID is automatically included in all HTTP requests and responses between the browser client and the server, but it needs to be manually included if you are managing state in temporary files or tables.

 Accessed using the SESSION property of . $webinfo ("WebServerContext") ü ü
Client state Information that is required by the application to maintain client context. It can include long term state such as user preferences, or short-term state such as a query or certificate.

Client context information is typically managed using cookies or temporary tables, depending on the amount of data, its purpose, and security requirements.

For more information, see State Management Mechanisms.

 Client state stored in cookies can be accessed using the USERCONTEXT, COOKIESIN and COOKIESOUT channels of $webinfo

For more information, see $webinfo: Cookie Topics.

 ü ü
Session state Information that can be shared between multiple HTTP requests for the duration of the session.

This data consists of name-value pairs called session attributes that are maintained by the WRD.

For the duration of the session, any application that can access the J2EE container (the servlet engine) can also access the session attributes. This can be useful if you are using, for example, a Java application instead of a Uniface component for authentication.

 You can set and delete session attributes using the SetAttributes and DeleteAttributes properties of .$webinfo ("SessionCommands")

You can examine session attributes using the SESSIONATTRIBUTES property of $webinfo ("WebServerContext")

ü  
Request state Information that can be shared between an HTTP request to a DSP and other DSP instances activated by WRD callback requests.

The Uniface Server creates the request state when it first receives the HTTP request, and destroys it when it returns the response to the browser.

By instructing the WRD to activate a callback operation, the Uniface Server can update the request context of the DSP with state information that has been updated by other DSPs.

To get or set the request state information you want to share between the first HTTP request and possible callback requests, use $webinfo("REQUESTCONTEXT").

For more information, see $webinfo ("RequestContext").

To activate a callback operation, use the WrdActivate property of $webinfo("SESSIONCOMMANDS").

ü  

Scope of State Information

Client state is known only to the browser until an HTTP request is submitted. Any state information that is needed or stored on the server is included in the request so that the Uniface Server can execute the server page and match its state to the client state before processing, and then returning the updated state information in the response.

For DSPs, it is possible for the response to instruct the WRD to activate callback operations on component instances (of the same DPS or of difference DSPs). The WRD can be called several times while the HTTP request is processed, and during that time, the request context is used to share information between the current request and any callback requests. The response is returned to the client only when the reponse returned by the originating DSP does not contain a callback request (wrdActivate).

The following illustration shows the session and request boundaries that determine the scope of session state and request state.

HTTP Session and Request-Response Boundaries

HTTP Session showing HTTP request-response cycles and state

  1.  Client state is maintained by the web browser. Relevant client state, such as data, is included in HTTP requests.
  2.  Session boundary (purple line). Created by the first HTTP request, it usually remains for multiple HTTP requests.
  3.  Session state is held by WRD and is available to all HTTP requests in the session.
  4.  HTTP request boundary (blue line). Basic request and reponse. All state information is held in the DSP. Request state is empty.
  5.  HTTP request boundary (blue line). Request includes WRD callback requests that activate other DSP instances.
  6.  Request state is used to hold shared information. It is destroyed when the HTTP response is returned.