skip to main page content CETIS: Click here to return to the homepage
the centre for educational technology interoperability standards

skip over the long navigation bar
Press centre

Inside Cetis
what is Cetis?
Contact us
Cetis staff
Jobs at CETIS


XML: Click here to get the news as an RSS XML file XML: Click here to get the news as an Atom XML file iCAL: Click here to get the events as an iCalendar file

what are learning technology standards?
who's involved?
who's doing what?

CETIS Groups
what are cetis groups?
what difference can they make?
Assessment SIG
Educational Content SIG
Enterprise SIG
Metadata SIG
Life Long Learning Group
Portfolio SIG
Accessibility Group
Pedagogy Forum
Developer's forum

Accessibility (310)
Assessment (74)
Content (283)
Metadata (195)
Pedagogy (34)
Profile (138)
Tools (197)
For Developers (569)
For Educators (344)
For Managers (339)
For Members (584)
SCORM (118)
AICC (18)
CEN (34)
DCMI (36)
EML (47)
IEEE (79)
IMS (302)
ISO (21)
OAI (24)
OKI (20)
W3C (37)

print this article (opens in new window) view printer-friendly version (opens in new window)

How to let educational systems talk

The public draft release of the new IMS General Web Services spec, is both a relatively simple and pragmatic guide as well as a milestone of some import for educational technology. It essentially sets out how systems on a network can have a webservice conversation. It doesn't determine what the conversation is about, and the language is from somewhere else, but it does set the basic template of how to do web services in the e-learning domain.

In order to get systems such as VLEs and SRSs to talk, a number of things need to come together. Assuming web services as the means to communicate, some sort of description of a service needs to be drawn up. There's also the message format, the structure of the data inside the message, the means of shifting the messages about and the structure of the conversation. Aside from that, there's a whole raft of things that you can add to make the conversation secure, involve other systems, stitch different services together, make sure that the message has really reached its destination and much more.

Thing is, each and every one of these aspects can be done in any number of ways, which means that it is necessary for the maker of that VLE to know what choices the maker of that SRS has made for each of those aspects. Preferably even if that system sits on a completely different platform, or is written in a different language.

Fortunately, some of these web service implementation choices are widely adopted and the most common have been bundled into profiles. The best known of these is Web Services Interoperability (WSI), which essentially says that you should use the W3C's WSDL to describe your service and SOAP for the message format, and use use them in a specific way that is supported by most implementations.

Even then there are some choices to be made, and that's where IMS General Web Services ( GWS) come in.

The IMS group, co-chaired by Microsoft's Kathy Schroeder and Sun's Shrikanth Raju, have taken the WSI's 1.1 profile and narrowed it down still further, mostly in the areas of messaging models, error/status codes and where to place them, and how to construct the necessary control files for a service.

The main purpose of this profile is to structure specific IMS service specifications in a similar way. The IMS Enterprise Services spec, for example, has already been informed by the GWS approach and restrictions. Future IMS service specs will follow the same approach, and therefore only differ from each other in the data and behaviour that is specific to them. The idea is that the mooted Packaging Services spec, for example, should differ from Enterprise Services only in some of the operations and the data that will be carried in the SOAP messages.

That way, GWS supports implementors by making a lot of the code re-useable. But it doesn't stop there, since the General Web Services documentation itself carries quite a few targeted references on how to do web services to begin with.

Furthermore, GWS follows the new IMS specification process that is built on UML. The details are worthy of another article, but it essentially means that all data and behaviour of an IMS spec are modelled in UML diagrammes first. That UML is then used to generate all the control files; XSDs for a pure data spec and WSDLs and XSDs for a service enabled spec. But UML auto-generation is not limited to those technologies, it can also be used to create other representations such as RDF/XML or language specific code stubs (e.g. in Java). That opens up the possibility of generating OSIDs to complement Web Service definitions from the same source; an idea that has been around for a while.

The gubbins

The main choice the GWS group in making the IMS spec is to limit the number of messaging models to three for now: Synchronous Request/Response, Asynchronous Request/Response and Polled. These are essentially in ascending order of greater complexity, but also greater robustness.

Synchronous Request/Response will be familiar to anyone who has done some basic web server work, including the snag of an overloaded server being unable to fulfil a request, and thereby tying up the requester. Likewise the inability to find out what went wrong where if there is no response server down?, router on the blink? misconfigured firewall? etc.

Asynchronous is a little better in those regards in the sense that both the requesting and the providing system get acknowledgments that messages have been received (with some defined status codes for what's being done with these messages), and that the requesting system isn't tied up waiting for a response. But implementing such a messaging model means more coding for developers.

Polled Request/Response is more robust yet because the requesting system can do other things, and then poll a provider for a response. Publish and subscribe is also mentioned as a possible model, but it is not fleshed out yet in the public draft release.

Yet more messaging models can be added as and when required, so if they are deemed sufficiently mature and offer necessary functionality, new versions of GWS will appear. Final release of the spec won't happen until early 2006, so there may be some changes in the mean time.

Another major aspect of service communication that GWS advises on is how to handle status and error reports both generally, and for each communication model. Stuff can go wrong (or right!) in a myriad ways, but GWS makes the essential distinction between transaction status (e.g. whether that student really did get created in the VLE) and messaging status (e.g. whether the message about that student is being processed). Transaction status depends on the service definition, but messaging status is taken care of by both a fixed list of major statuses and values, and an extensible set of more detailed reports.

GWS also outlines in some detail how to construct the whole service definition document set. If you want to, both the data structure and service behaviour can be stuck into one single WSDL file, but there are three increasingly more complex sets of documents that import the necessary WSDL and XSD files in a defined hierarchy. Daunting at first, the multiple file solution has the clear advantage that only those aspects that require maintenance need to be changed, rather than the whole service definition.

Though WSI, from which GWS is derived, now has a basic security profile (WSI-Security minimalist profile), IMS has chosen not to go down that route just yet. It merely advises to use https when needed.


IMS General Webservices public draft is a mere two documents and a handful of examples, all of which are available from the IMS website.

Related items:


No responses have been posted

Creative Commons License This work is licensed under a Creative Commons License.

syndication |publisher's statement |contact us |privacy policy

 go to start of page content