Java Reference
In-Depth Information
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:
