190

IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES,

ReST-Based Web Access to

Learning Design Services
Juan Manuel Dodero and Ernie Ghiglione
AbstractThe IMS Learning Design model defines how users are engaged in
learning activities to use learning objects and learning services. Although these
are similarly accessible from URLs in a learning design, they are essentially
different in the form of accessing their features and operations from a learning
activity user interface. This paper proposes a Representational State Transfer
(ReST) architectural style of accessing a learning service and its constituent
resources from a Web-based environment. A methodology to guide the design of
learning service access is also described. The method is applied to integrating
operations of a generic wiki service in the client interface of a learning activity and
validated on actual wiki services providing ReST-based programming interfaces.
Index TermsComputer-assisted instruction, Web-based services, software
architecture patterns, hypermedia architectures.

INTRODUCTION

A Learning Design (LD) defines a set of people in specific groups

and roles engaged in learning activities with a number of resources
and services. The IMS LD specification provides a framework of
elements, such as learning objects and learning services, which can
be used to formally describe an LD. What distinguishes a learning
object from a learning service is that for the former, its location or
Uniform Resource Identifier (URI) is known at design time,
whereas services are enacted after the LD is instantiated under
the form of a Unit of Learning (UoL) [1]. Learning objects and
learning services are essentially different at the time when they are
available to the learning designer. But, from an accessibility
viewpoint, learning objects and learning services are also different
on their interfaces, which are the way to access and exploit those
features that are useful for the learner.
A learning service is a functional concept supporting a user in
the learning process [2]. In the IMS LD model, a learning activity
and its services are mediated by an environment, as depicted in
Fig. 1 [3].
Typical learning services include authorization and authentication, mail and messaging, conferencing, search, sequencing, and
collaborative editing and assessment, among others. These usually
provide an Application Programming Interface (API) to enable any
external application, such as LD players, to send requests to and
receive answers from the service in a Web-based runtime
environment. IMS LD-based learning services require a Web
Service Description Language (WSDL) specification of the functions the service provides [2].
The focus of this paper is on how a learning service is
accessed from a particular LD activity on a Web-based environment. The main issue in achieving interoperability between IMS
LD-compliant players and learning services is having a generic
and comprehensive description of any feasible service for
teaching and learning. Current IMS LD interoperability solutions

. J.M. Dodero is with the Departamento de Lenguajes y Sistemas

Informaticos, Universidad de Cadiz, C/ Chile, 1, 11002 Cadiz, Spain.
E-mail: [email protected].
. E. Ghiglione is with the Macquarie ELearning Centre of Excellence,
Macquarie University, Sydney, NSW 2109, Australia.
E-mail: [email protected].
Manuscript received 15 Sept. 2008; revised 18 Nov. 2008; accepted 4 Dec.
2008; published online 9 Dec. 2008.
For information on obtaining reprints of this article, please send e-mail to:
[email protected], and reference IEEECS Log Number TLT-2008-09-0080.
Digital Object Identifier no. 10.1109/TLT.2008.21.
1939-1382/08/$25.00 2008 IEEE

Published by the IEEE CS & ES

VOL. 1,

NO. 3,

JULY-SEPTEMBER 2008

such as the ELF e-learning framework1 are focused on providing

a tightly coupled, function-based access interface to a model of
the service; this model often is not exposed, and it is assumed
that it is shared by all learning activities that consume the
learning service. However, it is often sufficient to know what
resources and features are available in the service model and
how to access them, while keeping the interaction between
activities and services as simple as possible.
Learning services can be classified according to the kind of
service provider and to the service containment degree, which
means that you need to locally download the service software to
be able to access it (tight containment), or you need to set up a
remote access to the service before using it (loose containment).
On the one hand, the provider can be a standalone service or an
LMS-hosted service. Instances of standalone services include all
kinds of Web 2.0 applicationssee, for example, Google maps
used as a learning service in [4]whereas LMS-hosted services
usually come under the form of LMS-specific activities (e.g.,
moodle or dotLRN assignments, questionnaires, forums, wikis,
and so forth), LMS-hosted services are more difficult to access
since they only exist in the context of an LMS-specific course. On
the other hand, learning service access is classified according to
the containment degree. We focus our work on accessing loosely
contained, standalone services, since 1) the transformation of an
LMS-hosted service to the standalone version is a technical issue
that can be easily managed by the LMS; and 2) tightly contained
Web services require first downloading the access software, thus
any accessibility issue can be readily solved.
The key issue is providing learning services with an easy and
flexible approach to access them from learning process activities
when these are runpossibly on an external LD sequencing
service. The access requirements can be summarized as follows:
.

