The mediation layer is part of the integration domain level and is responsible for forwarding information. It includes the most important functionality of the integration domain. Its main task is to ensure the reliable forwarding of information to business components in the process layer, or directly to building blocks in the collection/distribution layer. In more complex scenarios, the information forwarding process can be enhanced by information transformation and filtering, and so on.
The basic requirements for the implementation of the mediation layer are listed in the following table, along with where in the book to find more information.
|
Requirement |
Section of Chapter 1 |
|---|---|
|
Messaging, publish/subscribe, message brokers, and messaging infrastructure |
Messaging Publish/subscribe Message broker Messaging infrastructure |
|
ESB |
Enterprise Service Bus (ESB) |
|
Point-to-point, hub-and-spoke, pipeline, and Service-Oriented Architectures |
Integration architecture variants |
|
Federation, population, and synchronization |
Data integration |
|
Direct connections, broker, and router |
EAI/EII |
The base technologies needed for the implementation of the mediation layer are listed in the following table:
|
Base technology |
Section of Chapter 2 |
|---|---|
|
OSGi |
OSGi |
|
Java Business Integration (JBI) as a sample ESB implementation |
Java Business Integration (JBI) |
|
Service Component Architecture (SCA) as a sample component framework |
Service Component Architecture (SCA) |
The following building blocks are used in the mediation layer:
One problem that occurs in many integration scenarios, is the need to map external data formats from several different source systems onto the internal data formats of many different target applications. In the case of a point-to-point approach, each combination would have to be mapped individually.
The problem can be resolved by introducing a general format, which is used in the integration solution and in all new target applications. Only one mapping to this internal format needs to be maintained for the existing applications. This keeps maintenance and development costs to a minimum. Internal formats of this kind are referred to as canonical formats. In the context of ESB, the term normalized message format is also used.
Canonical data models are independent of any specific application. Each application is decoupled from other formats and only needs to be able to generate and read the canonical format. Application-specific components that implement the message translator pattern are used for this purpose.
A canonical data model reduces the number of message translators needed, as only one is required for each application.
One single canonical data model does not always have to cover the whole enterprise. It's definitely valid, and often even better, to start small and to only concentrate on a subset of the data within an enterprise, often on so-called domain levels. The result of this is to have different and independent canonical data models, each with a domain specific scope. Such a canonical data model can be seen as a domain-specific view on the enterprise-wide data model.
In an environment where multiple ESBs are used on different levels (using the federated ESB pattern), it's also possible to have different canonical models on each level, that is a federated canonical data model message endpoint.
This group of patterns connects applications to messaging systems. The building blocks are listed in the following table, though only those patterns that are frequently used in practice are described:
|
Building Block |
Description |
|---|---|
|
Message endpoint |
An application is connected to a message channel through a message endpoint. This is a client of the messaging system and the application can send and receive messages via this message endpoint. |
|
Polling consumer |
A polling consumer sends a call to the messaging system only when the application wants to receive a message. This is also referred to as a synchronous receiver, as the receiver is blocked until the message is received. The receiver polls for a message, processes it, and then polls for the next message. |
|
Event-driven consumer |
An event-driven consumer is a component that is called by the messaging system when a new message arrives on the consumer channel. Using a callback method in the application API, the event-driven consumer forwards the message to the application. This is also referred to as an asynchronous receiver, as the receiver does not have a running thread until the callback thread delivers a message. |
|
Competing consumers |
Competing consumers are a group of several potential receivers on a single point-to-point channel. The consumers compete with one another, but only one can process each specific message. This makes it possible to process several messages in parallel. |
|
Message dispatcher |
A message dispatcher reads a message from an individual channel and sends it to the correct receiver, where it is processed. The message dispatcher can decide which receiver is appropriate for each message. |
|
Selective consumer |
Selective consumers filter the messages arriving in the channel and receive only those messages which fulfill the selection criteria. |
This group of patterns is responsible for sending messages using channels, the details of which are listed in the table below. Note that only those patterns which are frequently used in practice are described.
|
Building Block |
Description |
|---|---|
|
Request/reply |
Request/reply ensures that an application which sends a message to the messaging system can receive a reply from the receiver. A message request/reply pair is used for this purpose, with each message having its own channel. |
|
Building Block |
Description |
|
Return address |
In a request/reply scenario, the request message contains the return address, which specifies where the reply message should be sent. |
|
Correlation identifier |
Each reply message can contain a correlation identifier (a unique ID), which specifies the request message that the reply refers to. |
This group of patterns relates to different types of channels, and the methods used to connect them to an application. The building blocks are listed in the following table. Only those patterns which are frequently used in practice are described.
|
Building Block |
Description |
|---|---|
|
Point-to-point channel |
The use of a point-to-point channel allows the message system to ensure that a message can only be processed by one single receiver. |
|
Publish/subscribe channel |
A publish/subscribe channel makes it possible for a message to have several potential receivers. The messaging system ensures that every receiver receives the message once. |
|
Invalid message channel |
If a receiver recognizes that a message is incorrect (for example, in its format) or seems to not make sense, it can place the message in an invalid message channel, which is a special channel for messages that the receiver cannot process. |
|
Dead letter channel |
If the messaging system recognizes that it is not possible to deliver a message, it can move the message to a dead letter channel. This channel is also referred to as a dead letter queue or dead message queue. |
|
Channel adapter |
The channel adapter acts as a client of the messaging system and calls the application via a specific API. This allows every application to be connected to a messaging system and to interact with other applications, providing that a suitable channel adapter is available. |
This group of patterns enables the sender and the receiver of a message to be more effectively decoupled. The building blocks are listed in the following table. Only those patterns which are frequently used in practice are described.
|
Building Block |
Description |
|---|---|
|
Pipes and filters |
Pipes-and-filters is a style of architecture which allows larger processing tasks to be broken down into a sequence of smaller, independent steps (filters) connected through channels (pipes). |
|
Content-based router |
A content-based router sends a message to the correct receiver on the basis of its content. The routing process can be based on a range of different criteria, such as the existence of fields or field contents. |
|
Message filter |
The message filter is a special type of router. On the basis of a selection of criteria, it removes unwanted messages from a channel. If a message meets the filter criteria, it is forwarded. Otherwise, it is discarded. |
|
Dynamic router |
The dynamic router is an additional control channel, which receivers can use to register and identify the messages that they are interested in. The dynamic router stores the receivers' preferences in a rules database. |
|
Recipient list |
Each receiver has its own channel. On the basis of the incoming message, the recipient list identifies the list of receiver endpoints and sends the message to all the receivers on the list. |
|
Splitter |
A splitter breaks a composite message down into several individual messages, which are subsequently processed independently. The splitter publishes each message individually. |
|
Aggregator |
The aggregator is a special message filter. It receives a message stream, identifies the messages which need correlating, correlates them into a single message, and publishes this message on the output channel. |
|
Resequencer |
The resequencer can receive a message stream with messages in the wrong order. It has an internal buffer for storing messages that arrive in the wrong order until the correct order is restored. |
This group of patterns ensures that applications can interact with one another using the messaging system, despite the fact that they describe data in different ways and use different formats. The building blocks are listed in the following table. Only those patterns which are frequently used in practice are described.
|
Building Block Building Block |
Description |
|---|---|
|
Message translator |
The message translator is a special message filter that can convert data from one format to another. It is primarily used to ensure that domain objects and the canonical data model have the same format. A translator is a special type of filter. |
|
Content enricher |
A content enricher is a special kind of transformer, which can add missing information to a message from an external data source. |
|
Claim check |
The claim check stores the message data in persistent storage and only sends a reference to the subsequent components. These components can use the reference to access the stored information. This reduces the volume of data in the messages sent across the system. |