Skip to main content

Patterns for e-business > Select Business pattern > Select Application pattern >
c


Application Integration::Federation application pattern::Runtime patterns

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


The Data Integration node is at the core of the Federation runtime pattern. It contains the knowledge and functionality that enables real-time access to and manipulation of data in disparate locations and formats across multiple Data Server/Services nodes. The function of the Data Integration node is invoked by an Application Server/Services node, which may be entirely separate, or integrated with the Data Integration functionality.

A Data Server/Services node is a generic data storage node that provides managed, persistent storage of any type of data and a means to directly access and manipulate that data. The data may be stored in files and accessed through file I/O routines or may be stored in a database with more structured and managed access methods.

The flow is as follows.
1. A requesting application makes a query of data from the "federated" data source, for example, a simple SQL Select request.
2. The Data Integration node processes the request, and utilizing its metadata (which defines the data sources) passes on the requests to the appropriate data sources.
In many cases, the data integration/federation logic within the Data Integration node may be logically separate from the data connector logic. This data connector logic spreads out the overhead of making the query to multiple data sources, allowing the queries to run in parallel against each database. When performance is of major concern, multiple logical data connectors may exist to process queries against a single data source—the idea here being to prevent any single node in the process from becoming a bottleneck if too many requests run against one data source.
3. In all cases, the results that are returned from each individual data source must then be aggregated and normalized by the data integration layer so that these results appear to be from one "virtual" data source.
4. The results are then sent back to the requesting application, which has no idea that multiple data sources were involved.

What's Next
Next, review product mappings.

c