Open integration: Services must publish their interfaces so

that their operations or primitives can be called from
external activities.
Fine grain control: A fine grain access level must be
provided to exploit the service interface primitives on
an individual basis, as well as to access the back-end
objects or resources supporting those operations.
User interface decoupling: The service primitives must be
decoupled from the user interface used to call them, so that
it permits an easy replacement of either the interface or the
service.

ACCESSING LEARNING DESIGN SERVICES

From the very beginning of the IMS LD specification, Olivier and

Tattersall [1] argue that the key issue to be addressed is how to add
services to an LD such that they still retain portability across
different LD-compliant platforms. The approach to this issue taken
by the SLeD and CopperCore Service Integration (CCSI) is to
provide generic descriptions of operations and methods for each
service without requiring the service provider to update their API
to fit with a particular description [2]. Such descriptions are
usually provided by a WSDL specification, which has to be
updated if the service interface changes or is extended. Moreover,
if the particular service provider has an operation that does not fit
in the generic operations, CCSI provides an adapter to take
advantage of these operations. However, you need to update the
player, making it difficult to add a new service type [5].
The LAMS approach took the other way around and suggested
that, in order to create tools and services that are meaningful from
an LD perspective, it is more practical to build them from scratch
than reengineer existing ones [6]. The issue here is the loss of
1. http://www.elframework.org/.

IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES,

VOL. 1,

NO. 3,

JULY-SEPTEMBER 2008

Fig. 1. View of activities, resources, and services of the IMS LD information model.

generality for building and switching new services, although the

advantages about the actual accessibility to special-purpose
services are clear. The aim of the LAMS approach of integrating
LMS-hosted services as LAMS tool adapters is to identify the
fundamental operations or primitives that tools and services
should provide for their integration with an LD player. Although
such primitive operations span through the whole life cycle of the
service (i.e., authoring, enactment, operation, monitoring, import/
export facilities, and so forth), we are only considering here the
regular operation with service-specific requests (e.g., posting/
replying to a forum, completing an assessment, and so forth).
When such services are provided by an LMS-hosted tool, adapting
the LMS interface or implementation is required, so it depends on
the LMS facilities to do thatfor instance, accessing dotLRN
forums [7] from the LAMS player was easier to adapt than moodle
forums [8]. These adaptations include the LMS-provided service
user interface as a whole within the LD, thus providing a coarsegrain access to the service.
Another interesting solution is interposing a software wrapper
between the LD player and the service provider that instantiates
and enacts the service, multiplexes service calls, and compiles
interesting data from the service operation [9]. This generic service
integration approach enables switching the service if required (i.e.,
you have to rewrite or adapt the wrapper, not the LD or the service
provider) and solves the trade-off about fine versus coarse service
call granularity needed for the LD being aware of individual
operations, since the wrapper is responsible for data compilation in
either case. Nevertheless, changes and extensions to already
wrapped services require rewriting the service access-specific
code of the wrappers. This approach scales as long as the wrapper
is carefully designed to easily allow for those changes.

2.1

ReST-Based Learning Service Architecture

The current interest in Web services appears to be deeply

