Protocol Bridging

How can a service exchange data with consumers that use different communication protocols?

Problem Services using different communication protocols or different versions of the same protocol cannot exchange data.
Solution Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.
Application Instead of connecting directly to each other, consumer programs and services connect to a broker which provides bridging logic that carries out the protocol conversion.	Impacts Significant performance overhead can be imposed by bridging technologies, and their use can limit or eliminate the ability to incorporate reliability and transaction features.
Principles Standardized Service Contract, Service Composability	Architecture Inventory, Composition

Table 6.18 – Profile summary for the Protocol Bridging pattern.

Problem

Services delivered as part of different project teams or at different times can be built using different communication technologies. For example, services can use completely disparate frameworks (such as JMS and DCOM) or different versions of the same communications technologies (such as HTTP plus SOAP versions 1.1 and 1.2).

This is a common scenario when design standards are not prevalent in an enterprise and services are primarily designed in support of tactical requirements. As a result, service interoperability outside of immediate composition boundaries is severely diminished, leading to missed opportunities to reuse and recompose services for new purposes. Over time, this leads to ÒislandsÓ of disparate service compositions that are reminiscent of traditional, silo-based application environments.

Figure 6.80 –  The consumer programs (left) cannot access the service because the communications protocols used by the consumers are not supported by the service. The service only accepts messages that comply to SOAP version 1.2 transmitted via HTTP.

Solution

Protocol bridging technology is used to overcome the disparity between different communications frameworks by enabling the runtime conversion of protocols.

Figure 6.81 – The consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

Application

This pattern is commonly employed when legacy systems need to act as service consumers or when legacy logic needs to be encapsulated by services. As mentioned earlier, it is also used to overcome communication gaps when disparate sets of services are delivered.

A protocol bridging layer is composed of a set of adapters that act as on-/off-ramps for a given transport protocol. These adapters may be off-the-shelf products provided by the broker or a third-party vendor, or they may be generated to mirror specific service contracts using a proprietary protocol dialect.

Taking non-functional aspects (such as transactions, reliability, synchronicity) into account, these adapters convert messages from one protocol-specific binding into another. When a protocol bridge receives a message it transforms the received message into a protocol (or protocol version) compliant format and does whatever other work is required to comply with the target protocol (or protocol version).

Protocol bridging can be used to expose or access services via multiple protocols, depending on whether adapters are implemented on the consumer or provider end. A multi-protocol conversion program can offer support for numerous protocols (HTTP, JMS, UDP, TCP, etc.) that can be natively exposed as independent protocol bridging services.

Impacts

While necessary to overcome protocol disparity, Protocol Bridging is a pattern only used out of necessity. From an architectural perspective, it is considered an undesirable option because of the design complexity and runtime performance overhead it imposes. Even though it can support interoperability between services, it does so at a less than optimal level. Service compositions relying on this pattern often end up having decreased levels of availability and reliability.

Protocol Bridging originated with early EAI platforms and is therefore still considered an integration-related design approach. The manner in which it involves protocol adapters and translation logic can be overly complex because of the binary encoding used by many transport protocols. In some cases, protocol conversions may result in inaccurate semantic meanings being applied to message contents.

Though an expected part of brokerage functionality, some platforms may support limited sets of protocols with an emphasis on conversion to and from SOAP and HTTP only.

Relationships

Protocol Bridging is a pattern that has long been used to solve traditional integration problems, and therefore finds itself closely related to Legacy Wrapper and Dual Protocols (when disparate dual protocols are used). The nature of the bridging technology can be influenced by Canonical Resources when choices are available.

The extent to which this pattern is applied to intra-service bridging requirements only is based on how successful the application of the Canonical Protocol has been in achieving a sole inter-service communications technology.

Figure 6.82 – The Protocol Bridging pattern provides low-level conversion of different communication technologies and therefore relates to patterns (such as Inventory Endpoint and Legacy Wrapper) that require this type of functionality, as well as standards-based pattern that seek to avoid it.

As member of the Broker compound pattern, Protocol Bridging is commonly associated with the parent Enterprise Service Bus pattern (Figure 6.x).

Figure 6.83 – The Protocol Bridging pattern provides fundamental integration functionality that positions it as a core patter of both Broker and Enterprise Service Bus compound patterns.

Case Study Example

Case study content is not available on this Web site.