discover d3.2technical specification for discover platform...

D 3.2 Technical Specification for the DISCOVER platform Revision: 1.6 Authors: Dani Blanco (CETEMMSA)

Project co‐funded by the European Commission within the ICT Policy Support Programme

Dissemination Level

P Public

C Confidential, only for members of the consortium and the Commission Services

DELIVERABLE

Project Acronym: DISCOVER Grant Agreement Number: 297268 Project Title: Digital Inclusion Skills for Carers bringing Opportunities Value and Excellence

of 37

Revision History and Statement of Originality

Revision History

Revision Date Organization Description #1.0 03rd September 2012 CETEMMSA Technical specification for DISCOVER platform #1.1 18th September 2012 CETEMMSA Draft deliverable circulation #1.2 20th September 2012 CETEMMSA Deliverable completion and corrections #1.3 21st September 2012 CETEMMSA Second draft circulation for contributions #1.4 24th September 2012 CETEMMSA Adding partners contributions #1.5 25th September 2012 CETEMMSA Final draft circulation #1.6 26th September 2012 CETEMMSA Final contributions

Statement of originality: This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

of 37

Table of Content

REVISION HISTORY AND STATEMENT OF ORIGINALITY 2 TABLE OF CONTENT 3 TABLE OF FIGURES 4 EXECUTIVE SUMMARY 5 1. INTRODUCTION 6 1.1 OBJECTIVES 6 1.2 PURPOSE 6 1.3 STRUCTURE 6 1.4 INTENDED AUDIENCE 7 2. GENERAL HARDWARE SPECIFICATION AND NETWORK DISTRIBUTION 8 2.1 OVERALL APPROACH 8 2.2 SERVER HARDWARE SPECIFICATION 8 2.3 USER NUMBER PREDICTION AND TRAFFIC LOAD 9 2.4 HYPOTHETICAL DEPLOYMENT SCENARIO: NETWORK ARCHITECTURE 9 3. SPECIFICATION OF DISCOVER PLATFORM UNDERLYING COMPONENTS 12 3.1 INTRODUCTION 12 3.2 OPERATING SYSTEM 12 3.3 ADMINISTRATION AND VIRTUALIZATION TOOLS 13 3.3.1 XEN 14 3.3.2 RAID SYSTEM 15 3.4 DISCOVER PLATFORM UNDERLYING COMPONENTS 16 3.4.1 MYSQL DATABASE ENGINE 16 3.4.2 APACHE WEB SERVER 17 4. SPECIFICATION OF DISCOVER PLATFORM COMPONENTS 20 4.1. INTRODUCTION 20 4.2. MOODLE 21 4.3. MAHARA 24 4.4. CUSTOMIZATION SPECIFICATION 25 4.5. SPECIFICATION OF THE INTEGRATION OF MOODLE & MAHARA 29 4.5.1 MOODLE AND MAHARA REQUIREMENTS FOR INTEGRATION 29 4.6. MOODLE MODULES SPECIFICATION 34 4.7. SPECIFICATION OF THE INTEGRATION OF DRUPAL WEBSITE & MOODLE PLATFORM 35 4.7.1 MOODLE INTEGRATION MODULE V.6‐X‐2.3 36 4.7.2 QAPI 36 4.8. ACCESS DEVICES 37

of 37

Table of Figures

FIGURE 1 - SCENARIO CONFIGURATION AND NETWORK ARCHITECTURE 10 FIGURE 2 – DISCOVER PLATFORM LAYER STACK 20 FIGURE 3 – COMMUNICATION BETWEEN LEARNING MANAGEMENT SYSTEM

(LMS) AND SHARABLE CONTENT OBJECT (SCO) 24 FIGURE 4 - POSSIBLE LOOK FOR DISCOVER PLATFORM 26 FIGURE 5 – LOOK OF THE DISCOVER PROJECT WEBSITE 27 FIGURE 6 – DRUPAL THEMES DIAGRAM 28 FIGURE 7 – MOODLE NETWORKING SETTINGS 30 FIGURE 8 – MOODLE NETWORKING SETTINGS 31 FIGURE 9 – MAHARA INSTITUTIONS ADMINISTRATION 32 FIGURE 10 – MAHARA INSTITUTIONS ADMINISTRATION 33 FIGURE 11 – MANAGING OF MOODLE PEERS 33 FIGURE 12 – MOODLE/MAHARA COMMUNICATION 34 FIGURE 13 – MOODLE/DRUPAL WEBSITE COMMUNICATION 36 FIGURE 14 – DISCOVER SINGLE ENTRY POINT SPECIFICATION 37

of 37

Executive Summary

As a first step before starting the actual development a technical specification for the design and further development of DISCOVER platform needs to be defined. This is, where possible, built on user requirements and needs. Accordingly, this document will define the underlying platform from which all DISCOVER services and content will be offered. Additional local systems will be integrated and offered as services to the platform users later on. The DISCOVER platform technical specifications will describe the server configuration needed to deal with aspects such as load and balance control; the services needed to maintain the platform (database engines, application servers, etc...) and all components needed to build the DISCOVER platform (essentially the integration of the e‐learning system Moodle with the portfolio Mahara); as well as any other basic tools, modules or components selected to provide useful tools to the platform environment to be developed.

of 37

1. Introduction

1.1 Objectives

To define the DISCOVER platform technical specification for its design and further development. This covers all the basic aspects of server configuration to host DISCOVER services, definition of the support services required to run the DISCOVER platform as well as defining its own components that configure the base of the DISCOVER platform with its related tools or modules, and how this integration will be performed. This deliverable is closely related to “D3.3 Technical specification of local systems” and can be considered as the first part of two of the complete specification of the DISCOVER system.

1.2 Purpose

