Intermediate Routing

How can dynamic runtime factors affect the path of a message?

Problem The larger and more complex a service composition is, the more difficult it is to anticipate and design for all possible runtime scenarios in advance, especially with asynchronous, message-based communication.
Solution Message paths can be dynamically determined through the use of intermediary routing logic.
Application Various types of intermediary routing logic can be incorporated (most commonly via service agents) to determine message paths based on message content or environmental factors.	Impacts Dynamically determining a message path adds layers of processing logic and correspondingly can increase performance overhead. Also, the use of multiple routing agents can result in overly complex service activities.
Principles Service Loose Coupling, Service Reusability, Service Composability	Architecture Composition

Table 6.11 – Profile summary for the Intermediate Routing pattern.

Problem

A service composition can be viewed as a chain of point-to-point data exchanges between composition participants. Collectively, these exchanges end up automating a parent business process.

The message routing logic (how messages are passed from one service to another) can be embedded within the logic of each service in a composition. This allows for the successful execution of predetermined message paths. However, there may be unforeseen factors that are not accounted for in the embedded routing logic, which can result in the risk of system failure.

Examples of this include:

•     The destination service a message is being transmitted to is temporarily (or even permanently) unavailable.

•     The embedded routing logic contains a Òcatch allÓ condition to handle exceptions, but the resulting message destination is still incorrect.

•     The originally planned message path cannot be carried out, resulting in a rejection of the message from the serviceÕs previous consumer.

Figure 6.x illustrates these scenarios.

Alternatively, there may simply be functional requirements that can only be fulfilled by dynamically determining a message path.

Figure 6.51 – A message transmission fails because the service is not available (A). Internal service routing logic is insufficient and ends up sending the message to the wrong destination (B). Internal service logic is incapable of routing the message and simply rejects the message (C), effectively terminating the service activity.

Solution

Generic, multi-purpose routing logic can be abstracted so that it exists as a separate part of the architecture in support of multiple services and service compositions. Most commonly this is achieved through the use of event-driven service agents that transparently intercept messages and dynamically determine their paths (Figure 6.x).

Figure 6.52 – A message passes through two router agents before it arrives at its destination. The Rules-Based Router identifies the target service based on a business rule that the agent dynamically retrieves and interprets (see the Rules Centralization pattern). The Load Balancing Router then checks current usage statistics for that service before it decides which instance or redundant implementation of the service to send the message to.

Application

The service agents required to perform dynamic routing are often provided by messaging middleware and are a fundamental component of ESB products. These types of out-of-the-box agents can be configured to carry out a range of routing functions. However, the creation of custom routing agents is also possible and not uncommon, especially in environments that need to support complex service compositions with special requirements.

Common forms of routing functionality include:

•     Content-Based Routing: Essentially, this type of routing determines a messageÕs path based on its contents. Content-based routing can be used to model complex business processes and provide an efficient way to recompose services on the fly. Such routing decisions may need to involve access to a business rules engine to accurately assess message destinations.

•     Load Balancing: This form of routing agent has become an important part of environments where concurrent usage demands are commonplace. A load balancing router is capable of directing a message to one or more identical service instances in order to help the service activity be carried out as efficiently as possible.

•     1:1 Routing: In this case, the routing agent is directly wired to a single physical service at any point in time. When messages arrive, the agent is capable of routing them to different service instances or redundant service implementations. This accommodates standard fail-over requirements and allows services to be maintained or upgraded without risking Òdisruption of serviceÓ to consumers.

Regardless of the nature of the routing logic, it is desirable to be able to update and modify routing parameters dynamically – ideally even by business analysts so that they can adapt and control the business logic in real-time. This is particularly important when business logic is subject to frequent change. If changes are extremely frequent it can be further beneficial to model the routing logic through the extraction of complex business rules that describe declarative logic on top of the message content and use the outcome to make the routing decision.

A more frugal alternative is to employ content-based routing using XPath or XQuery expressions. However, these languages require technically more involved personnel for their control and maintenance.

Impacts

The usage of routing agents allows the automation of complex decisions and the quick adaptation to changing business requirements. However, the complexity and flexibility of incorporating intermediate routing logic into composition architectures is not without disadvantages:

•     Dynamic modification of routing rules at runtime can introduce the risk of having previously untested logic set into production. If possible, routing rule set changes should first be put through a conventional staging process.

•     Dynamic routing paths can be elaborate and therefore difficult to manage and update, leading to a risk of unexpected failure conditions. A centralized routing rule management system can help alleviate the risk of introducing a central point of failure.

•     Physically separated routing logic will naturally add performance overhead when compared to direct consumer-to-provider communication, where the routing logic is embedded within the consumer program.  

Additionally, security can be a concern when applying this pattern. You may want to control who will and will not process a message containing sensitive data. An inventory architecture with many built-in intermediate routing agents can provide native functionality that conflicts with some security requirements.

Relationships

Routing functionality can be associated with most messaging-related design patterns, including the fundamental Service Messaging pattern as well as Message-Level Security. The extra metadata provided by the Messaging Metadata pattern allows the more advanced forms of routing described earlier in the Applications section.

When implement routing logic within event-drive agents (as per the Service Agent pattern), the Canonical Resources pattern can influence the platform and technologies used to build and host the agent programs.

Figure 6.53 – The Intermediate Routing pattern provides specialized, agent-related processing in support message transmissions, and therefore has relationships with several messaging patterns.

Because of their messaging-centric feature-sets, enterprise service bus platforms are fully expected to carry out Intermediate Routing functionality in support of sophisticated service activity processing. As shown in Figure 6.x, this pattern is therefore one of the three core patterns that represent the Enterprise Service Bus compound pattern.

Figure 6.54 – The Intermediate Routing pattern is one of three core design patterns that comprise the Enterprise Service Bus compound pattern.

Case Study Example

Case study content is not available on this Web site.