Framework Design for Modular Web-based Application Using Model-CollectionService-Controller-Presenter (MCCP) Pattern

Design pattern become an important thing in assisting the development of web-based application and in handling the problem of dynamically changing of organization structure and problem domain. Model-View-Controller (MVC) is a well-known design pattern in web-based application development due to its nature in the separation of an application into several parts, hence easy to reuse and maintain. However, integration of such design pattern requires several improvements in the design phase of information system development since it handles business process choreography and integration between application. Modification the interaction style of objects in a particular design pattern become a challenging problem. An application framework that employ ModelCollectionService-Controller-Presenter (MCCP) design pattern, which is resulting from modification of MVC design pattern, was proposed. The proposed framework also allows different applications to run simultaneously and provides inter-application data exchange mechanism to improve the data communication process between applications. The MCCP design pattern application framework shows that the application framework requires 51% less memory resources than another similar MVC framework such as CodeIgniter and cope the flexibility problem in data format presentations by providing a Presenter in the designed


Introduction
Several organizations, which have many divisions or units, use several information system or computer application programs. The computer programs and information system were generally used to support their people daily work and organization business process. Many organizations develop custom applications in their information system in supporting their business processes by having their own in-house development team directly working and develop applications on-site. Several 42 p-ISSN: 2540-9433; e-ISSN: 2540-9824 applications or computer programs were running in their own operating environment to meet organization or specific requirements of business processes.
In order to accommodate the changing dynamics of user requirements in a currently running business processes, web-based applications are more appropriate to be implemented than native desktop applications as users are not required to be manually install or update the application manually. In a web-based application, any changes made on the application server will be directly reflected and distributed to all activeusers. As long as application users are using web-application using compatible web browsers there will be no issues in user's computer platform. Application developers will have full control in the distribution of developed application even though webbased application has limitation in programming code optimization, bigger overhead, and less control in utilizing computation resources of user computer than native desktop applications [1].
It is very common that applications need to be able to communicate with each other. There are cases that one application requires data from the output of the other application. The need of data integrations and business process choreography between units in organization urge the flexibility, ease of use, ease of access, and ease of development of information system in the future. The difference between applications data format, storage, and running environment make data integration between applications becomes difficult.
Although web-based applications in an information system are offering several more conveniences over native desktop applications, there are several other problems faced in a software development life cycle mainly in data integration problem between applications, user authentication, user authorization towards functionalities and data access among different applications. People who have several roles in organization business process may have different authorization towards different applications. That kind of users are often had to login and logout between applications in order to complete their tasks that needs to be performed in different applications.
Organization data stored in database are essentially owned and managed by their own respective application. Application has full control in managing their own data stored in a database. Such application is essentially not allowed to directly access nor modify data stored in a database owned by another application. Direct access or direct modification of other application data may cause high level coupling. Shared data access between application is categorized as common coupling or content coupling that is considered as a poor system architecture design [2]. High coupling level such as common and content coupling would lead to a decrease in terms of software quality. Therefore, a web-application framework design, which proposed in this research, had to accommodate data communication interface or Application Programming Interface (API) between applications that allow applications to exchange data among each other.
Another problem resolved in this research is related with user authentication and access control. When several users own several roles across applications, they may perform certain functionalities in several applications associated with their roles. Every role has their own respective functionalities among applications. Therefore, the designed application framework should allow users completing their task and perform several application functionalities in different applications based on associated roles without them having to re-authenticate while using different applications. p-ISSN: 2540-9433; e-ISSN: 2540-9824 One of popular web-application design pattern is Model-View-Controller (MVC). MVC become very popular since several web application development frameworks were built on this pattern [3A]. In MVC design pattern, an application is divided into three parts, i.e. application logic as Controller, user interface as View, and application domain as Model. In MVC, reuse of programming code led to reduction in application code complexity, increasing code flexibility, and reduce coupling in application code components [4A]. However, MVC design pattern does not solve problem to be solved by programming code. MVC does help to write application programming code that is flexible, decoupled, easy to understand, and easy to reuse in another part of code [4A].
This research proposes an enhanced web application development framework based on MVC design pattern that allow application developers to develop multiple web-based applications in a single application framework setup in order to simplify the development process of applications and process of integrating the applications. The application framework also provides data communication between applications that allow application to access other application data. Several performance measurements were conducted to the framework in order to describe its performance characteristics compared to another similar web application framework.

