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)

Redwood group maps Managed Learning Environments

When any new technology comes on the scene, there's always a scramble of people figuring out methods, and trying stuff that'll work for them. Service oriented approaches (soa) to Managed Learning Environments (MLEs) are no different. Just as certain, however,is the point at which some structure and coherence is brought to bear. For service oriented MLEs, that is exactly what the Redwood Group is planning to do.

Co-ordinating service oriented approaches to MLEs is a bit more challenging than most because each specific approach will have its own requirements and legacy systems to support. Even within an implementation different groups of users wil have different existing and future 'ways of doing things' (business processes) that all need to be taken into account. Jump one level up to a coordinated approach to designing architectures, and the degree of variation starts to look a little daunting.

Nonetheless, the participants represented in the Redwood Group have each already tried such a thing by focussing on specific sectors or technologies. The Schools Interoperability Framework (SIF), for example, has been successfully integrating systems in the US k12 sector for a fairly long time. Though it is called a framework, it specifies each service in precise detail, and has a programme that certifies conformance.

Sun and Microsoft also participate, and bring not just the underlying implementation platforms that most people will use —J2EE and .Net, respectively—, but also specific sets of system integration solutions based on their products. Busy implementation communities that make use of these products also come along.

Sakai brings not just an approach and components, but a complete system into the mix. A work in progress, the multi-institution initiative is building a coherent set of applications with sets of interfaces to facilitate building more Sakai components or to allow integration with existing systems.

On the specification body side, both OKI and IMS bring their specifications into the Redwood group. For OKI this means a specific architecture and a set of interfaces (Open Service Interface Definitions) that allow service exposure and consumption. For IMS, that means the general approach defined in their Abstract Framework, and a growing body of loosely coupled webservices that allow a wide variety of systems to share data and functionality. The two approaches can be usefully combined.

Also represented are user communities such as EU Schoolnet, Industry Canada, Australia's Department of Education, Science and Training (DEST) and JISC/CETIS. The latter three have already come up with a collaborative service oriented approach —the E-Learning Framework (ELF)— and are busy specifying service interface definitions as well as open source toolkits that allow people to integrate these services with new and existing applications.

Not that the list is exhaustive or finite: the Redwood Group is open and pretty informal. Started at this year's Alt-I-Lab interoperability conference, colloboration takes places over the humble Yahoo group service that has also served the original RSS and SOAP development groups well.

All of which is very well and possibly quite impressive in breadth, but leaves the question what exactly is involved in making al these approaches coherent.
For that, the Redwood Group has a number of deliverables planned.

First among these will be growing a list of reference implementations and papers. Not just from the e-learning world, but also beyond, both because other sectors have had a bit of a head start in the soa field, and because a number of the services required in an MLE will not be specific to e-learning.

Also in the process of collection is a set of common business process models and software patterns and anti-patterns. That is, a library of the kinds of procedures and tasks a soa MLE needs to support, and a library of software designs that can be used to support them.

The heart of the matter, though, will be a set of presciptive guidelines about how to factor, design and implement service interface definitions and a set of agreed service models. Factorisation and agreed service models are the heart of any service oriented approach, since they need to be stable and widely agreed. The specific binding on a service can be altered relatively easily, and the same service can be exposed using more than one interface or even interface technology. Ultimately, services are all just interfaces to systems that act on their own internal data and business logic. But the basic cut of what kinds of data and behaviour a particular service needs to expose is not so easily changed once its been decided.

Not that the effort is solely technical; a business case for service oriented approaches is also planned shortly. This document will outline what the risks, advantages and return on investment is like for institutional managers who are thinking of going down the service oriented route.

The current set of deliverables is planned to be completed in a year, and after that, depending on demand, the group might dissolve itself. In that sense, it is very much a task oriented, ad hoc group that has little interest in adding itself to the pile of e-learning specification and standardisation bodies.

Given the wide scope of MLEs in general, and the diversity of service oriented approaches, the goals of the group look fairly ambitious. Success will be determined largely by the degree of commitment from the participants. Fortunately, there is one aspect of soas that is working in their favour: it is inherently modular. Not everything needs to be agreed right down to running code, either in the software or in the functional sense. Agreement on any level is useful, and can be picked up and filled in by narrower groups with specific requirements.


All Redwood Group documents and discussion can be found on the Redwood Yahoo Group.

Update: There's an interesting take on the Redwood Group in an eWeek article that rather emphasises the Sun - Microsoft collaboration aspect. Which is indeed praiseworthy, but something the companies have been doing within IMS for a long time now- including on webservices.

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