Patterns: Information Aggregation and Data Integration with DB2 Information Integrator

Chapter 3. Data Integration and Information Aggregation patterns 111

This pattern is defined on http://www.ibm.com/developerWorks/patterns/ as

well as in a number of redbooks, as referenced in “IBM Redbooks” on page 299,

and most recently in Self-service solutions with Process Choreographer,

SG24-6322-00, and will not be described further here.

However, as previously mentioned, applications that combine analysis and

update function are becoming more common. With this in mind, here we explore

use of the Agent application pattern in combination with Federation as described

in “Agent: Federation variation pattern” on page 111. This variation pattern forms

an important component of our overall solution, in addition to the 3.4, “Data

Integration:: Population” on page 72, and 3.6, “Information Aggregation:: User

Information Access” on page 98, patterns described earlier

This section is organized as follows:

򐂰 Business and IT drivers

򐂰 Agent: Federation variation pattern

򐂰 Guidelines for usage and scenario

3.7.1 Business and IT drivers

Business and IT drivers for the Self Service:: Agent pattern are described in the

prior references. However, there are specific IT indicators for the use of the

Agent: Federation variation pattern.

Like the Agent pattern itself, the Agent: Federation variation meets the business

need for an application design that provides a unified customer-centric view that

can be exploited for mass customization of services and for cross-selling

purposes. This business need almost inevitably leads to a requirement to access

and/or integrate disparate data from distributed sources. As the heterogeneity of

these sources increases, it is worth considering the use of the Federation pattern

to simplify this distributed access, rather than arbitrarily increasing the complexity

of the Agent pattern to handle all possible data sources and combinations.

The specific IT drivers for the Agent: Federation variation pattern are therefore:

򐂰 Leveraging existing skills and investment

򐂰 Simplifying back-end integration

򐂰 Reducing coding complexity and maintenance costs

3.7.2 Agent: Federation variation pattern

The Application and Runtime patterns for the Agent: Federation variation pattern

are described here.

112 Patterns: Information Aggregation and Data Integration with DB2 Information Integrator

Agent: Federation variation application pattern

Figure 3-26 represents the Agent: Federation variation application pattern.

Figure 3-26 Agent: Federation variation application pattern

Figure 3-26 shows how the Agent function can invoke the Federation pattern to

gain access to diverse and distributed data sources.

Use of the Federation pattern in support of the Agent tier is indicated when there

exist multiple, diverse data sources that must be accessed from the Agent tier.

Federation provides both read-only and read/write access and also allows

access either directly to the data store or via an application API. The value

provided by Federation here is in hiding the diverse access method and data

structures behind the single access method provided by the Agent pattern. This

can significantly simplify the programming of the Agent tier, as Federation takes

care of the many diverse access methods. Federation may also cache data as

described earlier; this is omitted from the figure for simplicity.

The standard Agent pattern emphasizes the role of an ODS as a supporting data

store for the Agent. However, with the introduction of the Federation pattern, we

LEGEND:

Data sources are represented by disks in three different colors / shades:

Blue / plain: Read/write

Yellow / diagonal hatching: Read-only

Green / vertical hatching: Temporary

Read/write and read-only refer only to the interaction between the overall pattern and that data source

as also indicated in most cases by annotation on the linkages. In general we may assume that the

application associated with a particular data source has read/write access.

A dotted box around an application and source data indicates that the source data may need to be

accessed through the owning application via its API, or may be accessed directly via a database API.

In general, a dotted box around a number of components indicates that we are not specifying which

of those components we are interacting with.

A dashed line, arrow or component indicates an optional component.

Agent

Metadata

Application

Federation

Application

Source

read

read/

write

ODS

read/

write

Source

synch

Presentation

Presentation

synch

mutually exclusive

Temporary

store

Temporary

store

Agent

Metadata

Application

Federation

Application

Source

Application

Source

Application

Source

read

read/

write

ODS

read/

write

Source

synch

Presentation

Presentation

synch

mutually exclusive

Temporary

store

Temporary

store

Temporary

store

Temporary

store