## 3 The Mediator-Wrapper Architecture  
The MW architecture was first envisioned as an information system architecture [26], allowing a modular architecture for subtasking when numerous data sources are imposed, in opposition to monolithic architectures. This was specifically intended for information and knowledge management systems for informed decision making. Expanding on the idea of what is achievable using the MW architecture, [PERSON] et al. [6] observed its usage for the exchange of data across heterogeneous information sources. [PERSON] and [PERSON] [3] also observed the mediator-wrapper architecture to uniformly access legacy stores through the GARLIC system [2]. Similarly, the mediator-wrapper architecture was used as a basis for the TSIMMIS project [4]. [PERSON] et al. [27] put the mediator-wrapper architecture firmly into the context of data source integration systems. The MW architecture in the most general sense is an architectural pattern, consisting of mediator and wrapper components, used to query and acquire data from multiple data sources. The wrapper component is directly connected to a data source and acts as a standardized interface to that data source. The wrapper wraps (or encapsulates) the data source for further use throughout the rest of the system, effectively making it the only component in direct contact with the data source. To ensure such functionalities, the wrapper must be able to translate queries, data and metadata coming to and from the data source, as well as the layers above. The mediator component is architecturally situated above the wrappers. The mediator's task is to connect multiple wrappers and integrate their data and metadata. Because data, metadata and queries are logically intertwined, the mediator also must have the ability decompose and allocate queries to its connected wrappers. Certain aspects of the MW architecture can be clarified by following the top-to-bottom flow of data as shown in the conceptual illustration of the MW pattern in Figure 1. The me diator receives a query which is then propagated accordingly to its connected wrappers. Not all wrappers need be included in a query, as all the data required by the query might not be in all the data sources. The queried wrappers then translate the queries according to their data source's schema and querying language. The returned result is then translated back into the system standardized result format and propagated to the mediator and above. This pattern of interaction is the basis for the complete MW architecture. A more global view is shown in Figure 2, illustrating the layering of mediator and wrapper components. The data sources to be integrated are at the lowest layer. Each data source is covered by a single wrapper via a direct connection. As an example, a system where each wrapper operates over a single data source is displayed (Figure 2), although [PERSON] and [PERSON] [28] display a possibility of a wrapper operating over multiple data sources. It can be observed that the \"one wrapper--one data source\" setting gives more agility for appending new data sources to the integration system, as it allocates the responsibility of overseeing data sources to each wrapper separately and thus balances the workload. It is also interesting to comment that this component setting is better suited for systems being built bottom-up [28; 29], where data sources are expected to be appended and the global data overview is expected to change. The first layer of mediators is located directly above the wrapper layer. Figure 2 displays their relationship in a form where each mediator in this layer can be connected to multiple wrappers, and multiple wrappers can be connected to a single mediator. This is in line with the MW architecture displayed in [28]. [PERSON] et al. [6] and [PERSON] et al. [30] displayed an architecture in which each mediator of the first mediator layer is connected to just one wrapper and vice versa, showing that this is also a feasible solution in cases where mediators are only needed for translation.