HTTP is a stateless protocol used in the World-Wide-Web. In HTTP all requests to a server are independent of each other. This approach works very well for general information access and for applications that follow the REST architectural style. However, there are architectural designs which are impossible without session state maintained between a browser and a server.

Netscape developed HTTP Cookies to support a mechanism to add state tracking to the HTTP protocol. Cookies are simply a small amount of data that are stored in the browser and returned to the server with each request. Cookies are used either to store a session key or a very small amount of session data within the browser client.

In Java J2EE, Servlets can support a session between the browser and the server by using either URL re-writing or the HTTP Cookie mechanism. A J2EE container transparently tracks session state and provides the programmer with a session context to access that state. A programmer may store information such as shopping cart contents in a J2EE Session context.

HTTP Sessions

In NetKernel the ext-session module provides a session management framework. Like the J2EE Servlet Session it provides the illusion of a stateful HTTP protocol. The ext-session module has two parts, the session mapper and the session manager. The session mapper uses the Cookie mechanism and works with the session manager to provide a capability similar to the J2EE Servlet Session context. Because the session manager is distinct from the session mapper in NetKernel, the session manager may be used in any application, independently of the HTTP protocol.

We have already seen how ext-session provides URI based sessions and how they can be managed with the provided services. It is also useful to automatically maintain a session. ext-session provides the Session Mapper accessor that performs automatic session creation and cookie based session affinity for regions of a module's URI address space called zones.

Below is a diagram of a module URI address space and the session URI address space managed by the session data accessor. A session zone is a transparent layer over the module address space.

All requests for resources which are in the session zone will be automatically reconnected to their session. If the session does not exist a new session will be created for that request.

Module Configuration

To use the automatic session facility a module maps all requests to the session mapper using a simple URI rewrite rule and provides the mapper with configuration information defining the various zones. Note: in the rewrite rule the $e1 is important as it indicates that the URI to be mapped to a session is escaped.

With this rewrite mapping rule in place, the session mapper will receive all requests and use its configuration information to match the requests against defined session zones. Session mapper zones are configured in the resource ffcpl:/etc/SessionPolicy.xml document. Below is a single zone which creates a session zone for all requests in the .*/mypath/.* URI address space.

• match is a regular expression applied to the URI of the request.
• token is the type of the external session token to use. Currently only cookie is supported.
• path is the path that will be set on the cookie. This should match the external public address space of the web request that will be handled by this module. Usually it is sufficient to make this path the same as the match path.
• type contains settings for the session type to create. Currently only simple is supported.
• id a unique identifier for this session policy [default "DefaultPolicy"]
• max-sessions the maximum number of sessions to permit. [default 50]
• max-duration the maximum age that a session may have. [default 300,000 milliseconds]
• min-duration the minimum age before a session is at risk of being culled by new sessions.[default 30,000 milliseconds]

If a request URI matches the regular expression then it will be reconnected with its session. If a request URI does not match the regular expression then it is reissued without modification - making the mapper completely transparent for non-matching cases.

HTTP Cookies

The sessionmapper requires that your HTTPBridge be configured to pass cookies - please see theguide.

Example

Suppose that a session mapper is configured with the above example zone definition and a request is received for the URI active:dpml+operand@ffcpl:/mypath/myprocess.idoc. The session mapper tries to match the request URI against it's defined session zone policy. Since the request contains /mypath/ it matches our example request. The session mapper uses a value in the cookie passed with the request to reconnect to the session URI. If no cookie is found a new session is created. Finally the session mapper reissues the original request with the session URI attached.

active:dpml+operand@ffcpl:/mypath/myprocess.idoc+session@session1234567890123456

Once the request issued by the session mapper is completed the session mapper automatically and transparently attaches a session cookie to the response before it is passed back to the requestor.

Any subsequent external request in the session will include the cookie on the request. The session mapper strips the external cookie session token, reconnects to the session and exchanges the cookie for the internal session URI. If expired, a new session is created.

Using Sessions in DPML

If a request in a session zone runs a DPML program the session URI can be access with:

this:param:session

within the DPML program. This reference can be used just like the var:session URI examples shown in the first section.