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.

New SCORM ebook coming soon!

I'm writing an ebook explaining how to build an HTML-based SCORM course. Subscribe to be notified when it's ready, as well as receive early bird pricing and some free goodies!

No spam, no sharing your email address, unsubscribe at any time. Powered by ConvertKit
Advertisements

17 Replies to “SOAP for SCORM”

  1. Wow! This is HUGE! Thanks for the links and the update. I work for the Commonwealth of Virginia and they currently use Meridian as their state-wide LMS solution. I can’t wait until this gets rolled out. Nice presentation and easily understandable. Thanks Philip!

  2. You may want to add that while RTWS only supports single SCOs, a single SCO could actually be a very robust learning experience with internal branching, adaptive behaviors, etc. so you can still do all of the things S&N allows, it just won’t be interoperable or supported by RTWS. I’m always afraid that when we say only supports a “single SCO”, it gives the connotation that the SCO is just a short, plain, simple lesson without interactivity or adaptive capabilities.

  3. Cool idea, and hope it goes through.

    >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.

    In my opinion, the error-checking/handling in 90% of LMSs is horribly poor anyway, so this doesn’t seem as a major drawback.

    Thanks for sharing, and wish I saw the presentation at DevLearn.

  4. Awesome. There is so much potential in this concept. I don’t think it’ll be that much more complex to implement in a content package than current constructions once it gains maturity.

    Many are confused by the simple SCORM API stuff, but frameworks that bolt it on in “it just works” mode. If RTWS framworks function similarly, the abstraction can easily isolate levels of developers / assemblers that aren’t comfortable with the complexity of that layer away from it.

    I can’t wait to see this take hold. Really exciting stuff! 🙂

  5. Philip,

    I’m curious whether ADL or LETSI ever considered a REST over SOAP. It seems to me that SOAP would be a bit more difficult to grasp by general e-learning practitioners, designers, and even developers. Any insights?

    Thanks for your blog and sharing over the years. I’ve solved a few problems using your codes. I wanted to tell you that, and introduce myself at DevLearn, but I never got to see you.

    Garrick
    web creative
    eLearning Guild

    1. @garrick

      thanks for the kind words.

      RE: REST over SOAP, I know it was discussed, but it was before my involvement, so I’m not privy to the particulars of the conversation. However, I can (unofficially) say that some of the LETSI folks I’ve spoken with are aware of SOAP’s drawbacks, and appear open to the idea of using REST instead of SOAP. The RTWS project is still in prototype, which means it’s still malleable, and perhaps LETSI will work on a REST implementation if enough people voice support for it. Anyone can join LETSI and put in their 2 cents!

  6. Philip,

    This isn’t a comment, but I couldn’t find anywhere else to thank you for your PDF Object Code Generator so I thought you’d see it here. It was a GREAT help. I tried to a couple hours to validate “embed src” and then found your site.

    I thought you’d like to know there is one tiny flaw in the Standard Markup generator. It doesn’t close the with . It generates

    Again, thanks

  7. also not on topic but EasyCaptions articles are timed out for comments –

    Big Thanks for EasyCaptions – A bit of searching indicates someone wants to hire a freelancer (in the worst way) to make EasyCaptions work with dfxp format by reworking the js no less (the worst way)

    I took a dfxp xml snip into gnumeric and got something out that will work with EasyCaptions.

    I think EasyCaptions method and format should be a standard – thanks again.

  8. Seem that Philip’s posts are closing too soon anyway 🙂

    Phil, I think it’s great to have you detail projects that way. I am a bit worried that RTWS would take years to get widespread adoption, but… I wish it the best.

    On a side note, I’ve been trying to find out what it is you do exactly and the only thing I found on your about page is that you’re a “instructional technologist” and that sounds a bit “undefined” to me. Mind telling what’s your daily job like?

    Sounds pretty useful to me that you’d have a technical blog like that. Actually, and even if I obviously have less time to give them a stylish finish like yours, I have pretty much the same kind of professional interests so I think I’ll be watching it more closely in the future. Way to go!

  9. @john thanks, sorry about the comments timing out.

    @yannick thanks. i’ll have to write a post about the ‘instructional technologist’ title, as most people have no clue what it means, though i must admit i kind of like it that way!

  10. I’m mostly interested in how you got involved professionally into designing SOAP for SCORM. Is that something your employer is asking/motivating you to do? Sounds like a lot of fun to me.

  11. @yannick i got involved with LETSI because of their work to push SCORM forward, and one thing led to another.

    to be clear, i didn’t design the RTWS system — it was designed by the LETSI RTWS working group. my role (so far) has been limited to giving feedback about the RTWS from a client perspective, building a client-side prototype to work in conjunction with the server-side/LMS prototype built by Ben, and speaking at DevLearn. the RTWS working group did all the heavy lifting.

    as for employer support, unfortunately, my (former) employer had no involvement and did not support or encourage my efforts at all. (hence the word ‘former’!) i worked on it in my spare time as a labor of love.

  12. We have over 3000 courses in our elearning system. Porting these to use whatever new technology is not trivial. As a matter of fact we have no need to have our courses to be outside of our servers since this will make it impossible to track changes. Most of our courses are for legal compliance. The idea that any course from anywhere connect to our LMS to persist data is not going to fly with our legal department.
    Honestly I really don’t see the need to use web service/SOAP for course-to-LMS communication. This will make it overly complicate. We used simple json/ajax technology with much success.

  13. The course does not have to be launched from an LMS, and thats cool, but the service does not need to be part of an LMS either — and thats even better! It could be a part of some sort of cloud service enabled by single sign on of sorts. And the course could be something else than a SCORM course, but still be using the service — and then we could really be going somewhere.

    The whole SCORM/LMS-thing is a total mess and have been hampering e-learning for too long!

  14. I think this is a brilliant idea! It would provide course developers with more flexibility, and it would give us the ability to track use of job aids and other performance support materials.

Comments are closed.