Sessions using work areas

When work areas are available, the application presentation layer passes the session ID, sub-session ID (if applicable), and session context instance ID to the application logic layer through a work area. For example, in the application presentation layer, the CSEstablishSessionServlet creates the HTTPSession to support various HTTP requests. The HTTPSession can have an associated ActivitySession to enhance the performance of any EJBs used in the session on the server. An invoker or an EJB Access Action propagates the session to the application logic layer by invoking a process through the EJB interface in the Business Process Component. The mechanism used to do the propagation is the shared WorkArea service provided by the WebSphere(R) Business Integration Server Foundation. For each request from the client, the invoker or the EJB Access Action creates a new work area and stores the session ID, sub-session ID (if applicable), and session context instance ID in the work area. When it receives the EJB call, the Business Process Component retrieves the session ID and session context instance ID from the work area. When it receives the response from the application logic layer, the invoker or the EJB Access Action ends the work area. Note that if the application presentation layer is using WSIF with SOAP binding to communicate with the application logic layer, work areas are not available.

The following diagram shows the toolkit components that are involved with supporting sessions in the application presentation layer and in the application logic layer.

Diagram of the end-to-end architecture using work areas

For more information on work areas, see the WebSphere Business Integration Server Foundation help.