Project Acronym: DOULS
Version: 0.4
Contact: Jason Platts
Date: 13/12/2010
Project Document Cover Sheet
Project Information
Project Acronym
DOULS
Project Title
Distributed Open University Learning Systems
Start Date
1 July 2010
Lead Institution
The Open University
Project Director
Niall Sclater, The Open University Strategy Unit
Project Manager &
contact details
Judith Pickering
LTS, Perry Building
The Open University
Walton Hall
Milton Keynes MK7 6AA
Partner Institutions
N/A
Project Web URL
www.open.ac.uk/blogs/douls
Programme Name
(and number)
E-learning programme: Distributed VLE
Programme Manager
Sarah Davies s.davies@jisc.ac.uk
End Date
31 December 2011
Document Name
Document Title
Project Plan
Reporting Period
Author(s) & project
role
Jason Platts, Lead Technical Developer
Date
13/12/2010
Filename
DOULS_Technical Model.doc
URL
Access
 Project and JISC internal
 General dissemination
Document History
Version
Date
Comments
0.1
01/12/2010
Initial outline – J.Platts
0.2
07/12/2010
Draft research – J.Platts
0.3
10/12/2010
Finalise research content – J.Platts
0.4
13/12/2010
Add development content – J.Platts
Page 1 of 8
Document title: DOULS Technical Model
Project Acronym: DOULS
Version: 0.4
Contact: Jason Platts
Date: 13/12/2010
Technical Model for DOULS development
In work package 2 of the project technical investigation was carried out to further understand
the options, issues and technicalities of developing some of the functionality outlined in the
project plan.
During this stage the ‘visioning’ activity was also taking place; researching and developing
ideas for a ‘distributed’ Open University learning system, which was initiated by Niall Sclater
(Project Director) through a serious of meetings with project members/contributors and other
institutional stakeholders.
The technical areas that were researched were informed by:
 some of the initial ‘visioning’ work
 the need to understand some of the technologies involved and their potential use
 co-ordination with relevant areas of the OU VLE development programme (in
particular Personalisation)
 ideas discussed at the JISC DVLE programme meeting in Bolton on the 14th
September
This document outlines some of the main research areas that were investigated along with
the technical model (framework) that will be used.
Research
Gadgets/widgets
The terms gadget and widget often seem to be interchangeable, but in fact they are actually
independent defined specifications (OpenSocial gadgets, W3C widgets).
OpenSocial/Google gadgets are web gadgets added to a page via an iframe with their content
rendered by a gadget server such as Apache Shindig. At the most basic level gadgets can be
added to any web page as html, but in order to use social information the gadget must be
placed in a web platform that is an OpenSocial container. The OpenSocial specification is
supported by Google and has been widely adopted by a number of popular sites such as
iGoogle, Yahoo, MySpace and LinkedIn.
W3C Widgets can be deployed to web, desktop or mobile environments. Using the Apache
Wookie server W3C Widgets can be added to a number of web platforms, including Moodle.
Form the outset of the start of the project it was clear that whatever platforms we would
distribute the VLE to then there would need to be a reasonable level of adoption (or potential
for) of those platforms by end users. It made sense to concentrate on OpenSocial gadgets as
they are widely adopted by sites with large populations; including iGoogle and Google Sites
which are available to OU students as part of our Google Apps for education provision. There
has also been work undertaken in the university to include OpenSocial support in the
SocialLearn platform and with personal learning environments (ROLE project). If W3C
widgets became a more mature technology with wider adoption during the project then it
might be possible to convert some gadgets to this format at a later date.
When working with stakeholders to gather requirements and ideas for gadgets it became
clear that there was confusion over the term gadget and what it meant. A short introduction to
gadgets and what they are was written for the project and used to clarify what we were
proposing to develop.
Page 2 of 8
Document title: DOULS Technical Model
Project Acronym: DOULS
Version: 0.4
Contact: Jason Platts
Date: 13/12/2010
Presenting gadgets to users
The gadgets being produced in the project are going to sit outside of the VLE in other,
potentially external, platforms. To drive adoption and usage there needs to be promotion and
support for the gadgets so that students can:
 find out about gadgets, what they are and where they can use them
 find out what gadgets we provide and why they might use them
 understand how to install/use the gadgets we provide
 know where to find support materials