influenced by the architectural style [10]. Representational State
Transfer (ReST) is an architectural style based on the HTTP
protocol that describes a navigational, resource-oriented style of
design [11]. This means that, for each resource, a URI must be
provided to let client applications navigate from it to other
resources. ReST is usually confronted by the Service-Oriented
Access Protocol (SOAP), which actually represents a procedural,
function-oriented style of design in which the service is provided
with a set of procedures or functions that can be called to access the
service public operations [13]. However, at an abstract level, Web
service architectural styles can be classified into those that favor a
tight coupling of components using SOAP and those that favor a
loose coupling of components following the ReST principles.
According to the ReST style, everything on the Web is a
resource. A resource has different representations (HTML, XML,
and so forth) and is addressed by a name or URI, which is built
upon a uniform scheme of /resource/id/verb. Resources support
simple verbs, e.g., Create, Read, Update, Delete (CRUD). The verb
is sent to the URI as an HTTP methodi.e., POST (create), GET
(read), PUT (update), or DELETE (Delete)to realize the requested

191

CRUD function on the resource identified by id. Excepting the

POST request, the verb is omitted since it is implicit in the HTTP
method. The representation format of the output (HTML, XML,
and so forth) is part of the HTTP header and can be specified on
the URI as /resource/id.format. Following ReST principles
ensures an open integration API to access Web services or
resources, as required above. Unlike a SOAP service, where all
requests are directed to a single endpoint, a ReSTful Web service
accepts requests at multiple URIseach mapped to a different
resource. Instead of requiring a WSDL to describe all of the
methods and arguments the LD might call, the specification of a
ReSTful service is just the list of resources it exposes. This
characteristic fosters the fine grain control requirement mentioned
above. The ReST-based style of accessing learning services
provides a loosely coupled integration between LD activities and
learning service providers, so endorsing the user interface
decoupling requirement.

2.2

ReST-Based Learning Service Access

The ReST-style access to learning services consists of a facade object

[12], which is represented by a URL and receives requests to create
or manipulate an object instance, which in turn can be referenced
using a particular URI. Such objects represent resources that are
inbounds to the learning service facade and are referenced by
arguments of the service operation, as depicted in Fig. 2.
There are several benefits of the access to learning services
derived from the ReST architectural style:
Uniform access method: The main advantage is the uniform
interface by which all resources are accessed with a generic
set of HTTP methods.
.
Addressable resources: The service implementation is comprised of resources that are named and addressable from
the service provider outbounds.
.
Resource interconnection: The representations of resources
are interconnected using URLs, thereby enabling an LD to
progress from one state/activity to another in a navigational style.
.
Extensibility: ReST provides a flexible scheme to easily
implement changes and extensions to services and service
wrappers.
The architecture of how ReST-based services are accessed
describes layered mediators or wrappers, such as proxy servers,
cache servers, gateways, and so forth, that can be inserted
between the LD player and the service provider to support
performance, security, and so forth. In fact, the generic service
integration approach [9], which interposes a wrapper for service
execution enactment and awareness, can be readily combined
with a ReST-based architecture by deploying the wrapper as a
kind of layered component.
.

2.3

Service Access Design Methodology

Weller et al. [5] enacted the need of a methodology for describing

learning services so that new ones can be added to an LD. The
methodology must encompass the means by which services are
described and how LD recognizes these. Under the ReST
principles, we have taken the following steps for the proposed
design methodology:
1.

Define the facade of the service. This can be a simple

interfacewhether the correspondence from service primitives to their object implementation is simpleor an
adapter component, which translates service requests to
the object collaboration that realizes them. For instance, the
operation create_post(user, post_contents) used to create a
post in a blog service can be implemented by a single
method call to user.create_post (post_contents) on the user

192

IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES,

VOL. 1,

NO. 3,

JULY-SEPTEMBER 2008

Fig. 2. Learning service access architecture.

2.

3.

4.

5.

object. However, the operation get_user_tagged_posts

