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 > Decomposed Capability

Decomposed Capability (Erl)

How can a service be designed to minimize the chances of capability logic deconstruction?

Problem

The decomposition of a service subsequent to its implementation can require the deconstruction of logic within capabilities, which can be disruptive and make the preservation of a service contract problematic.

Solution

Services prone to future decomposition can be equipped with a series of granular capabilities that more easily facilitate decomposition.

Application

Additional service modeling is carried out to define granular, more easily distributed capabilities.

Impacts

Until the service is eventually decomposed, it may be represented by a bloated contract that stays with it as long as proxy capabilities are supported.

Principles

Standardized Service Contract, Service Abstraction

Architecture

Service

Listen to the podcasts that accompany this site

The Invoice service (middle) derived from the same business entities (left) exposes a series of more granular capabilities, several of which correspond directly to specific business entities. This increases the ease at which subsequent service decomposition can be accomplished. The decomposed services (right) are no longer in conflict because the capabilities affected by the decomposition are clearly mapped to the new services. Those same capabilities also remain in the Invoice service contract (top right) as per Proxy Capability.

Related Patterns in This Catalog

Contract Denormalization, Proxy Capability, Service Decomposition

Related Service-Oriented Computing Goals

Increased Intrinsic Interoperability, 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.