Related Work
There are many choices of use framework in web development. Among of them, there is Laravel which is recently being very popular web application framework among web developers, Zend Framework which is devoted to enterprise scale web applications, Struts, JSF, Ruby on Rails, Grails, CakePHP, Django, Lift Framework, Catalyst, and many more. Every framework is offering their own advantages and disadvantages in particular aspects. Several issues faced by web application frameworks were memory management issues, complex design pattern, execution performance, scalability, maintainability, reusability, suitability, fitness for a particular purpose, and application modularity problem. Thus, leading software engineers and researchers to creatively propose solutions to resolve the issues.
Dragos-Paul Pop [5A] proposed a solid framework that is claimed to be able to reduce web application development times drastically, thus allowing web application developers to focus on application specific tasks rather than wasting more time in trying to implement or extend well-known patterns and practices. However, the performance of rendering engine and support in several NoSQL systems were require improvements.
Several existing frameworks have complex design patterns whereas the complexity of framework and application design were not always comparable to its performance. Some files were included during script execution. To overcome this problem, Umi Sa'adah [6] uses a simple design pattern, namely Singleton and namespace or package in Java. This research yields a lightweight PHP framework, with Singleton design pattern, namespace, AJAX, and multiple databases.
In another research, Hossein Shams [7A] introduces MVCC (Model-View-Controller-Context) as an architectural pattern solution for software frameworks to overcome problems that were faced by application programmers in the application layer. The architectural pattern can be implemented in various frameworks thus yield 44 p-ISSN: 2540-9433; e-ISSN: 2540-9824 an easy and rapid application development, reusable code, and development flexibility for the developers.
Application development best practices are activities, technical or important issues, which are identified by users in a specific context, that render excellent services and expected to achieve similar results in similar situations. Every framework has its own best practices whose aim is to facilitate the development of web applications. However, there are no current comparative analysis that identifies best practices in web application frameworks. María del Pilar Salas-Zárate [8A] identifies a set of best practices for web frameworks. Afterwards, these best practices were analyzed and discussed in terms of developing Lift-based web applications. The identification of these best practices would allow developers to construct more interactive and efficient Lift-based web applications, integrating features found in Web 2.0 technologies with less effort thus exploiting framework's benefits.

Model-View-Controller (MVC)
Web-based Model-View-Controller (MVC) is a well-known design pattern used to develop a web based application that separates application into three parts based on business logic (Model), rendering output (View), and glue between Model and View (Controller). Reusing a Model by several Views is one of major advantages of MVC design pattern. Therefore, it is possible that an equal data to have multiple different presentations. MVC design pattern encourages developers to partition their application code into modular Model, View, and Controller. Therefore, application codes are relatively easy to reuse, maintain, and developed further. View represents the functionality of presentation layer in an MVC architecture. It is basically containing user interface (UI) components were data elements were taken into a particular presentation. Model is responsible in managing all business logic and data structure that is required by business organization. It also handles all data requests from Controller through Views. A Controller, which maps application Model and View, describes the application logic process. Web-based application, which developed based on specific design pattern like MVC offers several advantages, such as application More or less, MVC design pattern is a direct translation to Boundary-Control-Entity objects in object-oriented analysis and design. In MVC design pattern, attributes and behaviors of entities or objects were translated into Models. Entities or objects which handled in a particular operation might be a single object or a collection of objects. Behaviors related to a single object and a collection of object might be different and may cause process ambiguity. Several behaviors might be applicable for a single object but not for a collection of object and vice versa. Therefore, this pattern could be improved by separating models that process singular object and a collection of object.

