## 6 Discussion  
The MW architecture has numerous advantages when it comes to implementing a data source integration system, especially if the system is expected to connect a larger number of data sources. As was also demonstrated in this paper, when certain rules are followed to keep the components well formed, the maintenance of such systems also becomes easier. In the case of appending new data sources, they are each assigned a wrapper, and the wrappers are connected to selected mediators. In the case of managing schemas, this management is modularized by the system architecture itself. Workloads on hardware can also be balanced, as components can be set up on different machines. Although it was mentioned that some authors did not use the MW architecture in terms of system components, most of them recognized these advantages and modeled their inner system modules to work in a similar fashion. This allowed them to at least use the advantageous modularization of tasks and responsibilities in a data source integration system. The architectural pattern's idea was agreed with up to a point, this point being the representation of data to users and the responsibilities of upper layer mediators. It was found that there is a responsibility of representing data that usually are either delegated to the upper layer of mediators or specialized user application. The former case has made systems less flexible and maintainable, while the latter has greatly limited the types of access and data representations that systems support. To keep the responsibility of data representation inside the system, the idea of a new architectural component was proposed--the mask. As with mediators and wrappers, some basic rules for masks have been set to assure that they are well formed and fit into the MW architecture. The mask takes on the responsibility of representing data and creating an interface for users to connect to. It was also reasoned that appending masks to a MW architecture technically creates a new architectural layer--the mask layer. By using the mask layer, a data source integration system increases its representational versatility and thus, its usefulness. Now a data source integration system can be viewed as a singular source of data but through multiple masked sources. In addition, if masks adhere to a certain representational standard, then the data source integration system becomes open to different kinds of user applications. The mask component was internally detailed as much as possible in an abstract and generic form to prevent any partiality to a specific programming language or paradigm. Reasoning about the mask's hypothetical functional requirements has progressed to a simple functional component structure. This basic model was then enriched by recognizing processes that a mask should support, leading to a more detailed conceptual inner-component design. This process also allowed thinking about a more concrete placement of the mask component in a real-life implementation, which was concluded with the proposal that a mask should be implemented as a software module used by the mask component's application code. The mask's software module requires partial implementation, per mask kind, for it to be used. The dynamic nature of distributed heterogeneous systems is maintained by constructing components that can react to changes at runtime. To accommodate this, components, including the proposed mask, must operate over metadata as well as data. In the concrete case of the mask, schemas are metadata. The existence of a metadata database in the mask was also indicated to accommodate such properties. Because of the addition of a new architectural layer, it was decided to declare this a revision of the MW architecture and name it as the MMW architecture. To show that the MMW architecture has benefits over other MW architectures, a quantitative analysis over requirement shift costs was performed on multiple scenarios. These scenarios were also used to comparatively analyze the 1 LMW and 2 LMW architecture.