Scenario: Different user sessions under the same workstation session
This scenario demonstrates how to use the application and channel session IDs when several contexts need to persist in the application session table for a given session and for an extended period of time, to be used by multiple operation requests, each requiring its own parent context. A concrete example would be where a single workstation requires multiple users and concurrent context hierarchies, one for each user. This situation may arise if multiple users share a single desktop workstation.
The scenario is shown in the following diagram:
A session has been established with the server, and the workstation context (wks1) associated with the session has already been created by a previous operation. This operation also added a session entry into the application session table, thus establishing a link between the session and the context instance.
The diagram corresponds to the following sequence of actions:
1 The application creates the client operation whose context contains data belonging to user1. This operation is meant to create a specific context in the server, chained to the workstation context, so that any operation from user1 will be chained to the created context. The operation returns an identifier (a subsession) that will be required in subsequent requests to identify user1.
2 The application executes the client operation, which sends the operation to the server with a valid channel session ID.
3 The multichannel support implementation creates the server operation, instantiates the context, and chains it to the workstation context (as shown by the dotted line).
4 The operation performs the following process flow:
▪ Create a new instance of the context.
▪ Get the unique subsession or application ID (for example, JavaExtensions.getAlphaUniqueSessionId();).
▪ Update the server operation (aServerOperation.setApplicationId(appId);).
▪ Create an application subsession entry in the session table for the session, the application (application subsession), and the context (Context.addApplicationSession(applicationID, sessionID, context);).
▪ Unchain the operation context (an operation does this as part of its default behavior).
5 The multichannel support implementation sends the response to the client with the valid session and application subsession IDs. The Client/Server Service on the client side maps the application ID from the server to the client operation. An optional implementation for HTML would return the IDs to the client in the parameters for the Execute Request Protocol.
6 The client operation uses the application ID and updates the client context hierarchy to maintain the application ID between requests. The management of the application ID between client operation requests is the responsibility of the application implementation.
7 Any subsequent requests to the Client/Server Service from a client operation that contains the application ID will cause the multichannel support implementation to chain the server operation context to the context specified in the application session table for this application ID, not the session ID. The application must map the application ID to the client operation before sending the request.