The purpose of this deliverable is to consolidate the DISCOVER platform technical specification. The selection of the involved components, tools or modules that will form the basic structure of the DISCOVER platform will be done according to the previously defined user requirements and needs. This document will describe these components, how they fit and are integrated together, the underlying services needed to support the DISCOVER platform or the optimal server configuration according to the expected traffic load, users, etc... Apart from these components specification, the service will be tested before its release to real users to ensure the best performance.

1.3 Structure

This deliverable is structured in three main chapters according to the three main aspects of the DISCOVER platform.

First, chapter 1 will define the hardware requirements in order to assure the best performance on the future deployment of the DISCOVER platform. This section will take care of the server/s hardware requirements. A study of the expected number of users of the DISCOVER services and predicted traffic load will result in load/traffic balancing during deployment if required.

In chapter 2, an overview of the tools, components or services needed to develop the DISCOVER platform will be defined. Basically, an operating system running on the servers will be used to host the DISCOVER platform. Over it, some other auxiliary services or components will be needed: application servers, database engines, administration tools, etc... For each relevant component a specification table with the most important features, characteristics and the version used will be shown.

Finally, chapter 3 will address the specification of the components of the DISCOVER platform. The basic platform will be formed of essentially the integration of the Moodle e‐learning platform and the Mahara portfolio. Both will be integrated and then customized according to user requirements and needs. This chapter explains how these components will be customized and integrated, which other components or modules will be integrated within the platform and how the users will access the DISCOVER services.

of 37

1.4 Intended audience

This deliverable is aimed at internal use by the consortium, especially by the technical personnel that will be involved in the technical definition of the DISCOVER platform, its design and further development. Together with the second part of the specification (which will be described in D3.3) related to the local systems, this document intends to be the complete technical specification for the DISCOVER system.

of 37

2. General hardware specification and network distribution

2.1 Overall approach

This chapter focuses on the system requirements specification regarding the underlying layer of the system to be deployed, that is the basic hardware requirements to ensure an optimal performance of the DISCOVER services in an hypothetical deployment scenario.

Firstly, the characteristics of the development server will be described as the starting point for the development of the DISCOVER platform and subsequent testing. Secondly, the deployment scenario will be described according to the expected traffic load and number of users previsions, and is likely to require a distribution server in order to manage user requests, achieve optimal balance of the traffic generated by the users and distribute the different services that run over the hardware and OS (application servers, database engines...) in the most proper configuration.

User numbers and traffic will be predicted to decide if the hypothetical deployment scenario requires a distribution on different servers to assure the service performance. This will help design the optimal hypothetical distribution in preparation of the system deployment.

2.2 Server hardware specification

The next features describes the hardware characteristics of the server to be used for the DISCOVER platform. During the development phase, a development server with these characteristics will be used, which is separate from the server that will host the actual service. This means that all the components needed for the operation of the platform will reside in the same server and that any development will not impact on user access or performance.

Development server specifications

System Intel Xeon E5606 2.133Ghz

Manufacturer Intel

Category Hardware

RAM memory 8GB

Disk drives 2 HD 1Tb SATA ‐ Raid 1 (Hard)

Technical characteristics

Essentials

Launch Date Q1'11

Processor Number E5606

# of Cores 4

# of Threads 4

Clock Speed 2.13 GHz

Intel® Smart Cache 8 MB

Bus/Core Ratio 16

Intel® QPI Speed 4.8 GT/s

# of QPI Links 2

Instruction Set 64‐bit

of 37

Instruction Set Extensions SSE4.2

Embedded Options Available No

Lithography 32 nm

Max TDP 80 W

VID Voltage Range 0.750V‐1.350V

Memory specifications

Max Memory Size 288 GB

Memory Types DDR3‐800/1066

# of Memory Channels 3

Max Memory Bandwidth 25.6 GB/s

Physical Address Extensions 40‐bit

According to the following deployment scenario, it can be considered that any server needed for the distribution of the DISCOVER services into a server network must satisfy these characteristics.

2.3 User number prediction and traffic load

One of the most important aspects to take into account to define the hardware distribution for a real working scenario, is the correct prevision of the expected number of users the DISCOVER services will reach as this fact is directly related to the traffic load the service will be able to manage and bear: when more users are simultaneously requesting services data, more resources and better management systems will be needed to balance the traffic load.

Taking into account this important fact, a prediction on the needs according to a certain number of users can be done looking at the configuration of a real Moodle deployment: In such configuration, two servers of similar characteristics to the one that has been specified to host the DISCOVER platform are sized and configured such that each could take on the role of the other if it is needed. That is a security mechanism that assures the service in case one of the servers fails. Configured to handle a maximum of 256 web connections each, it is known that’s sufficient for a Moodle installation of a size of 25,000‐30,000 students, which is sufficient to begin to offer the DISCOVER platform services.

Of course, as we can deduce, the optimal solution for a growing number of users is to configure a totally scalable network model that let the system grow with new servers to respond to increased user requests while a load balancer manages the user traffic and redirects each user request to the most appropriate server in each instance.

The following section outlines how this hypothetical distribution scenario can be configured to achieve this principle: be as scalable as possible to respond to increasing users’ requests, expanding within the same network architecture and adding new server/balancers to manage the traffic load.

2.4 Hypothetical deployment scenario: Network architecture

The key to the appropriate network architecture for the working scenario will be to configure a scalable distribution, which will enable the easy increase of network resources and balance traffic

of 37

demands of a growing number of users, according to the predictions and premises of the previous section.

