Master SOA Design
Pattern Catalog
|
|
"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.
|
|
|
|
|
|
|
|
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.
|
|
|
