## 5 Extending the Mediator-Wrapper Architecture
### Hypothetical Implementational Example  
As referenced before, [PERSON] et al. [40] presented SOS (Save Our Systems) as a system for uniform operations over non-relational stores. The representational format of this system was a web API with URI-like resource identification, serving result data as JSON objects. They also defined generic wrappers (in their case as modules), which are implemented per data store kind. The wrappers in their case also concern themselves with representing the underlying systems. Although not a data source integration system itself, the SOS system could keep its raison d'etre and be conveniently extendable to the likes of a data source integration system if it were reimagined following the MMW architecture.  
\begin{table}
\begin{tabular}{l l l l} \hline \hline
**Sc.** & **1 LMW** & **2 LMW** & **MMW** \\ \hline
1 & \(C_{Me}^{impl}+C_{Me}^{depl}+N\times C_{Comm}^{Set}\) & \(C_{Me}^{impl}+C_{Me}^{depl}+C_{Comm}^{set}\) & \(C_{Ma}^{impl}+C_{Ma}^{depl}+C_{Comm}^{set}\) \\ \hline
2 & \(C_{Me}^{depl}+N\times C_{Comm}^{set}\) & \(C_{Me}^{dpl}+C_{Comm}^{set}\) & \(C_{Me}^{depl}+C_{Comm}^{set}\) \\ \hline
3 & \(C_{Me}^{dpl}+N\times C_{Comm}^{set}\) & \(2\times C_{Me}^{depl}+(N+1)\times C_{Comm}^{set}\) & \(C_{Me}^{depl}+C_{Ma}^{depl}+(N+1)\times C_{Comm}^{set}\) \\ \hline
4 & \(C_{W}^{depl}+C_{Comm}^{set}\) & \(C_{W}^{depl}+C_{Comm}^{set}\) & \(C_{W}^{depl}+C_{Comm}^{set}\) \\ \hline \hline \end{tabular}
\end{table}
Table 2: Shift costs for all scenarios and architectures.  
Additionally, using different mask kinds, the representational form of these data storages could be expanded on.  
A hypothetical example of such a system use case is presented in Figure 17, where the revised SOS system provides uniform access over a single HBase, Redis, and MongoDB database. At the top of the component hierarchy, each database must be converted to the SOS interface for application access, as presented by [40]. This interface can be presented via mask components of the SOS mask kind.  
Starting from the bottom of Figure 17 hierarchy, observing only solidly outlined elements, a wrapper is connected to each data source. Since it is not advisable to connect masks directly to wrappers and following RMa2 stating that masks should only connect to mediators--a single mediator is connected to each wrapper. A SOS mask is connected to each of these mediators, thus encompassing the original SOS system's functionalities. These settings do not restrict the system to just using a SOS mask. Additional mask kinds can be connected to these singular mediators to offer an alternative presentational form and keep in line with the SOS use case of uniform system access. Such an example is given in Figure 17 with a JDBC mask representing the Redis database.  
The singular mediators are of a translational nature, but also enable the system hierarchy to be expanded. If, by example of the mediator shown with a dashed outline in Figure 17, a mediator connecting to each of the singular mediators is provided, then that part of the system becomes a data source integration system. Consequently, the integrating mediator allows connections coming from different masks.  
Not only does the MMW architecture allow the emulation of a system, such as the SOS, but it also expands on it. If it were not for the mask components taking on the responsibility of system representation, all mediators would have to be adapted (redesigned and reimplemented) to the SOS interface standard to work as both the SOS system and a data source integration system, which itself does not explicitly require adherence to the SOS interface standard. In effect, the use of the MMW architecture enables standardized  
Figure 17: The SOS system implemented in the MMW architecture.  
implementation of mask kinds dedicated to data representations from Table 1 (illustrated in Figure 17 as masks \(X\) and \(Y\)).