The following figure shows the first response to user requests by a block of load balancers. The load balancers mission is to distribute the traffic of the user requests among the different servers, which offer the DISCOVER services according to their available resources. It is also a safety mechanism. If a server fails the requests to that failing server can be redirected to the others. For example, load balancers, which are usually virtualized machines running on the same or different servers, can be configured in active/passive mode so if moodle‐lb‐M fails moodle‐lb‐N can take over. The same happens with database engine servers and Moodle web servers. Their principal role is to handle contents data and web connections and its number can be upgraded in a scalable way if the number of connections or users rises, but can also be held on reserve or as mirror servers to be used if some of the other production servers fail.

Figure 1 ‐ Scenario configuration and network architecture

of 37

Apart from taking into account these recommendations for a hypothetical deployment scenario, it should be noted that in a real working case each server would be completely dedicated to a specific role: data store, web server, load balancer... and may be in different physical locations. However, during the development phase while the DISCOVER platform components are going to be integrated, we will use just one development server on which the different components will be running within the same server.

of 37

3. Specification of DISCOVER platform underlying components

3.1 Introduction

Once the hardware specification has been defined, it will be needed to configure this hardware, and in this case the development server, with the proper software, administrative tools and support components in order to achieve the requirements for deployment at the top level of the DISCOVER platform.

The underlying software requirements, which enable the functioning and deployment of the higher level platform components, can be classified in one of the following categories:

Operating system (OS): Set of software and tools that manages the resources of the system needed to run other programs.

Administration and virtualization tools: Tools for the system management and hardware resources virtualization. Virtualization allows splitting physical server resources in different virtual machines, which is useful during development phase.

Application and web servers: Container that holds the web sites or web applications to manage and serve requests; returning the results as HTML that is interpreted by the users Internet navigators. To do this some web servers implement other language interpreters (as for example PHP) to perform the translation.

Data storage and data engines: Data management software that can be accessed through the standard SQL protocol in order to ask for the data that is contained on it. It holds the users’ data, contents, and in general any data related to the web applications that need a permanent storage.

One of the most important features of all the software components that are going to be used for the development of the DISCOVER platform is that all of them are totally free and most of them even open source or using general public licenses (GPL). Open source promotes free redistribution and access to an end product's design and implementation details, which allows a self‐enhancing diversity of production models, communication paths, and interactive communities, empowering free development and customization according to users’ needs.

In the following section, this chapter will review which of these components are needed for the deployment of the higher components of the DISCOVER platform (essentially Moodle + Mahara), specifying the versions which are going to be used, as well any special configuration taking into account the final requirements for the development of the DISCOVER platform.

3.2 Operating system

First of all, any hardware needs to run an operative system to use the resources of the server. This is the lowest software layer, and is needed for the rest of software components or programs to function. Because of this, it is defined as a collection of software that manages computer hardware and provides common services for computer programs.

of 37

There are lots of different operating systems that can be classified in different kinds and categories, but there is one particularly interesting as it is used worldwide in many production servers under open source license: Linux, a Unix‐like operating system that was developed without any actual Unix code and which code can be read and modified by anyone. Because of this it has been widely adopted for its use on servers. Nowadays there are several popular distributions, such as Red Hat, Debian or Ubuntu.

The DISCOVER platform development server as well as any server that finally will be used for production purposes, will run Linux as the operating system, using the Debian Lenny distribution. Detailed features of Linux Debian Lenny distribution can be found in the next table:

Linux operating system

System Linux

Developer Debian Project Community

Category Operating system

Distribution Debian

Codename Lenny

Version 5.0.10

Release Date February 15th, 2009

Supported architectures

Alpha 64‐bit PC (amd64) ARM EABI ARM HP PA‐RISC 32‐bit PC (i386) Intel Itanium IA‐64 MIPS (big endian) MIPS (little endian) PowerPC IBM S/390 SPARC

Once the operating system to be used for the development of the DISCOVER platform is defined, the next steps is to prepare the development environment as is explained in following section.

3.3 Administration and virtualization tools

Above the operating system layer the use of administrative and virtualization tools is defined to improve performance and ease development or integration of other components. Within this group the utilization of the XEN virtualization tool is particularly noteworthy, as this allows the development server to be split into different virtual machines that can specifically be devoted to different functions: application server, database engine, etc... This will be used in the development environment to simulate different dedicated servers, while on a deployment scenario these servers will really be physically separated.

of 37

Another important administrative tool is the RAID (redundant array of independent disks, originally redundant array of inexpensive disks) configuration, which makes use of the multiple disk drive components combining them into a single logic unit. The different architectures of RAID implementation are followed by a number to identify each scheme. The purpose of the RAID schemas is to provide a different balance between three key goals: resilience, performance, and capacity.

The foundations of these tools are explained below, detailing the configuration that will be used both in the development machine in terms of virtualization as well as in both development and production in the case of the RAID system.

3.3.1 XEN

XEN is a hypervisor providing services that allow multiple computer operating systems (OS) to execute on the same computer hardware concurrently. It was originally developed by Cambridge University and nowadays is maintained by a developer community as free software licensed under GNU General Public License (GPLv2). Moreover, most Linux distributions had included XEN packages to interact with the XEN hypervisor and start additional domains, but because XEN was not accepted into the mainline Linux kernel and installation required several kernel patches, some distributions dropped out‐of‐the‐box support in subsequent releases, although some distributions are again considering its support.

Server virtualization using XEN provides benefits such as:

Consolidation leading to increased utilization

Rapid provisioning

Dynamic fault tolerance against software failures (through rapid bootstrapping or rebooting)

Hardware fault tolerance (through migration of a virtual machine to different hardware)

Ability to securely separate virtual operating systems

Ability to support legacy software as well as new OS instances on the same computer.

Moreover, XEN support for virtual machine live migration from one host to another allows workload balancing and the avoidance of downtime. Virtualization also has benefits when working on development: running the new system as a guest avoids the need to reboot the physical computer whenever a bug occurs.

