Design overview¶
Principles and decisions¶
There are few principles:
- Supporting a Learning Tool must be simple and easy.
- The solution must be secure. A student should never be able to open a lab session unless the Learning Tool grants him access to it or unless the lab provides open access to it.
- It must work with Learning Tools in a variety of situations, from universities supporting Single Sign-On solutions -such as Shibboleth- or directory protocols -such as LDAP- to secondary schools with almost no IT infrastructure.
- IT services of entities deploying gateway4labs must be able to audit quickly whatever involves the Learning Tools.
- It must support multiple remote laboratories, so they can collaborate towards the same shared goal. While some code must be remote laboratory dependent, most of the code should be common.
Given that multiple Learning Tools are targeted, ideally there should be no Learning Tool dependent code. There are approaches that try to achieve this. However:
- Some of them do not guarantee that any malicious user can open a lab session without the Learning Tool supporting it. This is in conflict with principle number 2.
- Some of them rely on protocols not yet supported by existing Learning Tools, such as relying exclusively on Shibboleth or IMS LTI. This is in conflict with principles number 1 (if the Learning Tool does not support it, including it becomes complex), 2 and 3 (if the secondary school does not support that protocol, the solution will not work). Additionally, given that these protocols do not know what the Learning Tool itself states, certain common situations are not covered. For instance, instructors may want to establish which weeks lab sessions are available and which ones are not.
Therefore, we accept that there is some Learning Tool dependent code as the lesser of two evils, and only if it is required. However, so as to support the principles mentioned above, this code:
- Should be as small and simple as possible: IT services must be able to audit it quickly.
- Should not require upgrades too often: that will typically involve critical, slow processes by the IT services.
Most of the logic should therefore be located in other component. This component has been named labmanager, as detailed in the following section.
Roles¶
In gateway4labs there are the following roles:
- Remote laboratory administrator
- LabManager administrator
- LMS/CMS/PLE administrator
- Teacher
- Student
The remote laboratory administrator will create an account for each LabManager involved, and it will grant privileges for each LabManager.
The LabManager administrator will interact with the remote laboratory administrators to make sure that they are connected to the LabManager. He will also sign up different Learning Management Systems from different entities.
The LMS/CMS/PLE administrator will manage from the LMS/CMS/PLE to students. There are two versions at this moment: * When using LTI, the LMS/CMS/PLE administrator will create teacher users in the LabManager,
and assign them permissions on laboratories. Teachers will use these permissions (which contain a key and a secret unique for each teacher and laboratory) to add those labs to their courses. Students of those courses will automatically be able to use these laboratories.
- When using Basic HTTP, the LMS administrator will query courses in the LMS/CMS/PLE, and they will assign permissions to those courses. From that point, teachers will be able to upload SCORM objects refering to those courses and upload them to the LMS/CMS/PLE. From that point, students of those courses will be able to use them.
Architecture overview¶
As described in the figure above, there are three main components involved:
- The LMS/CMS/PLE (left side). If it supports IMS LTI, it will use it and no code will be required in the LMS/CMS/PLE. If it does not support it, it will have a small plug-in that communicates with the LabManager.
- The LabManager, which will receive requests from multiple, different LMSs and it will understand the protocols of different RLMSs. It does not have any LMS dependent code, but it has RLMS dependent plug-ins.
- The RLMS, which will support a federation protocol to process requests from the LabManager. The federation protocol from one RLMS to other will be different. It should not require anything special for being supported by the LabManager.
This way, if a new LMS/CMS/PLE is aimed, if it supports IMS LTI the support is automatic. If it does not support it, a new plug-in for that LMS is required in the LMS, but it has no impact on the rest of the RLMSs neither on the LabManager. If a new RLMS is aimed, a new plug-in for that RLMS is required in the LabManager, but it has no impact on the LMSs/CMSs/PLEs.
LMS to LabManager protocol¶
This only applies when the non IMS LTI version is targeted. Sample reservation request:
POST /gateway4labs/labmanager/requests/ HTTP/1.0
Authorization: Basic ASDFASDF (LMS token)
{
"user-id" : "jsmith",
"full-name" : "John Smith",
"is-admin" : true,
"user-agent" : "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0",
"origin-ip" : "192.168.1.1",
"referer" : "http://.../",
"courses" : {
"01" : "s",
"02" : "s",
"03" : "t", // "t" = teacher, "s" = student
"04" : "s",
},
"request-payload" : "SOMETHING-THAT-SCORM-SENDS"
}
Sample authentication request:
GET /gateway4labs/lms/authenticate HTTP/1.0
POST /gateway4labs/labmanager/lms/admin/authenticate/ HTTP/1.0
Authorization: Basic ASDFASDF (LMS token)
{
"full-name" : "John Smith"
}
Sample course listing request (q=text to filter, start=0 to go to the first page):
GET /gateway4labs/lms/list?q=elect&start=0 HTTP/1.1
Authorization: Basic ASDFASDF (LabManager token)
Sample course listing response:
{
"start" : 150,
"number" : 34000,
"per-page" : 10,
"courses" : [
{
"id" : "3465",
"name" : "Computers Architecture"
},
{
"id" : "2854",
name" : "Electronics Laboratory"
},
{
"id" : "2854",
"name" : "IEEE Student Branch"
},
],
}