Return to Home Page
Overview
    History
    Acknowledgements
    Podcasts
    Notification Form
    Feedback Form
    Press Release #1
    Press Release #2
    Press Release #3

Master SOA Design
Pattern Catalog
    Master Pattern List (alphabetical)
    Master Pattern List (by category)
    Master Pattern List (Text)
    Pattern Notation
    Pattern Profiles
    Symbol Legend
    Pattern Contribution Form

SOA Candidate Patterns
    SOA Patterns Review Committee
    Candidate Patterns Overview
    Candidate Patterns List
    Candidate Pattern Contribution Form
    Candidate Pattern
Feedback Form
    SOA Pattern Template

Design Pattern Basics
    What's a Design Pattern?
    What's a Design Pattern Language?
    What's a Compound Pattern?

Supplemental
    SOA Patterns and Application Technologies
    SOA Design Patterns Historical Influences
    SOA Design Patterns and Design Principles
    SOA Design Patterns and Design Granularity
    Legal

Resources
    Design Patterns Publications
    Reference Posters
    SOAPrinciples.com
    WhatIsSOA.com
    SOA Visio Stencil


Response Caching (Balasubramanian, Booth, Erl)


Home > Candidate Patterns List > Response Caching

How can the results of previously processed, yet still valid responses be reused by service consumers?  

Problem

Service consumers required to repeatedly invoke the same service capability and then return response messages that have not changed can impose increased runtime overhead and unnecessarily high response times.

Solution

In order to avoid wasteful request and response messaging, response message data is cached in various locations within the technology architecture that underlies service consumers and services.

Application

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 centers maintain their own cache to avoid duplicate requests and responses flowing unnecessarily across their network connections. Services maintain their own cache to avoid processing loads associated with repeated requests.

Response messages indicate their "cacheability" using metadata. 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

The latency, bandwidth, and processing impact of redundant requests is reduced or eliminated. Consumers that issue similar requests may be able to reuse each other's responses, reducing impact on services.

Caches must understand the contract in use and Reusable Contract can be further applied to increase cache effectiveness.

Explicit caching control decisions must be made by services. These decisions may require the service to generate unique identifiers for new versions of its data, or that the service changes its data at a predictable rate. An unambiguous means of determining that a later request is equivalent to an earlier request for caching purposes is required.

Inaccurate caching metadata could lead to stale information being used by service consumers.

Principles

Service Statelessness

Architecture

Inventory, Composition, Service
 
Caches placed at various locations can reduce latency (by eliminating requests to the service), decrease bandwidth usage (by limiting requests sent across network links), and lessen processing effort (by reducing requests sent to core service logic). Caches are particularly useful for decreasing overhead in stateless architectures.


Related Patterns in This Catalog

Content Distribution Network (Balasubramanian, Carlyle, Pautasso) , Lightweight Endpoint (Balasubramanian, Carlyle, Pautasso) , Reusable Contract (Balasubramanian, Carlyle, Pautasso),


Related Service-Oriented Computing Goals

Increased Organizational Agility, Reduced IT Burden

SOA with REST This page contains excerpts from:

SOA with REST: Principles, Patterns & Constraints
by Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso





(ISBN: 0137012510, Hardcover, 400+ pages)

For more information about this book, visit
www.soabooks.com.
The Prentice Hall Service-Oriented Computing Series from Thomas Erl
Home    SOA Books    SOA Magazine    What is SOA?    SOA Principles    SOASchool.com    SOA Glossary Copyright © 2007-2011
SOA Systems Inc.