For all these reasons that make the use of XEN so convenient, it has been specified that for the development environment the server will be split into two virtual machines simulating the database server engine and the Moodle DISCOVER platform web server.

Detailed XEN features are summarized as follows:

XEN virtualization tool

System Citrix XenServer

Developer The XEN project. XEN source Inc.

of 37

Category Virtualization tool

Version 6.0.2 (Free Edition)

Release Date Launched 2003 (October 21st, 2011 last stable).

License GNU General Public License (GPLv2)

Website http://www.xen.org

Supported platforms

Linux BSD OpenSolaris as management host Many OS including Microsoft Windows as guests.

3.3.2 RAID system

In computer sciences, RAID, acronym of Redundant Array of Inexpensive Disks, refers to a data storage system that uses multiple hard disks among which the data is stored and replicated. Depending on the configuration of the RAID system, the advantage of the use of this system may include higher integrity and resistance against fails on the data and higher throughput and efficiency with a higher capability.

Capability of integration of several low cost devices or even older technology on a set offering higher capacity, reliability, speed or a combination of these than a last generation more expensive unique device.

DISCOVER platform server implements a RAID 1 system. That means in this kind of system, which uses a system of mirroring without parity or striping, data is written identically to two drives, thereby producing a mirrored set.

The read request is serviced by either of the two drives containing the requested data, whichever one involves least seek time plus rotational latency. Similarly, a write request updates the strips of both drives. The write performance depends on the slower of the two writes (i.e., the one that involves larger seek time and rotational latency).

of 37

The most relevant parameters of standard RAID 1 level are summarized in the following table: Description

Nº drives Space Efficiency

Fault Tolerance

Array Failure Rate

Read Benefit

Write Benefit

Mirroring without parity or striping.

2 1/2 1 drive r2 2X 1X

At least two drives are required to constitute such an array. While more constituent drives may be employed, many implementations deal with a maximum of only two. The array continues to operate as long as at least one drive is functioning. With appropriate operating system support, there can be increased read performance, and only a minimal write performance reduction.

3.4 DISCOVER platform underlying components

In order to finish the specification for the development environment of the DISCOVER platform, it should be noted that some other support components running over the described operating system are mandatory to be able to develop, integrate and deploy the top level components that will form the DISCOVER platform. In fact, these components are essential to host the components and data offered by the DISCOVER services platform, hold users’ data, serve user requests etc...

3.4.1 MySQL database engine

Moodle, and any other local components that will be integrated within the DISCOVER platform as specified in D3.3, needs to hold their content and data related to users, among other information, on a permanent storage managed by a database engine.

Supported database engines by Moodle include MySQL, PostgreSQL, MSSQL, Oracle and SQLite. MySQL has been specified to be the database engine used for the development of the DISCOVER platform because it is the world’s most used open source relational database management system (RDBMS) that runs as a server providing multi‐user access to a number of databases.

The MySQL development project has made its source code available under the terms of the GNU General Public License, as well as under a variety of proprietary agreements, and usually free software open source projects that require a database management system use MySQL. Some examples of applications using MySQL are Joomla, WordPress or Drupal, which are content management systems, and also popular World Wide Web products such as Wikipedia, Facebook or Twitter.

Detailed features of the chosen MySQL distribution to be used by the DISCOVER platform as its database engine system are summarized in the following table:

of 37

MySQL database engine

System MySQL

Developer Sun Microsystems (MySQL AB until February 2008)

Category Database engine (RDBMS)

Version 5.1.63

Release Date August 2nd, 2012 (last stable)


Website http://www.mysql.org

Supported platforms

AIX BSDi FreeBSD HP‐UX eComStation i5/OS IRIX Linux Mac OS X Microsoft Windows NetBSD Novell NetWare OpenBSD OpenSolaris OS/2 Warp QNX, Solaris Symbian SunOS SCO OpenServer SCO UnixWare Sanos Tru64

3.4.2 Apache web server

Due to the fact that Moodle, which is going to be the base of the DISCOVER platform development, is a web based application, it needs a web application server to run. A web server is the software application that helps deliver the web content that can be accessed by the users through the Internet, and is the container where the web applications (websites, data storage, enterprise applications, etc…) reside.

The primary function of a web server is to deliver web pages on request to clients using the Hypertext Transfer Protocol (HTTP). This means delivery of HTML documents and any additional content that may be included by a document, such as images, style sheets and scripts. Moodle contents and pages, as part of a web based application, are consequently translated to HTML and delivered by a web server to the users’ web browsers through the Internet.

of 37

Moreover, taking into account that Moodle e‐learning platform is based on PHP script (Hypertext Preprocessor, a kind of general‐purpose server‐side scripting language originally designed for web development to produce dynamic web pages) a web server supporting the translation of this script into HTML will be needed.

There exist some different options when choosing a web server, the most important are:

Web server Vendor Description

Apache HTTP server Apache Running typically on Unix like operating systems, is a web server notable for playing a key role in the initial growth of the WWW and for supporting an enormous variety of features implemented as optional modules.

Internet Information Services Microsoft Web server application created by Microsoft for use with Windows supporting HTTP, HTTPS, FTP, FTPS, SMTP and NNTP, but not PHP, which makes it useless for project purpose.

Nginx Nginx Open source Web server and a reverse proxy server for HTTP, SMTP, POP3 and IMAP protocols, with a strong focus on high concurrency, performance and low memory usage.

With the larger amount of webs hosted worldwide, and a recognized reliability and performance, Apache is the most popular available web server. Therefore it has been chosen as the web server to use for the development and deployment of the DISCOVER platform. Moreover, it has support for all the essential additional features needed for the correct development, integration and deployment of the DISCOVER platform, such as PHP support to run the Moodle e‐learning platform.