Model-CollectionService-Controller-Presenter (MCCP)
According to sequence diagram of MVC design pattern as depicted in Figure 1, a Model is responsible to communicate with Database Management System (DBMS) server and fetches data result from database that is required by business processes logic or requested by users. The implementation of MVC design pattern in a web application development still faces a problem related to the Model functionality. Analysis phase in software development yields class diagrams from the problem domain analysis which will be translated into Model objects. Single or set of database result object, which implemented in same object of Model, may difficult to maintain when there is a change business process domain model. If a single object and object collections were modelled in the same Model class, then attributes in a class will become conceptually ambiguous between a single Model object and its collection. Another problem related to the Controller-View in MVC design pattern is the implementation of a View presentation codes and Controller codes into a single instance Controller object. Instead of only organizing an application logic flows, a Controller also responsible to format the data obtained from Model into a particular document format. The consequences of this implementation, if a similar data structure from Model p-ISSN: 2540-9433; e-ISSN: 2540-9824 requires different presentation formats, a change in a Controller class is necessary to support the change.
A Model-CollectionService-Controller-Presenter (MCCP) design pattern allows web application developers to overcome these two main problems faced in MVC design pattern. The basic communication in MCCP design pattern is shown in Fig. 2. Data structures produced from class analysis will be implemented as Models, whereas CollectionServices implements Model's behaviors in database. Presenter object on MCCP design pattern is responsible in data presentation to clients, thus Controller objects were focused to handle the application and data logic flows of a client's request.

Methodology
The methodology used to develop the designed framework is following a standard software development life cycle (SDLC). It is including requirement analysis to obtain specific requirements related with common web-based application functionalities for a single HTTP request and the common pattern in providing services to users. The framework and its components as the solution were designed based on the analyzed requirements using object-oriented approach. The designed framework should be able to run several web applications as modules and allow them to communicate between each other to exchange data or information. In the implementation phase, the designed framework was implemented using PHP programming language. Several applications were also developed using the same programming language that run on top of the designed framework based on use case scenarios that were specified in previous phase. The implementation of framework and applications that were developed were tested against the specified functionalities and scenarios. Several performance measurements in terms of memory usage and processing speed were conducted and compared to another similar web application framework to depicts its characteristics.

Requirement Analysis
Analysis phase in software engineering yields software analysis models, e.g. software requirements specification, and logical analysis model in form of analysis classes and objects along with the relationship between classes or objects. Analysis models are produced by identifying objects in the problem domain along with their attributes, behaviors, as well as relationships among those.
Like most web-based application framework that uses the MVC design pattern, the designed web application framework should be able to identify the Controller to use, method of Controller to execute, and if any, given method parameters from the HTTP requests. In addition, the framework should be able to identify which web application to run from the requested URL as it designed to support multiple application to run over it. However, HTTP is a generic and stateless protocol [11A] that independently process HTTPS requests without any knowledge of previously executed request. Some web applications may track and retain user's state information from page to page by the use of HTTP cookies or server-side sessions. When multiple applications run for a single user session, it is possible that applications could see state information of user that belongs to another application for the same user session ID. By default, if an application knows the session ID of user, they will know session data associated it. Therefore, the p-ISSN: 2540-9433; e-ISSN: 2540-9824 framework should provide a mechanism to manage session data for a particular user and only allow application to create or modify their own session data.
In MCCP design pattern, identified classes and relationships between classes of objects in problem domain were modelled into Model classes. However, object behavior and data operations such as Create, Read, Update, and Delete (CRUD) were modelled into CollectionService classes. Therefore, there are no specific functionality requirements for base Model class except for required getter and setter methods of identified Model attributes. For an instance, there is a class abstraction for car object namely Car, any attributes related to car object and its relationship with other class were abstracted into a Model class of Car. Database CRUD operations associated with Car object or collection of Car objects were abstracted into class of CollectionService, say CarCollectionService class. However, one CollectionService class does not always related with one Model class. Depending on the circumstances, one CollectionService object may be associated with one or more Model class. As of CollectionService classes are highly related with database operations of Model, the proposed application framework should provide base class to provide basic database operations and certain functionalities. Therefore, application's CollectionService classes could simply inherit CollectionService class of framework to obtain certain database operation and functionalities.
In terms of data integration, every application might have different database settings or configurations as they have full authority over data in respective database of application even in determining the type of Database Management System (DBMS) used for their respective data operations and functionalities. If there is an application requires data from another application database, then it is necessary for the application, which own the required data, to provide a particular way or mechanism to verify the requests and provide the requested data. Based on the previously stated background analysis, the proposed framework provided in this research should be able to provide a uniform data functionality and allowing web-based applications to be designed and developed using a particular design pattern. In addition, the proposed framework should be able to provide a mechanism for applications to communicate between each other, manages user sessions, and manages inter-application sessions.

