1. Introduction

Socio-Technical Systems are collaborative interacting systems where one or more social systems and a number of technical system work together to accomplish a goal meaningful for a community or user group. The technical part of the system is concerned with the processes, tasks, and technology needed to transform some inputs to corresponding outputs. The social part of the system is described by key attributes of people, such as people’s skills, values, responsibilities, and their roles in the system [1]. In advanced collaborative e-learning, our application domain, the relationships among the administration of a university, the students, and lecturers are mediated by technical systems, as these people all cross-interact within individual and federated e-Learning systems. A large part of these interactions are mediated by the institutional e-learning platform(s), that act as a medium-to-large scale socio-technical system, and their large scale scientific infrastructure that provides high quality and cost-effective services to academic and research organizations [2], providing cloud services such as Infrastructure as a Service (IAAS), Software as a Service (SAAS) and Platform as a Service (PAAS), that are new trends for NRENs [3]. Eduroam [4], EduGATE [5], eduGAIN [6] and Shibboleth [7] are widely adopted infrastructural building blocks used to provide a wide range of national services by NRENs and international services by so called regional NRENs. Specifically, Eduroam is a global wireless network that allows academics staff and researchers to access the services of their own institution with their roaming profile [4] from any participating institution. EduGATE is an identity manager used in GEANT to´ provide participating users with access to the different applications with a Single-Sign-On technique, effectively providing a connection between participating applications of the different NRENs that are members of GEANT [´ 5]. EduGAIN is also a national level identity management services provider, and it is used in the Irish Research and Education Network (HEAnet) [6]. Shibboleth supports collaboration and data integration between different learning management systems used in Internet2 and many NRENs [8]. Other platforms are directly or indirectly also service providers for collaboration, and provide widely adopted services for access and interoperability. For example, Office 365 provides a solution that integrates different applications, it uses Active Directory Federation Services (ADFS) and DirSync to provide a Single Sign-On password integration for a domain [9]. Similarly, the Security Assertion Markup Language (SAML) and Open Authentication (OAuth) [10] focus on providing and managing user Identities for SSO, so that the NREN users use the same Identity for all member applications. A secure SSO provides secured and uninterrupted services by keeping one authentication credential for each user so that, once authenticated, users do not need to provide their credentials again when accessing different web services that share the same SSO. Kamal et al. claim that Shibboleth is the most suitable SSO in the higher education domain. However, no global log-out, the infancy of the technology, implementation complexity, high reliability on assumptions that cause security risks are the main challenges of the Shibboleth technology [10]. The existence of duplicated data and duplicated profiles in the same domain is a serious problem for access, cost, and management. How to integrate the duplicated data requires further investigation. In this context, NREN infrastructures provide an opportunity to provide for uniform security, reliability, and reduction of the complexity for data integration across the participating e-learning system within the served NREN domain.
In this paper, that significantly extends work originally presented in ICALT 2020 [11], we focus on data integration in interinstitutional cross-organizational collaborations as well as in intrainstitutional multi-campus collaboration, two challenging situations with which we have direct experience.

1.1 Data Integration of E-Learning Systems In Large Scale Cross-Organizational Collaborations

This is a challenge because they use different e-learning platforms that do not interoperate in a native way. For instance, Figure 1 shows that Moodle, eDX and the national Higher Education Management Information System (HEMIS) are implemented in a single domain at the Kabul University, Herat University and Balkh University in Afghanistan. The shortcomings of the current situation are due among other causes to the lack of support of Single Sign-On in the three running applications. Accordingly, the applications implemented in this national collaboration domain [12] do not currently exchange data and they reside on three different platforms. EdX is implemented at six universities across the Afghanistan Research and Education Network (AfgREN) for national collaboration and accessibility [13]. Moodle is the second popular e-Learning platform. It is widely implemented in universities of Afghanistan [14], and in fact lecturers and students used Moodle en masse during the recent

universities lockdowns. The Higher Education Management Information System (HEMIS) is a traditional students management system. It was introduced by the National Higher Education Strategic Plan (NHESP) of the Ministry of Higher Education of Afghanistan to support in a standardized way the decision-making process and control management tasks in the adopting organizations, which impact the organization’s functions, performance, and productivity in all its aspects [15].
In our collaborative e-learning context, for example, the enrolment of students to universities is managed through this system. While it is mandatory for all universities to use HEMIS, also HEMIS does not support Single Sign On. As a consequence, each student has three profiles in three different e-Learning platforms, as shown in Figure 1. This distribution and partial data replication are challenging for the administration and maintenance of all these systems and their collaboration.

Figure 1: Student profiles in e-Learning systems of a single organization: The case of AfgREN 1.2 Data Integration of E-Learning Systems In IntraInstitutional Cross-Campuses S. Say et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 6, No. 3, 213-230 (2021)

This second challenge is illustrated with an application in Ireland. Through the Technological Universities Act the Irish Department of Further and Higher Education, Research, Innovation (the Irish Ministry) established in 2018 a process whereby consortia of local Institutes of Technology may submit an application for Technological University designation. De facto, this mechanism creates regional Technological Universities of larger size and diversity than the previous ITs. For example, in January 2019 the Technological University Dublin (TU Dublin) was formed by the amalgamation of three institutes of technology in the Dublin area (Dublin Institute of Technology, Institute of Technology Blanchardstown, and Institute of Technology Tallaght), yielding the second-largest university in Ireland based on the combined student population of 28,500. Other five TUs consortia have meanwhile applied, among which in 2021 the AIT-LIT consortium . This consortium is now establishing a (technical) University for the Midlands and the Mid-West by combining the Athlone Institute of Technology (AIT) in Athlone (in the Midlands) and the Limerick Institute of Technology (LIT) in Limerick (in the Mid-West). Accordingly, the new Technological University will be located in five different campuses across the Midlands and Mid-West of Ireland. In addition to the organizational and structural combination, many technical and infrastructural changes are also required: the data integration, resources sharing, and collaboration between technical systems of AIT and LIT need further investigation. To give an idea of the complexity of the challenge, of the six Working Groups established by the Professional Services Steering Group, five concern the socio-technical ecosystem of the e-learning platform .
Figure 2 shows the current state of the student profiles: they currently reside in different, independent e-learning systems of AIT and LIT, that need to be combined, and additionally also the financial system and many other information systems need data integration. The Higher Education Authority Network (HEANet) is the national research and education network (NREN) of Ireland: Similarly to AgfREN it provides a high speed secure and reliable backbone for the connection between these e-Learning systems, and users additionally also use public internet.

Figure 2: Currently interorganisational students profiles in the new AIT-LIT Technological University

In this paper, the contributions are
• to design an e-learning architecture based on NREN for the federated learning collaboration;
• in its pursuit, we apply the XMDD technology to design and implement a prototype of a e-learning reference implementation for data integration between different e-learning systems at three different levels: single organization, crossorganization and cross-nation.
• taking into consideration the diverse organizational strategies, policies, law and procedures of the collaborating parties.
Our solution and prototype go well beyond the SSO: we design a domain-specific e-learning broker for NRENs as a data integration application that focuses on an organization’s reputation management, identity management, process management, service brokering, with a search engine to lead users to the services available in the NREN domain, like for example an NREN local course management system. The prototype is easily accessible to designers, managers, developers, customers, and users, and it can be used as a showcase of the concrete application [16]. In the prototype and later in the developed system, users of the e-learning system access the resources located in the NREN domain based on their role in their local organization. We define which type of data is accessible to students, and at which level and which types of data are accessible for the academic staff and admin staff of each university.
The architecture and the XMDD model-driven design are our methodological contributions. The practical realization of a servicebased architecture on top of a variety of e-learning systems is the concrete proof of concept, that we applied to AfgREN as a case study.
Overall, we use advanced Information Technology and leading edge methods and tools for advanced Web application design and implementation, to produce computer software and applications that use the Internet and the World Wide Web to solve long term and large scale inter- and intra-institutional collaboration issues for e-learning.
The rest of the paper is organized as follows: Section 2 discusses the background of the domain technologies and the two case studies, Section 3 describes the methods and technologies adopted to produce the design and the solution, Section 4 illustrates the architecture design of the e-learning broker, Section 5 presents in detail the Model-driven design of the prototype reference system, in particular the Data model, Process models and GUI models, we explain our lesson learned in section 6, and the current status of the project explained in section 7, finally in Section 8 we conclude with a summary, some reflections and future work.

