Home > Design Patterns > Augmented Protocols

Augmented Protocols (O'Brien)

How can a service inventory augment its service offering without diverging from or compromising its Canonical Protocol?

Augmented Protocols

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 architecture's single communication technology that is 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. Feasible and desirable services are augmented by applying additional protocols, giving consumers additional beneficial service levels.

Impacts

The inventory architecture that is established using Canonical Protocol retains all of its benefits, but removes limitations imposed via its "lowest common denominator" communication technology by offering augmented protocols.

Architecture

Inventory, Service

Problem

As advocated by Canonical Protocol, there are many advantages for all of the 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 also allows services and consumers to communicate over additional protocols where applicable.

Augmented Protocols: A consumer has the option of sending a message using the Canonical Protocol, or the option of sending the message using Augmented Protocols for improved quality of service.

A consumer has the option of sending a message using the Canonical Protocol, or the option of sending the message using Augmented Protocols for improved quality of service.

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 protocols 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 standardized interoperability, it also by its very nature limits the capability of consumers to engage in services communication that is 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 the 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 offered 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. Any service consumer that is WS-I Basic Profile compliant can therefore access the service.

In addition to the BasicHttpBinding, Microsoft also offers a number of other bindings that augments WS-I Basic Profile that is 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 success of applying this pattern is based on the fact that it augments and extends Canonical Protocol and is not a replacement for it. An SOA cannot apply Augmented Protocol without adopting Canonical Protocol. Adopting Augmented Protocol significantly reduces the likelihood of having to apply Dual Protocols.

Impacts

The challenges in applying Augmented Protocol depend greatly on the technology that is chosen to implement services. In terms of WCF, bindings and the protocols that they represent are typically externalized within configuration files. This approach means that any changes that are made to the protocols for Canonical Protocol and Augmented Protocols are governed and applied by Infrastructure Architecture rather than the development process.

Augmented Protocols: 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 either 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.

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 either 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 that communicate using Canonical Protocol, and augments this by providing additional protocols.