Framework Design
The framework was designed to support MCCP design pattern as previously depicted in Fig. 2. It separates each application functionality into Model, CollectionService, Controller, and Presenter parts as necessary. An architectural design model of the designed web application framework that is able to run multiple application is shown in Fig. 3. An application dispatcher behaves as an execution starting point of an application and responsible in identifying which application to run, controller to instantiate, method to execute, and parameters to be given from an HTTP request. The proposed framework also provides a database interface for common RDBMS used in web-based application. A static view between web application components based on MCCP design pattern, the application framework, and relationships between them were modelled into class diagram as shown in Fig. 4. In the designed framework, application output or visual functionalities were handled by an instance of Presenter object inside a Controller. Every application has their own unique application ID so that framework's application dispatcher is able to identify which application to run based on the application ID received request URL. The application ID should be composed of URLcompatible characters and it shouldn't be too long for the sake of simplicity. Request URL format, which application dispatcher could parse for the designed framework, is shown in Fig. 5.
An application dispatcher main responsibility is to parse the received request URL and identify application to dispatch in terms of application components and data given that is separated by a forward slash from the request URL given. The mandatory components from the request URL is the application ID as the dispatcher requires it to determine which application to run. Basically, controller name and controller method to instantiate and execute are also compulsory. However, if the default name of p-ISSN: 2540-9433; e-ISSN: 2540-9824 application controller and method were already preconfigured, then if there are no controller name and/or method name were defined in the requested URL, the dispatcher will try to instantiate application's default controller, which has default controller name, and call its default method without giving any parameters.
In order to distinguish regular Controller and BridgeController call, application dispatcher detects in place of the controller name provided in the requested URL whether it is an "api" keyword. If so, then the application dispatcher will assume that the arguments right after the "api" keyword will be the bridge controller to instantiate. Hence, application controller cannot have name "api" as this name is used to distinguish between regular controller request and bridge controller request.

