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 maintain and expose the inherent linkage between business entities?
|
|
|
|
Problem
Business entities are naturally inter-related, yet entity-centric services are commonly designed autonomously with no indication of these relationships.
|
|
|
Solution
Relationships between services are expressed via the association between entity-related data sets.
|
|
|
Application
The most common implementation of this pattern is in the REST service that enables business entities to be linked at the information level using URIs in the form of anchor tags or XLink/XPointer in various content types.
|
|
|
|
Impacts
Cross-business entity relationships tends to be more prone to change than the entities themselves, making established links also subject to change, which will impact service consumers.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Raj Balasubramanian, Jim Webber, Thomas Erl, David Booth
|
|
|
|
| |
Problem
In any business environment there are entities that represent the primary and secondary artifacts involved in carrying out the business functions. These business entities can have numerous relationships with each other, many of which may even be dependencies. Some of these relations are physical in nature; some are implicit, while others may even be abstract. Understanding these relationships provides a useful insight as to the inner workings of an organization.
However, common service analysis and design approaches result in the delivery of services that are implemented independently with little to no indication of cross-entity relationships communicated to consumers. This can inhibit the consumer designers' understanding of the business entity relationships.
Solution
The relationship between business entities is expressed through the service contract or by inter-linking data sets and making these data-level relationships the basis of service-consumer data exchanges.
Application
There are two approaches to explicitly associating entities together at the service level:
|
•
|
The service contract can provide specific capabilities with names that indicate entity relationships.
|
|
•
|
Uniform Contract can be applied, requiring that entity relationships be defined at the data level and within the corresponding HTTP response or request representation.
|
The first approach is simply associated with how service capabilities are named. A Web service contract for a Customer service may expose an operation called "GetCustomerAccounts" to produce a listing of accounts for the given customer. In this case, the operation name itself communicates that the Customer and Accounts entities are related.
The second method relies on physically linking data sets at the level of representation in the request and response message together so that they can be accessed via the content of consumer request messages that express the same data entity relationships. In this case, Entity Linking is commonly applied by implementing a REST framework that positions a Uniform Contract via the standard HTTP method interface.
With this approach, the Customer service can be accessed via one of the pre-defined HTTP methods using a URI is based on the entity relationship. Because the data sets within the service implementation are cross-linked based on their entity relationships, these URI-based messages can navigated the inter-linked data architecture, as follows:
http://alleywood/customers/accounts/ab123
For service data represented as XML documents, this can be achieved using the XLink and XPointer technologies that provide a standard means of representing links between related XML documents.
Note: For HTML or XHTML documents, this pattern can be applied by using anchor tags to associated documents.
Impacts
Although an extent of entity relationship information can be expressed through customized service contracts, it is almost never a complete representation as it pertains only to the functionality offered by the service at any given point in time. Furthermore, different naming conventions used to determine service and capability names may be too vague and not conducive to accurately describing the nature of these relationships.
When this pattern is applied to REST services, XML documents representing entity-centric data sets need to be physically linked. This can tightly bind the underling data architecture and future changes to these links can have significant impacts because consumers are required to couple to the manner in which these links are established. In essence, this design pattern can result in negative consumer-to-implementation coupling because it simulates the type of negative coupling that occurs when consumer programs are bound to service contracts that mirror underlying physical data models.
Furthermore, the primary benefit of navigability is lost when content types used to represent data sets have no standard means of accommodating links.
Case Study Example
Subsequent to a meeting with its external partners, Alleywood architects are handed a new set of requirements that will need to result in enhancements to the Order History service. Specifically, the service needs to be able to show the relationship between the history of orders and to the individual order information. In addition several of the partners that have multiple accounts would like to be able to see how these accounts relate with each other.
To accomplish this, the existing Order and Order History schema (from the Transport Caching case study example) needs to be extended to address the new navigability requirements. Currently the linking between the data sets is performed inherently using specific attributes defined in the schemas. For example, each customer account has a customer_id attribute, as shown here:
<accounts customer_id="ab123">
<account id="9829">
<limit<20,000</limit>
<type<Checking</type>
<since<Jan 20, 2001</since>
</account>
</accounts>
There are two key issues the Alleywood team would like to address before starting on the actual implementation of this functionality:
|
•
|
They need to determine the direction of relationships and how navigation across the data sets should be allowed. For example, there is a one-to-many relationship between a customer and its accounts, but a many-to-many relationship between an order and its item. Therefore, does it make sense to have an explicit linking between accounts to customer as well as customer to accounts? Similarly, should there be a link between each order entry and its item?
|
|
•
|
Secondly, they need to decide on an appropriate representation for this data that will include explicit links and support for such linking as part of the content format. Their preference is an XML representation for accounts and order history data and they decide to use XPointer and XLink standards to express the links.
|
As far as the relationships are concerned, they choose to follow their existing business entity model and opt for linking accounts to customers, orders to items, and orders to customers (ignoring the reverse relationships from customers to accounts and customers to orders).
Provided here is a sample accounts profile record that has been modified to include explicit linking using an XLink to the customer profile:
<accounts xmlns:xlink=¡¦http://www.w3.org/1999/xlink¡¦
xlink:type=¡¨simple¡¨ xlink:href=
"http://alleywood/services/customers/ab123">
<account id=¡¨9829¡¨>
<limit>20,000</limit>
<type>Checking</type>
<since>Jan 20, 2001</since>
</account>
</accounts>
Similarly the orders have been modified to link back to the customer and item as well through the use of an XPointer to the specific account within a given customer, as follows:
<orders xmlns=¡¦http://alleywood/entity/orderhistory¡¦
xmlns:xlink=¡¦http://www.w3.org/1999/xlink¡¦
xlink:type=¡¨simple¡¨ xlink:href=
"http://alleywood/services/customers/ab123">
<order num='0101001092' xlink:type=¡¨simple¡¨ xlink:href=
"http://alleywood/services/customers/ab123#9829">
<placedOn>10/10/01</placedOn>
<placedBy>John C Randall</placedBy>
<totalPrice>$280.00</totalPrice>
<items>
<item xlink:type=¡¨simple¡¨ xlink:href=
"http://alleywood/services/products/p0190">
<name>GradeA Posts</name>
<qty>10</qty>
<unitprice>$14.00</unitprice>
</item>
</items>
</order>
</orders>
By using XPointer, the reference to the account with the ID of ¡§9829¡¨ for the customer with the ID of ¡§ab123¡¨ is referenced using the URI and a qualifier, as shown here:
http://alleywood/services/customers/ab123#9829
Now that explicit linking using XLink and XPointer has been added, service consumers can request customer profiles and navigate account details right from the order history response.
|
|
|
