## 5 Extending the Mediator-Wrapper Architecture
### On the Implementation of a Mask
Following the process inference of the data flow diagram of Figure 11, in Figure 12, the schema manager and schema translator (interface) are recognized as components--analogous to the schema loading and schema translation processes, respectively. The schema manager observes the system schema and updates the stored system schema appropriately. The inference of a general querying process in the data flow diagram leads to the recognition of the query manager component. This component manages the underlying translations and query execution sequencing. In general, its purpose is to produce a masked result for a masked query. This is achieved through the processes of query and data result translation, which themselves in turn lead to the recognition of the query translator (interface) and data result translator (interface) components. Regarding the mask's communication abilities with the rest of the system, the mask sends system format queries and results, just like mediators and wrappers. For this reason, the mask can use a standardized communication node (module) used in all other component types. Due to the communication restrictions of the mask (allowing for a single mediator connection), an extension of a basic communication node should also be implemented. This also allows the addition of new message types if such a requirement should arise later. To store all the data inferred for storage in Figure 11, a metadata store should also be introduced to the component. Such a store would be used by all components that require at least some schematic information or technical information. In Figure 12, this store is displayed, but the connections to other components are omitted for the sake of clarity. On the other hand, the mappings (marked as data storages in Figure 11) are not stored in the metadata database. They are presented by the component implementations  
Figure 12: Conceptual component design of the mask component. (marked gray) in Figure 12. For the mask to remain as generic as possible, such mapping rules are explicitly described by the schema, query, and result translator implementations. The aforementioned interfaces are used to keep a level of abstraction toward the other inner components. The implementations are case specific and created by the mask's developers according to their respective interfaces. This allows the development of a mask kind to be done without the need for extensive coding, as only the missing implementation pieces need to be filled in. This, by consequence, not only simplifies the development process, but also decreases the time required to develop a certain kind mask component. It is important to note that the term \"interface\" is used in its broadest form here, not excluding the development of the mask component in a non-object-oriented paradigm language (non OOP). Along with these interfaces being implemented as standard OOP interfaces, they can also be implemented as high-order functions in a functional paradigm or as separate implementations of function prototypes defined in library headers (to be linked before compilation) in a structural-procedural paradigm. This is one of the beneficial results of generic and abstract reasoning about mask components. The inner components that have been elaborated up to this point are part of a mask module, or rather a library. This is best understood from the point of another component marked gray in Figure 12--the mask application. The mask application is the execution entry point of the mask component. In the continuation of previous possible use-case examples, this component could be a web API or a TCP server listening for JDBC. Whichever the exemplified case, it would use the mask module as a library to connect to the integration system. The interfacing of the mask application and the module is achieved through the mask application interface that provides a universal interface for data storage.