Databases Reference
In-Depth Information
Reducing coupling in stateful services
A stateful service maintains context for a given client between invocations. When
using stateful services, we always need to return some kind of state information
to the client. To avoid unnecessary coupling, this state information should always
be opaque. By opaque, we mean that it should have no meaning to the client other
than as a reference that must be returned to the service when requesting follow on
operations. For example, a numeric session ID has no meaning to the client and
may be used by the service as an index into a table stored either in memory or in a
database table. We will examine how this may be accomplished later in this section.
A common use of state information in a service is to preserve the position in a
search that returns more results than can reasonably be returned in a single
response. Another use of state information might be to perform correlation between
services that have multiple interactions, such as between a bidding service and a
bidding client.
Whatever the reason may be, the first task, when confronted with the need for state
in a service, is to investigate the ways to remove the state requirement. If there is
definitely a need for state to be maintained, then there are two approaches that the
service can follow.
•
•
Externalize all state and return it to the client.
Maintain state within the service and return a reference to the client.
In the first case, it is necessary to package up the required state information and
return it to the client. Because the client should be unaware of the format of this data,
it must be returned as an opaque type. This is best done as an
<any>
element in the
schema for returning the response to the client. An
<any>
element may be used to
hold any type of data, from simple strings through to complex structured types.
For example, if a listing service returns only 20 items at a time, then it must pass back
sufficient information to enable it to retrieve the next 20 items in the query.
In the following XML Schema example, we have the XML data definitions to support
two operations on a listing service:
•
•
searchItems
nextItems