Like the other tools and components used for the development and deployment of the DISCOVER platform, Apache HTTP server is an open source free software developed and maintained by an open community of developers under the auspices of the Apache Software Foundation.

of 37

Detailed features of the Apache web server that is going to be used for the development and deployment of the DISCOVER platform is summarized in the following table:

Apache web server

System Apache HTTP Server

Developer Apache Software Foundation

Category Web server

Version 2.2.16 (PHP version 5.3.3‐7)

Release Date 1995 (17th April, 2012 last stable)

License Apache License 2.0

Website http://www.mysql.org

Supported platforms

Unix FreeBSD Linux Solaris Novell NetWare Mac OS X Microsoft Windows OS/2

Apart from the basic characteristics specified in the previous table, the Apache web server needs to be configured with some other features for the correct hosting of the DISCOVER platform. The Moodle based platform needs additional Apache features which enable, among others, PHP support for the Moodle/Mahara based platform, SSL support and integration facilities needed for the integration of Moodle e‐learning platform with Mahara portfolio.

The specification for the required Apache additional modules is described as follows:

Apache web server modules and tools

PHP Provided by the mod_php module + libphp5 library. Third party module developed by the PHP group that enables usage of PHP within Apache through the embedding of a PHP interpreter.

SSL PHP extension provided by the mod_ssl module. Provides strong cryptography via the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) cryptographic protocols by the help of the Open Source SSL/TLS toolkit OpenSSL.

CURL CURL is a command line tool provided as a PHP extension for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, Telnet and TFTP. CURL supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, kerberos...), file transfer resume, proxy tunnelling and a busload of other useful tricks.

of 37

4. Specification of DISCOVER Platform components

4.1. Introduction

On top of the defined structure of hardware and software components sits the DISCOVER platform. The DISCOVER system is specified as a platform offering different content and tools to the users through a set of services based on a web environment that can be accessed through the Internet via web browsers on the user PCs or via other mobile devices such as Tablet PCs or Smartphones.

The DISCOVER platform is based on the Moodle e‐learning environment for the learning content management, providing specific tools for students and course management, content management and more. Additionally, it will be integrated with the Mahara portfolio system, a framework for the management of users’ digital portfolios which includes functionalities related to social networking and interaction between users.

Following on from the previous sections the DISCOVER platform layer stack including all its different component elements can be drawn as follows:

Figure 2 – DISCOVER platform layer stack

Deliverable D3.3 will discuss how the integration of the local systems will be performed over the DISCOVER platform based on the integration of Moodle with Mahara. In the following chapter we will review the specification of the components that form the DISCOVER platform, how they are going to be integrated to work together, customized according the users’ needs and how the users will access the offered contents.

Hardware

Operating System (Linux Debian)

Virtualization tools (XEN)

Administration tools Web server & database engine (Apache + MySQL)

DISCOVER platform (Moodle + Mahara + other modules)

Local systems integration

of 37

4.2. Moodle

Moodle (which stands for Modular object oriented dynamic learning environment) is a free source web based e‐learning platform, also known as course management system (CMS) or virtual learning environment (VLE). Among its most relevant features it includes:

Different users’ roles, including administration, teachers and students.

Courses and content management with possibility of file upload and download.

Assignment submission

Grading

Social networking: Moodle instant messages, discussion forums...

Online tools: calendar, news and announcement, quizzes and more.

Wiki.

Ease of extension through the development of new modules.

Possibility of integration with other systems and platforms through the use of data sharing, XML, RPCs, web services or other communication mechanisms that can be developed as Moodle modules.

Moodle has been specified to be the basis of the DISCOVER platform due to its convenient features, scalability and ease for the developers to extend Moodle by creating plugins for specific new functionalities. Many third parties modules are currently available and even users can use PHP language to write and contribute new modules. The development and assistance of open source programmers has sped up the development of new Moodle modules, as well as rapidly fixed possible bugs.

In the following table, the specification of the version of Moodle that is going to be used for the development and deployment of the DISCOVER platform is summarized:

Moodle e‐learning platform

System Moodle

Developer Moodle HQ Moodle Community

Category Course management system

Version 2.3

Release Date August 20th, 2002 (25th June, 2012 last stable)


Website http://www.moodle.org

Supported platforms

Unix Linux FreeBSD Windows Mac OS X NetWare In general, any system supporting PHP and database engines.

of 37

The reason to use v2.x of Moodle is it includes key features regarding to activity completion and completion tracking. It includes the configuration of conditional activities, which enable teachers to restrict the availability of any activity according to certain conditions such as date, grade obtained, or activity completion. Completion tracking allows teachers to specify conditions that define when an activity is considered to be complete (e.g. when a certain number of posts have been made, or a grade has been reached or a choice has been made.)

The same configuration can be applied to courses, and in this way course completion can enable teachers to specify conditions that define when a student has completed a course. These can be useful features within the course sites and could easily allow a completion certificate to be released following completion of activities.

Over this specified version of Moodle, DISCOVER platform is going to use MILES+, which is an out of the box installation/extension of Moodle 2.x (which name is really the abbreviation of Medical Inter‐Linked Educational Space). It is a free source web based e‐learning platform arose from the mEducator project.

Due to its convenient features, scalability and ease for the developers to extend it by creating plugins for specific new functionalities, MILES+ has been specified to be the base of the DISCOVER platform joining Moodle itself. Among its most relevant features it includes:

Different users’ roles, including administration, teachers and students.

Courses and content management with possibility of file upload and download.

Assignment submission

Grading

Social networking: Moodle instant messages, discussion forums, etc. o Supporting of FOAF profile o Views of Users educational resources o Grading of educational resources by the user

Online tools: calendar, news and announcement, quizzes and more.

