"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)
Uniform Contract is considered a variation of Reusable Contract that is applied to all services within a given boundary (usually a service inventory). This compound pattern further requires that service functions are broken down into individual granular resources, as per Lightweight Endpoint and that links from one resource to another can be followed to allows service consumer to invoke the capabilities of each resource without foreknowledge of the service that exposes them. The link itself provides supplementary business context information that may have been abstracted out of the uniform contract. It both identifies the resource and provides machine-readable context that describes the business concept to which the link is referring. As a result, a uniform contract enables the dynamic recomposition of services and consumers.
Service consumers are able to discover new URLs at runtime and interact with them correctly because the interaction they want to perform is the same, regardless of which resource the interaction is directed at. Consumers are also able to use new resources they discover over the course of these interactions and use them correctly.
Uniform contracts are highly abstract and general. As explained in previous chapters, they are a core part of REST service architecture, relying on generic methods, such as GET and PUT, which are combined with media types in order to maximize the applicability and reuse of the contract. Also included as part of a uniform contract are headers and status codes used as part of the protocol and media types such as those in common use on the Web.
Figure 2: A uniform contract may necessitate that services expose multiple lightweight endpoints in order to provide enough context to ascribe meaning to uniform method invocations. In this case, the service capabilities can be read as "fetch the tax report", "fetch the invoice report", and "fetch the customs report". Each of these capabilities can return information in documents compliant with the same report media type.
Uniform Contract Pattern vs. Uniform Contract Constraint
The Uniform Contract compound pattern provides an alternative means of viewing and breaking down the uniform contract artifact and the Uniform Contract REST constraint that has were introduced in Part I and will continue to be referenced throughout upcoming chapters. To avoid confusion, when discussing an architecture from a patterns or constraints perspective, the capitalized term "Uniform Contract" is further qualified as a design pattern or constraint.
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura YouTube Channel
This page contains excerpts from:
