SOAP for SCORM

At DevLearn 2010, Ben Clark and I presented a session named SOAP for SCORM on behalf of LETSI. The topic was the LETSI Run-Time Web Service (RTWS), a proposed modification of SCORM to use SOAP for communication rather than the current JavaScript model. I presented the first half of the session, covering the basic “what” and “why” ideas while Ben covered the technical “how” details in the second half.

This blog post is my attempt at documenting my portion of the session. Bear in mind that there was a lot of Q&A from the audience, and much of the session was ad-libbed. The descriptive text presented below may not exactly match was what in the session, but the gist is there.

If you’re interested in the nitty-gritty technical details, check out the Developer’s Guide on the LETSI website.

The Presentation

SOAP for SCORM: Linking Training Apps to Your LMS with LETSI's Run-time Web Service (RTWS)

 

Learning Education Training Systems Interoperability

Some quick background information on the LETSI organization.

LETSI stands for “Learning Education Training Systems Interoperability”.

LETSI believes in pushing training systems forward through agile, iterative software development. Make things quickly, get feedback, and make changes. In our current Internet age, we don’t have the time to take years developing a spec. Make something that works, then turn it into a spec.

LETSI believes in engagement with standards bodies and vendors throughout the process. If a new technology is to become mainstream, it’s vital to get vendors in on the action. Make them stakeholders and get them involved in the project at an early stage.

Unlike some standards bodies, LETSI is transparent and open — there are no strings attached. Membership is not limited to corporations or agencies. Want to have a say in the future of training technology? Join LETSI and you could be on the conference call next week.

 

What is the RTWS? An alternative to JavaScript

Simply stated, LETSI’s Run-time Web Service (RTWS) is a replacement for the SCORM JavaScript API. There are some other features that go beyond SCORM 2004, but the bulk of the RTWS is focused on replacing the JavaScript communication system with a SOAP system.

 

SCORM API: A JavaScript object in a web browser window

The current SCORM architecture requires that courses be launched in a frameset or pop-up window.

 

Course pop-up window communicates with LMS browser window via JavaScript

The course frameset/window contains a JavaScript-based API that communicates with the parent frame/window (the LMS website).

 

LMS browser window communicates with LMS server/database via JavaScript and server-side scripting

The LMS website typically performs data gets/sets on a database using a combination of ajax (xmlhttprequest) and server-side scripting (PHP, ASP, Java, etc.).

 

LETSI Run-time Web Service: A direct connection between the course and the LMS via SOAP (XML)

The LETSI RTWS changes the architecture to eliminate the middleman (the LMS website), allowing the course to directly communicate with the LMS backend using SOAP. (SOAP can be loosely described as XML sent via HTTP requests.)

 

What does this mean? (and why should I care?)

 

No more dependence on Web browsers

Replacing the JavaScript API with a SOAP system means the course no longer needs to be launched from the LMS. If the course is no longer required to be launched from an LMS, the web browser itself becomes optional, enabling the course to be launched from a variety of environments, including mobile apps, desktop apps, hybrid Web/desktop apps such as Fluid, Prism and Adobe Air, and other software solutions such as virtual worlds and serious games. This effectively makes SCORM’s CMI data model available to almost every software/web-based training solution.

No dependence on the web browser also means the course content can be hosted anywhere, and is no longer required to be stored in the LMS system.

Note: In some prototypes, the course must be launched from the LMS for the first attempt. This is due to registration requirements that are still being ironed out.

 

Better security

The JavaScript API has long been the weakest link in terms of security; it’s easy to hack and can’t be encrypted. Replacing the JavaScript API with SOAP (XML served via HTTP/HTTPS) enables courses to use discreet, secure communication via HTTP POSTs, similar to banks and other sensitive systems. RTWS courses will be protected via a combination of a shared key (a hash stored in both the LMS and the course’s code), user name, user ID, and a secure password incorporating SHA-1 encryption.

IMPORTANT: Since the shared key and the password are contained in the course’s code, the course will only be secure if the developer keeps it secure. For example, using JavaScript to handle your SOAP calls will make your data viewable to the client. If you keep all of the SOAP work behind the scenes using server-side code, your course will be much more secure.

 

Better accessibility

The accessibility benefits of the LETSI RTWS are debatable, but here are some of my personal beliefs about how the RTWS can make a course more accessible:

1. Since the RTWS discards the SCORM JavaScript API, a web-based course can be built to run without without a single line of JavaScript (traditional form POSTS and server-side code can process the SOAP requests). I’m not saying JavaScript is bad, but it’s a fair assumption that in most cases pages that don’t require JavaScript are more compatible with alternative browsing devices.

Also, as a developer, I know first-hand that when JavaScript is *required* for a course, many developers feel they’ve been given carte blanche to go hog-wild with JavaScript; for example, they might use it for interactive widgets that require a mouse (not keyboard accessible) and dynamically update/generate page content using ajax (difficult for screen readers and braille displays). These situations are problematic for people who use assistive technology; by eliminating SCORM’s JavaScript requirement, we can force developers to take a closer look at why and how they’re using JavaScript, hopefully leading to a more accessible course.

2. No reliance on web browsers means a course can be built in a desktop app or other environment that may (or may not) be more accessible than a web site or Flash movie. Of course, this is completely up to the developer, but the possibilities are there if the developer chooses to go down that path.

 

Less restrictive development environment

Under the LETSI RTWS, courses no longer need to be uploaded to the LMS and can be stored on ANY web server. There are several useful byproducts of this:

1. Course manifests no longer need to list every course asset. (Manifests are still required because they contain core data about the course, including the shared secret.)

2. If you’re a course vendor, you can maintain control of all of your course materials and simply provide a link and manifest to clients. No more ZIPs!

3. Since the course materials remain on your server and are not required to run on the LMS server, you’re free to use server-side code (previously a taboo in SCORM).

 

What’s the catch?

 

Requires more work

Despite their often negative reputations, LMSs provide a key service for your SCORM course: a SCORM API with error-checking (including error/debug messages) and behind-the-scenes handling of the CMI data model for you. The RTWS is not currently equipped to provide detailed error messages regarding the use of the CMI data model; if you choose to use the LETSI RTWS in place of the SCORM API, you will no longer have the benefit of the SCORM API’s error messages.

In the RTWS each ‘set’ request is an XML document created by your course and submitted to the server via HTTP. Since your course is creating and submitting the XML, it must use its own logic to determine if there are any errors, such as malformed XML or misuses of the CMI data model. For example, if your course accidentally tries to set a read-only field such as learner_name, you will not receive any error messages. It is up to your course to ensure the specifications of the CMI data model are being followed.

(Hopefully in the near future there will be 3rd-party libraries or frameworks that will provide this logic for you so you won’t have to write your own.)

Also, your course must be using a technology that supports SOAP.

 

Only supports single-SCO courses

The RTWS currently only supports single-SCO courses, and does not support SCORM 2004’s Sequencing and Navigation rules.

On a related note, since the content is being abstracted from the LMS, the LMS’s SCORM “player” will not be available to the RTWS course.

 

http://letsi.org/rtws

You can read more about the RTWS at http://letsi.org/rtws

Reminder: LETSI membership is open to the public. If you’d like help shape the RTWS (or other LETSI projects), join us!

Additional notes and tidbits not covered in my portion of the presentation

  • I briefly demonstrated a prototype I created for Flash-based courses. My prototype uses a modified version of my pipwerks SCORM ActionScript wrapper, allowing developers to simply swap out the pipwerks SCORM class file with a new pipwerks LETSI RTWS class file and still have their course behave as it did with SCORM 2004. This prototype is not available to the public yet, but when I’ve worked out the bugs I will be sure to post a blog entry about it. Stay tuned!
  • The LETSI RTWS is based on the SCORM 2004 (4th Edition) spec and uses the same CMI data model.
  • Because the RTWS uses a new launch approach, support for querying the course’s attempt history has been added to the data model (see GetAttempt and GetAttemptList in the RTWS documentation).
  • Unlike SCORM, a Get request in the RTWS returns the entire data set in an XML file. It’s up to the course to parse the XML and extract the value for a particular CMI element. I’ve whipped up a document mapping the CMI elements to their XML equivalents.
  • A Set request can be partial (set a single or small group of elements) or complete (set the entire data model).
  • SCORM’s Initialize() and Terminate() methods are not currently used in the RTWS.
  • Rustici Software (scorm.com), Booz Allen Hamilton, and Meridian are all creating LMS prototypes that support the RTWS.
  • Rustici Software hopes to fold support for the RTWS into its SCORM Cloud service once the RTWS is ready for prime-time.
  • The ADL (owners of SCORM) are not involved with the RTWS, but they are aware of its existence and are monitoring the situation. In a separate action, the ADL is requesting input on the future of SCORM via Project Tin Can. It is LETSI’s hope that the RTWS, when ready, will be folded into the ADL’s plans for SCORM and that the two will co-exist peacefully.
Advertisements