Patterns: Information Aggregation and Data Integration with DB2 Information Integrator

Chapter 1. Introduction to Patterns for e-business 9

The makeup of these patterns is variable, in that there will be basic patterns

present for each type, but the Composite can easily be extended to meet

additional criteria. For more information on Composite patterns, refer to Patterns

for e-business: A Strategy for Reuse by Jonathan Adams, Srinivas Koushik, Guru

Vasudeva, and George Galambos.

1.3.2 Selecting Application patterns

Once the Business pattern is identified, the next step is to define the high-level

logical components that make up the solution and how these components

interact. This is known as the Application pattern. A Business pattern will usually

have multiple possible Application patterns. An Application pattern may have

logical components that describe a presentation tier for interacting with users, an

application tier, and a back-end application tier.

Application patterns break the application down into the most basic conceptual

components, identifying the goal of the application. In our example, the

application falls into the Self-Service business pattern and the goal is to build a

simple application that allows users to access back-end information. The

Application pattern shown in Figure 1-7 fulfills this requirement.

Figure 1-7 Self -Service::Directly Integrated Single Channel

Presentation

synchronous

Web

Application

synch/

asynch

Back-End

Application 1

Application node

containing new or

modified components

Application node containing

existing components with

no need for modification

or which cannot be changed

Read/Write data

Back-End

Application 2

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

The Application pattern shown consists of a presentation tier that handles the

request/response to the user. The application tier represents the component that

handles access to the back-end applications and data. The multiple application

boxes on the right represent the back-end applications that contain the business

data. The type of communication is specified as synchronous (one request/one

response, then next request/response) or asynchronous (multiple requests and

responses intermixed).

Suppose that the situation is a little more complicated than that. Let us say that

the automobile policies and the homeowner policies are kept in two separate and

dissimilar databases. The user request would actually need data from multiple,

disparate back-end systems. In this case there is a need to break the request

down into multiple requests (decompose the request) to be sent to the two

different back-end databases, then to gather the information sent back from the

requests, and then put this information into the form of a response (recompose).

In this case the Application pattern shown in Figure 1-8 would be more

appropriate.

Figure 1-8 Self-Service::Decomposition

This Application pattern extends the idea of the application tier that accesses the

back-end data by adding decomposition and recomposition capabilities.

Presentation

synchronous

Decomp/

Recomp

synch/

asynch

Application node

containing new

or modified

components

Application node

containing existing

components with no need

for modification or which

cannot be changed

Read/

Write data

Transient data

- Work in progress

- Cached committed data

- Staged data (data replication

flow)

Back-End

Application 1

Back-End

Application 2