April 3, 2009

Part II- LETSI Project – Web Services API for SCORM Run-Time Communication

Filed under: Uncategorized — Frank Polster @ 4:48 pm

We kicked off the project 25 March, with 16 folks joining us for an overview of the project and its goals.  Documents and minutes are posted on the project site.
One of the key discussion points was the need for a conceptual model for the web services API to manage run-time communication between learning content and a LMS or similar system.
Chuck Allen, Mike Rustici, Schwan Thropp, and Chris Guin have sketched out an outline and approach for the conceptual model which will be discussed at our second working session 8 April 09 1200hrs EST. If you have the time dial in and “brown bag” it with us (see below for details). We are looking for developers to participate in the project.
Conceptual Model –
Below is a rough breakdown of the phases and the requirements that would be handled within each phase. One of the key items for discussion I think will be signing up developers that are willing to look at different implementations – WS* or REST.  If you are interested contact us or attend this upcoming session on 8 April.
Phase 1
The first phase would be narrowly scoped. The work would largely be based on the conceptual model for the SCORM RTE as it exists today. Essentially, this can be thought of RTE web services designed within a SCORM 2004 context. However, certain extensions are contemplated for deployment within web services and to meet high priority requirements. Phase 1 itself would iterative and include several milestones and associated deliverables.
Within Phase 1, the scope of the initial round of work might include:
1. Working with essentially the same a set of operations as in the BBN web services RTE prototype. The BBN design would be updated so that it was “wrapped, doc/literal” style and conformant with WS-I basic profile.
2. Examining any necessary extensions to content packaging. These might include:
* An indicator to let the LMS know that the content will support the web services API.
* Elements to support the communication of credentials for access control. For example, an LMS ID and shared secret.
3. A number of RTE-specific details need to be defined or clarified. These include:
* Authentication of valid web services calls to the LMS. This might involve specifying use of some subset of WS-Security security tokens or simple convention using a share secret.
*  Defining how the launch of the content occurs. This initially would look at scenarios where the initial launch of content (whether browser-based and non-browser based) was browser-based. However, launch details for non-browser based content (e.g., Adobe Air) also would need to be considered.
* The web services API would need to be scalable. Of particular concern are the GetValue, SetValue operations. In the BBN prototype based on the ECMAScript API these are designed to communicate single parameters. Some notion of batching the communication of these items is necessary to minimize the number of calls across the network and optimize performance.
* There is the need to support asynchronous scenarios and sessions across extended time periods. The initial focus may be on scenarios involving content that was initially browser launched.
A second round of work, still within Phase 1, may bring in additional issues, such as:
* Sequencing
* Asynchronous/extended session support for content that wasn’t initially browser launched. (WS-I Reliable Secure Profile?).

Phase 2
Phase 2 would not be bound by the current SCORM conceptual model.
This Phase might incorporate new concepts being explored by other LETSI working groups (e.g., Orchestration).
Phase 2 might be more “resource-oriented” from the ground up. Design the RESTful web services first.
1. The need for speed. The goal is to have some Phase 1 working code in near term and to work in an iterative manner to fulfill the above requirements and those that may emerge.
2. Roles
* Architect
* Developers/Testers (need access to SourceForge?)
* Domain Experts
* Community of Practice Representatives. Need to come up with the right division of labor and meeting cycles to support the project.
3. The two-phase plan doesn’t necessarily imply that the work occurs in sequence.

4. Where to set up end points for testing? Content for testing
5. Many and various architectural and technical requirements.

8 April Project Agenda Details:
Concept Model Update – Chuck Allen et al
Source Forge Update – Frank Polster

Project Documents – see:
Date: 8 April 09

*  16:00 UTC
*   9:00am U.S. Pacific
*   noon U.S. Eastern
*  4:00pm UK
*  5:00pm France/Germany

Duration: 1 hour
Skype phone: +9900827049304412
Conventional phone: local number + access code 9304412
US 201-793-9022
Austria 0820 401 15470
Belgium 0703 57 134
France 0826 109 071
Germany 0180 500 9527
Ireland 818 27 968
Italy 848 390 177
Spain 902 881 270
Switzerland 0848 560 397
United Kingdom 0870 0990 931


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at

%d bloggers like this: