How
can service state data be persisted and managed without consuming service
runtime resources?
|
Problem
Context data and rules
associated with a particular service activity can impose a great deal of
runtime state management responsibilities upon composition controllers and
other involved services, thereby reducing their scalability.
|
|
Solution
Context data and rules are
managed and stored by dedicated system services that are intentionally
stateful.
|
|
Application
Stateful utility services
can be custom developed or provided as part of a vendor platform.
|
Impacts
If not properly
implemented, stateful services can become a performance bottleneck.
|
|
Principles
Service Statelessness
|
Architecture
Inventory,
Service
|
Table 6.27 – Profile summary for
the Stateful Services pattern.
Problem
The coordination of large activities requires the constant
management of related context information. Placing the burden of retaining and
processing this data upon controller services and other composition members
increases their individual memory consumption as well as the duration for which
they are required to remain stateful.
Figure 6.116 – The task controller
service of a modest composition is required to retain and manage all of the
service activityÕs context data until the activity is completed.
Solution
Stateful services are positioned as coordinators to manage
the flow and participation of service activities. This alleviates the need for
any one service, including the controller service, from having retain context
state data.
Figure 6.117 – With the use of
stateful utility services, context management responsibilities are deferred.
Services participating in the activity are required to regularly interact with
the context management services to keep them appraised of the activityÕs
status.
Application
This pattern is automatically applied when using an existing
framework, such as WS-Coordination. However, custom services can also be
developed to provide standard state deferral functions. Either way, what
distinguishes services dedicated to state management is that they are
deliberately stateful parts of the enterprise. Therefore, they intentionally
violate the Service Statelessness principle so as to support its application in
other services.
Note:
Stateful system services essentially become an extension of the underlying
infrastructure, and are typically considered members of the utility service
layer. To learn more about context data, context rules, and other forms of
state information, see Chapter 11 of SOA: Principles of Service Design.
Impacts
In high concurrency situations, stateful system services can
be required to manage numerous activities and activity instances at the same
time. If they are not supported by the proper infrastructure, the overall
performance and scalability of the service inventory can be compromised.
Relationships
Stateful Services establish a specialized variation of the
utility service and are therefore closely related to Utility Abstraction. They
may require a state management database behind the scenes, leading to the need
to apply the State Repository pattern.
Because they commonly exist as Web services, Service
Messaging is required for basic communication and Message Metadata provides a
means of supplementing state data deliveries with additional activity details.
Figure 6.118 – The Stateful Services
pattern results in the creation of system services that centralize state and
activity management, primarily via messaging.
Case Study Example
Case study content is not available on this Web site.