Fig. 5.
Request URL format for a web browser client (top) and another application controller as client (bottom) that application dispatcher parse in determining application to run, controller to instantiate, controller method to call, and parameters to be given. Protocol scheme a used to identify the scheme used in the request; b is server host name; c is the application identifier; d is the controller name to instantiate; e is the method of controller to call; f, g, and so on are the optional method parameters.
Database Interface. The designed framework allows application to have their own DBMS type to use. However, in order to unify the way application to communicate with DBMS, CollectionService base class provide an interface to various DBMS Connector as depicted in Fig. 6. Concrete DBMS Connector class should realize the DBConnector interface and implements all generic database functionalities as defined in the interface. Hence, CollectionServices should not really concerned in writing a specific database code for a particular DBMS type. It is possible to provide further DBMS functionalities, i.e. transaction, by extending the DBConnector interface with another interface. However, not every DBMS support all functionalities that another DBMS have. Fig. 6. shows an application would be able application to perform database communications with three different DBMS types using a single CollectionService class without having to worry which DBMS type it connects to. The application database connectivity design as depicted in Fig. 6 shows the flexibility of an application to switch to another Relational DBMS type. However, there are drawbacks faced by the above design. If an application intends to use a nonrelational or NoSQL database, i.e. NoSQL or MongoDB, then the database connectivity design would not work as expected. because there is no SQL query used in a NoSQL database engine. To resolve this issue, an application should implement their own database connectivity library to communicate with a NoSQL database.
Inter-application Communication. In order to communicate between applications, the designed framework provide a specific Controller to extend namely BridgeController that allow other application Controller to communicate with and exchange data. The BridgeController is designed to be separated with Controller as they both have different purpose even though they have similar behavior in the pattern. The separation is also intended to avoid confusion between Controller and BridgeController from the perspective of clients who perform the requests. The Controller is intended to serve HTTP requests from user's web browser while BridgeController is specifically intended to serve HTTP requests from Controller of another application. Data communication between applications diagram is shown in Fig. 7. Application BridgeController and Controller serve different type of client. They both implement different session handling method. Framework architecture diagram in Fig. 7 shows that the dispatched HTTP requests were served by a dispatched Controller. The Controller logically identify the required data sources to complete the request whether the data could be obtained from the database owned by the application or from the other application database. Application CollectionService responsible to provide data operations request from Controller or BridgeController. If a dispatched user request requires data from multiple data sources, then a Controller should be able to perform a data operation request to another application BridgeController. Communication between application Controller and another application BridgeController could be simply implemented using an HTTP Representational State Transfer (REST) architecture and Extensible Markup Language (XML) or JavaScript Object Notation (JSON) data format.
The sequence diagram for an application activity in processing a single HTTP request from a single user that requires data from multiple applications or data sources is shown in Fig. 8. As seen in the diagram, when an application Controller receives an HTTP request from a web browser client, it has two options in obtaining data. First, the Controller may obtain the required data from its own managed database using application's CollectionService. Second, the Controller could perform an HTTP request to another application that is served by another application's BridgeController. When an application CollectionService receives a data operation requests, it does not responsible to perform an execution authorization of a Controller. The authorization process of an HTTP request execution should be performed by application Controller or BridgeController before the actual CollectionService method is executed. Therefore, it is possible to reuse database-related methods in an application CollectionService by more than one Controller or BridgeController. Communications between an application Controller and another application BridgeController are treated in a different way as an application Controller is not a web browser that simply accept cookies from application server to retain its states between requests. Furthermore, because inter-application communication was designed using standard HTTP protocol or REST, it is possible another type of clients, e.g. Unix-based console commands, native desktop applications, and mobile applications, are accessing the API through BridgeController. Therefore, it is important that an API provided by application BridgeController to have a particular mechanism in communicating with varying clients. The framework BridgeController also designed to communicate using a standard REST and returns a platform-independent plain-text document such as XML and JSON. Session Handling. The framework is designed to handle requests to multiple applications simultaneously. If the session handling mechanism implemented in the usual single application way, therefore applications able to read or modify each other session data. Reading and modifying another application session data are certainly undesirable system behaviors. Therefore, the framework should provide a session handling mechanism that only allow application to read and modify their own session data. The framework proposed a centralized session data storage to put every applications session data. The data may be stored in form of a DBMS storage or stored as files in a framework-accessible shared folder. Session data and their storage handling were managed by a SessionManager helper object. The SessionManager helper object will be accessible by application Controllers. In order to protect the session data stored from other applications, the SessionManager will mark any data stored on the session storage with application's ID of application that own the data. However, in order to protect the session data from application ID spoofing, therefore the SessionManager should obtain the application's ID from Application Dispatcher. The sequence on how the designed framework handles user session is shown in Fig. 10. The sequence diagram also shows involved objects of framework when they handle web page requests from web browser.
The design of session handling in inter-application (API) communication requires several steps. First, the requested application BridgeController should know which application is currently accessing the service. Each client application should be registered in a particular service API client database. Client applications should send their application ID in every request so that service API could identify its client. If a client identity of an API cannot be identified, then the framework returns an error message and the process should stop. In an API request, a client of an application API send a request URL along with its application key, application id, access token given, and data to send. If the client is unauthorized to access the service, then the framework will return authorization error messages, otherwise its access token will be checked against its validity. An access token is considered to be valid if its fingerprint is valid and its access token is within a valid timespan. A fingerprint is a hash value that is computed from client's hostname or IP address and client's application id. If client's access token given is invalid, i.e. not exists or expired, then as long as its computed fingerprint is still correct, then a new access token will be generated and returned to the requesting client. If both client's access token and its computed fingerprint is correct, then the application will continue to proceed client's requests. Authorization check sequence in an application BridgeController's will be processed in framework's BridgeController base class, thus application BridgeController just need to extends the class. Detailed sequence of involved objects inside the designed framework along with its responsibilities of an inter-application communication between multiple applications are shown in the sequence diagram in Fig. 9.

