Master SOA Design
Pattern Catalog
|
|
"Introducing SOA Design Patterns", SOA World Magazine (PDF)
"The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation", SOA Magazine (HTML)
"REST-Inspired SOA Design Patterns", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles", SOA Magazine (HTML)
"Service Facade", InformIT (HTML)
"Non-Agnostic Context", InformIT (HTML)
"Domain Inventory", InformIT (HTML)
"Service Normalization", InformIT (HTML)
"Service Decomposition", InformIT (HTML)
"Canonical Schema", InformIT (HTML)
"Policy Centralization", InformIT (HTML)
|
|
|
Response Caching (candidate)
|
Home > Candidate Patterns List > Response Caching
|
|
How can the results of previous processing that are still valid be reused by clients?
|
|
|
|
|
|
Problem
Service consumers required to repeatedly invoke the same capability and always return responses that have not changed can impose unnecessary runtime overhead on services, consumers, and networks, and introduce unnecessarily high response times.
|
|
|
Solution
Responses are cached in various places in the architecture: Service consumers maintain their own cache to avoid repeatedly requesting the same data and improve response latency when the cached data is still fresh. Data center owners maintain their own cache to avoid duplicate requests and responses flowing unnecessarily across their network connections. Service providers maintain their own cache to avoid processing load associated with repeated requests.
|
|
|
Application
Service capability response messages indicate their cacheability using meta-data. Implicit caching information is included in contracts for when no explicit information is provided.
Cache components that understand the contract in use can choose to persist the response between requests. These components are able to determine whether two requests are equivalent for caching purposes, or whether they differ.
A cached response is reused when a new request is determined to be equivalent to the earlier request, and the cached response is still "fresh". A validation check back to the service may be used to ensure freshness.
|
|
|
|
Impacts
Explicit caching control decisions must be made by services that may include a requirement for state versioning, or for a predictable rate of change for state. An unambiguous means of determining that a later request is equivalent to an earlier request for caching purposes is required.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Balasubramanian, Carlyle, Pautasso
|
|
|
|
| |
Caches placed at various locations can reduce latency by eliminating requests to the service, reduce bandwidth usage by reducing requests sent across network links between data centers, and reduce processing effort by reducing requests sent to core service logic.
Uniform contract and fine-grained service endpoint patterns improve the effectiveness of caching components. Uniform contract keeps cache components loosely coupled with any specific service provider and service consumer. Fine-grained service endpoint supports a single scheme for identifying entities that cached responses relate to.
|
|
|
