96 Patterns: Information Aggregation and Data Integration with DB2 Information Integrator
As indicated by the dotted boxes enclosing the source/target data stores and
their controlling applications in Figure 3-16 on page 95, the Two-way
Synchronization pattern may act directly at the data level or at the application
level. However, from the viewpoint of Data Integration, the interactions are more
likely to be at the data level, while in Process Integration the interactions are
more often at the application level.
Applications in this solution design do not necessarily have to be identical.
Two-way Synchronization runtime pattern
As the Synchronization application patterns are evolving rapidly, typical Runtime
patterns are in the process of being identified and will be documented on the
Patterns Web site (http://www.ibm.com/developerWorks/patterns/) when they
are finalized.
3.5.3 Two-way Synchronization: Multi Step variation pattern
The Application and Runtime patterns for Two-way Synchronization: Multi Step
pattern are described here.
Two-way Synchronization: Multi Step variation application
pattern
Figure 3-17 on page 97 represents the Two-way Synchronization: Multi Step
variation application pattern.
Chapter 3. Data Integration and Information Aggregation patterns 97
Figure 3-17 Two-way Synchronization: Multi Step variation application pattern
Figure 3-17 shows how the Population application pattern can be composed to
implement both directions of the synchronization data flow. An additional function
“Reconcile” appears between the two data flows, and it is here that the complex
process of ensuring that data updates do not conflict, cancel out, or get
otherwise corrupted is handled. If the opportunities for conflict are minimal (when
there are few overlaps between data flowing in either direction), this pattern can
be effectively constructed from existing Population components. However, for
more complex situations, a specialized product solution will be more appropriate.
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.
Process
Metadata
Apply
Gather
changes
Application
Source/
Target
Process
Metadata
Gather
changes
Apply
Application
Source/
Target
Reconcile
Temporary
store
Temporary
store
Temporary
store
Temporary
store
Process
Metadata
Apply
Gather
changes
Application
Source/
Target
Application
Source/
Target
Process
Metadata
Gather
changes
Apply
Application
Source/
Target
Application
Source/
Target
Reconcile
Temporary
store
Temporary
store
Temporary
store
Temporary
store
Temporary
store
Temporary
store
Temporary
store
Temporary
store
Get Patterns: Information Aggregation and Data Integration with DB2 Information Integrator now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
