Dashboard > SCORM 2.0 > ... > SCORM 2.0 White Papers > Aki - OLSA On-demand Communication
  SCORM 2.0 Log In | Sign Up   View a printable version of the current page.  
  Aki - OLSA On-demand Communication
Added by Avron Barr, last edited by Erin MacNeil on Aug 27, 2008  (view change)
Labels: 

Enable Richer Content Interactions with OLSA On-demand Communication

Shota Aki, SkillSoft

Summary

SkillSoft's Open Learning Services Architecture (OLSA) On-demand Communication is introduced as a solution for enabling richer content interactions between a Content Service Provider and a Learning Management System.
We propose to have OLSA On-demand Communication adopted as part of SCORM 2.0.

Requirements/Needs Outlined

Recommendations

The use cases and problems identified in this paper are definitely applicable to the industry. There is a need to content providers to be able to host their own content and provide additional training in a flexible manner. Having been previously adopted, OLSA could serve as a good starting point for additional capabilities in SCORM 2.0. Shota, it seems like you've crafted this specification to work well in existing LMS's that already support SCORM/AICC. If that constraint is lifted and you get to design SCORM so that these capabilities are included natively, what would you do differently?

I think one variation I could see adding is supporting a push-model, where the Content Service Provider pushes data to the LMS. The current proposal only describes a pull-model but there is no technical reason why there couldn't be both.

Also, the current proposal is agnostic with regards to whether AICC or SCORM content is being launched out of the LMS. It can accomodate simpler and more secure launch methods, for example something like:

1. LMS is configured to interact with a given Content Services Provider (with appropriate WS security credential)

2. LMS imports a list of IDs for e-learning assets from the CSP (lets skip the entitlement details for now)

3. When ever the LMS wants to launch an asset off of the CSP, it executes this sequence:

    a. Call CSP with username, asset ID, security creds (extend this call to support passing all sorts of user profile data)

    b. LMS returns a sessionid-protected, time-limited launch URL valid only for that user and asset

    c. LMS redirect user with this URL

    d. User interacts with content, when the user is done, the CSP (or content) notifies the LMS the session is complete (maybe through a temporary URL-back-to-the-LMS also passed at step a from the LMS to the CSP.)

    e. If the pull-model is enabled then the LMS can pull the data. If the push-model is enabled then maybe the temporary URL is used by the CSP at step d to send the data.

The launch sequence like above would be nice have standardized, maybe as part of this proposal.

However, the key issue that we feel that needs to be addressed is that we have use-cases where content is launched not direcly by the LMS. This raises the issue of: well how do we get the data back to the LMS since the customer wants to continue using it as the system of record. If content is being launched from a separate Portal (the worst case) then I think the pull-model (as currently described) is the simplest way to do this. A standard solution for this use-case would really open things up and allow content service providers to innovate with new content.

Site running on a free Atlassian Confluence Community License granted to MedBiquitous Consortium. Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.6.0 Build:#913 Sep 27, 2007) - Bug/feature request - Contact Administrators
Atlassian Confluence