Implementation and Testing
The proposed framework designs were implemented in a virtualization environment of Linux Centos 7 operating system. A web-based environment was setup to run several web-based applications using an Apache web server with a PHP library as a module. Two RDBMS, i.e. PostgreSQL and MariaDB as a replacement for MySQL, were also p-ISSN: 2540-9433; e-ISSN: 2540-9824 setup and configured to represent a multi database server environment. The database server was setup in the same operating system environment as the web server, therefore configured data connectivity between web server and database server will be localhost.
The designed application framework, application dispatcher, and the application itself were implemented using a PHP programming language. Every request received by web server is converted into a particular URL format which directed to the application dispatcher to parse using Apache web server rewrite module. This way, the application dispatcher script will be hidden to the clients, thus creating more secure application framework.
In the following file and directory structure, the document root that is accessible to the clients is inside the /var/www/html directory. The framework base classes such as Controller, CollectionService, Presenter, and database connector classes were located in /var/www/framework directory. Therefore, it only accessible through application classes and codes. Application that run over the framework were located in the /var/www/html/apps directory and all of their application code were placed under their own application id and the code respective class directory, i.e. model classes in /model directory, controllers in /controller directory, collection services in /collectionservice directory, bridge controllers in /bridgecontroller directory, and application's UI files, which will be read by framework's Presenter class, located in /view directory.
Directory structure of the designed application framework that hosts two applications whose application ID appA and appB.   . 11. Implementation and test environment setup By using framework and application setup structure as depicted in Fig. 10, in order to depicts the application framework characteristics and evaluates its functionalities as previously designed, several test scenarios used in this research are: 1. Application A receive a request to display a list of students and put another student data that retrieved or written from/into a MariaDB database server. This scenario evaluates the Controller and CollectionService components of Application A functionalities in providing services to user request. 2. Application B receive a request to display a list of books and put another student data that retrieved or written from/into a PostgreSQL database. This scenario also evaluates the Controller and CollectionService components of Application B functionalities in providing services/data to user request from a different data sources. 3. Application B receive a request to display a list of students that retrieved from MariaDB database that is provided by Application A. This scenario evaluates both Controller of Application B and BridgeController of Application A communication which depicts the capability of one application to be able to interact with another application to obtain data/information that is owned or provided by another application or platform. Test scenario number 1 and 2 from the above test scenarios are depicting the abilities of the designed framework to simultaneously run several applications and also showing that applications are able to perform database operations regardless the type of database used. Test scenario number 3 shows the designed framework abilities in providing data communication mechanism between different applications. $encodedData = $this->callApi('appA','home/index/getStudents'); $listOfStudents = $this->presenter->jsonDecode($encodedData); $this->presenter->show('studentIndex.php', $listOfStudents); } Test Result. Based on the test conducted to the scenario number 1 and 2, it is known that the proposed framework was able to run multiple applications simultaneously in a single application framework setup. The dispatcher for the application framework is able to identify application to run from a request URL given from users. Both applications are able to obtain and return the requested data in a particular format from two different DBMS type using MCCP design pattern.
On the test scenario number 3, a request to application B is trying to obtain the same data as test scenario number 1. However, in order to obtain the requested data from application A, application B communicates with application A through an API call. Based on the test, a client request to application B that requires data from application A can be successfully completed.
In order to measure the application framework performance characteristics, several runtime execution tests were done based on the test scenario number 1 and 3. During runtime execution tests, the execution time of a request and its memory usage were p-ISSN: 2540-9433; e-ISSN: 2540-9824 measured. The measurements were conducted for read-write requests of a single application and read-write requests that requires inter-application communication. The application framework execution time measurement results are shown in Table 1. The measurement tests were performed using Apache JMeter as application's client.
The proposed framework was deployed in a Linux Centos 7 as an Oracle VirtualBox guest operating system in Windows 10 Professional host. The guest operating system is configured to run with 1 core of CPU, with 1024 MB of memory. The host machine is running on a physical Intel Core i7-4790 CPU with 1TB of HDD, 8 GB of DDR3 RAM, and virtualization settings enabled in BIOS. Both application framework and database servers are installed and running inside guest operating system. Application framework software testing environment used during testing are Apache Web Server 2.2, PHP 5.6 library, MariaDB 5.5.50, and PostgreSQL 9.6.1.  external application data. However, there are no significant execution time differences between read and write data operations for both scenarios. The memory usage between test scenario number 1 and 3 of the requested application is shown in Table 2 and Fig.  12. It shows that the memory usage in a single MCCP application request in a read or write data operation, requires around 1.1 MB of memory. A single MCCP application request that requires external application data uses memory for about 900 kB. This research also conducts execution time and memory usage comparison between the proposed framework and the popular CodeIgniter framework. The time execution and the memory usage comparison between the proposed framework and CodeIgniter framework is shown in Table 3. Based on the test results shown in Table  3, both the proposed framework and CodeIgniter framework takes around 43ms in average to perform read or write data operation in a single application request. However, there are no significant execution time differences between the proposed MCCP application framework and CodeIgniter framework. Based on the application memory usage comparison between the proposed MCCP application framework and CodeIgniter as shown in Table 1, there are significant memory usage differences for a single read and write data operation request. The proposed framework uses 1.1 MB of memory while the CodeIgniter framework requires more than 2000 kB of memory in both read and write data operation scenarios for a single request. The software version of CodeIgniter framework used in the comparison test is v3.1.3.

