Application Integration::Broker application pattern::Runtime patterns

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

• Generic
• SOA profile

Generic DC runtime patterns

Broker application pattern::Runtime pattern
(Click a node to get a detailed explanation.)
Design Last Updated: 10-20-2004

The Broker tier in the Application pattern is implemented in this Runtime pattern with a Broker node. The Broker node is responsible for the routing and distribution of incoming messages to the target applications. It has the ability to decompose and recompose messages.

The Application Server/Services nodes execute the logic of the target and source applications.

Broker application pattern=Pub/Sub runtime variation
(Click a node to get a detailed explanation.)
Design Last Updated: 10-20-2004

Pub/Sub is a Runtime variation of the Broker application pattern. In this variation, the Broker node offers a dynamic quality of service named Pub/Sub. The Runtime pattern for this variation is a Collaboration composed from two types of interaction. The first of these is the Message Connection variation. This describes a subscribe/unsubscribe interaction which allows Target Applications to alter the Rules Directory content to add or remove themselves from distribution lists. The second type of interaction is the Broker interaction which describes how a single Source Application can use the Broker node to interact with multiple Target Applications.

The Pub/Sub quality of service can be further qualified as either synchronous or asynchronous. A synchronous interaction occurs when a Target Application only receives messages from the Broker node whilst online. An asycnhronous interaction occurs when messages from the Broker node are queued for the Target Application while it is offline.

SOA profile

In this second section we specialize the Broker 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]Broker runtime pattern (aka ESB runtime pattern)
(Click a node to get a detailed explanation.)
Design Last Updated: 04-28-2005

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.

[SOA]Broker=Integrated ESB variation (Emerging patterns)
The following are all emerging patterns which experienced integration architects expect to see in the near future. They will be verified as new products and new standards are introduced.

• ESB Topology patterns (Emerging patterns)
  • Directly Connected ESBs
  • Brokered ESBs
  • Federated ESBs
• ESB Governance patterns (Emerging patterns)
• ESB Adapter patterns (Emerging patterns)
  • Adapter Connector
  • Boundary Services Adapter Connector
  • Composite

ESB Topology patterns (Emerging patterns)
The ESB Topology patterns are variations of the SOA profile and describe topological relationships between ESBs.

ESB Topology::Directly Connected ESBs
(Click a node to get a detailed explanation.)
Design Last Updated: 10-14-2005

The Directly Connected ESBs pattern for integrating ESBs is the simplest type of interaction and is based on a point-to-point topology. Using this pattern will result in the ESBs communicating directly with each other.

ESB Topology::Brokered ESBs
(Click a node to get a detailed explanation.)
Design Last Updated: 10-14-2005

The Brokered ESBs pattern separates the ESB integration logic and related business rules from the ESBs. This pattern reduces the number of point-to-point connections which is a benefit over the Directly Connected ESBs pattern.

ESB Topology::Federated ESBs
(Click a node to get a detailed explanation.)
Design Last Updated: 10-14-2005

The Federated ESBs pattern adds orchestration of service consumer requests which will span multiple ESBs and/or multiple service providers. It also adds the ability to attach a service consumer directly to the hub component.

ESB Adapter patterns (Emerging patterns)
The ESB Adapter patterns describe how the ESBs will send and accept messages and more importantly, message context.
The following table lists the major differences between the two ESB Adapter patterns.

ESB Topology::Adapter Connector
(Click a node to get a detailed explanation.)
Design Last Updated: 11-01-2005

The ESB Adapter::Adapter Connector pattern is an established pattern and is not unique to ESB integration. It is a common pattern when connecting heterogeneous applications (See Process Integration::Direct Connection). In the case of ESB integration the ESB Adapter::Adapter Connector pattern supports the interaction between a service consumer on a local ESB and a service provider on a foreign ESB. The logic to translate ESB behaviors (for example logging, assured delivery, and security) to support that interaction are built into the adapter connector and then bound to the adapter connector at design time.

ESB Topology::Boundary Services Adapter Connector
(Click a node to get a detailed explanation.)
Design Last Updated: 11-01-2005

The Boundary Services Adapter Connector is an emerging pattern to create run time (as opposed to design time) configurable and composible interactions between applications. Boundary Services Adapter Connector lives at the edge of an application and takes the context of an event outside of the boundary and translates it to a context understood within the boundary. It also takes the internal event context and prepares it for external consumption. The Boundary Services Adapter Connector pattern has roots in SOA techniques.

ESB Topology::Composite
As with the Governance patterns and Topology patterns it is possible to use more than one ESB Adapter pattern. It is doubtful that any instance of integrated ESBs will be implemented using only the Adapter Connector or the Boundary Services Adapter Connector pattern. The reasons to use both ESB Adapter patterns can be financial and technical and it will be necessary to make trade-offs between implementing the Boundary Services Adapter Connector and Adapter Connector patterns.

Next, review product mappings for this Runtime design.