2. Background

Educational organizations need higher speed intranet and internet connections to access the heterogeneous traffic, and demand novel services [17]. Educational institutes at all levels suddenly closed in most countries worldwide due to the outbreak of COVID-19 early this year [18], and in many cases they have not yet returned to on-site education. According to the UNESCO report, due to the COVID-19 pandemic 850 million school children worldwide have been locked out of their schools, and have turned to online learning to continue their education, with added high pressure on e-learning systems and remote communication tools. While we hope the pandemic will soon pass, online education will always be needed for many aspects of high-quality education. Fortunately, over 120 countries [19] in the world established National Research and Education Networks (NRENs) to provide research and educational services, establishing a shared Information Technology infrastructure and providing it at a reduced cost with higher quality connection than regular and commercial Internet Service Providers (ISPs).

2.1 AfgREN

Concerning the background in the specific case studies considered in this paper, Figure 3 shows the current physical layout of the Afghanistan Research and Educational Network (AfgREN). Its Network Operation Center (NOC) is physically located at Kabul University and currently most of the AfgREN connectivity is provided by Afghan Telecom fiber optic links. Most public universities (in green) have a direct connection to the AfgREN NOC, but some like Herat University are connected indirectly by fiber. They use the same group of Internet Protocol (IP) address of AfgREN and its services, but the fiber network is from other ISPs. A group of provincial universities is connected to the AfgREN NOC via wireless WiMAX technology. Internationally, AfgREN is connected with the TEIN network by a 155 Mbps fiber optic link via Pakistan. TEIN covers mostly South Asian countries, with 21 NRENs of South Asian countries [3].
The services provided by federated members of TEIN include internet access, e-learning, tele-medicine, and support for research collaborations [2]. For the global connection, TEIN connects Asia to the European regional NREN GEANT, which includes HEANet,´ the Irish Higher Education Authority net. GEANT provides global´ identification via eduGAIN [6].
Various E-learning platforms such as Moodle, edX, Cisco Networking Academy, and many traditional applications including HEMIS are implemented in the AfgREN domain, providing a wealth of the most popular services [20]. The Higher Education Management Information System and the University entrance exam management information systems are specific purpose web-based applications developed by the Ministry of Higher Education of Afghanistan and they are used by all the public Universities in the country.

Figure 3: The AfgREN Layout and Connection Structure

Moodle [21] is an open-source e-learning platform that can be installed on a local server or accessed via the Internet. It provides a variety of communication facilities such as a discussion forum, message systems and wiki [21]. It is used for learning, assessment and management, and it provides various types of reports, courses, assignments and knowledge assessments.
edX [22] is also open-source, it was developed by the MIT and Harvard universities in the USA and it is mostly popular for MOOC courses and online certification. edX provides facilities for discussion between students and teachers, online video lectures, course materials, various online exams, and virtual libraries [23]. A comparison of edX with five other e-learning platforms in [21] (Coursera, Google Course Builder, Class2Go, Udemy, and Lernanta) shows that edX has more educational tools than the other four, each of these e-learning platforms has many good learning resources for the educational organization and avows that the integration of the platforms would provide many more learning opportunities for the students.
Cisco Networking Academy was the first e-learning system widely applied in Afghanistan universities. Kabul University is the main regional academy and trains instructors for other local academies [24]. The Cisco e-learning system is implemented in the Computer Science faculties in Afghanistan, providing course materials, laboratory tools, and an online examination system.
Moodle provides more features than edX and other e-learning systems used in the AfgREN domain. It offers more possibilities to customize and connect with other e-learning systems through its Learning Tool Interoperability [25] technology, and thus appears to be the most suitable platform for organizations that require a customized learning management system. However, there is a gap between these software applications and NRENs, and we endeavor to prototype an application to bridge the gap

2.2 Technological University Consortium

The second case study in this paper concerns the new Technological University currently being established in Ireland from the combination of the Athlone Institute of Technology and the Limerick Institute of Technology.
AIT was established in 1970 under the structure of Regional
Technical College (RTC) in Athlone, a city in the geographical centre of Ireland, to provide technician level courses. In 1993 AIT became an autonomous institution, in 1998 AIT was officially redesignated to Athlone Institute of Technology. Since then, AIT established itself as a center of academic excellence with an applied, industry-focused offering of engineering courses. AIT has more than 6,000 undergraduate, postgraduate and Ph.D. students from 84 nations around the world.
The Limerick Institute of Technology (LIT) is a multi-campus institute that was originally established in 1852 in the School of Ornamental Art and later restructured several times. Currently, LIT has three campuses located in Limerick, Tipperary, and Clare. LIT has more than 7,000 undergraduates, postgraduates, and Ph.D. students [26].
Based on the strategic plan of the Irish government [26] the new
Technological University will start in September 2021 and operate in multiple campuses covering 4 counties (Limerick, Clare, Tipperary and Westmeath) as shown in Figure 4. The campuses will be connected by the HEAnet backbone. HEAnet is the Irish national education and research network, providing e-infrastructure services for approximately 218,000 students and staff and connecting around 67 educational and research organizations at the national level. In total, around one million users in the research and academic organizations are using HEAnet. The main strategy of HEAnet [27] is to provide collaborative partners, trusted provider services, common, reparable and shareable solutions, innovative solutions, identity federation, brokerage, Key Advisor services, conduit to Europe services and make the country’s institutions an excellent place to work.

Figure 4: The Technological University Multi-campuses (AIT-LIT), from [26]

The campuses will be connected by the HEAnet backbone. HEAnet is the Irish national education and research network, providing e-infrastructure services for approximately 218,000 students and staff and connecting around 67 educational and research organizations at the national level. In total, around one million users in the research and academic organizations are using HEAnet. The main strategy of HEAnet [27] is to provide collaborative partners, trusted provider services, common, reparable and shareable solutions, innovative solutions, identity federation, brokerage, Key Advisor services, conduit to Europe services and make the country’s institutions an excellent place to work.
In this research, we target e-learning services brokerage in HEAnet as the means to provide collaboration between the multicampuses of the new Technological University. Currently, HEAnet provides the served institutions with four types of brokerage including hardware and equipment, software and license, services and consultancy, and students and staff offers. However, e-learning brokerage is also very important for users. Instead of searching the websites of all institutes, users prefer to refer to the website of HEAnet and search there for their required courses .

3. Design and Implementation Method

For the analysis, design and implementation we adopted the eXtreme Model Driven Development paradigm (XMDD) [28]. This way we work primarily on models that are compiled to code and automatically deployed, achieving an agile approach along the entire process and an extended DevOps technique for the prototype, that starts from models instead of code. Specifically, we used a three cycles scrum approach [29] to design the architecture [30] and the prototype of this e-Learning collaboration system. We used the Requirements Bazaar tool [31] to collect user stories and prioritize the requirements. Altogether, the applied design and development methodology is participative, agile, model-driven and low-code.

3.1 Participative Design

Collection of the user stories and the prioritization of the requirements are important steps in software development. We used the Requirements Bazaar concept and web-based tool [31] to collect, analyze, and then prioritize user stories. In addition to collecting the user stories, researchers and system developers can prioritize requirements based on the number of votes and comments provided by the users. Requirements Bazaar provides interaction facilities with the stakeholders from the beginning until the end of the project, facilitating the co-design and co-development approach we wished to adopt. We posted the list of elicited functional requirements and system/architecture features on the Requirements Bazaar portal as a project that we shared with the stakeholders. This enabled the various groups of contributors to Vote on requirements, Select requirements, add comments, add new requirements, and maintain continuous communication with the researchers. A vote means that this requirement is important and it has a high priority, a Select means that this item is required. Through comments, contributors can provide more detail to existing requirements, request changes to system features, and add sub-requirements for the system features. In this work, we combine votes and select in the same column because several stakeholders used them quite indifferently. When contributors selected both options we counted it only once [32].
We also distributed a questionnaire concerning the current state of the e-learning systems. Figure 5 shows that currently lecturers are using many different tools for online teaching and to share course materials. We also asked students about the same and their needs: data scattering is the main challenges that students and lecturers identified as a key problem for integration of the data between different applications.