Wiki.

Ease of extension through the development of new modules.

Possibility of integration with other systems and platforms through the use of data sharing, XML, RPCs, web services or other communication mechanisms that can be developed as Moodle modules.

Description of Educational resources with mEducator Ontology/Scheme

Publishing description of resources as RDF triples accessible from a SPARQL endpoint

Educimology of Resources o Results of resource searching appeared in a map o Relative resources/knowledge/information appearance

Repurposing of Educational Resources

Searching and retrieving educational resources through SPARQL endpoints

Searching and retrieving resources through web services

of 37

In the following table, the specification of the version of MILES+ that is going to extend Moodle that and be used for the development and deployment of the DISCOVER platform is summarized:

MILES+ ELearning component

System MILES+

Developer Moodle HQ Moodle Community AUTH team

Category Learning Content management system

Version 2.2

Requirements Moodle v2.2 +

Release Date January 2009 ( Sep, 2012 last stable)


Website http://www.meducator3.net/milesplus

Supported platforms

Unix Linux FreeBSD Windows Mac OS X NetWare In general, any system supporting PHP and database engines.

Modern e‐learning environments, like Moodle, have matured, as perceived through the description of their structure and functions. Modern standards such as Sharable Content Object Reference Model (SCORM), adapt requirements regarding interoperability, accessibility, reusability, affordability, durability, maintainability and adaptability of the learning material. SCORM is based on widely accepted technology standards such as XML and JavaScript and it is embraced by a large number of providers, institutions and corporations worldwide. It is also used as the basis for evaluation of e‐learning platforms. The structure and the content of courses that follow SCORM standard is most easily described through the use of metadata.

Regarding the development of the web‐based courses, it involves not only the availability of material to the student and the platform to host the course. It imposes mainly the establishment of a teaching method or strategy that will accommodate the design requirements.

The model assumes the definition of learning objects and learning outcomes for a specific target audience and the design of an instructional module incorporating several types of learning material such as lecture notes, video, audio, communication/interaction activities. The above learning material may be created using different formats, and may be given through synchronous or asynchronous modes.

Most modern e‐learning environments, as Moodle with MILES+ do, support the SCORM standard. The SCORM standard provides a set of functions to communicate with Learning Management

of 37

Systems (LMS) like Moodle. During the execution of an activity, the SCORM environment communicates with LMS through these functions.

Figure 3 – Communication between Learning Management System (LMS) and Sharable Content Object (SCO)

The content of the courses will be created by the use of a SCORM editor (e.g. eXe, XERTE, etc.). Social Media tools have now crossed Moore’s chasm, easily reached early majority and are currently under rapid development and evolution. However, the idea of social learning software itself, especially in real educational and vocational training scenarios (case of carers), has not been widely developed and exploited, since too few innovators and early adopters are actually using social media technology to enhance existing training curricula designs and learning behaviors. WEB 2.0 technologies of learning component‐Moodle will be exploited and best practices derived from consortium partners previous project (IntraMEDnet, WideMEDnet, etc…) will foster DISCOVER enhancement in collaborative learning by the use of Social Media.

4.3. Mahara

Mahara is an open source ePortfolio and social networking web application which allows users with tools to create and maintain a digital portfolio of their learning, and social networking features to allow users to interact with each other. It supports Leap2A specification, which allows users to import and export data, to take their content with them from one Mahara installation and import it into another. It also allows limited interoperability between Mahara and other systems supporting the Leap2A standard.

of 37

It is a complement focused on the user, and not on the courses the user is participating in, and because of that is a good complement to the Moodle environment. Among its most relevant features it includes:

Electronic portfolio, blog and CV constructor.

Social networking: Users community creation with forum and shared artifacts.

Media: Integration with other social networks and media tools: RSS, Youtube, etc... Mahara has been specified to be integrated with Moodle in order to be the ePortfolio offered to the users for the DISCOVER platform. The specification of this component is summarized in the table as follows:

Mahara e‐portfolio and social networking system

System Mahara

Developer Catalyst IT Ltd.

Category Portfolio

Version 1.2.6

Release Date December 1st, 2006 (November 3rd, 2011 last stable)


Website http://www.moodle.org

Supported platforms

In general, any system supporting Moodle, as it is integrated with Moodle.

4.4. Customization specification

As a flexible open source environment, Moodle already incorporates tools for the management of different themes and customization of the site through the use of templates. From administration site, it is possible to manage the different themes held in a moodle deployment and easily change between them. Especially for developers, is possible to create and use new themes to give Moodle the desired look, as it is fully customizable.

Moodle themes folder contains several files and subfolders that compose the structure and style of the users’ view. The subfolder pix of this structure contain all the images used by the theme. Some other relevant files used to customize the theme are summarized next:

favicon.ico: The little icon showed on the internet navigator when accessing the site.

header.html & footer.html: These files can be modified to give the header and the footer a customized look, and contain their own logo, user name, start menu, navigation bar and more. CSS (cascade style sheets) can be used to customize the styles, as well as PHP to show any data from the database or what needed to customize these sections.

styles.php: This file needs to be referred from header.html to set the bridge to the styles.

of 37

config.php: In this file it can be configured how the several style files work together. Themes can be constructed over the standard provided by Moodle or over any other parent theme and can include or exclude several CSS files, where the styles are defined.

Style sheets: To isolate the page contents from the styles of the web page that configure its presentation, CSS files defining these styles are used. This provides a better accessibility and flexibility, as well as a better design of the website decoupling presentation from contents. To manage easily style changes on the website (colour, fonts, etc...), there are some CSS files devoted to that: styles_colour.css, styles_fonts.css, styles_layout.css.

