Application Integration::Population=Multi Step Federated Gather variation::Runtime patterns

Population=Multi Step Federated Gather variation::Runtime pattern
(Click a node to get a detailed explanation.)
Design Last Updated: 10-20-2004



The flow in the figure above is that the Process tier makes a query for data from the "federated" data source such as a simple SQL SELECT request. The Data Integration node processes the request by using the metadata (which defines the data sources) to pass on the requests to the appropriate data sources. Usually, the Process node and the Data Integration node are collocated and tightly integrated.

In many cases, the data integration/federation logic within the Data Integration node is logically separate from the data connector logic. This data connector logic spreads out the overhead of making the query to multiple data sources, thereby 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 eliminate any single node in the process from becoming a bottleneck, if too many requests run against one data source.

In all cases, the results that are returned from each individual data source must then be aggregated and normalized by the Data Integration node so that these results appear to be from one "virtual" data source. The results are then sent back to the Population (Process) node, which has no idea that multiple data sources were involved.

What's Next
Next, review product mappings.