Result and Discussion
In this paper, we have demonstrated the implementation of a new approach web-based design pattern MCCP. The proposed design pattern is able to communication between application and more flexible due to the change of the business process requirements. Such representations are advantageous for many reasons. For example, the proposed design pattern in this research is designed based on real world organization problems in a highly changing requirement environment and developed on the basis of the needs of data integration between different applications within the organization. The test results in this MCCP design pattern application framework shows that the application framework use less resources than another similar MVC framework such as CodeIgniter in terms of memory usage. Furthermore, MCCP design pattern also cope the flexibility problem in data format presentations by providing a Presenter in the designed framework. Based on the test conducted, the designed framework is capable to run multiple applications simultaneously in a single framework setup.
In overall, MCCP-based modular application framework is successfully implemented and tested with some drawbacks. First, this design pattern requires more performance, scalability, and several other non-functional evaluations before being used in a large-scale production environment in order to know the behavior of the application framework in a large-scale environment. Second, despite the interrelation is assumed in same organization, it has not implements an authentication mechanism between application. Third, the possibilities in scaling the application server physical setup yields session handling and application handling problems. Fourth, when several applications run by a single application framework and problems occurred in the application framework itself instead of the application that run on top of it, then every application that is currently running will be unstable.
Based on the measurement test results, a single application request that requires external application data requires less memory. This is due to an application Controller that requires data from external applications, it performs an external API call to obtain the requested data instead of instantiating a CollectionService. However, despite of using less memory, the external applications that provide the necessary data from the API call in the second scenario also uses memory as in the first scenario. Therefore, if the memory usage of both applications that communicate were summed, then they both requires more memory than in a single application usage scenario. Security issue in inter-application communication should be taken into concern. As the proposed communication mechanism offer several possibilities to access an application API from different type of application as its clients.
Future enhancements can be performed by adding a particular User Access Control (UAC) mechanism based on defined application user roles such as Role-Based Access Control (RBAC) thus improving security in the mechanism of data access. Another enhancement to the designed framework is the ability in managing running applications during runtime as multiple applications will run on top of it. Instability of application will affect the overall stability of other applications. Therefore, a dedicated Operational and Maintenance (OAM) systems that allow system administrator to monitor the runtime condition and manage every application that run over the framework would be highly necessary.

Conclusion
This paper presents design of a web application framework that allow multiple application run on top of it. The framework implements Model-CollectionService-Controller-Presenter (MCCP) design pattern. It enables application to provide web services or API and exchanges data between applications through API call mechanism which handled by BridgeControllers of application. Application request between from a web browser and an application Controller as clients were handled differently. There are no noticeable differences in terms of execution time between the proposed framework design and CodeIgniter application framework. The proposed application framework had a similar performance in terms of the execution time required to process a single request. However, the proposed application framework requires less memory to process a single data operation request from a client.
Inter-application communication between an application Controller and another application BridgeController has 30ms execution time overhead on a single application framework local setup. Despite of less memory usage of the requested application in this inter-application communication scenario, there is an additional memory requirement for the other requested application in processing other application the request. In other words, when an application calls another applications API, it is basically the same as running two or more applications at the same time, thus requires more computing resources. However, data exchanges between applications is made possible with the proposed mechanism in the designed framework.
In larger context, there are possibilities in implementing the proposed framework design into mobile platform so that a single mobile application could provide different and modular services as required by its users. However, the implementation of the designed framework in mobile platform could be analyzed and researched further to obtain several findings and depicting its characteristics. System scaling in terms of data capacity and performance-related problems could be an interest of further research, analysis, and improvement.