Session

Pattern Properties

Type: Processing

Level: Architectural

Purpose

To provide a way for servers in distributed systems to distinguish among clients, allowing applications to associate state with the client-server communication.

Introduction

In a networked Personal Information Manager, it’s likely that you want to centralize some of the information, like a company’s customers.

Clients would need to routinely update contact information on the server, and the updates might occur over several stages. Users might modify information about the contact's position and company, then modify contact addresses. Since there can be any number of address updates, and users can potentially be entering the information in real time, you decide to allow the client to submit the changes over multiple interactions with the server.

This brings up a problem—how do you track a user’s changes that relate to a specific contact, when these changes take place in stages? Multiple clients will be making updates at the same time, and the server will need to know which updates come from which clients. Otherwise, one client might update the wrong customer record.

The most efficient approach is to associate a temporary identity with each user, so that the server can keep better track of workflow. When a user begins to edit information on the server, the server starts a session, issuing it a session ID. Each time the user performs an edit, such as adding or removing an address, the user’s application sends the session’s ID to the server. When the contact information has been updated, the application the user is using sends a finalize message to the server to indicate that the client is done updating that contact information. The server then ends the session.

This solution, also known as the Session pattern, provides a number of benefits to the server. It provides the server with a way to differentiate among clients, and to keep track of a particular client's progress in workflow. Finally, it allows the server to store information that is in flux, instead of storing the information on the client. With a session, the server can cache the user’s information in memory until the user has completed the edits.

Applicability

The Session pattern is appropriate for client-server or peer-to-peer systems with the following requirement: Client identity – You need some way to distinguish among callers in a multiuser system.

Additionally, Session is normally used for systems with one or both of the following characteristics:

Operation continuity – You want to be able to associate specified operations with each other in the system. Operations might follow a transactional or a workflow model.

Data persistence – You need to associate data with the client over the time that the client interacts with the server.

Description

Information about the Session pattern is divided into the following sections.

Stateful and Stateless Communication

Communication between distributed systems can be stateful or stateless.

148

An example of stateful communication is sockets. Requests from the client to the server can be made sequential and the server is aware of the previous calls.

Stateless communication is when the server does not take into account what has happened before. The server does not distinguish one call from the other and each call is self-contained—all information needed is provided by the call. This model is usually straightforward to implement, and can greatly simplify both client and server code.

The Internet is an example of this stateless model. In the Web, Hypertext Transfer Protocol (HTTP) is a stateless communication mechanism between a Web browser and a server. With a core set of simple operations, it is well-suited for its original purpose: the transfer of documents across the Web.

Applications Often Require Stateful Communication

Applications sometimes have more complex communication needs, and stateless communication isn’t appropriate. In particular, business applications often require support for some or all of the following:

Workflow – A connected sequence of business operations

Transactions – An associated set of operations that succeed or fail as a unit

Application data – Information associated with client-server interaction

Consider a classic e-commerce application. While a customer shops for products, the system must store data that represent the contents of the shopping cart. Online shopping also uses workflow to define the series of actions required to check out, pay for items, and ship an order. Such applications clearly need a way to represent the ongoing interaction between client and server over the duration of the shopping trip.

Session Pattern and Stateful Communication

The Session pattern is useful for these more-complex applications. The Session allows you to establish the identity of multiple clients, and might also provide one or more objects to represent the conversational state between a client and a server. It provides continuity between a client and server over an extended period of time, potentially spanning many requests over the application lifetime.

The Session pattern is quite useful when you want to support workflow between multiple client-server interactions—associating multiple actions as a whole. Without the concept of a session, a server has no way to effectively keep track of which operations belong to which client.

In Web applications, you can frequently see sessions being introduced for just this purpose. Under normal circumstances, the Web operates with a stateless model. If you want to support e-commerce, however, you need a way to manage a session. As users shop in a Web site, they can potentially add (and remove) many items from their shopping cart before they purchase items. If you don’t use a session to track their activities and to store the items that they might purchase, your e-commerce Web site is reduced to a simple online purchase form.

Real-World Stateful Communication

Any situation in the real world with the concept of identity and transactional state provides an example of a Session. A delicatessen, for instance, uses face recognition to establish client (customer) identity and enable the use of its services. This enables the server (deli worker) to distinguish among the requests of different customers, and manage multiple requests. Perhaps customer 42 takes a long time to make up his mind, asking first for a pound of anchovies and pastrami, then cancelling the pastrami and switching to corned beef, and adding a ham on rye to the order.

Even though the customer may make many requests, the server knows that the final order belongs to the same customer, and no other customer will end up with 42’s pastrami. The only danger in this system is the possibility that other deli customers may lose patience with customer 42. Of course, that might motivate the owner to hire more help and make the delicatessen multithreaded.

Implementation

The Session has two fundamental requirements:

149