## 4 Problems with the Mediator-Wrapper Architecture  
So far, mentioning the way in which users connect and use these systems has been omitted. Multiple authors have opted for connecting users to the system via specialized applications which are system specific [31; 33; 34]. Such applications connect directly to the highest mediator layer (or the integration layer in case of an alternative architecture).  
Figure 5: An exemplified assignment of schemas to a MW system with a single mediator layer.  
Figure 6: An exemplified assignment of schemas to a MW system with an exporting mediator layer.  
This puts additional responsibilities on the mediators in the higher layers. These mediators not only have to mediate schemas from lower layers, but also manage their GESs, as shown in the example of Figure 5. Opposed to this, the exporting mediators shown in Figure 6 seem like a better solution due to the functional responsibility being shared among multiple mediator components. This also has its issues. RMe1 prohibits the mediator from exporting data in a format that is not internally used by the system itself, meaning that data translation is going to have to be done in a user application. This breaches the system's separation of concerns, leading to client applications having to perform the translations. It seems that this responsibility cannot be shared among components of the mediator type. Therefore, we add a third rule for mediators:  
**RMe3** Mediators should be used to mediate, not to represent.  
This problem is further exacerbated when one takes notice of the user applications usually implemented alongside these systems. Although user applications generally display just one format of data, it is interesting to notice the variety of data formats that have been used as presentational in different systems--from JavaScript object notation (JSON) collections [40; 41] and extensible markup language (XML) documents [42], to tabular data [43; 44]. The way of access can also be varying--a Java database connection (JDBC) API [44], web applications built onto the system [41] and even a web API [40].  
This is also the case with state-of-the-art databases and frameworks designed with specific representations of data sources in mind. Some authors still show a preference for an SQL interface [20; 21; 38; 45], while others prefer a key-value [19; 22; 23], graph [13; 14; 15], semantic web [17; 18], an XML [46], flattened data [47], or a plain-text interface [48]. [PERSON] et al. [11] also showed a system with three types of data representations: an object storage via a representational state transfer application programming interface [49] (REST API), file storage, and NoSQL tablestore service. [PERSON] et al. [50] and [PERSON] et al. [51] also showed that data representation (views) is becoming a key factor in data handling.  
With the increase in data format variety (illustrated by Table 1), it is becoming more apparent that a data source integration system, as a singular data source, will itself have to support data representation in different formats. It is important to note that data, schemas, and queries face this same issue equally.  
A more general point is that the MW architecture in its current state diverges from the idea of a clean system architecture. The clean architecture principles of architectural layering, separation of concerns, managing dependencies, control flow and testability are a solution to achieve a flexible and largely scalable system [52; 53]. Such a system is an expected requirement for gathering and managing large amounts of data from multiple sources.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Reference (Project)** & **Data Representation and Access** \\ \hline
[6] & \\
[4] (TSIMMIS) & specialized desktop application \\
[2] (GARLIC) & \\ \hline
[40] & \\
[41] & JSON (+ web API) \\
[11] & \\
[49] & \\ \hline
[42] & XML \\
[46] & \\ \hline \hline \end{tabular}
\end{table}
Table 1: Overview of existing data management concepts and projects in regards to their data representation.