SOFTWARE – PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2012; 42:1229–1246 Published online 30 September 2011 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/spe.1130
Architecture of a multiplatform virtual campus Antonio Navarro1, * ,† , Jesús Cristóbal2 , Carmen Fernández-Chamizo1 and Alfredo Fernández-Valmayor1 1 Departamento 2 Unidad
de Ingeniería del Software e Inteligencia Artificial, Universidad Complutense de Madrid de Apoyo Técnico y Docente al Campus Virtual de la Universidad Complutense de Madrid
SUMMARY The design, development and maintenance of large virtual campuses are complex issues. This paper describes the architecture of a large university multiplatform virtual campus. Because we have not found virtual campus architectures described in the literature, the goal of this paper is to make our experience available to a wider audience so that organizations interested in the deployment of a large virtual campus can take advantage of our work. Thus, this paper analyzes this architecture from three different points of view: (i) software architecture; (ii) detailed software design; and (iii) hardware architecture. Copyright © 2011 John Wiley & Sons, Ltd. Received 20 July 2011; Revised 5 September 2011; Accepted 5 September 2011 KEY WORDS:
e-learning; integration; LMS, WebCT; Moodle; Sakai; Blackboard
1. INTRODUCTION The use of information and communication technologies (ICT) in education has been a focus of interest for the education community for years [1]. At present, the use of ICT in education is usually denoted by electronic-learning or e-learning [2], which has become a key factor in the success of universities and higher education institutions [1, 3–6]. Thus, traditional universities are evolving, totally or partially, into virtual universities, which offer their courses in e-learning format [7, 8]. This situation has promoted the appearance of virtual campuses: ‘The virtual campus is a metaphor for the electronic teaching, learning and research environment created by the convergence of several relatively new technologies including, but not restricted to, the Internet, World Wide Web, computer-mediated communication, video conferencing, multimedia, groupware, videoon-demand, desktop publishing, intelligent tutoring systems, and virtual reality.’ [9]. In more recent studies [7, 10–12] virtual campuses are understood, in a broader sense, to be the integration of ICT in terms of both educational and organizational university settings. In this paper, virtual campuses are considered to be those software systems that higher education institutions use to give support to their teaching and learning activities [6]. The Universidad Complutense de Madrid (UCM) is an old university, founded in 1499, and is currently the largest nonopen university in Spain. In the academic year 2009–2010 there were 85,500 students and 6200 lecturers. The 26 faculties of the UCM teach 65 first degree programmes and 105 master’s and doctorate programmes. Today, like many other universities, the UCM is making a major effort to introduce modern e-learning technologies to improve its educational processes. In the academic year 2003–2004 the UCM Virtual Campus (UCM VC) [13] was set up. The main objective of the project was to make available to students and lecturers all the support that modern *Correspondence to: Antonio Navarro, Departamento de Ingeniería del Software e Inteligencia Artificial, Universidad Complutense de Madrid, Spain. † E-mail:
[email protected] Copyright © 2011 John Wiley & Sons, Ltd.
1230
A. NAVARRO ET AL.
information and communication technologies can provide to improve the quality of learning and research activity at the university [14]. The UCM VC includes the management of students enrolled in courses, the management of the content of courses and facilities for cooperation and communication: work groups, chats, forums, etc. The UCM VC has seen a considerable growth in the number of users since its introduction. Thus, in the academic year 2003–2004, a testing year, only 3500 students, 200 lecturers and 90 courses were active. Academic year 2004–2005 was the first true active year of the UCM VC. In that year 19,000 students, 1100 lecturers and 1600 courses were active. From then, to academic year 2008–2009 the number of students and teachers grew at an approximate annual rate of 1.5 for users and 1.4 for courses. At present, the UCM VC has 81,000 students, 3900 lecturers and 5900 courses. In these years of operation UCM VC has had two different architectures, and a new architecture is planned. For years one of the main problems of the UCM VC has been the use of a single e-learning platform [15], or learning management system (LMS). The presence of different platforms allows better services to be provided for teachers, who can select the most appropriate e-learning platform for their teaching and research activities. However, the presence of three platforms forces the need for a more advanced architecture for virtual campuses [16]. The multiplatform architecture of the UCM VC is not a consequence of a transition process. During the initial years WebCT 4.1 [17] was the only e-learning platform available at the UCM VC. This situation had several drawbacks: (i) dependence on a specific e-learning platform, forcing the periodic renegotiation of financial conditions; (ii) before the introduction of the UCM VC (and WebCT 4.1, Blackboard, Washington, DC, USA) several lecturers, departments and other entities were using other LMSs, such as Moodle [18], a situation which persisted after the introduction of the UCM VC; (iii) a large number of users demanded the use of additional LMSs. Some of them argued the need for specific tools included in these LMSs, while others called for the use of open software. In academic year 2009–2010, the multiplatform virtual campus was deployed to mitigate these problems, and WebCT 4.1, Moodle 1.9 and Sakai 2.4 [19] were the three available LMSs in the UCM VC. In the UCM VC, lecturers can select any available LMS to support any of their courses. Thus, a lecturer could have an undergraduate course in Moodle, and a master’s course in Sakai. At present WebCT 4.1 is being removed from this architecture because of saturation problems, and only Moodle 1.9 and Sakai 2.4 are going to be maintained in the UCM VC, although, lecturers will still be able to access their WebCT-supported courses for a transition period. However, the future inclusion of Blackboard Learn 9.1 (Blackboard, Washington, DC, USA) [20] as an additional available LMS has not been ruled out. This paper describes the architecture of the UCM VC. The goal is to facilitate the work of those professionals involved in the development of large virtual campuses. In our opinion, a paper of this nature can be very useful because, at present, there is no literature about this issue, except [21], which does not include detailed descriptions of software or hardware architectures. There are also important conclusions regarding software engineering infrastructure in a large virtual campus that have been analyzed in [16], but this paper focuses only on software and hardware architecture. This paper is organized as follows: Section 2 describes the software architecture of the UCM VC. Section 3 describes the detailed design of the more characteristic elements of the UCM VC. Section 4 describes its hardware architecture. Finally, Section 5 presents conclusions and future work. Throughout the paper, UML 2 (OMG, Needham, Massachusetts, USA) [22] diagrams are extensively used to describe both software and hardware architecture.
2. SOFTWARE ARCHITECTURE OF THE UCM VIRTUAL CAMPUS The UCM VC is a complex system made up of four different applications: (i) several e-learning platforms, responsible for core e-learning facilities(e.g. content publication); (ii) a Java 2 Platform Enterprise Edition (J2EE) [23] data load application, responsible for transferring course and user data from the university management system to the virtual campus administration database; (iii) Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
ARCHITECTURE OF A MULTIPLATFORM VIRTUAL CAMPUS
1231
a J2EE administration application, responsible for administrative tasks (e.g. changing a password); and (iv) an integration page that provides a unified view of the courses virtualized in different LMSs. The e-learning platforms used in the UCM VC are: WebCT 4.1, Moodle 1.9 and Sakai 2.4. However, the detailed description of their architectures is outside the scope of this paper. The software architecture for the other applications that make up the UCM VC is described in terms of UML 2 components diagrams [22]. 2.1. Data load application The UCM stores data regarding students, courses, centers, etc., in a common database. However, for interchange and data warehouse purposes a data warehouse database is available. The description of the applications that transfer data from the central UCM database to the data warehouse facility is outside the scope of the UCM VC and, therefore, of this paper. However, we have developed the application that loads data from the data warehouse database to our Virtual Campus database. This database is used during the creation of courses in the e-learning platforms as well as during the enrolment of users for these platforms. Figure 1 describes the overall architecture for data loading. The data loading application is very simple because it is a converter for relational tables. However, its presence is a key aspect of the UCM VC. Direct access to the data warehouse facility could be provided, but from the beginning the UCM VC has had its own database. This approach has various advantages: (i) the UCM VC does not depend on an external UCM data warehouse facility; (ii) integration between common UCM data and specific VC data is facilitated; and (iii) the UCM database remains stable regardless of changes in the external UCM databases. However, it forces the daily loading of data from the UCM data warehouse to the virtual campus database. 2.2. Administration application The administration application takes care of the management of: (i) users in the different e-learning platforms, for example user enrolment or password change, and (ii) the management of the courses in the platforms, for example course creation in a specific platform. This application is thus basically divided into two subsystems: one responsible for user management and the other responsible for course management. Their architecture is very similar. Figure 2 depicts the architecture of the course management subsystem. Note that, according to Figure 2, this subsystem is a classic multitier subsystem [24]. Multitier architecture has been chosen because of its enhanced maintainability with respect to other architectures [24]. The most specific characteristic of this subsystem is the update of the e-learning platforms through a file text (components W updates, M updates and S updates) that informs an updater (components W updater, M updater and S updater) of the changes in every platform (e.g. course enrolment or user update). This updater runs on the same machine as the platform and searches for new updates each minute. This communication mechanism is needed because of the network access restrictions existing in the machines where the platform runs. This is a simple, old solution, which is being changed to a communication schema based on databases.
Figure 1. Overall architecture for data loading. The architecture for the UCM database and UCM data warehouse is enormously simplified. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
1232
A. NAVARRO ET AL.
Figure 2. Software architecture for the course management subsystem.
2.3. Platform integration application The UCM VC is a multiplatform tool built on several e-learning platforms. The suitability of these platforms to be part of an integrated architecture varies widely. WebCT 4.1 is an old application built using Perl scripts [25] and its integration capabilities are very limited. Moodle is newer, and has a good Application Programming Interface (API) for accessing its components. However, the presence of web services in Moodle is very limited. Finally, Sakai has a good API and a reasonable range of web services. Figure 3 depicts the software architecture for this application. In the case of Moodle and Sakai, specific components that use the APIs of both platforms have been developed (Moodle services and Sakai services components). These components work as REST web services [26]. They are invoked by the integration components of the application (MoodleConnectionImp and SakaiConnectionImp components) via Uniform Resource Locator (URL) (using a JAVA HttpURLConnection [26]) and they codify their answer in Extensible Markup Language (XML) format [27]. The presence of cookie-codified information between the clients and the invoked services hinders the full REST implementation of these services [26]. Note that Hypertext Markup Language (HTML) is a stateless protocol. There are three choices to preserve the users’ state while interacting with the virtual campus [28]: (i) cookie-based state; (ii) session-based state; or (iii) database-based state. The cookie-based state was chosen in this implementation. However, we are moving towards a database-based state to enhance security. Ultimately, the communication between the invoker and the services could be made via encrypted XML information. We have chosen the database-based solution because it avoids the need for coding/decoding the information. However, the database-based state preservation makes it difficult for our services to work effectively as REST web services. In the case of the WebCT platform, its own Perl scripts are used as a type of REST web service. The main problem in this case is that the response is directly processed from the HTML code included in the response provided by the Perl scripts. We have used this solution because of the obscurity of the WebCT code and the restrictions that WebCT imposes in the validation of users. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
ARCHITECTURE OF A MULTIPLATFORM VIRTUAL CAMPUS
1233
Figure 3. Software architecture for the platform integration subsystem.
Regarding security issues, in the cookie-based solution, the sensitive information is encrypted, and the cookie has a limited lifetime, preventing inappropriate use by hackers. In the databasebased solution, the sensitive information stored in the database is also codified, and access to it is restricted to internal UCM servers by Internet Protocol (IP) direction, preventing an external attack by hackers. Figure 4 depicts a screenshot of this integration application. Note that the courses belonging to different platforms are shown in a common screen (with single sign-on). 3. SOFTWARE DESIGN The components diagrams depicted in Section 2 give an overview of the architecture of the solution. This section focuses on the detailed design of the most characteristic elements of the UCM VC in terms of UML 2 class and sequence diagrams [22]. 3.1. Generic design As mentioned in Section 2, a multitier architecture was used in the design of the UCM VC. We tried to use a systematic design that is repeated from tier to tier. We did not use all the design patterns provided in the Core J2EE Design Patterns catalog [24]. Detailed reasons can be found in [16], but time restrictions and staff skills are the most significant of these. Figure 5 depicts the common design for the presentation tier. In this design the UML Web Application Extension (UML WAE) [28] was used. UML WAE is very useful for depicting the presentation tier of multitier applications [29]. In UML WAE, contents provided by the web server are called Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
1234
A. NAVARRO ET AL.
Figure 4. Screenshot for the integration subsystem.
Figure 5. Generic design for the presentation tier.
pages, which are represented by stereotyped classes. There are different types of pages: (i) static web pages, represented by the stereotype client page; (ii) forms, represented by the stereotype form; and (iii) computational processes running in the server (e.g. servlets [23]), represented by the stereotype server page. Navigational relationships between pages are represented by stereotyped navigated associations: (i) hyperlinks, represented by the stereotype link; (ii) data sending between forms and computational processes, represented by the stereotype submit; (iii) forwarding of control between computational processes, represented by the stereotype forward; and (iv) construction of static web pages by computational processes, represented by the stereotype build. In this implementation Struts 1.3 (The Apache Software Foundation) [30] is used with a mix of front and application controller [24]. Struts forms are depicted as context objects [24] in Figure 5, which depicts the generic design for the presentation tier. In our overall design, every action invokes Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
ARCHITECTURE OF A MULTIPLATFORM VIRTUAL CAMPUS
1235
its application service [24] via an interface. Its implementation is built using an abstract factory [31] to create it. Communication between layers is carried out using transfers [24]. In our application, no distributed business logic elements are present and a Plain Old Java Object (POJO) implementation of the application services has been chosen. Therefore, abstract factories and interfaces are enough to access them. Otherwise, business delegates [24] would have been used. Figure 6 depicts the generic design for the business tier. As in the case of the presentation tier, application services use elements of other packages isolated via interfaces and abstract factories. Note that in this application no business objects [24] have been implemented. The complexity of managing their dynamic references to other business objects, and of their persistence, manually using a domain store [24], or automatically using a persistence framework (e.g. EJB Persistence API [32]), led us to reject their use. Figure 7 depicts the generic design for the persistence tier. As in the other tiers, this tier follows the rules of a multitier architecture without any business objects. Although it has not been depicted in Figures 6 and 7, a transaction manager [24, 33] was implemented and used to guarantee the atomicity of transactions. Figure 8 depicts such a transaction manager. Note that, except for the classes MySQLTransaction and TransactionFactoryImp, the classes depicted in Figure 8 can be reused in different applications. The design follows the rules stated in [24, 33]. Thus, the class TransactionManager/TransactionManagerImp is a singleton [31] that stores the ongoing transactions in a ConcurrentHashMap using the execution Threads as indexing elements. Each concurrent client carries out put/get operations taking into account their own Thread of control as an indexing element of the ConcurrentHashMap. Therefore, different clients cannot carry out put/get operations on the same element of the ConcurrentHashMap. In any case, the use of a HashMap has been discarded to avoid theoretical problems with the management of key collisions in
Figure 6. Generic design for the business tier.
Figure 7. Generic design for the integration tier. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
1236
A. NAVARRO ET AL.
Figure 8. Management of transactions in the UCM VC.
HashMap inner implementation. If extra concurrent control is desired, synchronized blocks, or Collections.synchronizedMap(Map m) can be used. Both application services and Data Access Objects (DAOs) manage the transactions using the TransactionManager. Ultimately, an implementation of a Transaction holds a Java Database Connectivity (JDBC) Connection [23] for accessing the database and locking the necessary tables. In this transaction mechanism, the blocking behavior is delegated to the database locking mechanisms, because the database is accessed using a JDBC Connection, which allows table locking for queries that access the database using different Connections. All the applications services and DAOs involved in a transaction can access the transaction because they belong to the same thread. In our design, the TransactionManagerImp indexes Transactions by Threads. Thus, when an application service starts a new transaction, the TransactionManagerImp uses the thread where the calling application service is running to index the transaction. Later, when a DAO belonging to the same execution thread needs to access the transaction, the TransactionManagerImp uses the thread where the calling DAO is running to retrieve the transaction. In short: (i) Transactions hide the JDBC Connections that are used for accessing the database, which supports table locking; (ii) Transactions are started by application services and reused by DAOs (indeed, DAOs reuse the JDBC Connection that underlies the implementation of the Transaction interface); and (iii) all the participants in a transaction (application services and DAOs) access the same active Transaction because they belong to the same execution Thread and Transactions are indexed and retrieved by the TransactionManagerImp using these execution Threads. Therefore, this transaction manager can be reused in applications whose persistence does not rely on business objects or on persistence frameworks. Although there are very good implementations of the JAVA Transaction API [34], we have made our own implementation for productivity reasons. Our implementation is very simple (only comprising a few classes) and it was more productive to implement our classes than to use a framework (the staff had no experience with these frameworks). The overall design used in the UCM VC is based on multitier architecture [24] but in a simplified version, which has the maintainability and transactional benefits of a full multitier architecture, but without the drawbacks associated with its complexity. However, the lack of business objects lowers the abstraction level of the overall design. In any case, the long-standing rule of decomposing Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
ARCHITECTURE OF A MULTIPLATFORM VIRTUAL CAMPUS
1237
a system in highly cohesive and loosely coupled modules [22, 24] is easily implemented with this simplified multitier design. 3.2. Platform integration The design of the platform integration application that provides a uniform view of the courses that a user may have in different platforms (Figure 4) deserves a section. Figure 9 depicts the core of the design of this application. In this application, there is a director class (PlatformIntegrationImp) that orchestrates the process of extracting the contents (mainly courses) of the three e-learning platforms, as Figure 10 depicts. To launch concurrent processing, this class starts and joins three runnable classes that obtain information about every e-learning platform (WebCTInfoObtainer, MoodleInfoObtainer and SakaiInfoObtainer), as Figure 11 depicts for the Sakai case. Everyone of these classes uses a thread timer class (WebCTThreadTimer, MoodleThreadTimer and SakaiThreadTimer) that launches a class responsible for connecting with every platform and invoking the REST services using an HttpURLConnection (WebCTConnectionImp, MoodleConnectionImp, SakaiConnectionImp), as Figure 12 shows for the Sakai case (class HttpURLConnection is hidden in class SakaiConnection). This connection is made according to the REST invocation depicted in [26]. The classes PlatformIntegrationImp, the info obtainers, and the thread timers are business classes, while the connection classes are integration classes, which is why these classes are displayed via an interface. Sometimes the e-learning platforms are saturated and the behavior of the classes that use HttpURLConnections becomes unpredictable. Therefore, the classes that invoke RESTtype services are runnable classes (WebCTConnectionImp, MoodleConnectionImp,
Figure 9. Class diagram for the core classes of the platform integration application. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
1238
A. NAVARRO ET AL.
Figure 10. Initialization and joining of the business threads that obtain the information about each e-learning platform.
Figure 11. Initialization of the thread timer for Sakai and Sakai information storing.
SakaiConnectionImp) that have their own control thread. This thread is tested by the thread timer classes (WebCTThreadTimer, MoodleThreadTimer and SakaiThreadTimer). If after three tests performed during 6 seconds the class responsible for connecting with a platform using the HttpURLConnection does not respond, the HttpURLConnection is disconnected and the class remains, closing the connection in its own thread. The timer class responds to its info obtainer class, and the information belonging to that platform is not included. Experience has demonstrated that the overall process can be compromised by a temporary saturation problem in an e-learning platform. Note that the thread that executes the timer process cannot be waiting for a signal that the thread that connects to the platforms has completed its processing, because this thread can be engaged waiting for the response of a saturated platform and our solution precisely avoids having the whole integration application waiting for a single platform response. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
ARCHITECTURE OF A MULTIPLATFORM VIRTUAL CAMPUS
1239
Figure 12. Sakai’s thread timer sleeps and awakes waiting for Sakai’s response. If obtained, it is read and stored in a StringBuffer.
A solution based on changing the response timeout in the servers was not chosen because these servers also interact with humans, and the timeout for humans (which are not waiting for the composition of the responses of three platforms) can be larger than for the integration infrastructure. In any case, it is very important that only those platforms where users have courses be requested to provide course information. Otherwise, e-learning platforms are exposed to unnecessary requests that can compromise their performance. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
1240
A. NAVARRO ET AL.
Finally, all the information is stored in a common class (PlatformInformation) that is used to generate the integrated view of the courses that a user can have in different e-learning platforms, as Figure 4 depicts. Event-driven architecture (EDA) could have been used for the central application to communicate with LMSs. In the context of enterprise applications with distributed systems concurrently accessed, EDA is usually implemented as a group of event senders that send messages to event listeners. These listeners receive state change data (events) and pass them along to event dispatchers, which then activate processes that depend on the nature of the triggering events [35]. The main advantages of EDA are loose coupling and asynchronous communication between message senders and receivers. EDA has not been used in the UCM VC architecture, mainly because synchronous communication is needed between the central application and the LMSs, although LMSs may be saturated and the central application may have to close communication with these LMSs. Therefore, an EDA solution would have forced the presence of event listeners at both sides of the solution (central application and LMSs). In addition, the EDA processes responsible for the interaction with the saturated LMSs may have the same problems as the web services that interact with the LMSs in the present architecture. Therefore, some type of time control should be imposed on these processes, as it is imposed at present on the central application that invokes web services. In addition EDA needs the support of a framework for message-driven programming, or other technologies for implementing an EDA bus [35], which represents the presence of an additional programming framework. Therefore, we have decided to use a REST-based web service implementation because of its greater simplicity. 3.3. Virtual campus database The UCM VC database is a large database with more than 70 tables. Its full description is thus outside the scope of this paper. However, in this paper we mention the most characteristic part of this database – the part responsible for course management. In the original model, a course had different groups and therefore the group was the teaching element that had its counterpart in the virtual campus (Figure 13(a)). In the present model, a course has different activities (e.g. theory and practical work), with different groups for each activity (Figure 13(b)). This leads to a ternary relationship that has to be split into three binary relationships (Figure 13(c)), plus some additional constraints (e.g. the existence of a group in the same course linked to the same activity). Because the virtual campus administration database takes into account current courses and former courses belonging to a previous architecture of the virtual campus, an entity called VCPotentialSpace is used to bring together the different types of space that can be virtualized in the UCM virtual campus. Figure 13(d) depicts the relational version of this entity, and its relationship with the new courses depicted in Figures 13(b) and (c). Some of the seven different spaces that can be virtualized in the UCM VC have been omitted for the sake of conciseness in Figure 13(d). It is important to note that this database is used by the applications that comprise the UCM VC for checking the users and their courses. The core e-learning information managed by the LMSs remains stored in LMS databases. Therefore, there is no problem in using a common representation format for the different information stored in every LMS, because only simple LMS-related data such as the course identifier, or the platform where a course has been created, is stored in the UCM VC database. The UCM VC database has more than 70 tables because the information about courses that the UCM manages is very complex, and this database stores information about the UCM courses. Thus, the UCM VC database stores information about UCM centers, curricula, student enrolments, etc. This information is not used in the LCMs, but it is necessary for the correct management of the UCM VC. 4. HARDWARE ARCHITECTURE This section focuses on the hardware architecture of the UCM VC and the assignation of the components that make up the software architecture to execution nodes. This information is presented using UML 2 deployment diagrams [22]. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
ARCHITECTURE OF A MULTIPLATFORM VIRTUAL CAMPUS
(0, n)
1241
(1,1)
Group
Course
(a) Original relationship
(1, n)
Course
(1,1)
C_A_G
(1, 1)
(1,n)
Activity
(1,1) (1, n)
(1, 1)
Course
Activity (1, n)
(1, n)
Group
Group (b) Present relationship
(c) Implementation of the present relationship
(d) CASE tool diagram for the new relationship, including table VCPotentialSpace
Figure 13. Different conceptions of courses. (a) UCM VC original conception; (b) UCM VC present conception; (c) implementation of the present conception; and (d) relations diagram for the present conception, including the VCPotentialSpace table, which brings together different courses that can be virtualized in the virtual campus. The other spaces have been omitted for the sake of conciseness.
4.1. Data load application The hardware architecture that supports both the UCM database and its data warehouse is huge and outside the scope of this paper. Figure 14 depicts a simplified version of the hardware that supports the data load application. The only points to be noted in this architecture are the use of MySQL 5.1 (Oracle Corporation, Redwood Shores, California, USA) as database server [36] in the virtual campus and the J2EE implementation of the data load application. 4.2. Administration application The administration application responsible for course and user management has a more complex architecture than the database server. Figure 15 depicts this architecture. As shown in Figure 15, this architecture relies heavily on VMware virtual machines (VMware Inc., Palo Alto, California, USA) [37]. In this architecture the UCM web server is based on Sun UltraSPARC III (Oracle Corporation, Redwood Shores, California, USA) architecture [38], with four processors running at 1.2 GHz, 16 GB RAM and 160 GB of hard disk. This server has two additional hardware devices: an SSL accelerator Radware CT-100 (Radware, Inc., Mahwah, NJ, USA) [39] for enhancing the performance of SSL connections, and a load balancer Radware AppDirector 1016 (Radware, Inc., Mahwah, NJ, USA) [39]. This balancer redirects the requests to two servers that hold four instances of Apache Tomcat (The Apache Software Foundation) [40]. These servers have two processors, 2 GB of RAM and 30 GB of hard disk. In both servers, the J2EE application of the virtual campus is deployed. Regarding the e-learning platforms, every platform has its own hardware architecture. WebCT runs on its own server with powerful hardware infrastructure: eight UltraSPARC III processors at Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
1242
A. NAVARRO ET AL.
Figure 14. Simplified version of the hardware architecture involved in the data load application.
1.2 GHz, 34 GB RAM and 2.4 TB of hard disk. Moodle is deployed on four servers accessed by a load balancer and an SSL accelerator. Each server has four processors, 4 GB RAM and 420 GB of hard disk. Finally, Sakai runs on a server with two processors, 4 GB RAM and 25 GB of hard disk. The hardware infrastructure of the virtual campus server has been designed and tested to support between 600 and 800 concurrent users. It is worth mentioning that WebCT and Moodle have better hardware infrastructure than Sakai (including fault tolerance resources). This is why, at present, they are the main platforms in the UCM VC. However, in the near future WebCT is to be replaced by Sakai. This change will force a redistribution of the hardware architecture in the UCM VC. 4.3. Platform integration application The hardware architecture for this application is the same as the architecture for the administrative application. The most notable feature is the assignation of components to execution nodes. Figure 16 depicts this assignation. 5. CONCLUSIONS AND FUTURE WORK A multiplatform virtual campus has been developed in the UCM in response to the requirements of users, who wanted the best platform for their respective teaching needs. However, the presence of different platforms has forced us to develop an advanced architecture in the UCM VC. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
ARCHITECTURE OF A MULTIPLATFORM VIRTUAL CAMPUS
1243
Figure 15. Deployment diagram for the course management subsystem.
This paper describes the solution developed to deal with this problem in the UCM VC. There are several important conclusions that we have drawn from our experience and these may prove useful for others. Thus, the multitier architecture has been chosen because of its maintainability, which has been successfully tested during these years in the UCM VC. The presence of a specific database for the UCM VC has had important advantages, isolating our system from the problems of other databases used in our university. However, its presence forces the daily loading of data from the data warehouse database to the UCM VC database. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
1244
A. NAVARRO ET AL.
Figure 16. Deployment diagram for the integration application.
The use of REST-based web services is very simple. Indeed, programmers were unaware of the use of this philosophy in the implementation of the UCM VC. These services are simpler than Simple Object Access Protocol (SOAP)-based services [26]. In the case of our implementation, because these services are interacting with web platforms that can be saturated at some moments, their invocation using an HttpURLConnection can be problematic. We have found a thread-based solution that can be easily implemented in J2EE, but that other languages such as PHP could not implement in a straightforward way. However, a SOAP-based solution would not solve the problem. These services interact with elearning platforms whose network performance and response can be unpredictable under heavy load. Because the integration application depends on the response of three e-learning platforms, the whole integration process cannot be waiting for a single platform to respond. Note that this response is totally independent of the invocation protocol of the services that interact with the learning platform. Therefore, in our opinion, a SOAP-based solution would need to be based on the same threaded solution. Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
ARCHITECTURE OF A MULTIPLATFORM VIRTUAL CAMPUS
1245
A solution based on changing the response timeout in the servers is not a choice because these servers also interact with humans, and the timeout for humans (which are not waiting for the composition of the responses of three platforms) can be larger than for the integration infrastructure. An EDA-based solution was not chosen because of its greater complexity. Multitier architecture is a powerful tool that improves system maintainability. However, full multitier architecture can impose major restrictions on the complexity of a software project. In the UCM VC we have implemented a simplified version of this architecture that allows us to design a system that can be broken down into highly cohesive and loosely coupled modules. Although the solution’s level of abstraction is not as great as that of solutions based on business objects, all the maintainability and transactional benefits of the multitier architecture have been achieved. Thus, during the initial deployment of the UCM VC there were several problems because of LMS (WebCT 4.1) overload but the use of a transaction manager that allowed the rollback of LMS-related transactions avoided a number of serious consistency problems with the database. Our transaction manager is a simple, but powerful, class, reusable in different web applications, and not tied to the presence of business objects or specific persistence frameworks. Regarding hardware architecture, the UCM VC has substantial hardware architecture, compared with that of other Spanish virtual campuses. The request balancer is very useful, but our experience tells us that it has to be well configured to avoid problems with the user’s sessions. Apart from the need for powerful hardware architecture, software configuration is a fundamental issue. WebCT is going to be removed from the UCM VC architecture because, although the capacity of the hardware where it is deployed is not used intensively, the response of the machine is not good. WebCT was designed to support far fewer than the present number of users and its behavior has consequently become somewhat unpredictable. It is well worth mentioning that an important drawback in the organization of the UCM VC is the management of the machines by the UCM systems department. This leads to configuration and availability problems because in most cases these machines cannot be configured by the team responsible for software development. However, this is an organizational issue, independent of software and hardware architectures. Future work involves the development of an architecture based on the isolation of the e-learning platforms using SOAP-based web services. User validation using Lightweight Directory Access Protocol (LDAP) [41], and the inclusion of Blackboard Learn 9.1 as a new e-learning platform are additional goals.
ACKNOWLEDGEMENTS
The Ministerio de Ciencia e Innovación (project AACV TIN2009-14317-C03-01), and the Universidad Complutense de Madrid (group 921340) have supported this work.
REFERENCES 1. Guri-Rosenblit S. Eight Paradoxes in the Implementation Process of E-learning in Higher Education. Higher Education Policy; 18:5–29. 2. Kaplan-Leison E. ASTD Learning Circuits. Glossary http://www.learningcircuits.org/glossary, 2009. 3. Instructional Technology Council, ITC. 2008 Distance Education Survey Results. http://www.itcnetwork.org/file. php?file=%2F1%2FITCAnnualSurveyMarch2009Final.pdf. 4. Leidner DE, Jarvenpaa SL. The use of information technology to enhance management school education: a theoretical view. MIS Quarterly; 19(3):265–291. 5. Neville K, Heavin C, Walsh E. A Case in Customizing E-Learning. Journal of Information Technology; 20(2): 117–129. 6. Yábar JM, Hernández J, López Roldán P, Castellá J. The UAB Virtual Campus: An Essential Platform for a European Higher Education Environment. Journal of Cases on Information Technology; 9(2):37–48. 7. PLS RAMBOLL. Studies in the Context of the E-learning Initiative: Virtual Models of European Universities http://www.elearningeuropa.info/extras/pdf/virtual_models.pdf. 2004. 8. Whittington CD, Sclater N. Building and Testing a Virtual University. Computers and Education; 30(1-2):41–47. 9. Van Dusen GC. The Virtual Campus: Technology and Reform in Higher Education. ASHE-ERIC Higher Education Report. 25(5). Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
1246
A. NAVARRO ET AL.
10. Allison DH, DeBlois PB, the EDUCAUSE Current Issues Committee. Current IT Issues Survey Report. EDUCAUSE Quarterly 2008; 31(2) http://www.educause.edu/ir/library/pdf/eqm0823.pdf. 11. Epper RM, Garn M. The Virtual University in America: Lessons from Research and Experience. EDUCAUSE Centre for Applied Research (ECAR) Research Bulletin; 2004(2) http://www.educause.edu/ir/library/pdf/ERB0402.pdf. 12. Green KC. The 2005 National Survey of IT in U.S. High. Education: Growing Campus Concern about IT Security; Slow Progress on IT Disaster Planning, http://www.campuscomputing.net, 2005. 13. UCM Virtual Campus, https://www.ucm.es/campusvirtual. 14. Navarro A, Fernández-Valmayor A. Conceptualization of Hybrid Websites. Internet Research; 17(2):207–228. 15. Navarro A, Cristóbal J, Fernández-Valmayor A, Fernández C, Hernanz C, Guillomía S, Buendía F. Towards a New Generation of Virtual Campuses. Advanced International Conference on Telecommunications 2010, 2010. 16. Cristóbal J, Merino J, Navarro A, Peralta M, Roldán Y, Silveira RM. Software engineering infrastructure in a large virtual campus. Interactive Technology and Smart Education, in press. 17. Wikipedia. WebCT, http://en.wikipedia.org/wiki/WebCT. 18. Rice W. Moodle 1.9 E-Learning Course Development: A Complete Guide to Successful Learning Using Moodle. Packt Publishing: Birmingham, 2008. 19. Berg A, Korcuscka M. The Official Sakai Handbook: Creating Content, Installing, and Using the Open Source Learning Management System. John Wiley and Sons: Hoboken, 2009. 20. Southworth H, Cakici K, Vovides Y, Zvacek S. Blackboard for Dummies. For Dummies: Hoboken, 2006. 21. Michiels E, Widya I, Volman C, Pokraev S, De Diana I. On the Enterprise Modelling of an Educational Information Infrastructure. Technical Report TR-CTIT-00-18, Centre for Telematics and Information Technology, University of Twente, Enschede, http://www.ub.utwente.nl/webdocs/ctit/1/0000002f.pdf. 22. Arlow J, Neustadt I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design, 2nd edition. Addison-Wesley Professional: Upper Saddle River, 2005. 23. Weaver JL, Mukhar K, Crume JP. Beginning J2EE 1.4: From Novice to Professional. Apress, New York City, 2004. 24. Alur D, Crupi J, Malks D. Core J2EE Patterns: Best Practices and Design Strategies, 2nd edition. Prentice Hall/Sun Microsystems Press: Palo Alto, 2003. 25. Schwartz R, Phoenix T, Foy BD. Learning Perl, 5th edition. O’Reilly Media: Sebastopol, CA, 2008. 26. Hansen MD. SOA Using Java Web Services. Prentice Hall: Upper Saddle River, 2007. 27. W3C Extensible Markup Language (XML) 1.0, Fifth Edition, 2008, http://www.w3.org/TR/2008/REC-xml20081126/. 28. Conallen J. Building Web Applications with UML, 2nd Edition. Addison-Wesley: Boston, 2002. 29. Navarro A, Fernández-Valmayor A, Fernández-Manjón B, Sierra JL. Characterizing navigation maps for web applications with the NMM approach. Science of Computer Programming 2008; 71(1):1–16. 30. Goodwill J, Hightower R. Professional Jakarta Struts. Wrox Press, 2003. 31. Gamma E, Helm R, Johnson R, Vlissides JM. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1994. 32. Rubinger AL, Burke B. Enterprise JavaBeans 3.1, 6th edition. O’Reilly Media, 2010. 33. Fowler M. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002. 34. Oracle Java Transaction API, JTA, http://www.oracle.com/technetwork/java/javaee/jta/index.html, 2011. 35. Taylor H, Yochem A, Philips L, Martinez F. Event-Driven Architecture: How SOA Enables the Real-Time Enterprise. Addison-Wesley Professional, 2009. 36. Dubois P. MYSQL, 4th edition. Addison-Wesley Professional, 2008. 37. Lowe S. Mastering VMware vSphere 4. Sybex, 2009. 38. Sun UltraSPARC, http://www.sun.com/products/microelectronics/products.jsp. 39. radware, http://www.radware.com/. 40. Chopra V, Li S, Genender J. Professional Apache Tomcat 6. Wrox Press, 2007. 41. Carter G. LDAP System Administration. O’Reilly, 2003.
Copyright © 2011 John Wiley & Sons, Ltd.
Softw. Pract. Exper. 2012; 42:1229–1246 DOI: 10.1002/spe
