Managing application state across an HTTP request sequence

XCICS initiates a new alias transaction and a new program for each request made by a Web client. You need to consider how the application's state will be managed between requests. If you need to share data across the request sequence, between different programs or instances of the same program, you can do this using XCICS-managed resources, or using elements of the requests sent by the Web client.

When more than one exchange of a request and response between a Web client and XCICS is needed to complete a task successfully, each new step in the sequence is initiated by the Web client. You can design the response sent by XCICS to guide the Web client, and any human user of the Web client, to the next step. For example, the entity body can contain controls (such as links or buttons) that the end user can use to compose the next request. However, you cannot easily enforce the correct sequence of requests. In particular, the planned sequence can be disrupted if:

•	The client is a Web browser, and the end user types a known URL to initiate a particular request, rather than selecting a control in an HTML page provided by a previous response.

•	The end user abandons the activity altogether, by shutting down the Web client or by changing to some alternative activity with the Web client.

You should design your application programs so that they can cope with delays or disruptions in the request sequence. For example, if you are sharing data across the request sequence, you should ensure the data is cleaned up if the request sequence does not complete or is delayed excessively. If your application programs update protected resources, you should ensure that updates that must be committed or backed out together are made in the same transaction. (This means that a single request from the Web client should be designed to complete the update.)

The ideal situation for an application is that each exchange of a request and response is self-contained and completes an independent element of the task. However, this design is not always possible, especially when the task is complex, or when a Web client has sent a pipelined sequence of requests. A pseudo-conversational model may be required, where the application's state must be managed between requests. This can be arranged using the following techniques:

•	You can design the requests sent by the Web client so that application state, or shared data, is incorporated in the request, for example as part of a request URL that is used when the Web client submits an HTML form. The next program can examine the request URL to obtain the shared data.

•

You can store small quantities of application state using hidden fields in an HTML form that is returned to the Web client as a response. When the user performs the next action in the planned sequence, the request that they send to XCICS can include the hidden fields, which can be located and read by the next application program.

•

For larger quantities of state, and state with an extended lifetime, you can create a XCICS-managed resource to maintain the application's
state, and pass a token that represents the resource. This token can be conveyed from program to program in a pseudo-conversation as a hidden field in an HTML form, or from interaction to interaction as a query string in a URL. This technique can be used for preserving information throughout a pseudo-conversation, and also for preserving information throughout an extended interaction between an end user and various XCICS application programs, perhaps over several pseudo-conversations.