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 with
Page Numbers (PDF)
    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


Dual Protocols (Erl)


Home > Inventory Implementataion Patterns > Dual Protocols

How can a service inventory overcome the limitations of its canonical protocol while still remaining standardized?  

Problem

Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution

The service inventory architecture is designed to support services based on primary and secondary protocols.

Application

Primary and secondary service levels are created and collectively represent the service endpoint layer. All services are subject to standard service-orientation design considerations and specific guidelines are followed to minimize the impact of not following Canonical Protocol.

Impacts

This pattern can lead to a convoluted inventory architecture, increased governance effort and expense, and (when poorly applied) an unhealthy dependence on Protocol Bridging. Because the endpoint layer is semi-federated, the quantity of potential consumers and reuse opportunities is decreased.

Principles

Standardized Service Contract, Service Loose Coupling, Service Abstraction, Service Autonomy, Service Composability

Architecture

Inventory, Service




Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

Related Patterns in This Catalog

Canonical Protocol (Erl), Concurrent Contracts (Erl), Contract Centralization (Erl), Logic Centralization (Erl), Protocol Bridging (Little, Rischbeck, Simon), Redundant Implementation (Erl)


Related Service-Oriented Computing Goals

Increased Intrinsic Interoperability, Increased Vendor Diversification Options, Increased Organizational Agility, Reduced IT Burden


SOA Design Patterns 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.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-2010
SOA Systems Inc.