Skip to main content

Application Integration::Broker application pattern=Router variation::Runtime patterns

Overview

On this page, two categories of Runtime patterns are described:

Generic DC runtime patterns

Broker application pattern=Router variation::Runtime pattern

Broker=Router variation::Runtime pattern Service Consumer and Service Providers are linked via a Router node.
Application Server / Services Application Server / Services Application Server / Services Application Server / Services Rules Directory Router Node
Design Last Updated: 10-20-2004
(Click a node to get a detailed explanation.)

The Router node provides the logic to perform intelligent routing of messages to one target application at a time. It does not include the simultaneous distribution or decomposition capabilities that the Broker node provides.

SOA profile

In this second section we specialize the Router pattern for the SOA environment using the SOA profile. The SOA profile terminology is indicated using the [SOA] qualifier.

The generic Broker, and Rules Directory in the figure above are specialized in the SOA profile to:

  • an ESB (supporting the Broker and Rules Directory requirement plus the SOA infrastructure requirement for service location transparency and interoperability, encapsulated reusable business function and explicit implementation-independent interfaces)
  • Service Consumers and Providers

[SOA]Router runtime pattern (aka ESB runtime pattern)

[SOA]Router Several Service Consumers and Providers are linked via a Enterprise Service Bus.
Application Server / Services Application Server / Services Application Server / Services Application Server / Services Application Server / Services Application Server / Services Enterprise Service Bus
Design Last Updated: 05-04-2005
(Click a node to get a detailed explanation.)

The use of an Enterprise Service Bus offers the following benefits:

  • The ESB is a bus with a single configuration and distributed deployment. Managing communications through the bus provides many advantages, including decoupling of service requesters and providers, and centralized control of a service namespace.
  • Protocol conversion occurs inside the ESB (for example, SOAP/HTTP to SOAP/JMS). Requesters using one protocol can invoke services that are exposed using a different protocol.
  • The ESB can provide logging and transformation of service requests and service responses.
  • The ESB can provide centralized security for Web services invocations. It can, for example, authenticate all service requesters centrally.
  • The ESB provides a common access point for service requesters that need access to services providers. The ESB intercepts and routes requests to the relevant service provider. A change in the location of the service provider only affects the ESB routing; the service provider location remains transparent to the service requester.

Specifically, we use the Enterprise Service Bus=Router variation to provide:

  • Service routing of requests from service requesters to the relevant service provider based on a routing table.
  • Protocol transformation, to allow the decoupling of the protocol that is used between the service requesters and service providers.

Next, review product mappings for this Runtime design.

Close [x]

App Server/Services

Applications rely on services provided by their hosting server to interact with other applications. These are modeled using the application server/service node. Some examples of services provided by this node include:

  • A TCP/IP pipe established using the hosting operating system
  • A servlet or Enterprise JavaBean (EJB) invoked by WebSphere Application Server
  • The Java Message Service (JMS) or Java 2 Platform, Enterprise Edition (J2EE) Connector application programming interfaces (APIs) provided by WebSphere

Close [x]

Rules Directory

The rules directory contains the rules generally used to control the mode of operation of an interaction, depending on external factors. Examples of such rules are:

  • Business data mapping rules (for adapter connectors)
  • Process execution rules and intermediate results
  • Autonomic rules (such as priority in a shared environment)
  • Security rules
  • Capacity and availability rules

The rules directory may or may not exist. If it exists, it can still be left off the Runtime pattern when analysis determines that interaction rules are not an important part of the solution, for example.

Close [x]

Router

The Router node is a variation of the Broker node. It allows a single interaction from a source component to be switched and adapted to only one of multiple target components. It separates the application logic from the distribution logic based on router rules.

Close [x]

ESB

The ESB is a key enabler for a SOA as it provides the capability to route and transport service requests from the service requester to the correct service provider. The true value of the ESB concept, however, is to enable the infrastructure for SOA in a way that reflects the needs of today’s enterprise: to provide suitable service levels and manageability, and to operate and integrate in a heterogeneous environment.

Furthermore the ESB needs to be centrally managed and administered and have the ability to be physically distributed.

Close [x]

SOA

The original set of PI patterns is intended to satisfy a wide generic set of integration requirements, not just SOA. The SOA profile specialises these more general patterns for the SOA environment.

[SOA]Router runtime pattern variations (aka Integrated ESB runtime patterns)

As the [SOA]Router runtime pattern variations are the same as the [SOA]Broker runtime pattern variations, the links below lead you to the [SOA]Broker runtime patterns. To see product mappings, guidelines and related links, please follow the path on the [SOA]Broker page.