Symbol Legend Sitemap

SOAPatterns.org

Overview
- Introduction
- History
- Acknowledgements
- Podcasts
- Candidate Patterns
- Forms
- Press Releases
- Resources
Compound Patterns
Design Patterns (alphabetical)
Design Patterns (by category)
- Foundational Inventory Patterns
- Logical Inventory Layer Patterns
- Inventory Centralization Patterns
- Inventory Implementation Patterns
- Inventory Governance Patterns
- Foundational Service Patterns
- Service Implementation Patterns
- Service Security Patterns
- Service Contract Design Patterns
- Legacy Encapsulation Patterns
- Service Governance Patterns
- Capability Composition Patterns
  - Capability Composition
  - Capability Recomposition
- Service Messaging Patterns
- Composition Implementation Patterns
- Service Interaction Security Patterns
- Transformation Patterns
- REST-inspired Patterns
Cloud Computing Patterns
Service Technology Specs
SOA School
- Home
- Matrix
- Certifications
- Courses
- Exams
- Self-Study Kits
- Workshops
- Licensing
- Online Store

Home > Design Patterns > Compatible Change

Compatible Change (Orchard, Riley)

How can a service contract be modified without impacting consumers?

Problem

Changing an already-published service contract can impact and invalidate existing consumer programs.

Solution

Some changes to the service contract can be backwardscompatible, thereby avoiding negative consumer impacts.

Application

Service contract changes can be accommodated via extension or by the loosening of existing constraints or by applying Concurrent Contracts.

Impacts

Compatible changes still introduce versioning governance effort, and the technique of loosening constraints can lead to vague contract designs.

Principles

Service Loose Coupling, Standardized Service Contract

Architecture

Service

Listen to the podcasts that accompany this site
Service Contract-Related SOA Design Patterns
Advanced Service Versioning

Compatible Change: The existing capability is not renamed. Instead, a new capability with a new name is added alongside the original capability, thereby preserving compatibility with both Consumers A and B.

The existing capability is not renamed. Instead, a new capability with a new name is added alongside the original capability, thereby preserving compatibility with both Consumers A and B.

Related Patterns in This Catalog

Canonical Versioning, Concurrent Contracts, Termination Notification, Validation Abstraction, Version Identification

Related Service-Oriented Computing Goals

Increased Organizational Agility, Reduced IT Burden

This page contains excerpts from:

SOA Design Patterns by Thomas Erl

Foreword by Grady Booch

With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.

(ISBN: 0136135161, Hardcover, Full-Color, 400+ Illustrations, 865 pages)

For more information about this book, visit www.servicetechbooks.com.

This page contains excerpts from:

Web Service Contract Design and Versioning for SOA

by Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley

Foreword by David Chappell

With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.

For more information about this book, visit www.servicetechbooks.com.