Last week, I attended the IEEE Learning Standards Technology Committee (LSTC) meeting in Alexandria, VA. There are at least a couple topics discussed at the meeting I'd like to cover. I'm starting in reverse order in this post since I'm covering a topic discussed on the last day of the three-day meeting.
On that third day, Chris Guin of BBN joined us to review the "SCORM RTE Web Services Interface." This was developed as part of an "Integrated Prototype Architecture" funded by Joint ADL Co-Lab beginning in 2006. A paper describing this work was submitted in 2008 in response to LETSI's call for papers on requirements for a successor to the current-day SCORM standards. As the paper describes, the web services interface follows "as closely as possible" the SCORM ECMAScript Interface for Content to Runtime Services Communication (IEEE 1484.11.2-2003).
A key difference between the two versions of the same interface is that while the ECMAScript API facilitates communications to an LMS from a Sharable Content Object (SCO) delivered within web client, the SOAP-based Web Services interface allows any application to act as an SCO. Thus, the web services version opens up the opportunity to use SCORM for integrations where content is delivered within a specialized simulation or game application rather than just a browser.
Chris walked us through the interface, which is formally described in this WSDL. A next step discussed for the IEEE LSTC will be to take the work started by BBN and formalize it as a standard, similar to what IEEE LSTC did with the ECMAScript interface standard. BBN's design and IEEE LSTC's next steps on a standard version of the web services interface are sensible and consistent with prior work. However, if you crack open the WSDL as well as take a look at the ECMAScript interface on which it is based, you can get a few clues on where a new, more broadly scoped examination of learning content integration might go. This is the type of work that LETSI is beginning.
Looking at the SCORM RTE Web Services Interface WSDL, you can see that this is a "code-first" versus "contract-first" approach. A code-first approach isn't surprising since the goal was to implement functionality that already existed. You also can see that the interface was implemented within WSDL using a remote procedure call (RPC) style. Again, this design is understandable since it is likely closest to the functions within the existing ECMAScript API on which the web services binding is based. While these choices are understandable within the design scope for this particular web services interface, I think you can safely say that this design would be not a good starting point for next-generation web services to support learning content integration. There are a few different reasons. A simple reason is that this design fails WS-I interoperability profiles. However, I think that a bigger, more important reason is that the RPC-based design obscures key entities or "resources" that likely should be explicitly defined and considered within next-generation standards.
One of the suggestions I made at the LSTC meeting is that the group consider sketching out a RESTful web service before working on the SOAP-based version of the web service. Upon further consideration, I think this is better advice for LETSI in starting its next-generation work than for LSTC in formalizing the existing web services binding based on the ECMAScript Interface. After further study, I'd say that creating a RESTful web services version of the existing ECMAScript API is simply a case of "can't get there from here" (at least not in an elegant way).
For LETSI's next-generation work, starting by sketching out a RESTful version of the web service before developing a SOAP-based version would provide some useful constraints. In RPC-based designs, noun and verb tend not to be as clearly delineated as they should be. Also in the RPC design, you'll tend to proliferate a lot of specialized, "activity-based" operations (e.g., "terminate," "initialize" being examples). Sketching out RESTful services forces you to consider exactly what entities are being managed and to define them a bit more explicitly.
In the case of the SCORM RTE interface, the main resource being managed is a "communication session." At first glance, I know a few people will wonder if whether a "communication session" is a resource at all. But a tenet of RESTful design is that you take "session state" and convert it to "resource state." So instead of special-purpose "initialize" and "terminate" operations in the RPC interface, you'll do something like posting "active," "complete," and other relevant states to a "communication session" resource. This is very different from the RPC design, but those designing the next-generation of learning, education, and training interoperability specifications will soon realize the benefits. My guess is that "communication session" is a resource LETSI will encounter in many other areas of its work, such as "orchestration" (the LETSI development effort looking beyond the "sequencing" concepts used in today's learning standards). So under the RESTful approach, in some respects you'll proliferate more "resources," but you'll wind up reusing these resource definitions across multiple interfaces.
Are these the ravings of another REST zealot? No, not at all. Hopefully, I'm stating the obvious in saying that the RPC-style design used in SCORM RTE Web Services Interface -- while understandable within the design-scope within which it was developed -- is a dead-end (or should be) in terms future learning content interoperability work.
I expect that SOAP-based web services will be a priority of many LETSI development efforts and will remain a primary focus of many LET system stakeholders. However, starting with RESTful web services builds in constraints that rein in complexity, which is important since the scope of LETSI's work is potentially quite large. I fully expect that LETSI's work will not be strictly RESTful. For instance, I can imagine LETSI SOAP-based web services going beyond REST's narrow verb set and specifying verbs with additional business semantics that stakeholders may require. However, even if this occurs, LETSI will still be in good shape if what results are SOAP-based web methods specified using a consistent verb-noun convention that can easily be translated to a simplified RESTful form (as opposed to "can't get there from here").
The above is strictly my own opinion. For those interested in learning more, LETSI has a conference call scheduled for Wednesday, March 25, Noon EDT (1600 UTC) that will focus on work relating to the RTE web services interface. For further information, contact LETSI.