(user, tag), which retrieves the postings of a user that are
marked with a specific tag, might require an adaption
to translate it into a more complex call, such as: tag.filter
(user.get_posts()); now, it requires knowing not only the
operation interfaces but also the relationships among
user, post, and tag objects. The facade is not really
indispensable, but it is a procedure-oriented gateway to
access the resource-oriented ReST service, required if the
LD player needs a typical function-based API.
Design the object model of the service resources. The
remote resources involved in a learning service invocation
usually exhibit relationships among them, such that chains
of objects and relationships are also referenced in the call.
For that aim, an object model of these service resources
must be defined. In the blog service example, user objects
are 1 : n associated to posts, tags are n : m associated to
posts, and users are n : m associated to tags.
Map service operations to ReSTful URIs. Once the service
interface and the component objects are defined, the URI
scheme is defined. This scheme is typified by ReST as a
chain of /object_type/object_id/ parts, optionally ended by
a /request part. For example, the URI /users/x/posts/y/
might represent the posting y of user x in a blog service; and
/users/x/posts/new would represent a request to create a
new post for user x.
Provide a written specification of the ReST service interface. This step is not mandatory but allows for summarizing the permissible URIs designed in the previous step, by
means of an explicit description in Web Application
Description Language (WADL). It works similarly to
WSDL with SOAP and essentially enables the automatic
generation of a user interface to access the service.
Map ReSTful URIs and invocation arguments to the LD
user interface or interaction elements. The LD activity
invocates the service from a user interface element.
Availability of these user interface elements depends on
the kind of LD player invocating the service. On the one
hand, the IMS LD specification uses properties to retain all
values from user interaction. Property values are set and
viewed through global elements, which are IMS LD
instructions that can get and set property values, usually

contained within forms delivered to the user. Then, global

elements are mapped to URIs. On the other hand, LAMS
LD activities directly use HTML forms and controls to
handle the interaction, so these would be mapped to the
service URIs. It is worth mentioning that the optional step
4 would considerably facilitate this task, since the mapping
can be automated by generating the user interface from the
WADL specification.

VALIDATION CASE: HOW TO ACCESS WIKI LEARNING

SERVICES

Wikis are readily available Web applications that provide a kind of

collaborative authoring service, which can be usefully integrated in
a learning process as long as an open API is provided by the wiki.
The case of wikis is used to show how the above-mentioned
benefits derived from ReST apply throughout the steps of the
design methodology.

3.1

Wiki Service Facade

We have applied the design method described above for a set of

basic wiki services. Fig. 3 depicts the wiki service API, which
consists of a set of operations to be invoked from a running LD.
This is a simple facade of the wiki service (methodology step 1)
because actual wikis provide additional functionalities on pages
for tagging, watching, access control, and so forth. Nevertheless,
the service interface can be extended if needed, just by further
applying the design method on the extended functionalities.

Fig. 3. UML facade of the wiki service.

IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES,

VOL. 1,

NO. 3,

JULY-SEPTEMBER 2008

Fig. 4. Class diagram of the wiki service object model.

3.2

Wiki Object Model

Although the wiki API only provides a functional abstraction of

the service operations, there exists an underlying object model
of resources available through these operations. For instance,
the operation create_page (user, page_contents) is called to
create a page associated to a contributing user; hence, it deals
with two kinds of objects, i.e., users and pages. According to
the methodology step 2, the object model in Fig. 4 represents
the object types involved in the wiki service interface.

3.3

Wiki ReSTful API

The ReST API that results from mapping the service operation to
ReSTful URIs (methodology step 3) is described in Table 1. ReSTful
URIs provide a simple and standard syntax to describe User-Page
and Page-PageVersion relationships of the object model, such that
any operation invocation can be easily generated from that model
as an HTTP method call. For example, the get_page_versions
(page_id) operation retrieves all versions of a given page; to
implement a ReSTful call to this service, the URI /pages/:page_id/
versions is formed; parts of the URI prefixed with a colon stand for
the actual values of the operation arguments. Therefore, all
resources of the wiki (i.e., users, pages, and page versions) can
be uniformly named, accessed, and addressed out of the service
provider through common HTTP requests.
One advantage of this approach is that it provides a fine-grained
access to the resources that compound the wiki service. Instead of
having a single coarse-grained URL to access the overall service,
component objects of the service (i.e., users, pages, and page
versions) are visible and can be navigated from the LD. Another
advantage of ReST style is that the format to deliver the output of
the service invocation is specified by appending .xml, .html, or
any other desired suffix to the URI. For instance, /pages/32/
edit.iphone would deliver a form to edit the page with id 32 on an
iPhone. This enables the interconnection of resources required to
navigate from one LD activity to another, and it can do it for a
diversity of delivery formats and user devices.

