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)

IMS publishes service oriented architecture whitepaper

The paper is a revised version of a document presented during last year's alt-i-lab conference (the old version date is still on it), and is indeed well worth revisiting. In it, Four experts from IMS, Sun, Microsoft and the Open Knowledge Ininiative (OKI) consider the fundamentals of the approach as applied to the learning, education and training sector.

The first part of "Basic Architectural Principles for Learning Technology Systems" is a pretty handy and readable introduction to the whole area of service oriented architectures (SOA), and outlines most of the conceptual aspects that drive it.

The beef, however, is in the exposition of three main ideas: the distinction between consumer oriented interfaces and provider oriented interfaces, the importance of framework flexibility with rigid functional factoring and the modular nature of a service.

The distinction between consumer oriented interfaces and provider oriented interfaces is a further exposition and generalisation of what has been referred to as the distinction between Application Programming Interfaces (APIs) and (web) service interfaces. In concrete terms, it is the difference in purpose between something like the OKI repository Open Service Interface Definition (OSID), and something like the IMS Enterprise Services spec.

The first is used mostly in situations where high performance is critical, and on a single machine. It basically is meant to shield the application that gets data and behaviour through the interface from how that data and behaviour is pumped in. Hence 'consumer oriented'.

Provider oriented interfaces such the IMS Enterprise Services spec are designed from the opposite point of view: whichever application offers the service should be shielded as much as possible from where the consuming applications sit and what they look like, or how many there are. The spec is known, and the consumers have to fit what it does.

The contrast makes clear that for maximal flexibility for a whole system now and in the future, it's best to use both consumer and provider oriented interfaces in the same environment.

The need for flexibility at the system level (i.e. a whole Managed Learning Environment) will probably be familiar to anyone who's tried to manage an institutional network for a while. In a word, you never know what kind of services will be required a few years or even months down the line, and when it happens, you don't want multiple systems that fall over or need major revision to accommodate the new demand.

The IMS whitepaper, however, shows the inevitable flip side of flexibility in one aspect- you buy it with rigidity in another. The rigidity in a service oriented architecture is bought from the factorisation of the services, it is argued. Though applications can't know or need to know what other services are available in the system, they do need to be consistent in what they offer themselves.

The whitepaper authors draw that down to not just the level of a service's scope and definition ('this is my job'), but also the exact service contract ('this is how I do my job'). They even state that "It is common for an individual service to be deployed long before any consuming applications are even developed, let alone deployed."

Though that might be true in a well understood and mature architecture, it leaves a bit of a developmental question. To be fair, the authors didn't aim to address the question of how to develop a SOA, but for something to work well for years, you have to test it in anger for quite a while too.

Fortunately, the modular nature of services as described in the paper point to a means of making the development of services rather more doable. Services themselves can be broken down along two dimensions and therefore four 'slots' that can each be defined independently. Viz: services have behaviour (what I'll do given your message) and have data (the structure of the messages). Both behaviour and messages can be expressed in different ways. If any four of these turn out not to work well, it ought to be possible to change it, without disturbing the others.

If any of this sounds familiar to some, it is because the E-Learning Framework is built very much on the same principles as those outlined in the whitepaper. Conceived around the same time, and on the lessons of the OKI, IMS Abstract Framework, Sun's e-learning platform and Microsoft's web service work, both the paper and the framework suggests that the time has come to start building a service oriented approach to learning.


The "Basic Architectural Principles for Learning Technology Systems" white paper is available from the IMS website (124 Kb, pdf).

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