Home > State Management Explained > Session and Context Data

Session and Context Data

The data a service processes when stateful can also vary. Many terms have been used to classify different types of state data, but we'll settle on the following:

  • session data
  • context data
  • business data

Session data typically represents information associated with retaining a connection made between a program and its client program (or client user). This connection may or may not be an actual physical connection. For example, if you access a Web site with your browser, it may be programmed to establish a unique session identifier to correlate future interaction with the browser and other parts of the site. This value is then passed between the browser and the Web site with each subsequent exchange.

In service compositions, the execution of a business task can take the shape of a runtime activity that spans multiple services. In this case, the state information that is passed between them (if any) goes beyond session-type information, in that it pertains to more than just keeping track of the session. This type of activity-specific information is what we refer to as context data.

Associated with context data is the actual logic used to process it. Usually this logic is tied to the workflow rules that govern the processing of the activity. We therefore make a further distinction between context data and context rules. Both context data and context rules are commonly centralized within middleware, namely in transaction coordinators.


Example 1 – The WS-Coordination specification provides a context management framework that can represent context data and context rules in standardized headers. In this example, the CoordinationType element establishes that WS-AtomicTransaction protocols (rules) are in use.

Finally, business data represents information that is relevant to the business task currently executing. This typically refers to persistent data retrieved from a repository. The classic example is a set of data records returned by a database query. It may be required to store this information in memory for data sharing or future reference purposes within the lifespan of a service activity.

Unlike the other forms of state information we covered, business data is typically transported within the message body as part of the message payload. It therefore is not data that actually represents or expresses the state of the service or the activity; however, the need for it to be temporarily persisted by the service can require that the service remain stateful.

There are other forms of state information you will encounter or perhaps even create yourself when designing services. The types we described in this section are common to most service processing requirements.