IBM WebSphere Multichannel Bank Transformation Toolkit, Version 7.1

How session management works

Session management involves passing the session ID, sub-session ID (if applicable), and session context instance ID from the application presentation layer to the application logic layer. This enables the application logic layer to chain the process context to the session context and makes the session data available to the process. The following steps describe how the presentation layer supports sessions when the presentation and application logic layers are running on WebSphere®. If they are not, the work area is not available and the application presentation layer passes the session ID in the logon process invocation instead.

To avoid complexity, the steps treat the presentation layer, Business layer, and CHA as black boxes and concentrates on the interaction between them. Note that if the requests are running under a sub-session, the steps remain the same. The only difference is that the work area or process request must contain the ID of the session and the sub-session. The steps also assume that cookies are enabled so that the WebSphere Application Server is performing session management. See Session management without cookies for information how sessions can be managed without using cookies.

When a user logs on using the default logon process, the following happens:

  1. A user enters a URL in a browser. This sends an HTTPRequest through the CSEstablishSessionServlet.
  2. The application presentation layer creates an HTTPSession.
  3. The application presentation layer displays the logon page.
  4. The user submits the logon request.
  5. The application presentation layer starts a work area and stores the session information in it.
  6. The application presentation layer launches the logon procedure and waits for a response.
  7. In the application logic layer, logon function retrieves the session ID from the work area.
  8. The logon procedure creates the logon context, and chains it to the root context.
  9. The logon procedure validates the logon information and removes the logon context. If the logon information is valid, the logon procedure will create the session context and chain it to the root context.
  10. The logon procedure returns session context instance ID to the presentation layer.
  11. The application presentation layer ends the work area.
After the user logs on, the toolkit handles the user's subsequent requests in the following way:
  1. The user sends a request to the application presentation layer.
  2. The application presentation layer starts a work area and stores the session information in it.
  3. The application presentation layer launches the corresponding business component and waits for a response.
  4. In the application logic layer, the BTT framework retrieves the session ID from the work area.
  5. User uses the BTT framework to create the process context. User can chain this process context to the session context.
  6. The Business logic layer creates a response, which includes the session context instance ID (optional).
  7. The business logic layer sends the response to the application presentation layer.
  8. The presentation layer updates the session entry in session table if the session context was changed.
  9. The application presentation layer ends the work area.

When the user submits a logoff request, the application presentation layer adds the additional steps of sending a cleanup request to the application logic layer, invalidating the HTTPSession. The cleanup request cleans up the session on the application logic layer. That is, the CHA removes the session context from the CHA hierarchy and the business logic layer performs any other additional logic needed to cleanup the session.



Feedback