By initially only promoting the use of gadgets within Google applications we can provide that
guidance and support more effectively. As part of Google Apps for education there is the
facility to provide a ‘start page’ to users; a personal customisable page where users can add
gadgets. Through the combination of promotion of this ‘start page’ and gadgets there is
potential for large numbers of students to adopt the gadgets we produce for the project (as of
Dec 2010 over 5000 students have an OU Google Apps account).
There are two different options to consider when setting up a personal ‘start page’ in Google
Apps. Research was undertaken to understand the implications of utilising either of the
options and the features and functionality they both support. The results of this research are
detailed in the ‘Google start page investigation’ document and were used when liaising with
stakeholders and decision-makers in the institution involved in the areas of Google Apps
provision, student tools and personalisation. It is expected that the ‘roll-out’ of the chosen
‘start-page’ (when finalised) will coincide with the release of the initial project gadgets.
Using Moodle 2 web services
Gadgets displaying information from external sites can obtain this information either from RSS
feeds or from a REST/JSON web service call. Many aspects of Moodle support the exposing
of information via RSS feeds, but the use of web services within Moodle is fairly recent.
Investigation into web services within Moodle was undertaken to ascertain how web services
are developed, administered and used.
Documentation for Moodle 2 web services is detailed at
http://docs.moodle.org/en/Web_Services.
Authorisation to web services is either granted to individual users or to an external system.
Web services can be administered by grouping the functions required into an external
function; this can then be restricted to authorised users and have access controlled by user
capability.
Integrating Gadgets with Moodle
If OpenSocial gadgets are to request information personal to the user from the VLE then there
needs to be a mechanism whereby this request is verified to of come from the correct user; to
prevent personal data being made available to other users either by accident or malicious
intent. Potential for this type of situation is amplified by the supporting of user profiles in some
social networks; for example if a user has a gadget on their profile page then others viewing
that page will be able to see that gadget – should they see the same contents that the gadget
‘owner’ sees?
Fortunately, the OpenSocial has mechanisms for dealing with such a situation through the
utilisation of OAuth security protocol and the concept of gadget ‘owner’ and ‘viewer’.
Investigations into how Moodle could utilise the security provided by OpenSocial to ensure
the integrity of requests is detailed in the post “OpenSocial (Google) Gadgets that connect to
Moodle” on the project website.
Page 3 of 8
Document title: DOULS Technical Model
Project Acronym: DOULS
Version: 0.4
Contact: Jason Platts
Date: 13/12/2010
Integrating Moodle with Google
The ‘visioning’ activity highlighted use cases where integration between Moodle and Google
might occur.
Currently two core Moodle features integrate with Google Apps; Repository and Portfolio.
Repository:
 Enables users to store and access personal files in Moodle
 Can connect to external sources (e.g. Google Docs) and import files into Moodle
 Is used to upload files for inclusion in activities such as forum posting.
Portfolio:
 Lets users transfer Moodle content to their ‘portfolio’
 Can connect to external sources e.g. Google Docs
 Functionality can be added (in development) to any aspect of Moodle, currently used