According to that, contents layer is presented thanks to the use of xHTML, and styles layer is configured thanks to the CSS files. To connect the information defined in both layers, xHTML tags and links with names within the page are used. Following these instructions, own customized themes can be created. It will be done to create the theme of the DISCOVER platform view, which will have a look similar to this:

Figure 4 ‐ Possible look for DISCOVER platform

Regarding to the EU Project DISCOVER website, the view configuration principles are quite similar: it has been deployed with Drupal, an open source CMS which allows the structure customization through the use of modules, blocks and themes, understanding structure as the place where the data is shown. In Drupal, like in Moodle, themes establish the look, view and fonts of the site.

of 37

Some of the components and modules that have been used for the customization of the public DISCOVER project website can be summarized next:

Drupal base: Main deployment of Drupal need as the base for the rest of components.

Menu module: Option menu that gives access to the contents.

Content module: Block with the data contents, which can be pages, news, etc...

Blog module: Provides a blog for the site.

Moodle Single Sign On (SSO): Will let the access to Moodle through the use of username and password.

A simple structure for the DISCOVER website has been specified, being accessible, friendly and easy to use. Structure of the site can be seen on the next screenshot:

Figure 5 – Look of the DISCOVER project website

of 37

Drupal styles customization is also performed through the use of themes and subthemes. The next diagram illustrates the files structure that can be found on a Drupal typical theme and subtheme configuration:

Figure 6 – Drupal themes diagram

Some concerns to take into account regarding Drupal theme files and structure can be summarized as follows:

.info (required): All that is required for Drupal to see a theme is the ".info" file. Should the theme require them, metadata, style sheets, Javascript, block regions and more can be defined here. Everything else is optional. The internal name of the theme is also derived from this file.

Template files (*.tpl.php): These templates are used for the (x)HTML markup and PHP variables. In some situations they may output other types of data ‐‐xml rss for example. Each .tpl.php file handles the output of a specific themable chunk of data, and in some situations it can handle multiple *.tpl.php files through suggestions. They are optional, and if none exists in a theme it will fall back to the default output.

template.php: For all the conditional logic and data processing of the output, there is the template.php file. It is not required, but to keep the .tpl.php files tidy it can be used to hold pre‐processors for generating variables before they are merged with the mark‐up inside *.tpl.php files. Custom functions, overriding theme functions or any other customization of the raw output should also be done here.

of 37

On the surface, sub‐themes behave just like any other theme. The only differences are that they inherit the resources from their parent themes. To create one, a "base theme" entry inside the .info file is needed. From there it will inherit the resources from its parent theme and there can be multiple levels of inheritance.

4.5. Specification of the integration of Moodle & Mahara

Moodle and Mahara are complementary systems, so support tools for the integration between these systems are freely provided. The integration is done with a Single‐Sign‐On (SSO) mechanism, which is a great manner to achieve that.

The way in which the integration works, can be summarized in the following use case: a user logs into one application, and by clicking on especially crafted links that are provided there, is transparently authenticated to a second application, even though it may be running on another completely different server or site.

When SSO is well configured and running, it can dramatically improve the sign‐up experience for new users of applications with the following features:

No need to create an account.

No need to find an unused username.

No need to think up and remember yet another password.

No new URL to remember.

No need to log in to yet another application.

No need to upload the same profile to the new application.

With the release of Mahara 0.8.1 and Moodle 2.3, Moodle can now be configured to let the users logging into Moodle click on a link that will bring them to the Mahara site, and automatically log them on to their Mahara account. If they don’t have yet an account on Mahara, their user data will be imported from Moodle, and used to populate their Mahara account. Even some other information related to the Moodle users’ profile (e.g. profile picture in Moodle), will also be imported to their Mahara account. All these features let users to begin to use Mahara account with absolutely zero configurations required.

4.5.1 Moodle and Mahara requirements for integration

This section describes the requirements to be achieved by Moodle and Mahara systems in order to be integrated together. Moreover, the procedures needed to produce the integration will be specified.

To integrate both systems basically two steps will be followed, configuring aspects related to basic networking between Moodle and Mahara and enabling SSO between them.

First, networking on Moodle will need to be enabled. To do that, the Moodle administration site provides access to networking parameters. To enable networking from “Site Administration >

of 37

Networking > Settings” all that is required is simply to switch the “Networking” value to ‘On’ and changes will be saved.

Figure 7 – Moodle networking settings

Once done in the Moodle side, and before continuing with the rest of configurations in the Moodle side, it will need to enable the networking features on Mahara side as well. To do this, Mahara also provides an administration environment in which the networking page with its features can be found. To enable Mahara networking the “Site configuration > networking” link should be accessed.

Once enabled, networking features can be observed (see figure below). First, WWW root should be listed. This root is the canonical address at which Mahara site can be accessed, and this address will be used later in the Moodle site to indicate to it in which address Mahara can be found.

Beneath the WWW Root, Public encryption key can be found. This is a file of seemingly random text, beginning with the line “‐‐‐‐‐ BEGIN CERTIFICATE‐‐‐‐‐“. The expiry date of the key is noted underneath. Mahara will automatically generate a new key when this on expires, and propagate the new key to the related peers (in our case to Moodle). To assure networking between Mahara peers, “Enable networking” setting must be fixed to “Yes” value.

of 37

Figure 8 – Moodle networking settings

Once networking settings have been enabled in both sides, single‐sign on (SSO) mechanism needs to be enabled as well. To enable SSO in Mahara an institution needs to be added and after that configuration of the Moodle site. An institution is just another site, Moodle in our case, with which we want to connect the Mahara system. To do this, it needs to introduce the Institution Name and Institution display name and configure the Authentication plug‐in value to “XMLRPC – Authenticate by SSO from an external application”.

of 37

Figure 9 – Mahara institutions administration

