SOA Pattern (#13): Canonical Protocol
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The rationale behind the Canonical Protocol pattern is very much fundamental to the actual reason behind adopting an SOA: designing solution logic in the form of interoperable services that can be repeatedly composed and is further linked with the increased ROI goal of SOA. This means that a prerequisite for service reuse is the ability for the services to be able to communicate with each other without requiring a bridging mechanism. Although the use of bridging technology makes a service available for reuse over a set of different communication protocol(s), such reuse is totally dependent upon the limitations of the bridging technology, for example, the types of protocol transformations that a bridging technology supports. Apart from this, the introduction of a protocol bridging layer introduces latency and processing overhead.
In order to address the aforementioned issues, the Canonical Protocol design pattern advocates standardizing a common communication framework for designing services in a service inventory. Although organizations would normally choose the web services framework because of the interoperability it provides, it is worth mentioning that choosing a communication framework should entirely be based upon the communication requirements of the service inventory. These communication requirements are best gathered by analyzing the service inventory blueprint as at this stage during the service delivery process, the services exist only as candidates, and before moving towards the design phase, an agreement on the communications framework would result in a more coherent service design. For example, an analysis of the service candidates contained within a service inventory blueprint may reveal that these services would never be composed by services outside the contained service inventory and that the kind of compositions in which they would be composed use TCP/IP based communication. Based on these requirements, it makes sense to use a binary protocol based communication technology rather than resorting to the more verbose SOAP over HTTP protocol. If subsequent service delivery projects reveal that there are some service capabilities which are of interest to other service inventories, the Inventory Endpoint pattern could be applied to create a service that is based on SOAP over HTTP protocol.
In some cases, services may communicate more efficiently if they use a proprietary protocol for communicating to services within the same service inventory; however, for interoperability with other service inventories, they may need to support an interoperable protocol. This could be achieved by standardizing on a communication framework that supports different bindings for the same service contract. For example, in case of Windows Communications Foundation (WCF), same contract could be exposed via an http binding as well as the proprietary nettcp binding. This is exactly what is advocated by the Dual Protocols design pattern as this mechanism establishes a primary and a secondary communication protocols for different types of service consumers.
The application of this design pattern endeavors to minimize the requirement for the application of the Protocol Bridging design pattern. However, in some cases it may be necessary to apply both of these patterns together. For example, the Canonical Protocol pattern can be applied to establish an interoperable inter-service communication channel; however, within the service implementation itself, the Protocol Bridging pattern can be applied in order to bridge any protocol disparity between the service logic and the underlying implementation resources.
The Canonical Protocol is a fundamental inventory standardization pattern that attempts to increase service reuse and recomposability by dictating the use of a single communication protocol for inter-service communication. Although its rationale seems to be simple and straightforward, the success of its application depends upon the ability to understand the true communication requirements of a service inventory and then to choose a communication framework that is mature, scalable and cost effective.
The SOA Pattern series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOAPatterns.org community site and the book “SOA Design Patterns” (Erl et al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the Prentice Hall Service-Oriented Computing Series from Thomas Erl (www.soabooks.com).