3.4

Integrating URIs in the LD Activity Interface

As the last step of the methodology, we realized an exploratory

evaluation of how the ReST-based scheme is integrated on an LD
activity interface for three wiki services, namely MindTouch
DekiWiki,2 OpenMaru SpringNote,3 and Google JotSpot.4 These
have been selected since they provide an open API to operate with
the set of available resource objects. Some of these wiki applications
do not provide a completely ReSTful API. For example, JotSpot
requires a POST removePage command instead of using the ReSTcompliant form of deleting a resource by means of the HTTP
DELETE message. However, they all provide the required ReST
functions as verbs to access the essential wiki services.
Resources available through the API are different for each
actual wiki application, as shown in Table 2. The first column
summarizes the resource objects that might be exposed through
the wiki API, while the rest of the columns indicate if they are
available  or not  on each wiki service. Some do not offer
2. http://wiki.developer.mindtouch.com/.
3. http://dev.springnote.com/.
4. http://developer.jot.com/.

193

their complete API through ReST. For example, JotSpot API can
handle tags and attachments, but its reduced ReST version does
not include such resource types. In such cases, they are marked
with a dot. Although resource objects have methods that
implement the service operations, these have not been described
as part of the table.
Then, we explored how wiki services are accessed from an LD
activity. The activity client interface has been developed with
Google Web Toolkit (GWT). The following code listing shows how
the get_page (page_id) service operation is implemented to enable
retrieving a wiki page from the activity:
class PageResource implements Resource {
List pageVersions;
String jsonRepresentation;
public void PageResource() {
populateFromRepresentation(jsonRepresentation);
}
//. . .
}
class Wiki extends Composite implements WikiFacade {
public void get_page(int page_id) {
//. . .
ResourceCollection pages =
new JsonResourceCollection(
"http://" SERV_PROVIDER GET_PAGE_CMD,
new ResourceFactory() {
public Resource create() {
return (Resource)
GWT.create(PageResource.class);
}
});
pages.find(page_id,
new ResourceResponseHandler() {
public void onSuccess(Resource resource) {
// Display page
String title =
((ProjectResource)resource).getName());
// . . .
}
public void onError(Request request,
Throwable exception) {
Window.alert("Page not found.");
}
});
}
//. . .
}
The program code shows how different service providers can
be integrated. First, the constant SERV_PROVIDER is configured
with the hostname of the wiki application provider (i.e., DekiWiki,
SpringNote, or JotSpot). Second, GET_PAGE_CMD holds the
ReST-style command for retrieving the pages. According to ReST
principles, it should be the string pages, but it can be configured
for any provider that does not fully comply with ReST vocabulary
(e.g., listAll retrieves all pages in JotSpot). The rest of the details of
the request (e.g., the page id) are uniformly coded in the method
ResourceCollection.find. Therefore, adapting the client access
interface from the LD activity to the learning service is as
straightforward as configuring the URI access point to the resource
and the ReST-based verb vocabulary. This way, ReST facilitates

194

IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES,

VOL. 1,

NO. 3,

JULY-SEPTEMBER 2008

TABLE 1
Mapping the Wiki Service Operation to ReSTful URIs

TABLE 2
Resource Objects Available through DekiWiki, SpringNote, and JotSpot APIs

updating the service access interface due to an eventual change or

extension to the service.

CONCLUSIONS AND FUTURE WORK

This paper has described a ReST-based architectural style of