Figure 5: Applications in use for e-learning in the AfgREN domain

3.2 Agile Design and Development

Figure 6 summarizes the agile development of the application: the user stories and requirements are collected directly from the users by using Requirements Bazaar. After the planning we designed the prototype using DIME, an Integrated Modelling environment that supports a model driven development and a fast-turn around DevOps cycle adequate for rapid prototyping. Currently we have the first version of the functional prototype of the reference system.

Figure 6: Methodology: the Agile development of the application and implementation tools

Figure 6 also shows the overall method from the tools perspective: we use Requirements Bazaar to collect the requirements, discuss with the users and collect the votes of the user and we prioritize the requirements based on the user’s votes. We use DIME for modeling and prototyping. DIME automatically generates Java, JavaScript and DART code, so we export the generated code and proceed to the deployment to a Java EE server side and an Angular 2 Web execution environment. We use GitHub and Bitbucket for the version control and the technical review.
The fast turn-around time for a prototype release is enabled by the model driven approach combined with the adoption of low-code development.
3.3 Model Driven Development
XMDD [33] offers a fast, understandable and easily modifiable paradigm for the co-development of complex systems, and it supports the agile development of the project in a modern and efficient DevOps fashion. The quick and efficient design and deployment of a web application with the XMDD paradigm provides an opportunity for developers to get continuous feedback from the customers/users, and improve the application in agreement with the users until the end of the project life cycle. XMDD is an evolution of the traditional model-driven engineering method (MDE) [34] that in particular supports service-oriented integration, a platform- and feature-based construction and reuse, and continuous integration and evolution.
MDE is a domain-specific modeling methodology that formalizes via models the application structure, behavior and the requirements and properties of IT systems within a specific application domain. It also facilitates formally analyzing specific aspects of models, easing the correctness and performance checking on the models to detect errors early, before investing deep in the development life cycle.
XMDD focuses on process models as a primary artifact, understood as descriptions of what the system or application should do. It provides model-level artifacts that are executable even before the full application design and implementation, thus it is accessible also to people that are either less technically skilled, or even not interested at all in usual programming. The benefit for our application is that the adoption of XMDD reduces the time needed for the implementation of the application [34] by adding a coordination layer to the system architecture that describes and then implements the coordination logic between the different components of the architecture.
3.4 Low-code Development
Using DIME [35, 36] as a low-code development environment for the XMDD paradigm, we have a ready graphical modeling tool for the entire architecture, including the data model, control flow and data flow, GUI (interface model) and security/roles and rights model. These models are easier to understand than code, thus supporting the interaction and co-design between IT professionals, domain experts, business experts, and users better than at the code level or the traditional (more technical) modelling level as in a typical UML [37] approach. This approach is extensively validated: it has proven successful in the development of web applications, telecommunication systems, game development, robotics, and bioinformatics systems [34]. In particular, XMDD and DIME support Domain Specific Languages, intended as domain specific libraries of services that provide reusable functionalities [38] and features [39, 40].

4. E-Learning Broker Architecture Design

We designed a domain-specific service-oriented e-learning system for systematic data integration and service brokering between different e-learning systems in NRENs. We refer here to the specific case of AfgREN, but the architecture is general, as we aim at standardization for compatibility beyond specific regional consortia.
In the specific case study, AfgREN is established at Kabul University and it provides services to Afghanistan’s public universities including Balkh University and Herat Universities. Figure 8 shows the architecture from the point of view of Kabul University: it has its own three layers (on the left) and it provides services to the external layer of the other universities (on the right) through the e-Learning Broker (center). The same layers and components exist for the other collaboration parties, which are symmetric.
In Afghanistan, the legal framework and procedures are the same for all the public Universities. This simplifies the collaboration because the three layers and several components in Kabul University’s local architecture (shown in Figure 8 left) are also applicable to the other public Universities in Afghanistan. The second case study exemplifies how much of the architecture and the broker carries over to the Irish TU setting.

4.1 National, Cross-Organizational Collaboration

4.1.1 Requirements

Prior to the design of architecture, we performed an architectural requirements prioritization using Requirements Bazaar concept and tool with an expert group of stakeholders that comprised the elearning committee of Kabul University and AfgREN network operation center engineers.
Figure 7 shows the functional requirements of system architecture together with the number of Votes/Select each attribute received in a Requirement Bazaar-supported session. We used Requirements Bazaar from the very early stages till the end of the development process to be in continuous contact with the remotely located expert groups, and negotiate and validate requirements and design decisions in each stage of the development.

Figure 7: Functional Requirements of the System Architecture

4.1.2 Choosing the Architecture pattern

Different architecture patterns exist for different applications, such as Layered architecture, Event-Driven Architecture, Microkernel Architecture, Micro-services Architecture, and Space-Based Architecture [41]. We carefully analyzed the application domain and requirements to decide which architecture pattern is the most suitable for the target application.
Layered Architectures consists of several layers addressing individual concerns [42]. The required number of layers depends on the complexity of the application: some complex applications, such as the Internet of Vehicle (IoV), have five layers [43]. Most of the layered architectures have four layers: a presentation layer, a business logic layer, a persistence layer, and a database layer. Sometimes in sample architectures the architects combine the persistence layer with the business logic layer. The process of passing data between layers needs to be very systematic. Layers need to be closed or open, only after having been processed by a specific layer the next layer is made accessible for its data processing. In a layered architecture, the components are accordingly also divided into these layers. The classification of components into different layers helps for easier separation of concerns in the development, test, and maintenance. Layers also provide better modifiability, offering a form of virtualization: if a component of one layer is changed, it does not affect components of the other layers. However, layers and tight coupling of components have a negative effect on the performance, agility, deployment and scalability of a system [41].
Event-Driven Architectures are used for highly scalable systems. Its two main typologies are the mediator topology and the broker topology.
A mediator topology is commonly used when the architect centralizes the events. The typical mediator topology has four main components (event queues, event mediator, event channel, and event processor) and two types of events: initial events and process events.
The broker topology is best used when the architect chains the events and does not need to centralize them. The broker topology has two main components: a broker component and an event processor component [45]. The Event-Driven Architecture pattern is a complex pattern, and the architect needs to consider the remote process availability issue, the lack of responsiveness and the broker reconnection logic in the broker event or face mediator failure [41].
Plug-in Architectures are used as a way of supporting relatively independent third party products. A Plug-in architecture pattern that is also called Microkernel pattern consists of two main components including the core system and one or more plugin modules. This architecture pattern is mostly used for product-based applications that have downloadable files.
Microservice Architectures are the oldest services-oriented pattern [50] and widely adopted in distributed and module-based systems. Currently, it is used as the predominant service-oriented architecture [50]. The microservice architecture pattern is a specialized alternative to a more general service-oriented architecture. It is a distributed architecture, where all components are separated and can be controlled with a remote access protocol. The distributed nature of this pattern provides more scalability and ease of deployment attributes [41]. However, microservice architectures have challenges of security [47].
The Cloud Architecture pattern is also called space-based architecture, and addresses the problem of scalability. An application that is accessible through a web interface is a suitable application for this pattern. However, the cloud architecture pattern is expensive and it is not suitable for a traditional database with a large number of operational services. The advantage of a cloud based architecture is that we can implement different architecture components in this pattern. The cloud-based patterns simplify the deployment of applications [48, 41].
Table 1 summarizes the comparative characterization of the described architecture patterns based on their quality attributes relevant to our application. We qualitatively indicate the extent to which each quality attributes is provided as Low (*), Medium (**) and High (***).
Table 1: Analysis of Architecture Patterns based on Quality Attributes [44, 42, 43, 41, 45, 46, 47, 48, 49]
Architecture Pattern Agility Deployment Testability Performance Scalability
Layered Architecture * * *** * *
Event-Driven Architecture *** *** * *** ***
Plug-in Architecture *** *** *** *** *
Microservice Architecture *** *** *** * ***
E-Learning Broker Architecture ** *** *** *** **

