Service Messaging

How can services interoperate without forming persistent, tightly coupled connections?

Problem Services that depend on traditional remote communication protocols impose the need for persistent connections and tightly coupled data exchanges, increasing consumer dependencies and limiting service reuse potential.
Solution Services can be designed to interact via a messaging-based technology, which removes the need for persistent connections and reduces coupling requirements.
Application A messaging framework needs to be established and services need to be designed to use it.	Impacts Messaging technology brings with it quality of service concerns such as reliable delivery, security, performance, and transactions.
Principles Standardized Service Contract, Service Loose Coupling	Architecture Inventory, Composition, Service

Table 6.25 – Profile summary for the Service Messaging pattern.

Problem

Common implementations of distributed solutions rely on remote invocation frameworks, such as those based on RPC technology. These communication systems establish persistent connections based on binary protocols to enable the exchange of data between units of logic.

Although efficient and reliable, they are primarily utilized within the boundaries of application environments and for select integration purposes. Positioning an RPC-based component as an enterprise resource with multiple potential consumers can lowering its concurrency threshold because of the overhead associated with creating, sustaining, and terminating the persistent binary connections.

Solution

Messaging provides an alternative communications framework that does not rely on persistent connections. Instead, messages are transmitted as independent units of communication routed via the underlying infrastructure.

Figure 6.109 – Services interact via the transmission of messages, self-contained units of communication.

Application

A messaging framework supported by the enterpriseÕs technical environment needs to be implemented to an extent that it is capable of supporting service interaction requirements. Many established design patterns for messaging frameworks exist, most of which emerged from experience with enterprise integration platforms.

Impacts

Some messaging frameworks cannot provide an adequate level of QoS to support the high demands that can be placed on services positioned as enterprise resources.

To fully enable the application of the Capability Recomposition pattern and many of the advanced service and architectural patterns, the message framework must provide a means of:

•     guaranteeing the delivery of each message or guaranteeing a notification of failed deliveries

•     securing message contents beyond the transport

•     managing state and context data across a service activity

•     transmitting messages efficiently as part of real-time interactions

•     coordinating cross-service transactions

Without these types of extensions in place, the availability, reliability, and reusability of services will impose limitations that can undermine the strategic goals associated with SOA in general. As explained in the upcoming Relationships section, several, more specialized patterns address these issues.

Relationships

As one of the most fundamental design patterns in this catalog, Service Messaging ties directly into interoperability design considerations. The success of this pattern is therefore fully dependent on the extent to which the Canonical Protocol and Canonical Data Model patterns are applied within a given inventory.

The Service Agent pattern forms a functional relationship with Service Messaging in that event-driven agent programs transparently intercept and process message contents. Messaging Metadata has a close relationship with Service Messaging because it essentially extends the typical message to incorporate meta details.

Figure 6.110 – The fundamental Service Messaging pattern establishes the basis for many, more specialized communication and messaging-related patterns.

Case study example

Case study content is not available on this Web site.