accessing learning services from LD activities on a Web-based
environment and has provided a methodology for that aim. The
proposed ReST solution is simple, since it is based on few
principles and well-defined operations, scalable, since it relies on
stateless protocols and distributed state, and layered, allowing for
any number of intermediaries between activities and services. The
service access requirements of open integration, fine grain control,
and user interface decoupling are fulfilled by the architectural
style and design methodology.
Providing activities with a user interface to access ReST-based
learning services is still a matter of configuration. In further work,
this interface might be generated from a WADL service specification provided beforehand. Another line of work is integrating the
ReST-based service access on a layered wrapper that enacts the
service and multiplexes service calls. This would provide the
generic service access approach [9] an improved scalable design.
In this work, we have only considered the integration of
service-specific primitive operations within LD systems. The actual

list of functionalities that need to be integrated must cover the

complete life cycle of the service, from authoring and enactment to
monitoring to interoperability facilities. This is an ongoing effort
that has been undertaken in the FLEXO project, funded by the
Spanish Ministry of Industry and Commerce, and realized in
cooperation with several Spanish companies and universities and
the LAMS Foundation.

ACKNOWLEDGMENTS
This work was supported in part by the Plan Nacional de
Investigacion Cientfica, Desarrollo e Innovacion Tecnologica,
Projects TSI-020301-2008-19 and TSI-020501-2008-53.

REFERENCES
[1]
[2]

[3]

B. Olivier and C. Tattersall, The Learning Design Specification, Learning

Design. A Handbook on Modelling and Delivering Networked Education and
Training, R. Koper and C. Tattersall, eds., pp. 21-40, Springer, 2005.
H. Vogten, H. Martens, R. Nadolski, C. Tattersall, P. van Rosmalen, and
R. Koper, CopperCore Service Integration, Interactive Learning Environments, vol. 15, no. 2, pp. 171-180, 2007.
IMS, IMS Learning Design Information Model. Version 1.0 Final Specification,
http://www. imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html,
2003.

IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES,

[4]

[5]

[6]

[7]
[8]
[9]

[10]

[11]

[12]
[13]

VOL. 1,

NO. 3,

JULY-SEPTEMBER 2008

J. Bouzo, H. Batlle, T. Navarrete, and J. Blat, Enhancing IMS QTI

Assessment with Web Maps, Proc. TENCompetence Open Workshop Current
Research on IMS Learning Design and Lifelong Competence Development
Infrastructures, June 2007.
M. Weller, A. Little, P. McAndrew, and W. Woods, Learning Design,
Generic Service Descriptions and Universal Acid, Educational Technology
and Soc., vol. 9, no. 1, pp. 138-145, 2006.
J. Dalziel, From Re-Usable E-Learning Content to Re-Usable Learning
Designs: Lessons from LAMS,
http://www.lamsfoundation.org/CD/
html/resources/whitepapers/Dalziel.LAMS.doc, 2005.
E. Ghiglione, LRN Tool Adapters, http://wiki.lamsfoundation.org/display/
lams/.LRN+Tool+Adapters, 2008.
E. Ghiglione, Moodle Tool Adapter, http://wiki.lamsfoundation.org/
display/lams/Moodle+Tool+Adapter, 2008.
L. de la Fuente, A. Pardo, Y. Miao, and C. Delgado, A Supporting
Architecture for Generic Service Integration in IMS Learning Design, Proc.
Third European Conf. Technology Enhanced Learning (EC-TEL 08), pp. 467-473,
2008.
M. zur Muehlen, J.V. Nickerson, and K.D. Swenson, Developing Web
Services Choreography StandardsThe Case of REST versus SOAP,
Decision Support Systems, vol. 40, no. 1, pp. 9-29, 2005.
R.T. Fielding, Architectural Styles and the Design of Network-Based
Software Architectures, PhD dissertation, Univ. of California, Irvine,
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm, 2006.
E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements
of Reusable Object-Oriented Software. Addison-Wesley, 1994.
E. Wilde and R.J. Glushko, Document Design Matters, Comm. ACM,
vol. 51, no. 10, pp. 43-49, 2008.

195