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)

Gluing learning applications together with SOAP

image:Gluing learning applications together with SOAP

In our previous article on architectures for learning systems ("The next big thing…") we talked about some of the ways that different standards-compliant programs could be connected using "services". In this article we look at what kinds of services we might use in education systems and take a more detailed look at SOAP, one of the technologies that may be used to implement them.

Services are parts of functionality that one application provides to others. The idea is that rather than each piece of software trying to do everything (and thereby replicating existing functionality), the various applications that make up a system instead make use of a single application that provides that service.

For example, a student administration system could provide a number of services:

  • Student validation service: Provides answers to questions such as "Does the student exist?" and "Are they registered on this course?"
  • Student details service: Provides details for a specific student, such as preconditions met or their accessibility profile
  • Student registration service: Allows students to be registered on a course.

This is by no means an exhaustive list, but gives some of the flavour of application services.

Now imagine you have several applications – a student administration system, a virtual learning environment (VLE) to play course materials, and a repository of resources to play in it.

If each application is aware of - and can make use of - the services offered by the others, then you have gone some way towards interoperability. The student can log onto the VLE and request a tutorial, and the VLE can then check the student is registered by using the administration systems' validation service and retrieve the content from the repository using the repository’s retrieval service.

Now we have a set of specifications for how data should be represented by these systems, as IMS Content Packages, Metadata, Learner Information Profiles and so on. So when the repository sends the content to the VLE then - provided both applications are compliant with IMS Content Packaging - the VLE can make sense of the material it receives.

Likewise, if the VLE wants details of the student, then the administration system can use the IMS LIP (Learner Information Profile) or IMS Enterprise specifications to return a description that the VLE can make sense of if it also implements the appropriate specification.

Unfortunately, the actual services that you would use to move this information around (like how to ask the repository to return a particular IMS Content Package) are not defined in current specifications. So, although both the VLE and the repository both understand IMS Content Packages, there is no standard method that they can use so that the VLE can ask for one!

Communication between learning applications is hampered by the lack of common message protocols and formats

Take one example: SOAP

If there was a standard way of providing services, what might it look like?

Well, one useful standard for implementing services is gaining a lot of popularity at the moment. Its called Simple Object Access Protocol (SOAP), and it makes use of the HTTP protocol used to request web pages from web servers, and combines it with XML to pass structured information back and forth between computers.

SOAP isn’t the only method available by any means – there are other standard protocols out there that use XML - take a look at this table on the W3C website to see a rundown of the more common ones. It does, however, have the advantage of being relatively easy to use, and works with practically any platform using any programming language. And we have to start somewhere!

So how would you go about providing services using SOAP?

Now at this point we’re going to start getting technical; so if you’re unfamiliar with either HTTP or XML, you may want to take a look at a primer on these terms first, such as Webopedia.


SOAP, simply put, sends XML "envelopes" using HTTP. A typical HTTP request contains a header identifying the resource, and possibly a "payload" containing some query items; for example, the URL requests the resource /content and passes it the value 10 for the variable "Page".

Using SOAP however, the HTTP payload is an XML file, like this:

POST /student-service HTTP/1.1
Content-type: text/xml
Content-length: 953
SOAPMethodName: urn:student-service:services#validateStudentRegistered

     <m:validateStudentRegistered xmlns m:=’urn:student-service:services’>
        <student id="110001">
        <course id="139391" name="SOAP Tutorial"/>

Lets take this one piece at a time.

The first two lines tell us that this is a request for the page /student-service on a server with the IP address using HTTP version 1.1.

The next two lines tell us that the payload is in XML format, and is 953 bytes long (the software works this one out – you shouldn't need to count characters manually!).

The last part of the header identifies the SOAP method that the request should call at /student-service. In this case we’re calling validateStudentRegistered. Note that this must be the same as the first line underneath the tag in the payload. Alternatively, the SOAPAction header can be used to simply route the request to a handler. In this example it could be:

SOAPAction: "/student-service/validatestudentregistered"

Finally, we have the XML message itself. SOAP only defines a couple of standard parts for a SOAP message:

  • <Envelope> contains the whole message
  • an optional <Header> element that can contain other information about the request (for example, to include details used in the BizTalk specification)
  • the <Body> element containing the message itself.

In our example, the message contains a <student> and a <course>. Currently there are no standard XML message formats for learning technology, so I just made that one up. If SOAP were adopted as a standard messaging protocol for interoperable learning systems, then perhaps organisations like IMS and ADL would provide specifications for how the body should be composed for a particular service message.

Now provided the format of my message is comprehensible to the server providing the service, I can send the message using HTTP and get a response back, perhaps something like this:

     <m:validateStudentRegisteredResponse xmlns m:='urn:student-service:services'>
        <Registration status="current" expires-on="12/11/2003">
           <student id="110001"/>
           <course id="139391"/>

This message tells me I’m currently registered on the course, and that my registration expires on the 12th of November 2003. Of course this isn't in the format you’d expect if you were using the IMS Enterprise specification, but serves as a simple example.

As you can see, the basics of SOAP are very simple. So how do you implement SOAP in your application?

There are a number of standard libraries and modules available now for most programming languages and platforms. Many of these are free, open-source projects, like pySoap for the Python language or Spheon JSoap for Java.

Using a SOAP library it is often possible to use SOAP without worrying about composing the actual requests; many current libraries will translate the response into native data types for the language you’re working with so you don’t have to bother manually parsing the XML body itself.

For example, this Python script uses SOAP to return a string from a function provided by a remote service:

# Import the SOAP library
import SOAP

# Define the function we are going to use.
# Sends message to CETIS15 and returns reply.
def getEcho():
  server = SOAP.SOAPProxy("")
  return server.echo("Hello World")

The server code looks like this:

# Import the SOAP library
import SOAP

# Define a function call that returns the string sent to it together with a Hello message
def echo(s):
  return "You said:" + s + "\n " + "Hi from CETIS15"

# Create a SOAP server and register the function call with it
server = SOAP.SOAPServer(("", 8080))

When the client code is executed, we get:

You said: Hello World
Hi from CETIS15

Although both the request and the response are made using SOAP, this is transparent from the application developer’s point of view; we are simply calling a function that happens to be on an application running on a remote server, and the protocol we are using is SOAP.

There are still some issues in SOAP about parsing certain data types – particularly elements like arrays – but simple types like strings, integers and so on are not a problem, nor are objects composed from simple types. As time goes on we’ll see most of these issues sorted out; given the number of developers using SOAP this is almost inevitable.

The most important issue with SOAP is performance; SOAP messaging is certainly not as fast as API calls in a more tightly coupled system. One possible workaround is a "handshake" process when two servers talk for the first time using SOAP; if both machines also support RMI or COM then they can "switch up" to the faster protocol. SOAP, however, is a good common-denominator protocol that most applications will be able to support and makes a reasonable starting point for applications to talk to one another.

In Conclusion

I hope you’ve found this introduction useful. Like most new technologies, the premise is fairly simple; the devil is lurking in the details of implementation. If you want to learn more about using SOAP from a developer’s perspective, then here are some good resources:

A Busy Developers Guide to SOAP
A Young Persons Guide to the Simple Object Access Protocol
SOAP frequently asked questions

Related items:


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