State Repository

How can service state data be persisted for extended periods without consuming service runtime resources?

Problem Large amounts of state data cached to support the activity within a running service composition can consume too much memory, especially for long-running activities, thereby decreasing scalability.
Solution State data can be temporarily written to and then later retrieved from a dedicated state repository.
Application A shared or dedicated repository is made available as part of the inventory or service architecture.	Impacts The addition of required write and read functionality increases the service design complexity and can negatively affect performance.
Principles Service Statelessness	Architecture Inventory, Service

Table 6.26 – Profile summary for the State Repository pattern.

Problem

It is often necessary to retrieve and cache bodies of data to which service capabilities require repeated access during the course of a service activity. However, some complex compositions introduce extended periods of processing during which this data is not required. While idle, this cached data continues to be stored in memory and consumes runtime resources.

This excess consumption can severely compound during periods of high concurrent activity, depleting the overall available resources and decreasing the scalability of a service inventory.

Figure 6.111 – During the lifespan of a service instance it may be required to remain stateful and keep state data cached in memory even as its participation in the activity is paused.

Solution

A state repository is established as an architectural extension made available to any service for temporary state data deferral purposes. This alleviates services from having to unnecessarily keep state data in memory for extended periods.

Figure 6.112 – By deferring state data to a state repository, the service is able to transition to a stateless condition during pauses in the activity, thereby temporarily freeing system resources.

Application

Typically, a dedicated database is provided for state deferral purposes. The database is located on the same physical server as the services that will be utilizing it, so as to minimize runtime performance overhead associated with the writing and retrieval of the data.

Alternatively, dedicated tables within an existing database can be provided. Though less effective, this still provides a state deferral option suitable for temporary data storage requirements.

Impacts

Incorporating the state deferral logic required to carry out this pattern can increase service design complexity, leading to more development effort and expense.

Although scalability can be increased by the application of this pattern, having to write data to and retrieve data from a physical hard drive imposes more runtime performance overhead than having to carry out the same functions against data stored in memory. For service activities with strict real-time performance requirements, this state deferral option needs to be carefully assessed.

Relationships

Establishing a state management system via the State Repository pattern naturally relates to other state deferral-related patterns, such as Stateful Services and Partial State Deferral. Both of these patterns may end up using the central state database commonly introduced via this pattern and the Canonical Resources can help ensure that no one inventory will have more than one type of state management database.

Figure 6.113 – The State Repository pattern is fundamental to just about any state management design consideration and related patterns.

Process Centralization will almost always require the application of this pattern to provide a means of persisting state data associated with the many business processes that orchestration environments are required to execute and manage. (Long-running processes in particular need such a repository in order to store activity state data for extended periods.) This is why State Repository is one of the core patterns that comprise the Orchestration compound pattern (Figure 6.x).

Figure 6.114 – The State Repository pattern is one of the core patterns that represent the Orchestration compound pattern.

Case Study Example

Case study content is not available on this Web site.