4.1.3 The Hybrid NREN e-Learning Architecture

Given the needs of our applications, we adopted a layered, eventdriven architecture with a broker technology that provides a high level of agility, ease of deployment, high level of performance and scalability [12, 49, 30, 20, 51]. In this system, the broker needs to publish events to different collaborative systems that are in different domains and follow different roles. Additionally, the XMDD paradigm automatically enforces a service-oriented approach [34] at the implementation level [52], so that we also reap the benefits of this paradigm in the application design and implementation. XMDD is compatible with the SCA service-oriented architectures standard [53], and is a service-oriented evoilution of the more traditional component based architectures in software design [54] and of the feature oriented architectures in early telecommunications services design [55]. It would even support higher order processes, allowing for full reconfigurability of the processes at runtime as shown in [56].
The NREN e-learning architecture shown in Figure 8 is composed of three layers: Internal Layer, Conceptual Layer, and External Layer (on the left). Each layer has several components and sub-components that provide the features identified as a core for any NREN e-learning system architecture.

Figure 8: The Component diagram of eLearning System Architecture for a subset of AfgREN

Figure 8 is adapted from the reference architecture for managing dynamic inter-organizational business processes (eSRA) [57] and shows the abstract level of the AfgREN e-learning architecture [49].
• Looking at the structure in the main node, that in AfgREN is
at Kabul University (Figure 8 left), the e-learning platforms are located in the External Layer.
• The ConceptualLayer comprises an e-learningSetupSupport component in which e-learning services are composed collaboratively in a crowdsourcing way. These e-learning services are process aware, have rules attached. Additionally, the Translator component converts heterogeneous data formats between the external and internal layers.
• The Internal Layer contains a Legal framework component in which local process enactment engines, legal process and orchestrate information technology infrastructure that is wrapped as a Web-service. Furthermore, in the Internal Layer local rules engines and local database systems capture the roles of the respective departments and user groups, including academic, administration and students. This structure and subdivision correspond to the essential features identified in various workshops with stakeholders of these groups.
4.1.4 The Broker Aspect: System-Level Features
The design of the e-Learning broker is based on the following elicited system-level features and requirements:
1. The NREN system supports the conceptual formulation of e-learning services between collaboration parties based on the accepted agreement and the established procedures.
2. Translation of the existing legal framework to a technical system, and the mapping of these between collaboration parties.
3. Projection of the e-learning services from the conceptual layer of each collaboration party to the external layer.
4. Brokering capability for the projected services. The broker needs to have access to all e-learning systems of the collaboration parties, the Broker provides an interface that users access different e-learning tools from a single interface, the Broker interface provide SSO services ad also integrate the data of used e-learning applications.
5. Verification of collaboration parties and exchangeable components is another task of Broker,
6. Announcement of the verified result to users, the new services, new members, and any possible issues also announce by the Broker component.
7. Stepwise and systematic construction of interoperable eLearning architecture based on NRENs.
8. Technology independent e-Learning architecture based on NRENs, easy to port to more modern technologies.
9. Interfaces for the separation of heterogeneous data, to protect private information and to enable a separation of internal and external processes. Collaboration between systems by using Single-Sign-On technology
10. Loose coupling for the interoperability of the e-learning platforms.
11. No central role for any member of the collaboration parties, each collaborative party should act as a party.
12. The Broker application will be installed in the network operation center of the NREN.

4.1.5 Data Management

For data management, the NREN e-learning architecture adopts an abstract data repository. This style keeps e-learning service consumers and providers of shared data from knowing of each other’s existence and the details of their respective internal implementations. The abstract data repository implements a layering style by interposing an intermediary protocol between the producer and consumers of the shared e-learning services. Its interface further reduces the coupling between data producers and consumers. Global and local process enactment and rules engines in the external- and internal layers are dedicated components for example for the technology translation, data mediation, and policy enforcement.

4.1.6 Broker-Based Service Mediation

The broker pattern in the AfgREN is implemented in the eLearning Broker component, a separate component that mediates between collaboration parties within the architecture, facilitating the rapid and performant matching of e-learning needs with requests from users. Its purpose is the redirection and bundling of communication among the parties, preventing parties from finding, contacting, and investigating every potential collaborating party separately.
The service oriented architecture of the eLearningBroker component is shown in Figure 9, and it is adapted from an NREN e-learning reference architecture [49]. The broker uses a publish/subscribe style in which publisher institutes submit new elearning services, and all subscribers that are members of the NREN receive notifications automatically. The broker works as a notifier between the collaboration parties. The subscription contract between collaboration parties can be a collaboration contract with free cost or with a price. In this star-like topology the publishers and subscribers are the leaves. This style is advantageous in a multiparty collaboration environment with large numbers of potential e-learning service consumers and providers. It provides a good system performance because of the reduced communication overhead and it enhances the flexibility and ease of integration of additional (national) e-learning systems. In this type of topology, users can easily access the many types of e-learning services provided by collaboration parties in the NREN domain.

Figure 9: The e-Learning Broker in Detail

4.1.7 The Core Services

The collaboration between organizations is based on the existing rules and procedures, and each party needs to specify their services and data. Conceptual patterns need to be set up in a technical system in such a way that collaborative parties access only the legal and correct exchangeable data.
Internally, the eLearningBroker includes sub-components for ReputationManagement and IdentityManagement, as well as a ProcessSnippetManager, a Validator, the proper ServiceBroker and a UserInterface.
The ReputationManager stores detailed information about collaboration parties including the list of exchangeable data/services and the level of service access. The IdentityManager stores detailed information about the users, user groups, their access capabilities, and it exchanges information with all sub-components of the eLearningBroker. The ProcessSnippetManager stores the business processes and collaborates with the ServiceBroker to provide the composed processes for the specific heterogeneous e-learning systems that each collaboration partner provides. There can be in fact various e-learning platforms, like Moodle or edX, that support different processes.
The Validator component consists of a ProcessCommunicator, a Verifier, a Translator, and an InterfaceChecker. When this component receives a verification request, it processes it, verifies the legitimacy w.r.t the contractual sphere, the access to services via an interface, and sends back the results.

Figure 10: The e-Learning Service Broker Detail

The ServiceBrokerManager consists of three other subcomponents: the ServiceLibraryManager, a Template
SearchEngine, and a Notifier. The ServiceLibrary stores the business processes of collaborative parties and provides information for the SearchEngine and Notifier. The business process specifictions stored in the ServiceLibraryManager works closely with the external layers of the collaboration parties. At the top-level users can search available services through the TemplateSearchEngine interface of the eLearningBroker. For instance in Figure 10 the SearchEngine exchanges data with the bid manager component for the brokering services. The UserInterface of the Broker provides access to all NREN eLearning services through this search engine.
Finally, the Interface component provides the user access interface for the users, so that through SSO users can access many participating applications with a single login.
In Figure 8 the Balkh University and Herat University on the right side of the system architecture have the same components as Kabul University, they receive the services and data through their own E-LearningExchange components, and their internal architecture.
The eLearningBroker component is an interface that facilitates the collaboration of e-learning systems through a rapid matching of e-learning needs with requests from users. Concretely, the broker works based on the collaboration agreement between the parties sharing e-learning services. Collaborating parties may have repository style. This style shields e-learning service consumers and providers of shared data from the knowledge of each other’s existence and the details of their respective internal implementations. Figure 11 shows the result of the solution provided by the new broker architecture; it solves the problem of data replication in a different system located in the same NREN domain shown in Figure 1.
Our proof of concept system in the reference implementation covers all the system features listed in Figure 7. These features were discussed with domain experts and prioritized. We prototyped the application Based on the designed system architecture, and shared it with the domain experts for further feedback and enhancement.
While the prototype is designed only for the AfgREN case, it is nicely applicable also for the Technological University.

