Learning RTE Web Services Project 2009 April 1 Chuck Allen Chris Guin Mike Rustici Shawn Thropp The purpose of the call was to explore a conceptual model for a web services API to manage run-time communication between learning content and a LMS or similar system. There was a consensus that it would be best to approach the project in phases. Below is a rough breakdown of the phases discussed and the requirements that would be handled within each phase. 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. The WS-I.org Basic Profile favors the “wrapped, doc/literal design.” This also tends to be less problematic in certain Microsoft tools. A good explanation of this design style is found here: http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html 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 shared secret. Defining how the launch of the content occurs. This initially would look at scenarios where the initial launch of content is browser based (but allow for the content to be either browser-based or non-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: Defining how content that communicates via web services (potentially ayschronously) is sequenced by the LMS. 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. Issues 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.