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

About the Book



SOA Design Patterns
by Thomas Erl

For more information visit: www.soapatterns.com

Related Publications


"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)





Entity Linking (candidate)


Home > Candidate Patterns List > Entity Linking

How can services expose the inherent linkage between business concepts in order to support loosely-coupled choreography?  

Problem

Conceptual business entities are naturally inter-related, yet services are commonly designed autonomously with no indication of these relationships. Service consumers and composition controllers may not have sufficient information available about such relationships to complete their function.

Solution

Services include entity references in service capability response messages.

Application

Response messages from entity-related capabilities include references to related entities. Identifiers may refer to other entities within the service, or to entities in another service. Service consumers with sufficient awareness of the related service contracts are able to navigate from entity to entity by following these "links" and thus correctly follow a choreography.

Impacts

Entity identifiers generally need to remain constant over the lifespan of the entities they identify.

Principles

Service Abstraction, Service Reusability, Service Composability

Architecture

Inventory, Service

Status

Under Review

Contributors

Raj Balasubramanian, Jim Webber, Thomas Erl, David Booth
 

Services that expose identifiers of related entities in capability responses are able to be used in a wider variety of compositions. A Report Printer service is able to look up any invoice fields that it might require, and is not limited to a predefined set within the standard report. An Invoice Printer service is able to cross-reference invoice and customer records in order to print mailing labels.



When combined with uniform interface and fine-grained service endpoint patterns, the entity linking pattern is transformed into resource linking. The uniform contract exposed by each resource allows its capabilities to be invoked without fore-knowledge of the service that exposes the resource. The link itself provides supplementary information that may have been abstracted away in the uniform contract. It both identifies the resource and provides machine-readable context that describes the entity the link is referring to.

A link from Invoice 2 to Customer 1 does not simply inform an Invoice Printer that a customer exists, but that Customer 1 is the purchaser of items listed in Invoice 2. The Invoice Printer expects that following the link will return a customer record that is correct to use on the invoice's mailing label. This expectation is derived from the link itself and its context as interpreted by the programmer who wrote the Invoice Printer. It is not derived from the uniform contract.

The freedom to link to a resource in any service allows the entity linking pattern to overcome service denormalization that may occur at service inventory boundaries. The invoice could refer to a customer resource in a service maintained by another department or business. Different invoices in the same service could refer to customers in different customer services. It is even possible for each invoice to refer to a canonical resource provided by the customer themselves through individually-operated services. The Invoice Printer is abstracted by the uniform contract from the detail of which service it accesses.


Related Patterns in This Catalog

Fine-grained Service Endpoint, Uniform Contract (Balasubramanian, Webber, Erl, Booth)


Related Service-Oriented Computing Goals

Increased Intrinsic Interoperability, Increased Business and Technology Alignment, Increased ROI, Increased Organizational Agility, Reduced IT Burden

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.