4.2 Intra-Institutional Cross-Campus Collaboration

different agreements, e.g. Some exchangeable data may be offered for free while some services may need to be paid by the users or collaboration parties. The e-Learning broker also sends notifications to collaboration parties.
The central advantage of the broker in a multi-party collaboration environment with large numbers of potential e-learning service consumers and providers is high system performance, supporting efficient access to many e-learning services provided by collaboration parties. This is due to reduced communication overhead and enhanced flexibility and ease of integration of additional e-learning platforms, which were among the top quality attributes requested by the experts.
Figure 11: Successful Data Integration with the AfgREN Broker
The NREN e-learning architecture implements an abstract-data
Cross-campuses collaboration within a federated institution requires to focus more on the resources sharing and data integration between different different applications: the e-learning setup must filter the exchangeable data based on the respective procedures and responsibilities of the collaboration units, which usually differ. In such a context, the legal framework and procedures, security and privacy are the top priorities.
replicated also for the cross-campuses collaboration. The formal move to the TU structure, with a start of operations as TU, will happen before the two ITs fully merge their policies and IT systems. The alignment of decisional and operational policies and regulations (that in Ireland are strongly local to each institution) and the de-duplication of IT systems to reach a single platform for every function will therefore happen gradually over time, if ever.
The TU will therefore face a transition time of likely several years where it will need to operate formally as one entity, but with regulations, policies and IT systems that start disjoint and will gradually converge, in some phased manner. The advantage of a broker based architecture as we propose is clear, due to the many components supporting the mapping of all these vital functions, it can evolve along the legal and operational changes, eliminating the need for costly point-to-point integration.

5. Model Driven Design of the E-learning Broker

Using DIME as a tool for prototyping and supporting XMDD and model-driven engineering method (MDE)[58] the web application development of the broker does not require extensive programming skills and it provides through the models an opportunity to involve a wide range of project stakeholders. This is a key factor for the success of a project.
We describe now the design of the AfgREN Collaboration Bridging Application, a web application that embodies the prototype for the AfgREN case study. We used the described XMDD approach and the DIME Integrated Modelling Environment as a MDD layer on top of the Eclipse IDE (integrated development environment).
For ease of understanding we describe the application design aspect by aspect, along the DIME model types: Data models for the data structures, Processes for the business logic, GUI for the web application presentation and interaction layer and Security for the Roles and rights management. We present the four aspects individually, but the prototype was developed in an agile and collaborative way, by co-designing and co-evolving the 4 types of models along the growth of the prototype in successive sprints.

5.1 Data Model

The data model in Figure 13 shows the structure of the e-Learning Broker that is an abstract model and organized elements of data that is relate to one another and to the properties of entities. The Base User, User, and Role were preexisting in DIME. We add the Broker component with its many sub-components: Thread, Category, SSO, Register, Search, Language, LegalFramwork, and detail of legal framework and many other sub components are required in the parts of the prototype. The Roles foreseen for the users of the application are a simple User group, an Admin group, a PowerUser group, and a GuestUser group. DIME creates a powerful data model for web applications with many advanced modeling features including AbstractType, ConcreteType, UserType, and EnumType, each of them have different attributes. The models are managed with bidirectional associations, association, and inheritance connection.
Three different Model Component Types are used in this data model: Concrete types (C) are used for the User, Broker, Thread, RegisterO, Category, SSO, Search LegalFramework, and Detail. The User type (U) is used for the Base User and the Enum type (E) is used for the Role and Language. We consider a User association connection between the User and BaseUser (in orange), a bidirectional connection between User and Thread (solid line), and an association connection between Broker and other components (arrows). In the associations as well as in the individual data types, we use square brackets to indicate lists or collections. For example, in Figure 13 the User association associates every User with the same BaseUser, but the BaseUser is associated to many concreteUsers, indicated as [concreteUser]. Similarly, a User can be associated to many Brokers and Threads.
The Model components have a rich set of typed attributes. For each attributes, the model shows whether they have no associations (yellow dot), unidirectional connection as the User.broker attribute with the Broker (yellow dot with one black dot), or bidirectional connection like the threads attribute of the User with another thread model component (yellow dot with two black dots).
All these model elements are formally defined, they are used by the DIME syntax and semantic checkers to ensure that the use of the components and data in the processes is syntactically and semantically correct. This integration of knowledge and checks across various model types is one of the advantages of XMDD as implemented in DIME in comparison with traditional model based approaches to software development, where these checks are not available, or not connected with a correct-by construction generation of code.
As we see, very little in this model is specific to a case study.
While the languages will change (English and Persian in the AfgREN case, English and Irish in the TU case), as well as the specific Legal regulations (e.g., GDPR for privacy is mandatory in the EU but not in Afghanistan, which follows national laws instead) the vat majority of the fields is present and very similarly instantiated in both case studies. All the e-learning application fields for example are instantiated to Moodle in both cases, and the user categories and roles so far seem to be shareable as well.
In this sense, we think that a good part of the architecture, data model, implementation and ontology are domain specific to a federated collaboration architecture, thus widely reusable across various kinds of supervised and regulated collaboration, and that a good part of the domain specific aspects, like the e-learning applications and parts of the student management can also be shared at the platform level across all the deployment instances. Only a small part of the data model, processes, GUI etc will need to be customised to the specific collaboration and to the specific institution. For example, the fact that some institutions are connected through WiMax is taken care of at a lower layer (the underlying network and pure connectivity layer) and does not reflect itself on this architecture and models.

Figure 13: Data Model of the Broker Application (in DIME)

5.2 Process Models

The DIME process models support a complex business logic, with the usual patterns (sequential composition, alternative choice, parallel fork and join, and hierarchy), advanced dynamic access control and long-running processes. The process models are interdependently connected with the data model and the user interface models. A web application like the bridging application requires the collaboration of several model types. Figure 14 shows the palette of models
we developed in this case study. We now describe some of them.

5.2.1 Home Process

The main process is the Home process. As shown in Figure 15, the Home Process model integrates the Public interface, Private interface and all required options for the Detail process of the e-Learning Broker application.
The process starts with the RetrieveAllThreads subprocess: it collects all the current learning materials including course title, learning support document, and library support materials, and then displays them on the PublicHome page. This is the public home page of the application, which is here represented by its GUI model. From the public home page, users can search for courses and materials. To do so, the system searches (Search process) the content metadata from all e-learning platforms registered in the NREN domain and collates the information in the RetrieveAll process.

Figure 14: The e Learning Broker Process Library (in DIME) Filters can be successively applied.

Open-access material and courses that will be categorized by the Universities can be used publicly without system login and with no

Figure 15: The e Learning Broker Home Process: Control Flow and Data Flow in DIME

limitation. If a course requires login credential, the user is required to have a user account in the e-learning platform used for course management in their organization, and their e-learning platforms should be a member of the NREN SSO that is located in the Broker component. After logout, the user returns to the public page of the Broker application, and at the same time user logout from all collaboration e-Learning systems.

5.2.2 Startup Process

Figure 16 (left) shows the Startup process model that adds users and threads to the collaboration system in a role based fashion. The roles Admin and PowerUser can add threads. PowerUsers are involved in creating a course, learning content, and informative materials. The subjects are categorized by the name of the departments, and PowerUsers of the e-Learning application can add a list of subjects under the name of each department. The logic of this part of the process model leads the system users to a local bridging application server. The Moodle platform is also located on the same server. A title, a short description, and a URL are required for all threads (see the GUI model in Figure 17) (right). Then a category is selected and the thread is submitted. The system records the author and date of the thread creation, duplicate threads are notified to their author.

5.2.3 Register Organization Process

