Dual Protocols

How can an inventory be standardized and not limited to a single communications protocol?

Problem Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.
Solution The service inventory architecture is designed to support services based on primary and secondary protocols.
Application The primary and secondary service levels collectively represent the service endpoint layer and all services are subject to the standard service-orientation design principles. Specific guidelines are followed to minimize the impact of violating the Canonical Protocol pattern.	Impacts This pattern can lead to a convoluted inventory architecture design, increased governance effort and expense, and (when poorly applied) an unhealthy dependence on Protocol Bridging. Furthermore, the endpoint layer is semi-federated, decreasing potential consumers and reuse opportunities.
Principles Standardized Service Contract, Service Loose Coupling, Service Abstraction, Service Autonomy, Service Composability	Architecture Inventory, Service

Table 6.9 – Profile summary for the Dual Protocols pattern.

Problem

As advocated by the Canonical Protocol pattern, it is preferred for all services within an inventory to communicate with the same communications technology. However, when that technology is inadequate for certain types of data exchanges, it can compromise service interoperability, thereby undermining all of the other strategic goals of service-oriented computing.

Solution

Two levels of services are delivered within the same inventory:

•     a primary level based on the preferred protocol

•     a secondary level based on an alternative protocol

This allows the secondary protocol to be used whenever the primary protocol is deemed deficient or inappropriate.

Application

The most common example of a protocol that is chosen for standardization but that is part of a technology platform that may not be suitable for all types of services is the SOAP and Web services technology platform. Services can be built as Web services, thereby standardizing the inventory communications protocol as HTTP (plus SOAP).

This choice, however, can raise a number of issues:

•     SOAP introduces message-processing overhead that may be unreasonable for service capabilities that need to exchange granular amounts of data or that need to be invoked multiple times by the same consumer during the same business process.

•     The additional messaging-related processing may be considered inappropriate for services that physically co-exist on the same server and do not require remote communication.

•     The service may require a special feature that cannot be accommodated by the Web services technology platform due to an absence of vendor support.

As stated earlier, issues such as these can make it difficult to justify the Canonical Protocol pattern on an inventory-wide basis.

When applying this pattern to a Web services-based service inventory, services built as Web services are typically classified as the primary service level because the use Web services supports several other design benefits and patterns (such as Decoupled Contract and Vendor-Agnostic Context).

However, for circumstances where Web services do not represent a suitable implementation option for services, a secondary protocol is chosen. Most commonly, this alternative protocol is based on a particular component platform (such as Java or .NET). In this case, components are designed as self-contained services subject to the full set of service-orientation design principles (including the standardization of the component interface via the Standardized Service Contract principle).

Figure 6.43 – A service implemented as a Web service (top) and a service implemented as a component (bottom). Both have standardized service contracts and are subject to all service-orientation design principles.

Figure 6.x illustrates how primary services existing as Web services can co-exist with secondary services existing as components. Both primary and secondary service levels represent official endpoints as part of a semi-federated service endpoint layer.

Figure 6.44 – From an endpoint perspective, the service contracts are all standardized, but their implementations are based on different communication protocols.

There are significant risks when applying pattern as explained in the upcoming Impacts section. To minimize this impact, the following guidelines should be followed:

•     Services based on the primary protocol must be accessed via the primary protocol when invoked by secondary services. In the case of Web services, this means not allowing component-based services to directly access the underlying components of Web services-based services.

•     Consider some or all services in the secondary level as transition candidates. If this pattern was chosen due to a lack of maturity in the primary protocol, then secondary services can be earmarked for an upgrade to the primary level once the technology has sufficiently evolved.

•     During a transitional period, use the Concurrent Contracts pattern to enable a service to be accessible via either protocol. This way, it can begin to interoperate using the primary protocol while continuing to support consumers that rely upon the secondary protocol.

•     Apply the Redundant Implementation pattern wherever feasible in support of secondary services. This is especially relevant when component-based secondary services are primarily composed by the core service logic of Web services-based services to avoid remote communication. Redundant Implementation will support the autonomy of both primary and secondary service levels.

Note that some secondary services may never transition, and therefore always remain based on the secondary protocol. This may be due to the nature of their functionality or the convenience of keeping them for intra-service composition purposes only.

As shown in Figure 6.x, the first guideline in the previous list establishes some ground rules as to how primary and secondary services should and should not interact.

Figure 6.45 – Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually corrupt the service inventory.

The key requirement to successfully applying this pattern is for the service to continue adhering to Standardized Service Contract, Service Loose Coupling, and Service Abstraction design principles to avoid many of the negative, indirect coupling types that can lead to governance problems.

Impacts

This design pattern must be used in moderation. It imposes some significant architectural constraints and sacrifices that must be carefully assessed before committing to an architecture based on primary and secondary protocols.

For example:

•     The use of Concurrent Contracts to provide secondary services with two interfaces while they are being transitioned from secondary to primary status can lead to overly complex governance requirements. If this pattern is applied to a large service inventory with a large percentage of secondary services, the transition effort may be unwieldy.

•     The repeated application of Redundant Implementation in support of secondary services can rapidly increase infrastructure budgets and the overall configuration management effort required to keep all deployments of a given service in synch.

•     Depending on which technologies are chosen for primary and secondary protocol levels, this pattern may limit the application of other key design patterns, such as Canonical Data Model and Schema Centralization.

•     The examples in this chapter were focused on Web services comprised of components that shared the same protocol technology as the component-based services. If this pattern is applied to primary and secondary service levels that are based on disparate protocols, it will introduce the need for the constant application of Protocol Bridging.

•     This pattern introduces the on-going risk of imposing too much technology coupling upon consumers, thereby making plans to migrate to a fully federated service inventory difficult to fully attain.

There are concrete benefits to carrying out this design pattern in the right way, but it introduces a whole new dimension to a service-oriented architecture migration project and the associated risks need to be planned for in advance.

Relationships

The extra requirements that come with applying the Dual Protocols pattern often need to be addressed with the application of additional, supporting patterns, such as Redundant Implementation, Concurrent Contracts, and Protocol Bridging.

Although this pattern fundamentally preserves the goals of the Logic Centralization and Contract Centralization patterns, it ends up augmenting the default approach of carrying out the Canonical Protocol pattern by introducing the need for there to be two canonical protocols.

Figure 6.46 – The Dual Protocols pattern can increase the complexity of an inventory architecture and therefore requires the support of other key patterns.

Case Study Example

Case study content is not available on this Web site.