Once XMLRPC communication mechanism is chosen, some of the parameters related to this plug‐in will need to be configured as seen in the next figure. Especially crucial fields are WWW Root that must be exactly the same as is specified in Moodle site config.php file and “The SSO in field” must be set to ‘On’.

of 37

Figure 10 – Mahara institutions administration

Once done, Mahara site must be added as a peer to Moodle. This can be done adding it from “Site administration > Networking > Peers” in the Moodle site:

Figure 11 – Managing of Moodle peers

of 37

Once working according to the specified configuration, Moodle users will have transparent access to the manager through the same Moodle site. An institution can have any number of authenticating authorities, and Mahara will try to authenticate users against those until it hits upon an authority that knows the user. An authority could be any system that already stores username and password information for users, for example, a student management system, an email server, and LDAP server or just a plain old database:

Figure 12 – Moodle/Mahara communication

4.6. Moodle modules specification

Many third party Moodle modules are already available and users can even use PHP language to write and contribute new modules. The development and assistance of open source programmers has sped up the development of new Moodle modules, as well as rapidly fixed possible bugs.

Typical plugins development includes fields such as:

Activities, which may include games or other related e‐learning contents.

Resource types.

Question types, which allow creating quizzes with several possible answer types, including multiple choices, true and false, fill in the blank, etc.

Data field types (for the database activity).

Graphical themes and customization.

Authentication methods (can require username and password accessibility) which may allow access to Moodle from other platforms or sites automatically.

Enrolment methods.

Content filters. According to the needs to be covered by the features of the platform, some of the modules to be taken into account for the development of the DISCOVER platform are specified as follows. These

of 37

will be installed as Moodle modules as part of the DISCOVER platform and will include common tools such as:

Learning activities o Quizzes and questionnaires. o Courses modules.

Social networking o Discussion forums. o Instant messaging (IM).

Common tools: o Calendar and agenda.

Other: o Globalization module to manage Moodle different languages. o Modules for mobile devices viewing, which may include modules to manage or

create in Moodle the templates suitable for mobile devices. o Plug‐ins for the integration with the local systems or other components that need to

be communicated with Moodle based DISCOVER platform (e.g. Mediasite plug‐in). These modules, plug‐ins and local systems as well as their communication specification with Moodle will be detailed in D3.3.

4.7. Specification of the integration of Drupal website & Moodle platform

The DISCOVER platform will be accessed through a single entry point, this means that access to the DISCOVER platform will be from the project public website (www.discover4carers.eu). The DISCOVER platform itself will then be accessed through a distinctive banner graphic on the home page of the project website. This login option will enable users to register for the DISCOVER platform and to access the contents of the platform. The project website will be the entry door to the whole DISCOVER platform, which once developed will be composed of the public web site (being developed under WP6), and the DISCOVER platform itself including integrated local systems, which will be described in Deliverable D3.3.

The project’s public website will provide all the information to let the user access the learning contents, user profile, additional information, etc... So on a multilingual environment provided by the web site the user will find instructions on how to access the DISCOVER platform once registered on it with a username and password. The process which the user will follow to access the DISCOVER platform can then be summarized then as follows:

On project website there will be an authentication/access banner. There already exist Moodle plugins, which may allow access to Moodle from other platforms or sites automatically.

Once the user is authenticated, they will be redirected to DISCOVER platform, based on Moodle, where the contents will be available depending on the user’s profile and permissions.

Users will be able to access through one transparent interface all the available content and functionalities provided by the underlying components. These include the contents provided

of 37

not only by the DISCOVER platform based on Moodle, but also the contents provided by the integration of the local systems, which will be detailed in D3.3.

Due to the DISCOVER platform structure, which as it can be seen is composed by several different modules, it will exist on a union between these components through a common integration of user profiles. To do this, the needed modules which are summarized as follow will be implemented:

4.7.1 Moodle integration module v.6‐x‐2.3

This is a useful module which allows the integration of the Moodle based DISCOVER platform with Drupal, which is the content management system in which the project web site is developed. In particular, “Single Sign On” (SSO) via GET arguments will send to Moodle the authentification of a user to be possible to use Moodle with Drupal.

4.7.2 QAPI

Some other modules like “QAPI” (which is the acronym of Moodle Quick API) are needed. This software provides an interface to create the needed communication between both systems. In this way, user authentication can be done through several techniques: using SSO, OpenID or LDAP. In order to use SSO, the Moodle SSO plug‐in must be used. To use OpenID “OpenID Provider Drupal Module” and “Moodle OpenID plug‐in” must be used, and finally to use LDAP “LDAP integration module” will be required”.

In order to perform this integration, versions of both the website and DISCOVER platform will be taken into account, being Drupal 6.2 the version of the project website and Moodle 2.3 the version of the DISCOVER platform.

Figure 13 – Moodle/Drupal website communication

Website (Drupal 6.2) DISCOVER platform (Moodle 2.x+)

Moodle integration plug-in

QAPI plug-in

SSO module

of 37

Then, according to this description, the following schema represents how the integration of the project website and DISCOVER platform will be done in order to let the user access the DISCOVER platform through this defined single entry point:

Figure 14 – DISCOVER single entry point specification

4.8. Access devices

Thanks to the facilities provided by Moodle features, the DISCOVER platform will be developed using different templates that will enable the use of the platform on several kinds of devices, including PCs, tablets and smartphones. Moodle already incorporates as part of its core system a template configuration mechanism that lets the developers configure and create different kinds of templates and views suitable for its view on these different devices. Then, when an user request is received by the DISCOVER platform, its Moodle base is able to detect automatically which kind of device the request came from, and choose the most appropriate template according to the detected device to show the contents on it.

discover d3.2technical specification for discover platform...

Documents