Registering new organizations to the list of collaboration parties is a core feature of the Broker, taken care of in the RegisterO process. Any user can add the reputation of the organization to the system, that needs approval by the Admin. The reputation of an organization is accessible through the registration button in the public interface. Figure 16(right) shows the process model for registering an organization on the basis of the name, type and official email of the organization, its domain name, and IP. This is a low-administration way to provide new facilities for the collaboration parties.
As evident from the Process Library in Figure 14, we defined and used more processes to perform other sub-tasks. From the process models briefly introduced we see that all the process models, the data model, and the interface models are integrated with each other and work together to generate a fully functional web application.

5.3 User Interface Models

Figure 16: The e Learning Broker Startup and Register Organization Processes in DIME

The dynamic and responsive graphical user interface of the Collaboration Application is built by means of DIME’s GUI process models, that are connected seamlessly to the business logic via hierarchical modeling. The Broker Web application has both a public user interface accessible to anyone, that shows a list of options and a list of subjects based on their category, and also a private interface accessible only to registered users. Figure 17(left) shows the top level DIME GUI model of the the public interface, and Figure 18 shows how the public interface of the deployed and running web application presents to the users.
The public user interface is intentionally kept simple. All the elements appearing on this interface (input fields, buttons, menus etc) are part of the GUI element library that comes with DIME, so there is no need to develop code for the GUI design, which is done in a purely zero-code drag and drop and configuration manner. This feature allows in particular a very efficient turn-around cycle for modifications of the look and feel of the web application.
The public interface also provides a good opportunity for the software developers to share with the reviewer team, product owner, and other stakeholders the prototype of the application, to get feedback and keep them committed to the project: these users can test and assess the application and give timely feedback, while most of them would not be able or willing to review the code.
Users of the participating institutions to the e-learning collaboration use the services of the NREN through the broker and the local e-learning systems in a secure way. They log in once to the server with their username and password, then to access other participating applications they are required at the first login a secure key. After the first login, they are enabled to use their applications without further formalities.
Once logged in, users reach their private user interface. From there they reach all the applications they are entitled to see in the NREN, and those where they can add new threads. Figure 17 shows the private interface model (right). The private interface is role-specific, currently covering course developers, system administrators, auditors, and maintainers. The administrator role of the system can define different roles for the users.
For security purposes, we use the Elytron[59] technology contained in WildFly 14 to provide authentication, authorization, and data encryption.

For the development of the current prototype, shown in Figure 18, we considered three options:

Figure 17: The e Learning Broker Public and Private Interface in DIME (GUI Models)

• In the first, a Moodle instance is installed on the server that runs the bridging application, and the Moodle application uses its Shibboleth instance to reach e-learning systems that support Shibboleth. In this case, the GUI model provides users with a button to login to Moodle. Once logged into this Moodle, users can access any other participating application that supports Shibboleth.
• A second option uses instead the Wildfly 14 contained in DIME. To configure the SSO, we replace the original DIME configuration with a modified ¡standalone-ha.xml¿. A key for using the SSO is created and shared with each member’s application. We use this option for the applications that support wildfly Web Single Sign-On.
• Additionally, to access other e-learning platforms such as edX, and in-house developed applications, the GUI model of bridging application provides the third option for users. Currently, the button of the third option is linked to edX
Afghanistan a customized e-learning application for Afghan public Universities. All three options are available in the public interface shown in figure 14 and users can select any option they required.

6. Lesson Learned

A central benefit of DIME and XMDD is that once a model is designed, due to the low-code approach to process development that reuses many preexisting components and a zero-code approach to the data design and GUI design, having the models is equivalent to having built a reference implementation. By code generation from the collection of models and components, as supported in DIME, we obtain a ready (prototype) application and this application is automatically deployed and fully functional for user testing or usage. This approach thus supports a more widely accessible collaborative DevOps style of design and development that improves over the currently standard agile approaches, that are code-based.
This way, it is possible to share and reuse the generated (native
Java, Javascript etc) code as-is, but also to change the models (in the DIME graphical editor, or alternatively in the standard Xpand Eclipse textual format) and re-generate and deploy a new version. This feature in particularly attractive in an environment that is still evolving, like for the TU intra-organisational collaboration. That collaboration is actually establishing an inter-organisational collaboration between two up to now independent institutions. It is likely to start as a very lightweight federation of distinct tools and systems, joined by a properly designed and managed access (SSO, security, and roles and rights), but it will over time substitute the 2 or more systems in place up to now for each aspect of the TU’s e-learning and students management with potentially only one system – either one of the current locally adopted solutions or a new one. In this context, it is important to be able to quickly experiment with alternatives, for example in a staging configuration, with quick turn around of modifications and easy and immediate access to the successive versions of the various features and services.
We already assessed that the current reference prototype is portable with minor modifications also for the Technical University use case. The detailed design of the Technological University collaboration is still ongoing and the development of the full application is accordingly future work. Along the agile development style, a first beta-release will be followed by two more increments in the coming months.
Additionally, the prototype works as generic reference platform for collaborative e-learning and student management, including for example lighter-weight collaborations with associated institutions, for example for ERASMUS+ international programs or interinstitutional national courses of study as the Irish Higher Education Authority increasingly promotes, for example in Digital Health
Transformation. The central feature of the architecture, reference application and concrete Web Application is that we can evolve and extend them with ease, integrating more functionalities and features. Specifically, the DIME models are both intuitive and formal, and designing systems with these models does not require computer programming knowledge. This provides a real opportunity to have prototypes co-developed by real users, including student administration employees, for a true co-design by those who deeply know the requirements of the organization.

7. Current Status

From the list of features and the data model of Figure 7, the SSO, registration, search engine, user accounts, legal framework, thread, and categories are already actively working. The multilingual language option and the user role management will be active in the next version of the prototype. At this stage, validation has taken place technically in the developer test and continuous feedback has been gathered from representatives of the user groups addressed in the workshops.
In the specific AfgREN context, there is a higher uniformity than in general NRENs because the members are public Universities that follow the same policy, law, and procedures defined by the Ministry of Higher Education of Afghanistan, while international NRENs are more heterogeneous. The network infrastructures, e-learning systems, and other applications are the same as in other NRENs. We provided AfgREN with an SSO by configuring the AfgREN Broker application (designed and code-generated with DIME) to serve also as an SSO server. We installed Moodle and enabled Shibboleth on it in the same server. We have currently prototypes of the searching engine, identity manager and reputation manager. We are working to develop the remaining subcomponents of the broker (validator, translator) and to add an intelligent agent in the Broker that provides a fully transparent SSO service for the different e-learning platforms implemented in the NREN domain.

8. Conclusions

We provided a modular and extensible architecture for NRENs as a modification of a previous reference architecture for business collaboration, now ported and extended to the e-learning data integration, as well as a novel architecture of an e-Learning Broker that is technology independent and thus helps furthering open education and learning collaboration. We adopted a model-driven design paradigm for the development of a reference prototype of a Web-based Collaboration Application that supports open education collaboration and data integration between different e-learning systems co-existing in an NREN domain.
In particular, we adopted AfgREN as a case study, considering the specific policy and strategy legally in place in the AfgREN domain. Based on the proposed NREN e-Learning architecture, we designed the data model, several process models and the interface models of the NREN e-learning broker. These models and processes are going to be provided open source, both in a DIME-specific format and in export formats reusable independently of DIME.
The current prototype of the reference implementation is functional, and we have indeed made use of the rapid turn-around time of design and DevOps iterations enabled by the chosen XMDD and low-code development technologies.
Acknowledgements This work was supported, in part, by Science Foundation Ireland grant 13/RC/2094 to Lero, the SFI Research Centre on Software (www.lero.ie). It was also supported in part by ALECS, the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No. 754489. A CC BY or equivalent licence is applied to the Author Accepted Manuscript, in accordance with the grant’s open access conditions

