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)
|
|
|
Augmented Protocols (candidate)
|
Home > Candidate Patterns List > Augmented Protocols
|
|
"How can a service inventory augment its service offering without diverging from or compromising its Canonical Protocol?"
|
|
|
|
Problem
Canonical Protocol requires that all services conform to the use of the same communications technology; however Canonical Protocol can constrain quality of service when additional protocols are also available.
|
|
|
Solution
The architectures single communications technology established as the sole or primary medium by which services interact is augmented to support additional beneficial protocols.
|
|
|
Application
A Canonical Protocol is applied to provide standardization of protocols across the service inventory. Where feasible and desirable services are augmented by applying additional protocols giving consumers additional beneficial service levels.
|
|
|
|
Impacts
The inventory architecture established using Canonical Protocol retains all benefits of it benefits but removes limitations imposed via its 'lowest common denominator' communication technology by offering augmented protocols.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Duanne O'Brien
|
|
|
|
| |
Note
For a definition of what a "protocol" refers to in this pattern, see the What Do We Mean by "Protocol?" section in the pattern description for Canonical Protocol - SOA Design Patterns, Thomas Erl, Prentice Hall.
Problem
As advocated by Canonical Protocol, there are many advantages for all services in an inventory to interact using the same communication technology. However, this inventory-wide standardization provides a lowest common denominator approach and can't take advantage of advancement and extension to protocols.
Solution
Additional protocols are supported as augmentation over and above the Canonical Protocol. This provides all of the benefits provided by Canonical Protocol, but allows services and consumers to communicate over additional protocols where applicable.
Figure 1: A consumer has the option to send a message using the Canonical Protocol, or for a better quality of service has the option to send a message using Augmented Protocols.
This solution provides the benefits of the combination of Canonical Protocol and Dual Protocols without their limitations.
Application
There is little argument against the fact that the most successful protocol in terms of vendor products, tooling and SOA implementations is HTTP, XML and SOAP, and more specifically the WS-I Basic Profile specification adoption.
While WS-I Basic Profile provides excellent interoperability, by its very nature it also limits the capability of consumers to services communication that can be achieved using other protocols.
A case in point is the use of Microsoft's Windows Communication Framework (WCF) as a foundation within the SOA. WCF is Microsoft's offering for all remote computing and in particular has been built from ground up as a first class approach to building and hosting Web Services.
Microsoft defines its endpoint protocol configurations as bindings. One of the out of the box Microsoft WCF bindings offers is the WS-I Basic Profile compliant BasicHttpBinding binding. In a service implemented using WCF, BasicHttpBinding is generally applied to provide the required protocol support for Canonical Protocol and therefore any service consumer that is WS-I Basic Profile compliant can access the service.
In addition to the BasicHttpBinding, Microsoft also offers a number of other bindings that augments WS-I Basic Profile including but not limited to:
|
•
|
WSHttpBinding - Includes support for WS-* standards and provides rich security, reliability, transactional and other features over HTTP.
|
|
•
|
NetTcpBinding - A high throughput binding with support for WS-* standards that leverages the benefits of low latency TCP.
|
|
•
|
NetMsmqPipeBinding - A high throughput binding with support for WS-* standards that leverages the benefits of queuing.
|
A service offered using WCF can use any combination of bindings as the binding configurations are decoupled from the service implementation.
The challenges in applying Augmented Protocol will very much depend on the technology chosen to implement services. In terms of WCF, bindings and the protocols that they represent are typically externalized within configuration files. This approach means making changes to protocols for Canonical Protocol and Augmented Protocols governed and applied by Infrastructure Architecture rather than the development process.
Figure 2: Using Canonical Protocol, the consumer sends a message to the service using the adopted WS-I Basic Profile XML + HTTP + SOAP communication technology stack. Using Augmented Protocols, the consumer sends a message to the service using Canonical Protocol, or has a number of options using the Augmented Protocol communication technology stacks. Using one of the protocols provided by Augmented Protocol gives the consumer additional benefits over and above the Canonical Protocol restrictions.
An implementation of SOA using Augmented Protocol supports services and consumers communicating using Canonical Protocol and augments this by providing additional protocols.
Impacts
The success of applying this pattern is based on the fact that it augments and extends Canonical Protocol and is not a replacement for it. Without adopting Canonical Protocol, an SOA cannot apply Augmented Protocol.
Adopting Augmented Protocol significantly reduces the likelihood of having to apply Dual Protocols.
|
|
|
