Travers - RTE Web Services

I have tracked Ginny's efforts in standards for immersive learning environments aka games for the better part of five years. Ginny was one of the key members of BBN's support to Ralph Chatham's DARPA DARWARS game project. Ralph had an idea that you could take a set of distributed users, playing in a set of different games, against a common training scenario, against a defined set of training objectives for the participants (individual and team).  

What emerged from the DARWARS program was not only a set of very successfully deployed training simulations (such as DARWARS Ambush!), but also a framework for configuring, coordinating and launching individual and team training and reporting and tracking trainees' performance against training objectives. This framework supports non-browser based, immersive, simulations (aka games for training) and uses web services to tie together separate components such as learning management systems, training systems, after action review and other assessment tools, etc.  

Under ADL sponsorship, this framework was extended to support integrated SCORM and game-based training; this paper outlines a web services interface for the SCORM runtime environment.  

I know this all sounds rather complicated and a little drawn out but I wanted to provide some context to what is a highly technical paper that is the out growth of 3 years of RDTE work with the DARPA project and 2 years of RDT&E prototyping with the ADL folks that implemented the developed web services in a game. There is a rather elegant architectural structure behind this paper that enables both individual and team training in games against defined training objectives and a set of competency models. Ralph's solution goes far beyond a "proposed design"; it has been implemented and used for several years.  

What Ginny's paper outlines are just those initial steps that provide a web services standard to enable integration of a SCORM runtime environment with immersive game-based training. This standard is a necessary first step and is a big deal. Ginny is to be commended for this great piece of work.  . .

I would love to see a web services interface to replace/compliment the EMCAScript API. I believe it is likely the best solution to the cross domain problem everybody thinks we need to solve.

I have one specific objection to the way this proposal implements a web services solution. This paper proposes that each SCORM API call be made as a separate web service invocation (please correct me if I misinterpreted).  That solution strikes me as not being scalable, especially when requests originate from a browser. Consider that just reporting the result of one interaction could take 6 or more SetValue calls. Now consider that John Campbell and Don Holmes just posted a papersaying that 250 interactions aren't enough. Also consider that most browsers only allow 2 active HTTP connections at one time. I've seen LMS's chose to implement the SCORM API by communicating with the server on every GetValue and SetValue call. In my experience, these implementations have been especially problematic.

I wonder if there is a way we could adapt this work such that calls are either batched or multiple data model elements could be sent in one call.

In our implementation of ITS in SCORM framework, we could not find better option than using web service for some of the evaluation features. I hope to see more use of web services.

I agree with Mike in that i have seen many issues surrounding multiple, sequential calls to the LMS.

In the "Browser Interface" section Virgina writes:
"this action [Terminate] is not sufficient to direct the RTE to deliver the next SCO"
The assertion makes sense, but how then, in this scenario will the SCO be removed from the users current session and what would be the impact on sequencing and rollup if any? I would assume that Terminate() call from the SCO through the Web Service to the LMS would work the same as Terminate() called from the RTE using JavaScript.

Just some things to think about.

Add my vote for providing Web Services based RTE for SCORM. It will certainly solve cross domain issues and also help supporting launching of courses from any system, say CMSs etc.

Another useful workflow that we are looking at is to support users to take courses offline using PDF or Adobe's AIR based applications or any other technology. Web Services based RTE is a must to support these use cases.