1. K. Upadhyaya, D. Mallik, “E-learning as a socio-technical system: An insight into factors influencing its effectiveness,” Business Perspectives and Research, 2(1), 1–12, 2013, doi:https://doi.org/10.1177/2278533720130101.
2. A. C. Risdianto, P. M. Thet, A. Iqbal, N. A. M. Shaari, H. K. Atluri, G. N. Nurkahfi, A. Wantamanee, R. Hakimi, U. Javed, M. Ahmad, et al., “Deploy- ing and Evaluating OF@ TEIN Access Center and Its Feasibility for Access Federation,” Proceedings of the Asia-Pacific Advanced Network, 42, 34–40, 2016.
3. N. Suresh, J. Mbale, A. Terzoli, T. K. Mufeti, “Enhancing cloud connectivity among NRENs in the SADC region through a novel institution cloud infras- tructure framework,” in 2015 International Conference on Emerging Trends in Networks and Computer Communications (ETNCC), 179–184, IEEE, 2015, doi:10.1109/ETNCC.2015.7184830.
4. L. Ssentongo, R. Kimera, B. Kakeeto, M. Mubiru, B. K. Moyer, M. Economou, C. J. Whalen, M. Tartakovsky, “Deploying Educational Roaming (eduroam) in a Rural Research Institution in Rakai, Uganda; Challenges and Lessons Learned,” 2016.
5. U. Pietrzyk, A. Zakhnini, M. Axer, S. Sauerzapf, D. Benoit, M. Gaens, “EduGATE–basic examples for educative purpose using the GATE simulation platform,” Zeitschrift fu¨ r Medizinische Physik, 23(1), 65–70, 2013, doi:http://193.48.81.146/sites/default/files/dx.doi.org/10.1016/j.zemedi.2012.07.005.
6. S. Michael, Z. J. Anna, “An Identity Provider as a Service platform for the eduGAIN research and education community,” in 2019 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), 739–740, IEEE, 2019, doi:978-3-903176-15-72019IFIP.
7. M. Li, C.-H. Chi, C. Ding, R. Wong, Z. She, “A Multi-protocol Authentica- tion Shibboleth Framework and Implementation for Identity Federation,” in International Conference on Security and Privacy in Communication Systems, 81–101, Springer, 2018, doi:https://doi.org/10.1007/978-3-030-01704-0 5.
8. N. Hamamoto, H. Ueda, M. Furukawa, M. Nakamura, T. Nishimura, S. Yokoyama, K. Yamaji, “Toward the Cross-Institutional Data Integration From Shibboleth Federated LMS,” Procedia Computer Science, 159, 1720– 1729, 2019, doi:https://doi.org/10.1016/j.procs.2019.09.343.
9. M. Katzer, D. Crawford, “Office 365 DirSync, ADFS, Single Sign On and Exchange Federation,” in Office 365, 545–630, Springer, 2013, doi: https://doi.org/10.1007/978-1-4302-6527-6 11.
10. P. Kamal, S. Mustafiz, F. M. A. Rahman, R. Taher, et al., “Evaluating the efficiency and effectiveness of a federated sso environment using shibboleth,” Journal of Information Security, 6(03), 166, 2015, doi:10.4236/jis.2015.63018.
11. S. Saay, T. Margaria, “Xmdd as key enabling technology for integration of large scale elearning based on NREN,” in 2020 IEEE 20th International Con- ference on Advanced Learning Technologies (ICALT), 45–46, IEEE, 2020, doi:10.1109/ICALT49669.2020.00020.
12. S. Saay, A. Norta, “An architecture for e-learning infrastructures on a national level: a case study of the Afghanistan Research and Education Network,” International Journal of Innovation and Learning, 23(1), 54–75, 2018, doi: https://doi.org/10.1504/IJIL.2018.088790.
13. U. K. Hazra, R. Das, S. Mukherjee, “e-Learning Platform in SAARC Coun- tries,” Library Philosophy and Practice, 1–9, 2019, doi:https://digitalcommons. unl.edu/libphilprac/2882.
14. A. Khaliq, M. S. Shams, M. M. Niazi, “COVID-19 Pandemic: Chal- lenges and Opportunities for Higher Education in the Afghanistan context,” doi:https://kardan.edu.af/data/public/files/KJEMS-3.3-2020-03% 2014102020083157.pdf.
15. M. Z. Sana, “Common Distributed Data Storage for Higher Education Man- agement Information System in Afghanistan,” International Journal of Scien- tific Engineering and Science, 32–38, 2020, doi:http://ijses.com/wp-content/ uploads/2020/05/120-IJSES-V4N4.pdf.
16. M. Beer, M. C. Meier, B. Mosig, F. Probst, “A prototype for information-dense it project risk reporting: an action design research approach,” in 2014 47th Hawaii International Conference on System Sciences, 3657–3666, IEEE, 2014, doi:10.1109/HICSS.2014.456.
17. I. Turus, J. Kleist, A. M. Fagertun, “Evaluation of flex-grid ar- chitecture for NREN optical networks,” in TERENA Network- ing Conference 2014, 2014, doi:https://orbit.dtu.dk/en/publications/ evaluation-of-flex-grid-architecture-for-nren-optical-networks.
18. S. Mahmood, “Instructional Strategies for Online Teaching in COVID-19 Pandemic,” Human Behavior and Emerging Technologies, 2020, doi:https:
    //doi.org/10.1002/hbe2.218.
19. S. L. J. Villalo´n, C. C. L. Hermosa, “The Role of National Research and Ed- ucation Networks Providing Connectivity and Advanced Network Services to Virtual Communities in Collaborative R&E Projects. CUDI: The Mexican Case,” in International Conference on Supercomputing in Mexico, 24–47, Springer, 2015, doi:https://doi.org/10.1007/978-3-319-32243-8 3.
20. S. Saay, M. Laanpere, A. Norta, “Requirements for e-testing services in the AfgREN cloud-based e-learning system,” in International Computer Assisted Assessment Conference, 133–147, Springer, 2016, doi:https://doi.org/10.1007/ 978-3-319-57744-9 12.
21. C. Costa, H. Alvelos, L. Teixeira, “The use of Moodle e-learning platform: a study in a Portuguese University,” Procedia Technology, 5, 334–343, 2012, doi:https://doi.org/10.1016/j.protcy.2012.09.037.
22. D. Volchek, A. Romanov, D. Mouromtsev, “Towards the semantic MOOC: Extracting, enriching and interlinking e-learning data in open edX platform,” in International Conference on Knowledge Engineering and the Semantic Web, 295–305, Springer, 2017, doi:https://doi.org/10.1007/978-3-319-69548-8 20.
23. M. Blagojevic´, D. Milo ́ seviˇc, “Massive open online courses: EdX vs Moodle MOOC,” in Proc. 5th International Conference on Information Society and Technology, Kopaonik, Serbia, 346–351, 2015, doi:https://aosus.org/uploads/ default/original/1X/97ba7ad9a50b2a3171ebaaa64d8cf2943af37807.pdf.
24. H. Sokout, T. Usagawa, “Analyzing the Current Situation of E-learning at Kabul Polytechnic University,” in Proceedings of the 2nd International Conference on Education and Multimedia Technology, 49–53, 2018, doi: https://doi.org/10.1145/3206129.3239428.
25. A. Naim, M. R. Hussain, Q. N. Naveed, N. Ahmad, S. Qamar, N. Khan, T. A. Hweij, “Ensuring interoperability of e-learning and quality development in education,” in 2019 IEEE Jordan International Joint Conference on Electri- cal Engineering and Information Technology (JEEIT), 736–741, IEEE, 2019, doi:doi:10.1109/JEEIT.2019.8717431.
26. AIT – LIT Consortium, “The context for the new TU,” in Applica- tion for designation as a technological university, 16–18, https://www. aitlitconsortium.ie/, 2020.
27. A. Harding, “Design and Implementation of Service Level Agreements at HEAnet,” www.heanet.ie, 2–14, 2007.
28. T. Margaria, B. Steffen, “Agile IT: thinking in user-centric models,” in Inter- national Symposium On Leveraging Applications of Formal Methods, Verifi- cation and Validation, 490–502, Springer, 2008, doi:https://doi.org/10.1007/ 978-3-540-88479-8 35.
29. S. Sharma, N. Hasteer, “A comprehensive study on state of Scrum development,” in 2016 International Conference on Computing, Communication and Automa- tion (ICCCA), 867–872, IEEE, 2016, doi:10.1109/CCAA.2016.7813837.
30. S. Saay, A. Norta, “Designing a Scalable Socio-Technical Method for Evalu- ating Large e-Governance Systems,” in Advanced Computational and Com- munication Paradigms, 571–580, Springer, 2018, doi:https://doi.org/10.1007/ 978-981-10-8240-5 64.
31. D. Renzel, M. Behrendt, R. Klamma, M. Jarke, “Requirements bazaar: So- cial requirements engineering for community-driven innovation,” in 2013 21st IEEE International Requirements Engineering Conference (RE), 326–327, IEEE, 2013, doi:doi:10.1109/RE.2013.6636738.
32. S. Saay, T. Margaria, “Model-Driven-Design of NREn Bridging Applica- tion: Case Study AfgREN,” in 2020 IEEE 44th Annual Computers, Soft- ware, and Applications Conference (COMPSAC), 1522–1527, IEEE, 2020, doi:doi:10.1109/COMPSAC48688.2020.00-39.
33. T. Margaria, B. Steffen, “eXtreme Model-Driven Development (XMDD) Tech- nologies as a Hands-On Approach to Software Development Without Coding,” Encyclopedia of Education and Information Technologies, 732–750, 2020, doi:https://doi.org/10.1007/978-3-030-10576-1.
34. T. Margaria, B. Steffen, “Service-orientation: conquering complexity with XMDD,” in Conquering Complexity, 217–236, Springer, 2012, doi:https:
    //doi.org/10.1007/978-1-4471-2297-5 10.
35. S. Boßelmann, M. Frohme, D. Kopetzki, M. Lybecait, S. Naujokat, J. Neubauer, D. Wirkner, P. Zweihoff, B. Steffen, “DIME: a programming-less mod- eling environment for web applications,” in International Symposium on Leveraging Applications of Formal Methods, 809–832, Springer, 2016, doi: https://doi.org/10.1007.
36. J. Neubauer, M. Frohme, B. Steffen, T. Margaria, “Prototype-driven devel- opment of web applications with DyWA,” in International Symposium On Leveraging Applications of Formal Methods, Verification and Validation, 56– 72, Springer, 2014, doi:https://doi.org/10.1007/978-3-662-45234-9 5.
37. N. Moreno, P. Fraternali, A. Vallecillo, “WebML modelling in UML,” IET software, 1(3), 67–80, 2007, doi:10.1049/iet-sen:20060067.
38. T. Margaria, A. Schieweck, “The Digital Thread in Industry 4.0,” in Inter- national Conference on Integrated Formal Methods, 3–24, Springer, 2019, doi:https://doi.org/10.1007/978-3-030-34968-4 1.
39. S. Jo¨rges, A.-L. Lamprecht, T. Margaria, I. Schaefer, B. Steffen, “A constraint- based variability modeling framework,” International Journal on Software Tools for Technology Transfer, 14(5), 511–530, 2012, doi:https://doi.org/10. 1007/s10009-012-0254-x.
40. M. Karusseit, T. Margaria, “Feature-based modelling of a complex, online- reconfigurable decision support service,” Electronic Notes in Theoretical Com- puter Science, 157(2), 101–118, 2006, doi:https://doi.org/10.1016/j.entcs.2005. 12.049.
41. M. Kircher, P. Jain, Pattern-oriented software architecture, patterns for resource management, volume 3, John Wiley & Sons, 2013.
42. A. Patwardhan, R. Patwardhan, S. Vartak, “Self-Contained Cross-Cutting Pipeline Software Architecture,” arXiv preprint arXiv:1606.07991, 2016, doi: arXiv:1606.07991v1.
43. O. Kaiwartya, A. H. Abdullah, Y. Cao, A. Altameem, M. Prasad, C.-T. Lin, X. Liu, “Internet of vehicles: Motivation, layered architecture, network model, challenges, and future aspects,” IEEE Access, doi:doi:10.1109/ACCESS.2016. 2603219.
44. M. Richards, Software architecture patterns, volume 4, O’Reilly Media, Incorighway North, Sebastopol, CA . . . , 2015.
45. O.-A. Schipor, R.-D. Vatavu, J. Vanderdonckt, “Euphoria: A Scalable, event- driven architecture for designing interactions across heterogeneous devices in smart environments,” Information and Software Technology, 109, 43–59, 2019, doi:https://doi.org/10.1016/j.infsof.2019.01.006.
46. A. Balalaie, A. Heydarnoori, P. Jamshidi, “Microservices architecture enables devops,” London: Sharif University of Technology, 2014.
47. N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Mazzara, F. Montesi, R. Mustafin, L. Safina, “Microservices: yesterday, today, and tomorrow,” Present and ulterior software engineering, 195–216, 2017, doi:https://doi.org/ 10.1007/978-3-319-67425-4 12.
48. F. J. Garc´ia-Pen˜alvo, J. Cruz-Benito, C. Maderuelo, J. S. Pe´rez-Blanco, Mart´in-Sua´rez, “Usalpharma: A cloud-based architecture to support Quality Assurance training processes in health area using Virtual Worlds,” The Scien- tific World Journal, 2014, 2014, doi:https://doi.org/10.1155/2014/659364.
49. S. Saay, “A Reference Architecture for A National E-Learning Infrastructure,” in Ph.D Thesis, 20–80, Tallinn University, 2018.
50. L. Chen, “Microservices: architecting for continuous delivery and DevOps,” in 2018 IEEE International conference on software architecture (ICSA), 39–397, IEEE, 2018, doi:doi:10.1109/ICSA.2018.00013.
51. S. Saay, A. Norta, M. Laanpere, “Towards an architecture for e-learning infrastructures on a national level: a case study of AfgREN,” in Interna- tional Conference on Web-Based Learning, 98–107, Springer, 2015, doi: https://doi.org/10.1007/978-3-319-32865-2 11.
52. M. Karusseit, T. Margaria, “Feature-based modelling of a complex, online- reconfigurable decision support service,” Electronic Notes in Theoretical Com-
    puter Science, 157(2), 101–118, 2006, doi:https://doi.org/10.1016/j.entcs.2005.12.049.
53. G. Jung, T. Margaria, R. Nagel, W. Schubert, B. Steffen, H. Voigt, “SCA and jABC: Bringing a service-oriented paradigm to web-service construc- tion,” in International Symposium On Leveraging Applications of Formal Methods, Verification and Validation, 139–154, Springer, 2008, doi:https://doi.org/10.1007/978-3-540-88479-8 11.
54. T. Margaria, “Components, Features, and Agents in the ABC,” in Objects, Agents, and Features, 154–174, Springer, 2004, doi:https://doi.org/10.1007/ 978-3-540-25930-5 10.
55. T. Margaria, B. Steffen, M. Reitenspieß, “Service-oriented design: the roots,” in International Conference on Service-Oriented Computing, 450–464, Springer, 2005, doi:https://doi.org/10.1007/11596141 34.
56. J. Neubauer, B. Steffen, T. Margaria, “Higher-order process modeling: product- lining, variability modeling and beyond,” arXiv preprint arXiv:1309.5143, 2013, doi:,doi:10.4204/EPTCS.129.1.
57. A. Norta, P. Grefen, N. C. Narendra, “A reference architecture for managing dynamic inter-organizational business processes,” Data & Knowledge Engi- neering, 91, 52–89, 2014, doi:https://doi.org/10.1016/j.datak.2014.04.001.
58. S. Boßelmann, A. Wickert, A.-L. Lamprecht, T. Margaria, “Modeling directly executable processes for healthcare professionals with xmdd,” in Service Busi- ness Model Innovation in Healthcare and Hospital Management, 213–232, Springer, 2017, doi:https://doi.org/10.1007/978-3-319-46412-1 12.
59. F. Marchioni, WildFly Administration Guide: The ultimate and most up-to-date appication server, ITBuzzPress, 2020.

(Click Here)