in tools like Forum and Glossary.
Research into using the Moodle 2 Portfolio API with Google Docs was undertaken and this
resulted in raising a number of bugs in the moodle.org issue tracking system.
Using the Moodle 2 Portfolio functionality a demonstration of pushing Moodle content into
Google Apps was developed as a proof of concept. This bespoke module pushed a user filled
‘template’ document into the users Google Docs account. This was demonstrated at the OU
VLE development programme workshops investigating the use of Google Apps for
ePortfolios.
Research was also undertaken investigating existing third-party integrations between Moodle
and Google. This included looking at the GLUE! architecture that was demonstrated by Carlos
Alario Hoyos from the university of Valladolid at the programme meeting in Bolton; where a
Google document is used to create a group collaborative activity.
One of the key areas of Moodle that may require updating to accommodate more advanced
and direct integration is the Google API authorisation code. Presently this connects to Google
APIs using the AuthSub security protocol. This protocol is not supported when connecting
directly to accounts in a Google Apps domain as this requires connection via the OAuth
protocol. Situations where this type of access might be required include; directly interfacing
with a user’s account without the need for their authorisation and undertaking activity on an
account that is not that of the current user e.g. sharing a central document.
The main issue concerned with use of domain level API access is that of security. API key
access can only be controlled at a tool/service level and can not be restricted to certain
accounts. Therefore there is the potential to access and interrogate/manipulate the contents
of any user documents without their express permission (via code). This presents a potential
security/data protection issue; especially if assessed material is stored within the Google
Docs domain.
If development is to take place using domain level API access then processes and
procedures will need to be in place to ensure that abuse does not occur. The project is liaising
with key stakeholders within the institution to resolve this issue in a timely manner so that
functionality specified for developments can be approved.
Conclusions
The development work required to meet the ‘vision’ of a distributed learning system falls
under two broad categories; developing integrations with external systems (Google Apps),
developing services and gadgets. Preparatory development will concentrate on the
mechanisms to create and deploy gadgets that connect to the VLE; creating a framework that
can be used later in the project to prototype and develop gadget ideas.
Page 4 of 8
Document title: DOULS Technical Model
Project Acronym: DOULS
Version: 0.4
Contact: Jason Platts
Date: 13/12/2010
Development
Details of the ‘Technical Model’ used in DOULS – the framework used to create and deploy
OpenSocial/Google gadgets that connect to a Moodle 2 VLE.
Moodle plugin
The Social Network Application Plugin (SNAPP) is a multi-purpose Moodle 2 local plugin;
created to enable the deployment of OpenSocial gadgets from Moodle and to provide a
number of features allowing for the connection of those gadgets to Moodle. This plugin is
currently at a beta stage, having been developed as part of the preparatory development task
in the project, and is yet to be completed.
An overview of the functionality is detailed in the post “OpenSocial (Google) Gadgets that
connect to Moodle” on the project website.
The plugin consists of the following features:
 Gadget XML serving – Allows dynamic information to be added to XML gadget files
e.g. Moodle url
 User mapping – Connection of OpenSocial user id to Moodle user id
 Connection to Moodle services – Connector to allow Moodle to securely distribute
data to gadgets
 Administration – Admin screens for the plugin to enable configuration and
management
 Libraries – PHP code classes used by the plugin, can also be used by other areas of
Moodle e.g. to verify requests from gadgets using OAuth
 Tests – PHP unit tests and test gadget
Using Gadget XML ‘server’
The gadget ‘server’ is located at ‘/local/snapp/gadgetserv/gadgetxml.php’ and is intended to
output OpenSocial gadget XML files located within the ‘local’ directory of the Moodle
installation.
To install a gadget using the gadget ‘server’ specify the path to the ‘gadgetxml.php’ file along
with the parameter ‘gurl’ pointing to the location of the desired XML, relative to the local
directory e.g.
‘http://www.mymoodleinstall.com/snapp/gadgetserv/gadgetxml.php?gurl=snapp/simpletest/ex
ample.xml’.
The gadget ‘server’ is intended to be used with XML files, but can also output the contents of
other file types as well such as php. If the file referred to in the ‘gurl’ parameter is unable to be
found then the gadget ‘server’ will return a file not found message (with an http 404 header).
The gadget ‘server’ will replace know placeholders within the specified file with dynamic
values. These placeholders are usually specified by inserting text within the gadget XML file
in the format %%placeholder%% (case insensitive).
The placeholder %%moodleurl%% will be replaced with the current Moodle installation root
url e.g. ‘http://www.mymoodleinstall.com’. This can be used to include references to files in
the current Moodle install within the gadget XML. This is of benefit to gadget creators as the
Moodle url may not be known in advance, or be a single address e.g. when distributing code
to others or when running multiple installations for development, testing, live etc.
Making secure requests from gadgets
In order for the request verification code in the Moodle plugin to be used any requests for
sensitive data to Moodle from the gadget need to be signed using the OAuth security
protocol.
The Moodle plugin can verify requests signed with either RSA-SHA1 or HMAC-SHA1. RSA
requests are signed using a public certificate – this must be either located at a publically
Page 5 of 8
Document title: DOULS Technical Model
Project Acronym: DOULS
Version: 0.4
Contact: Jason Platts
Date: 13/12/2010
accessible url so it can be downloaded by the plugin, or manually added to the plugin’s
certificate store in the plugin/authorisation administration screen. HMAC requests are signed
using a consumer key and secret that is container (e.g. iGoogle) specific – the key/secret
must be obtained from the containers you wish to support and then added to the
plugin/authorisation administration screen.
Example of JavaScript code to make a signed request from an OpenSocial gadget:
osapi.http.get({
'href' : '%%moodleurl%%/local/snapp/gadgetserv/mapuser.php?debug=1',
'format' : 'json',
'authz' : 'signed',
//'oauth_service_name' : 'hmac',//uncomment for HMAC
}).execute(mapresponse);
All certificates and consumer keys are stored in the Moodle database by the plugin.
Requests are verified using a copy of the open-source php OAuth library from
http://oauth.googlecode.com/svn/code/php/.
Mapping gadget user to Moodle user
In order for Moodle to be able to send user specific data to a gadget it needs to know which
Moodle user the gadget user matches. The mapping of this information is initiated by the
gadget through a signed request to the ‘gadgetserv/mapuser.php’ file. On receiving the
request this file will verify that the request is valid, using OAuth, and check for any existing
user mapping for the gadget user and gadget container (e.g. iGoogle). If there is not an
existing mapping stored in the database then a mapping url is sent to the gadget; this url
points to a Moodle page that will allow the gadget user to create a connection between their
Moodle account and their user in the particular gadget container.
Once a mapping is stored then all actions by the Moodle plugin that access user specific data
will check this mapping and only return data for the expected gadget user.
Administration
The plugin has a number of administration screens that allow for:
 Control over plugin configuration settings e.g. turn on/off plugin
 Management of containers e.g. add/disable/delete
 Management of public certificate store e.g. add/delete
 Management of consumer key store e.g. add/delete
 Management of user mapping e.g. delete connection. Individuals can manage any
mappings they have initiated; administrators can mange all mappings that exist in the
system
All of these functions are recorded to the Moodle log so that changes at a system level can be
audited. Key user activity, such as creating a mapping, is also recorded to the Moodle log.
Code libraries
Shared functions of the plugin are located in a php library – a single php file with multiple,
often static, classes. These functions can be used in other areas of Moodle as required; for
example, when needing to verify OAuth requests.
Tests
As well as php unit tests an example gadget is provided to demonstrate/test some of the
features of the plugin.
Page 6 of 8
Document title: DOULS Technical Model
Project Acronym: DOULS
Version: 0.4
Contact: Jason Platts
Date: 13/12/2010
“SNAPP” Moodle plugin – Sequence showing interaction with OpenSocial/Google gadget
Gadget
Gadget XML
Container e.g. iGoogle
Request verification
User mapping
Display gadget
Get XML
Get dynamic data
Return data
Send XML
Render gadget
Request information from VLE (AJAX)
Oauth parameters added
Check user registered
User information
Request for verified users data
JSON data
Page 7 of 8
Document title: DOULS Technical Model
Moodle 'data'
Project Acronym: DOULS
Version: 0.4
Contact: Jason Platts
Date: 13/12/2010
Gadget framework specification
A JavaScript library containing functions to interact with key features of the Moodle plugin will
enable gadget creators to easily connect to and utilise these features. A library of functions
also has significant benefit when creating multiple gadgets as there is then only one point to
test and fix for errors.
There needs to be a mechanism by which the library can be ‘configured’ by any gadget using
it. This would required setting global gadget settings such as the url to Moodle or the type of
authorisation needed to sign requests. These settings should be contained in a gadget object
that is created and defined within inline JavaScript in the gadget XML. No functions in the
library should be called automatically on load as they may require the gadget settings object
to be defined first.
The library should contain functions to enable the following features:
Check user mapping
The library should call the ‘mapuser.php’ file with a signed request, using the OAuth signature
method specified in the gadget settings object. A response function should process the result
of this request and assign values to the global settings object as appropriate.
If no user mapping exists then the url returned should be used to create a standard instruction
that links to this url. On selecting the url the user mapping should then be checked again at
regular intervals (e.g. 30 secs) and once the user has agreed to the mapping in Moodle the
instructions hidden. The load event of the gadget can then be called to initiate the gadget as if
first loaded.
Request to Moodle for data
A function to make an AJAX request to Moodle that is signed with the OAuth signature
method specified in the gadget settings object. A response function should check and return
the results of the request including checking for errors reported by Moodle.
Error reporting
A standard mechanism that will report any errors encountered with the Moodle plugin, when
called by the gadget, to end users.
Helper functions
A standard set of functions to undertake common tasks required by the gadgets; for example,
creating a status update.
Page 8 of 8
Document title: DOULS Technical Model