A Service-Based Architecture for Learning Management ... · the distributed LMS are called e-learning services. In addition, underlying infrastruc-ture services provide supportive

A Service-Based Architecturefor Learning Management Systemswhich Supports Personalisation and

Collaboration

Markus Schmid

Master of Science

Cork Institute of Technology

Supervisors:Dr. Jeanne Stynes

Dr. Reinhold Kroger

Submitted to the Higher Educational and Training Awards Council

March 2004

Contents

Acknowledgements XIII

Abstract 1

1 Introduction 2

2 E-learning 5

2.1 Introduction to learning theory . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Programmed instruction . . . . . . . . . . . . . . . . . . . . 6

2.1.2 The cognitive approach . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 Constructivism . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Categorisation of e-learning approaches . . . . . . . . . . . . . . . . 14

2.2.1 Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Classification of Web-based software for content presentation 15

2.2.3 Challenges to be met by e-learning software . . . . . . . . . . 16

3 Learning Management Systems 19

3.1 Technical challenges in e-learning . . . . . . . . . . . . . . . . . . . 19

I

3.2 Requirements definition for LMS . . . . . . . . . . . . . . . . . . . . 21

3.2.1 User roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3 Functional components . . . . . . . . . . . . . . . . . . . . . 24

3.2.4 Personalisation requirements . . . . . . . . . . . . . . . . . . 27

3.2.5 Collaboration requirements . . . . . . . . . . . . . . . . . . . 28

3.2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Interoperability standards and specifications . . . . . . . . . . . . . . 31

3.3.1 Learning Object Metadata . . . . . . . . . . . . . . . . . . . 31

3.3.2 Dublin Core Metadata . . . . . . . . . . . . . . . . . . . . . 32

3.3.3 ARIADNE . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.4 IMS Specifications . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.5 The Sharable Content Object Reference Model . . . . . . . . 38

3.4 Existing e-learning environments . . . . . . . . . . . . . . . . . . . . 44

3.4.1 WebCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4.2 Blackboard . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.3 Ilias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Design 52

4.1 A service-based LMS architecture . . . . . . . . . . . . . . . . . . . 52

4.1.1 Architectural building blocks . . . . . . . . . . . . . . . . . . 52

4.1.2 Overall system architecture . . . . . . . . . . . . . . . . . . . 54

II

4.2 Common data structures . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2.1 The TServiceInfo structure . . . . . . . . . . . . . . . . . . . 60

4.2.2 The TProperty structure . . . . . . . . . . . . . . . . . . . . 61

4.3 Infrastructure services . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3.1 The lookup service . . . . . . . . . . . . . . . . . . . . . . . 65

4.3.2 The property service . . . . . . . . . . . . . . . . . . . . . . 69

4.3.3 The logging service . . . . . . . . . . . . . . . . . . . . . . . 72

4.3.4 The security service . . . . . . . . . . . . . . . . . . . . . . 74

4.4 E-learning services . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.4.1 The annotation service . . . . . . . . . . . . . . . . . . . . . 83

4.4.2 The bookmark service . . . . . . . . . . . . . . . . . . . . . 91

4.4.3 The ISCORM service . . . . . . . . . . . . . . . . . . . . . . 96

4.4.4 The search service . . . . . . . . . . . . . . . . . . . . . . . 100

4.5 The portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.6 Cross service personalisation . . . . . . . . . . . . . . . . . . . . . . 104

5 Prototypical implementation 105

5.1 Technologies Used . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.1.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.1.2 WebServices . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.1.3 Mapping between CORBA and WebServices . . . . . . . . . 109

5.1.4 Possible usage scenarios for CORBA and WebServices . . . . 117

5.2 Implementation of a prototype . . . . . . . . . . . . . . . . . . . . . 119

III

5.2.1 Infrastructure services . . . . . . . . . . . . . . . . . . . . . 119

5.2.2 E-Learning services . . . . . . . . . . . . . . . . . . . . . . 129

5.2.3 Integration into an existing LMS portal . . . . . . . . . . . . 146

5.3 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

6 Summary and conclusions 151

6.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

6.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

6.3 External feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6.4 Future prospects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Bibliography 161

A Publications A-1

B Features of existing LMSs B-1

B.1 WebCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

B.2 Blackboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

B.3 Ilias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5

C IDL interface definition C-1

C.1 The service base interfaces . . . . . . . . . . . . . . . . . . . . . . . C-1

C.1.1 The abstract service interface . . . . . . . . . . . . . . . . . . C-1

C.1.2 The abstract infrastructure service interface . . . . . . . . . . C-3

C.1.3 The abstract e-learning service interface . . . . . . . . . . . . C-4

C.1.4 The abstract inner-institutional service interface . . . . . . . . C-5

IV

C.1.5 The abstract cross-institutional service interface . . . . . . . . C-5

C.2 The inferfaces of essential infrastructure services . . . . . . . . . . . C-6

C.2.1 The lookup service interface . . . . . . . . . . . . . . . . . . C-6

C.2.2 The logging service interface . . . . . . . . . . . . . . . . . . C-10

C.2.3 The property service interface . . . . . . . . . . . . . . . . . C-12

C.2.4 The security service interfaces . . . . . . . . . . . . . . . . . C-20

C.3 The interfaces of important e-learning services . . . . . . . . . . . . . C-24

C.3.1 The annotation service interface . . . . . . . . . . . . . . . . C-24

C.3.2 The bookmark service interface . . . . . . . . . . . . . . . . C-30

C.3.3 The ISCORM service interface . . . . . . . . . . . . . . . . . C-33

C.3.4 The search service interface . . . . . . . . . . . . . . . . . . C-36

D Other source codes D-1

D.1 The modified AXIS CORBAProvider . . . . . . . . . . . . . . . . . D-1

D.2 The portal login procedure . . . . . . . . . . . . . . . . . . . . . . . D-3

D.3 The Greenstone IDL interface . . . . . . . . . . . . . . . . . . . . . D-5

V

List of Figures

2.1 Focus of behaviourist approach . . . . . . . . . . . . . . . . . . . . . 7

2.2 Focus of cybernetic approach . . . . . . . . . . . . . . . . . . . . . . 8

2.3 cognitive operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 System - learner - interaction . . . . . . . . . . . . . . . . . . . . . . 17

3.1 A learners view of an LMS . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Use cases in an LMS . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 A minimal solution for LMS cooperation . . . . . . . . . . . . . . . 29

3.4 An approach for close LMS cooperation . . . . . . . . . . . . . . . . 30

3.5 ARIADNE system architecture . . . . . . . . . . . . . . . . . . . . . 34

3.6 Scope of IMS Packaging . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7 Scope of IMS DRI . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.8 Scope of the IMS enterprise specification . . . . . . . . . . . . . . . 38

3.9 Architecture of the SCORM runtime environment . . . . . . . . . . . 41

3.10 Configuration of a user’s “My WebCT” page . . . . . . . . . . . . . . 46

3.11 The blackboard user portal . . . . . . . . . . . . . . . . . . . . . . . 47

3.12 The Ilias user portal . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

VI

4.1 Cooperation of functional components . . . . . . . . . . . . . . . . . 53

4.2 The basic interface to be implemented by the services . . . . . . . . . 54

4.3 The service-based LMS architecture . . . . . . . . . . . . . . . . . . 59

4.4 The TServiceInfo structure . . . . . . . . . . . . . . . . . . . . . . . 61

4.5 The TProperty structure . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.6 The interface to be implemented by infrastructure services . . . . . . 64

4.7 The interface to be implemented by lookup services . . . . . . . . . . 67

4.8 The TOffer structure . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.9 The interface to be implemented by property services . . . . . . . . . 71

4.10 The property service callback interface . . . . . . . . . . . . . . . . . 71

4.11 The property service callback registration interface . . . . . . . . . . 72

4.12 The interface to be implemented by logging services . . . . . . . . . 74

4.13 ISO 10181-3 Access Control Framework . . . . . . . . . . . . . . . . 76

4.14 Authentication and Authorisation . . . . . . . . . . . . . . . . . . . . 77

4.15 The TLoginContextHandle data structure . . . . . . . . . . . . . . . 79

4.16 The interface to be implemented by authentication services . . . . . . 79

4.17 The interface to be implemented by authorisation services . . . . . . . 80

4.18 The interface to be implemented by e-learning services . . . . . . . . 82

4.19 The W3C Annotea architecture . . . . . . . . . . . . . . . . . . . . . 83

4.20 Mozilla displaying an annotation (using Annozilla) . . . . . . . . . . 85

4.21 The overall Annotation Service architecture . . . . . . . . . . . . . . 87

4.22 The interface to be implemented by an annotation service server . . . 90

4.23 The TCategory data structure . . . . . . . . . . . . . . . . . . . . . . 93

VII

4.24 The TBookmark data structure . . . . . . . . . . . . . . . . . . . . . 94

4.25 The interface to be implemented by a bookmark service . . . . . . . . 94

4.26 The Mozilla bookmark manager . . . . . . . . . . . . . . . . . . . . 95

4.27 The overall ISCORM service architecture . . . . . . . . . . . . . . . 97

4.28 The interface to be implemented by an ISCORM service . . . . . . . 99

4.29 The TSearchResult data structure . . . . . . . . . . . . . . . . . . . . 100

4.30 The TSearchResultElement data structure . . . . . . . . . . . . . . . 101

4.31 The interface to be implemented by a search service . . . . . . . . . . 102

4.32 The LMS portal accessing several LMS services . . . . . . . . . . . . 103

5.1 Initialisation of the LMS property service . . . . . . . . . . . . . . . 120

5.2 Overall implementation design of the LMS lookup service . . . . . . 121

5.3 Overall implementation design of the LMS property service . . . . . 125

5.4 The overall security service implementation design . . . . . . . . . . 127

5.5 The central classes of the authentication service . . . . . . . . . . . . 128

5.6 Principal architecture of an e-learning service . . . . . . . . . . . . . 129

5.7 Invocation of an e-learning service . . . . . . . . . . . . . . . . . . . 130

5.8 The overall annotation service implementation design . . . . . . . . . 134

5.9 Retrieving annotations for a certain URL . . . . . . . . . . . . . . . . 136

5.10 Important classes of the Annotation Proxy . . . . . . . . . . . . . . . 138

5.11 The overall bookmark service architecture . . . . . . . . . . . . . . . 140

5.12 The central classes of the bookmark service . . . . . . . . . . . . . . 143

5.13 The overall web-search service implementation design . . . . . . . . 144

VIII

5.14 The Greenstone web interface . . . . . . . . . . . . . . . . . . . . . 145

5.15 The overall lib-search service implementation design . . . . . . . . . 146

5.16 Additional menus for service integration . . . . . . . . . . . . . . . . 149

IX

List of Tables

3.1 SCORM API for execution state control . . . . . . . . . . . . . . . . 42

3.2 SCORM API for state management . . . . . . . . . . . . . . . . . . 43

3.3 SCORM API for data exchange . . . . . . . . . . . . . . . . . . . . 43

4.1 Information in a bookmark entry . . . . . . . . . . . . . . . . . . . . 91

5.1 Overview on middleware technologies . . . . . . . . . . . . . . . . . 106

5.2 Mapping of simple data types between WSDL and IDL . . . . . . . . 110

5.3 Mapping between LMS properties and CORBA properties . . . . . . 123

5.4 The offer type for LMS services . . . . . . . . . . . . . . . . . . . . 123

5.5 The fields of the MySQL annotations table . . . . . . . . . . . . . . . 137

5.6 The fields of the MySQL categories table . . . . . . . . . . . . . . . 141

5.7 The fields of the MySQL bookmarks table . . . . . . . . . . . . . . . 141

B.1 WebCT 3.6 features . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

B.2 Blackboard features . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

B.3 Ilias 3 features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5

X

List of Listings

4.1 Sample complex property . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2 Sample Annozilla annotation . . . . . . . . . . . . . . . . . . . . . . 84

4.3 Sample entry of a Mozilla bookmark file . . . . . . . . . . . . . . . . 91

4.4 Sample Mozilla bookmark file . . . . . . . . . . . . . . . . . . . . . 92

5.1 The Service Base interface in CORBA IDL . . . . . . . . . . . . . . 110

5.2 The Service Base interface in WSDL . . . . . . . . . . . . . . . . . . 111

5.3 A sample AXIS CORBA deployment descriptor . . . . . . . . . . . . 131

5.4 The performTheSearch method . . . . . . . . . . . . . . . . . . . . . 144

C.1 The abstract service interface . . . . . . . . . . . . . . . . . . . . . . C-1

C.2 The abstract infrastructure service interface . . . . . . . . . . . . . . C-3

C.3 The abstract e-learning service interface . . . . . . . . . . . . . . . . C-4

C.4 The abstract inner-institutional service interface . . . . . . . . . . . . C-5

C.5 The abstract cross-institutional service interface . . . . . . . . . . . . C-5

C.6 The lookup service interface . . . . . . . . . . . . . . . . . . . . . . C-6

C.7 The logging service interface . . . . . . . . . . . . . . . . . . . . . . C-10

C.8 The property service interface . . . . . . . . . . . . . . . . . . . . . C-12

C.9 The security service interfaces . . . . . . . . . . . . . . . . . . . . . C-20

XI

C.10 The annotation service interface . . . . . . . . . . . . . . . . . . . . C-24

C.11 The bookmark service interface . . . . . . . . . . . . . . . . . . . . . C-30

C.12 The ISCORM service interface . . . . . . . . . . . . . . . . . . . . . C-33

C.13 The search service interface . . . . . . . . . . . . . . . . . . . . . . . C-36

D.1 Modification to the AXIS CORBAProvider . . . . . . . . . . . . . . D-1

D.2 Run-Time Environment access of the LMS authentication service . . . D-3

D.3 The Greenstone IDL interface . . . . . . . . . . . . . . . . . . . . . D-5

XII

Acknowledgements

XIII

Abstract

Markus Schmid

A Service-Based Architecture for Learning Management Systems

which Supports Personalisation and Collaboration

This work develops a service-based architecture for an extensible and customisablelearning management system (LMS) runtime environment. The architecture mainlydefines interfaces for the interaction of functional system components represented byloosely coupled distributed services. Services that represent functional components ofthe distributed LMS are called e-learning services. In addition, underlying infrastruc-ture services provide supportive functionality such as service-lookup within an institu-tion. Users access the system using an LMS portal component that acts as a front-endfor the LMS services.

While existing e-learning environments provide a relatively good coverage of mostof the functional requirements defined in this work, they usually exclude the person-alisation and collaboration areas particularly addressed in this work. The e-learningenvironment is modelled as a distributed architecture with the functional componentsrepresented by a collection of more or less independent services. Our architecturetries to standardise core interfaces for services belonging to different classes. Theseinterfaces may be further extended by service vendors in order to support enhancedfeatures.

The main aims of the architecture are cross-service personalisation of the resultingrun-time system and support of institutional collaboration. The architecture focuses onmodularity, configurability and extensibility of the LMS services and supports institu-tional cooperation by allowing remote-access to LMS services.

1

Chapter 1

Introduction

The term e-learning refers to all instructions enriched by multimedia-support:

E-learning (electronic learning): Term covering a wide set of applica-

tions and processes, such as Web-based learning, computer-based learn-

ing, virtual classrooms, and digital collaboration. It includes the delivery

of content via Internet, intranet/extranet (LAN/WAN), audio- and video-

tape, satellite broadcast, interactive TV, CD-ROM, and more.1

E-learning has become very popular in the last years, peaking with the introduction and

propagation of so called integrated e-learning environments, normally implemented in

software. E-Learning environments help organise the process of learning. They pro-

vide learners with computer-access to content of teaching and support authors during

content creation and publication. Course trainers usually have access to administrative

features.

Usually the design of e-learning software follows the principles of the current views

in learning theory. However some applications still follow quite ancient approaches,

partly because these are easier to implement. In both cases, there is no denying the

benefits that e-learning brings:1Definition of the American Society for Training & Development (http://www.learningcircuits.org)

2

� Increased location independence - people may learn wherever they want

� Individual learning pace - slow learners may repeat content of learning without

interfering with others

� In asynchronous learning scenarios people may learn at the time of their choice

Looking at recent insights in learning theory, one realises that the learners’ personal sit-

uation and individual precognition are important factors to learning success. Integrated

learning environments will be better able to assist learners by offering a configurable,

personalisable learning environment. This requires the functional components of an

e-learning environment to adapt to different users, which is a huge challenge.

A second challenge comes from the trend for institutional cooperation. Currently many

institutions cooperate in order to create virtual courses or to implement “virtual uni-

versities” where students may study from home instead of attending courses. At the

same time there is an increasing demand by institutions to be as independent as pos-

sible from the vendor of the learning environment they currently use. This means that

a plug-in architecture that facilitates their efforts to enhance and customise existing

systems is preferred.

Chapter 2 gives an introduction to learning theory and introduces different scenarios

in which e-learning software may be used. It closes with a classification of different

types of web-based e-learning software while summarising the challenges to be met by

learning environments from the perspective of learning theory.

Chapter 3 assembles a list of required technical features that should be provided by

an up-to-date integrated e-learning environment. It also summarises existing standards

and specifications in the e-learning area, most of which deal with content interoperabil-

ity between different environments. The chapter closes with an examination of three

integrated e-learning environments currently available in the market.

3

Our proposed architecture is presented in chapter 4. This focuses on personalisation

and inter-institutional collaboration, two areas where deficiencies have been identified

in chapter 3. Our approach sees the e-learning environment as a distributed architecture

with the functional components represented by a collection of more or less independent

services. The architecture defines two layers of services and tries to standardise core

interfaces for services belonging to different classes.

Chapter 5 describes the prototypical implementation of a selection of these services

as well as their integration into an existing environment to prove the feasibility of our

architectural approach.

In Chapter 6 the architecture is evaluated and compared with other existing approaches.

4

Chapter 2

E-learning

“Whether users actually want to do this is never questioned.”1

Several different kinds of e-learning-related approaches are possible, e.g., online edu-

cation, distance learning, media-enriched learning.

Yet both traditional teaching methods and e-learning approaches are based on the same

principles in learning theory.

2.1 Introduction to learning theory

According to [KR79] the learning process consists of several different components:

� The content of teaching itself

� The (cognitive) operations performed by the learner

� The objects used to realise these operations, e.g., tasks or experiments

� The tools to facilitate the realisation of operations

1see [Alt91], page 32

5

All these components are independent of the distribution media, e.g., worksheet, slides,

a CD-ROM, the Internet or even remarks by a teacher, that are used to deliver the

material to the student. Teaching means going through a multistage process: First

one decides the content, then didactical aspects must be considered, and finally one

chooses the distribution media.

This three-stage process applies to e-learning as much as to traditional teaching ap-

proaches. At one end of the e-learning spectrum multimedia is used to provide all of

the components shown above. Because there is no human teacher that interacts with

the learner in this case, all possible scenarios must be covered and planned in advance.

This is one of the greatest challenges for the designer of e-learning courses.

It is not easy to determine the quality of media-enriched learning systems. According

to [Ker01] there is no “good” or “bad” media, e.g., CD-ROM is not necessarily better

than video. E-learning environments cannot be evaluated without looking at the learn-

ing process as a whole, which amongst others also comprises the personal situation

of the learner, the content to be provided and the individual experience a learner has

in using different media. How does this learning process take place? Let us look at

different theories about how the process of learning can be modelled and displayed.

2.1.1 Programmed instruction

2.1.1.1 Behaviourism

The first experiments using computers for instructing and learning purposes were car-

ried out during the 1960s and were based on the theories of behaviourism mainly prop-

agated by B. F. Skinner (see [Ski58]).

Behaviourism holds that learning is evidenced by a changing of behaviour. [Jon90]

expresses this as follows:

6

If we control the behaviour of the learner we also control his or her knowl-

edge acquisition.

This theory goes back to the research on animal-behaviour and conditioning carried

out by Pavlov in the 1920s. Pavlov today is still well known for his “dog experiments”

(see [Pav27] for details).

TeachingSystem

Learner

Information Question

Reaction

Feedback

"Intensification"

t

Main focus ofbehaviouristic

approach

Figure 2.1: Main focus of behaviourist approach [Ker01]

Skinner believed that the process of learning cannot be controlled by operations within

the learner, but by awarding or punishing a person depending on his reaction to a

question (see figure 2.1). He describes this as enforcing positive (K+) or negative

(K�

) consequences as feedback to a learners reaction.

Repeating occurrences ofK+ would lead to an increase in showing a particular reaction

to a question, repeating occurrences of K�

would lead to a temporary decrease.

A third consequence (K0) is also possible: A learner environment that ignores the

learners reaction leads neither to an increase nor to an immediate decrease of the oc-

currence of this particular reaction.

Skinner considered it very important to provide the feedback immediately after the

learners reaction to enable the learner to see the consequences of his own reaction.

Computer based training (CBT) programs were designed to implement this model by

asking learners different questions. K+ was then implemented as praise given by the

7

machine, e.g., using some bonus-point-system, after the learner gave the correct an-

swer to a question asked. Afterwards the machine continued with a new question. K�

was commonly implemented by some negative feedback like points deducted, followed

by a repetition of the question answered wrongly.

The term programmed instruction describes the application of behaviourist approaches

to CBT. According to Skinner it is essential to divide the content of teaching into

atomic parts, each of which is combined with a question that about 90% of the target

audience should be able to answer. The CBT application should be designed to work

through the content of teaching and the questions in a sequential order.

2.1.1.2 The cybernetic approach

TeachingSystem

Learner

Information Question

Reaction

Feedback

t

Main focus ofcybernetic approach

Figure 2.2: Main focus of cybernetic approach [Ker01]

The cybernetic model of the process of learning was derived from Skinners behaviourist

approach. However, instead of focusing on the consequences to learners’ reactions as

the behaviourist approach did, the cybernetic approach concentrated on the informa-

tion exchange between a learner and the teaching system (see figure 2.2).

The consequences are still provided by the teaching system, but in this model the

learner sees them as additional information he might use to improve his knowledge,

which could mean not to show a certain reaction any more. In contrast to the be-

haviourist model, the cybernetic approach sees the learner in an active role within the

process of learning.

8

The cybernetic model assumes that representing an information more often makes it

more likely for a person to remember this particular information. This is why in cyber-

netic CBT-applications important key words get repeated and questions concentrate on

these.

Further information about the behaviourist and the cybernetic models and their appli-

cation in CBT programs can be found in [Gag87] and [Ben88].

2.1.2 The cognitive approach

During the 1970s and 1980s people realised that the learning process does not neces-

sarily involve an immediate change in a learner’s behaviour.

Recognise Remember Store Analyse Think convergent Think divergent Think free

from theenvironment

frommemory

intomemory

compare inconsciousness

think accordingto a

thinking scheme

think accordingdifferent

thinking schemes

thinkspontaneous

Add new informationto consciousness

forwardand order

processinformation

according toa model,

consistent

restructureand

combine

cognitive operations

complexity

Figure 2.3: Cognitive operations according to [Rie91]

Cognitive operations are performed by learners throughout the process of learning

something. [Rie91] classifies these cognitive operations into several categories, e.g.,

“add new information”, “process information” (see figure 2.3). Note that the opera-

tions are of varying complexity, for example spontaneous thinking is regarded as very

complex, whereas remembering things is rather easy.

It is now the task of the teaching environment to animate learners to execute those

cognitive operations as often as possible. But how is this aim achieved? [Sal79] tries

to connect cognitive learning operations to media-features, which can be useful later

9

on for the design of media-content. According to this theory an author should always

be aware of the cognitive processes taking place when a learner uses the media. These

processes are supported by media-content, to the extent that parts of the cognitive

operations are externalised. This process is known as supplantation.

[Sal79] draws a distinction between three different steps of supplantation that build on

each other:

� A cognitive operation is modelled by media, e.g., some action is shown in a

video in order for the learner to follow the scene. Media supports the learner by

offering different camera perspectives or logical models.

� A task and the appropriate solution is shown and the learner has to find a suitable

way of getting to the resolution.

� A task is specified and the learner has to find both a suitable way of getting to

the resolution and the resolution itself.

The great problem of the cognitive approach is that it requires knowledge about the

cognitive operations a learner would perform on working on such tasks. Unfortunately

this can be different for various types of learners, e.g., experienced vs. beginner learner.

The way out of this dilemma is the creation of adaptive learning media that interacts

with learners. This of course is a huge task. First approaches to realise such adap-

tive teaching systems were done in the early 1980s, the software resulting from these

approaches can be summarised by the term intelligent tutorial systems (ITS).

One major problem of ITS is the amount of development-time needed to produce one

lesson. [Lip89] estimates this to be about 200 to 300 hours because of the complexity

involved applying artificial intelligence (AI) techniques. Another problem is the dif-

ficulty to reuse the specialised source code of those expert systems for other problem

domains. [Lip89] states:

10

Because of the complexity, cost, and time to build these programs, most

ITS have been designed and remain as prototypes.

2.1.3 Constructivism

From the middle of the 1990s a new approach to describe the process of learning was

discussed: Constructivism and situated learning. The new approach does not describe

the actions and reactions of a person as a result of information processing and resulting

decisions, but looks at them from a different perspective, taking into account the social

context a person resides in and his environment.

Constructivist theories think of knowledge as the contextual interpretation of facts to

be constructed within each situation that is new to someone. In this theory knowledge

is not “stored” within a person, and thus cannot be transferred, but is “produced” by

each more or less known situation (see [MV87] for details).

Taking this approach into account when creating media-based learning material does

not seem to be easy. However there are several theories on possible ways to implement

tasks complying to constructivism:

� Anchored instruction

� Cognitive instruction

� Project work

Anchored instruction describes a way of controlling the attention of a learner while

presenting the content of teaching. For example one way of implementing anchored

instruction is to embed facts that will be used later for solving a task into some inter-

esting narrative, thereby providing an additional “sense” of samples of usage for the

task. An example for that could be a “pirate-story”, where facts about distances and

11

the speed of the pirates’ boat lead to the task of calculating the duration of the travel to

some island.

Cognitive instruction is an approach that focuses on teaching learners using authentic

situations [NS90]. For a start, beginners might just watch an expert in doing something

and afterwards try to solve some small tasks themselves with the expert helping them.

By the time tasks become more complicated and specialised, the approach focuses

on enabling learners to use the knowledge gained in different contexts. For example

apprenticeship is a form of cognitive instruction.

Working on projects can also be seen as a constructivist approach to instructing learn-

ers. In this case, learners form groups, discuss their aims and consider possible ways

of proceeding on their own, assisted by a trainer who helps the group to focus on the

relevant facts. This approach is often used in situations where “usable” results are

required at project termination.

A discussion about the pros and cons of the constructivist approach compared to cogni-

tivism is beyond the scope of this document and can be found in [Jon91]. More details

on constructivism in general can be found in [JPW99].

2.1.4 Conclusion

For a long time programmed instruction was the only way to implement media-enriched

course-ware, even though learners had severe problems with the quite stereotypical

way of going through question/answer sessions. Once familiar with the system, users

often got annoyed about it.

The cognitive approach resulting in intelligent tutorial systems that are based on algo-

rithms developed in the context of AI then became the way to go. Unfortunately those

systems could not meet expectations, mainly because AI did not develop as fast as ex-

pected. For ITS it was not possible to determine satisfactorily a learner’s competence

12

within a certain knowledge domain from his behaviour while communicating with the

system. Even when working on trivial mathematical tasks, where it is sufficient for the

learner to apply an algorithm, several tests have to be performed by the system to rule

out the possibility of “slips of the pen” and to conclude some problem in understand-

ing. With the introduction of graphical user interfaces (GUI) the focus turned towards

an intelligent presentation of the content of teaching within the user interface.

The introduction of the constructive approach led to a paradigm shift to see media

not just as container for the transfer of knowledge but as tools to construct knowledge

within a learner. If interpreted like this, the constructive approach is no alternative to

the cognitive approach but is rather an add-on to enrich cognitive learning approaches

with a social context.

On summary, one can say that there is no such thing as the best method for the con-

struction of didactical enriched content of learning. Although behaviourist concepts

are considered to be outdated, there is still a significant number of tools in the area of

e-learning based on those concepts.

Today the way to go might be a combination of the cognitive and constructive approach

– adapted to the needs of the target learner group. So called hypermedia systems cur-

rently represent the “state of the art”. Hypermedia systems are integrated multimedia

e-learning environments and provide a web-based interface for content-access.

These hypermedia systems combine aspects of constructivism with ideas of cogni-

tivism, e.g., hypertext, which supports explorative learning, is combined with success-

ful applications of AI to provide a sophisticated user interface. The use of hypertext

in hypermedia systems is an ideal basis to provide access to simulations and other

problem-solving tasks that have been developed for ITS before.

13

2.2 Categorisation of e-learning approaches

2.2.1 Usage scenarios

The various models of learning described in section 2.1 on page 5 are as well rele-

vant for traditional ways of instructing learners as for new media-enriched ways of

instruction. E-learning simply places more emphasis on the media used.

Looking at usage scenarios for e-learning environments we will now concentrate on

hypermedia systems as they represent the most advanced kind of e-learning systems

currently available. Hypermedia systems are normally used in web-based learning

approaches or in scenarios where web-based content is made available in an “offline

version”, e.g., on a CD-ROM.

There are roughly three categories of web-based e-learning:

� Media-enriched learning within a traditional lecture

� Distance learning

� Online education

Phases of media-enriched learning within a traditional lecture or lab can be used to

add new value to traditional teaching. Approaches in this category could, e.g., use

web-based instruction material to research a specific topic. Typically this is done in

presence of the teacher with the class using some lab- or computer room.

Distance learning categorises approaches where learners do not attend lectures phys-

ically, but learn in different places (e.g., at work or at home). However lectures are

still presented by a human teacher, using for example video broadcast or streaming to

communicate with the learners. Other possibilities are to just broadcast voice or even

written comments that the teacher produces online or offline. The fact that learners are

14

instructed at the same time is characteristic for this category. However there might be

additional tasks for each learner to perform at a time that suits him.

Online education is the category with the most extreme position in terms of replacing

human teachers with the use of software and/or media. In online education scenarios

there are no restrictions in terms of location or access time for the learners – the learn-

ing environment is accessible individually and a learner’s progress is monitored on an

individual basis.

As the borders between these categories are somewhat floating, this work will concen-

trate on the category termed online education.

2.2.2 Classification of Web-based software for content

presentation

A large variety of software has been developed to fulfil the needs of these e-learning

approaches. In terms of web-based approaches we can categorise them as follows by

mainly focusing on navigation possibilities:

� Hypertext systems

� Electronic books

� Kiosk systems

Hypertext systems make extensive use of linking and allow users to navigate through

the content in several ways. In many cases no “default path” exists. This stimulates

learners to work through the system, following a path based mainly on their own in-

terest. However there is a danger of learners “getting lost” in the system or covering

very little of the material provided. Hypertext systems are especially useful for shared

learning – situations where two learners share one machine to discuss the content

15

provided (see [JJ86] for details). Research concentrates on the ideal granularity of in-

formation that should be provided within one page and the ideal number of links to be

used.

Electronic books could be described as hypertext system with certain constraints. They

offer a relatively small number of links, that usually follow a special schema. Elec-

tronic books try to transfer the characteristics of books to the hypertext by offering

similar possibilities concerning navigation and granularity of information presented

on a single page. The major disadvantages of electronic books are the lack of capa-

bility to present complex relations effectively and the danger of learners getting bored

very easily on using the medium.

Kiosk systems and guided tours are systems that use author-edited paths or predefined

links for navigation. These systems are usually used in “point of information” (POI)

or “point of sale” (POS) scenarios, where the user should just be given a very limited

capability to influence navigation. Kiosk systems thus just define a small subset of the

navigation possibilities of hypertext systems and electronic books. It is quite easy to

use such a system, and the provider ensures that all information provided has actually

been accessed by users who completed the guided tour.

From now on we will focus on hypertext systems because this paradigm is nowadays

implemented by many popular learning platforms.

2.2.3 Challenges to be met by e-learning software

When developing e-learning software, one must consider the following aspects (see

figure 2.4):

� The learner

� Intellectual and/or learning activities the system tries to trigger

16

� The knowledge domain and related material

� Goals/tasks/given intention/the “motive” for hyper-media use

Goals/Task/given intention/"motive" of Hypemedia use

Domain/Material(s)

Intellectual and/orlearning activities

User/Learner

Figure 2.4: System - learner - interaction according to [FM90]

[FM90] describes the following dependencies or interactions within such a system,

each represented by a triangle within the 3-dimensional figure:

1. Learner – goal – domain

2. Learner – goal – activities

3. Learner – domain – activities

4. Activities – goal – domain

The model describes the role of the learner as a vital part of the e-learning system.

Besides influencing goals and the knowledge domain to be presented (interaction 1),

his/her capability of performing cognitive operations has to be taken into account by

the system (interaction 2). Interactions 3 and 4 describe the dependencies between

learners, goals, knowledge domain and cognitive operations the system should aim at.

E-learning software should in all respects be designed according to the needs of the

target group of learners. This comprises the content itself, as well as presentation

17

and navigation. Content should be arranged clearly and should be presented in an

interesting way.

Designers of e-learning software, especially in online education, must compensate for

the absence of a human teacher with additional application features.

The underlying software platform, which amongst others is responsible for delivering

navigation, must provide an environment that is likely to encourage learners to both

use the courses it provides and to actually learn the content delivered.

As user questions and feedback to content providers are essential for content evaluation

and the improvement of the system, application developers should consider supporting

this feature.

The major advantage of the “online education” approach is that content delivery and

learning actually gets decoupled from time and location – everyone participating can

learn whenever and wherever he or she wants to learn.

A major challenge for online education is the compensation of problems that come

along with learners working on their own, separated from each other. In traditional

teaching, students and teachers as well as students among each other interact in class,

e.g., by asking questions to the teacher or even another student. The teacher recog-

nises if there are problems in understanding and reacts accordingly by giving addi-

tional explanations. Implementing this behaviour in software currently seems to be

impossible (see section 2.1.2 on page 10). Extending communication features within

the e-learning platform might be another possible way to tackle these problems.

As a result, meeting these challenges is vital for the success of any e-learning software.

In the following chapter we will take a look at e-learning systems from an architectural

perspective and define technical requirements to be fulfilled by an ideal e-learning

platform.

18

Chapter 3

Learning Management Systems

Current e-learning platforms typically consist of several modules that support course

development as well as administration and content presentation, e.g., an authoring en-

vironment, a content management system, an e-learning runtime system. Usually these

components are accessed through a web-based portal, but some systems may offer in-

dividual interfaces for each module. An e-learning platform that offers these features

is called a learning management system (LMS).

3.1 Technical challenges in e-learning

Content of Teaching

LMS

AuthoringEnvironment

ContentManagement

System

RuntimeEnvironment ...

Learner

Figure 3.1: A learners view of an LMS

In a learner’s view of such a system, content and the underlying presentation software

19

form a unit (see figure 3.1). The learner uses, e.g., a web-based portal, to access the

content delivered by the LMS. For him there is no way to tell if the system vendor or

the author of the content is responsible for a particular system reaction.

The content provided by an author forms a separate layer on top of the LMS’s soft-

ware components. However, when designing content, authors have to depend on the

system’s capabilities of navigation, search, user management, testing, etc. As different

LMSs provide varying capabilities, transferring content from one system to another is

a challenging task.

To enable authors to produce valuable content in terms of didactics and according to

the latest models of learning theory, as well as to simplify content transfer between

systems, minimum requirements have to be defined for the underlying LMS. It is diffi-

cult for authors to produce valuable content using a “bad” LMS platform but a “good”

LMS does not guarantee that the content produced will be valuable either. Both LMS

vendors and authors have to cooperate to reach that aim.

Another challenge in LMS-design is to provide support for a customisable system

behaviour to enable both inexperienced and experienced learners to work successfully

with the system, i.e., the system should be able to adapt to the individual needs of a

learner. This concept must be supported at different levels within an LMS’s runtime

environment:

� It must be possible to personalise the output and behaviour of individual func-

tional components of an LMS, e.g., search or annotation facilities. Looking at

the diversity of functional components involved, this is a highly individual task.

� There has to be some kind of support for a “system wide personalisation strat-

egy”. The system as a whole must coordinate adaptation efforts within the func-

tional components in oder to offer a user some kind of individual portal.

20

� A third important challenge concerning the architecture of an LMS is the in-

creasing demand for collaboration between different institutions.

“Virtual universities” offer learners the opportunity to study online without the need

to go to a physical university. Such institutions are often established jointly by several

traditional universities, cooperating to provide online studies at reduced cost and at

the same time, enabling resource sharing, e.g., digital libraries and search engines, for

the traditional courses they offer. There is therefore a need to provide a simple access

point that a learner can use when working with the system.

In the following section, we specify the requirements that must be met by LMSs that

support the creation of valuable and portable content of learning. After that we will

have a look at standards and specifications that currently define a basis for content

portability.

3.2 Requirements definition for LMS

As content presentation is independent from the authoring environment we will con-

centrate on defining requirements for the runtime system and other LMS modules re-

lated to it. The requirements to be defined can be grouped into categories, each cover-

ing a specific aspect or “use case” of the LMS.

In addition, a general support for personalisation of the runtime environment is neces-

sary. The learner might consider the personalisation features as part of the LMS access

portal, even though they do affect the design of all LMS components.

3.2.1 User roles

One must consider the different roles users can take up when communicating with the

LMS:

21

� Author,

� Administrator,

� Trainer,

� Learner.

Although usage scenarios might exist where there are no trainers (or teachers), typi-

cally there is at least one person responsible for a course. In some cases author and

trainer are just the same person, nevertheless this person plays different roles.

3.2.2 Use cases

Author

Administrator

Trainer

Learner

produces content

receives feedback

administrates users/roles

administrates ressources

localises courseware

is responsible for courses

gives feedback

tests learning success

communicateswith learners

uses courseware

annotates courseware

Figure 3.2: Use cases in an LMS

Authors produce teaching content for the system by using its authoring environment.

In addition they receive feedback from trainers who use the content in courses they are

responsible for. Depending on this feedback they might modify the content to provide

improved or updated versions.

22

Administrators are the technical contacts for authors, trainers and learners. The admin-

istrator is also responsible for the management of user roles and user accounts within

the LMS. The LMS itself (i.e., the system itself and the local resources involved) is

supervised by the administrator. He/she is responsible for course management on the

system, incorporating a possible version control of course-ware and access control to

the LMS. Part of the administrators’ tasks may overlap with the duties of the system

administrator responsible for the underlying machines and operating systems. The ad-

ministrator uses the communication and administration facilities provided by the LMS.

Trainers receive feedback about course-ware from the learners. In addition they may

be involved in monitoring the progress of learners by inspecting logs and test results.

This very much depends on the scenario the system is used in. Trainers may also be

involved in “localising” the content by adding annotations and local resources or by

combining several subjects into one module. Trainers usually interact with learners

and authors of course-ware using the communication module of the LMS. They may

also use some kind of administration tool to adapt the content of teaching to local

needs.

Learners use the LMS to acquire knowledge. They usually access the system via some

portal that represents the user-interface of the runtime environment (see 3.1). Learners

browse the content provided by the LMS. The LMS should offer facilities to bookmark

sections and to annotate the content provided in order to support learners. By perform-

ing self-tests, a learner can monitor his progress through a course. To communicate

with the trainer and other learners the communication module of the system can be

used. Typically learners use additional features provided by the portal to support their

tasks, e.g., search capabilities or capabilities to personalise the portal.

Looking at the use cases described above (see figure 3.2), we observe that only learners

and trainers actually get in touch with the runtime module of the LMS, which is the

one we are mainly interested in. Therefore we will take a closer look at the functional

23

components of an LMS runtime module which provides the features that are necessary

to implement the use cases defined above.

3.2.3 Functional components of the runtime module

To fulfil the needs of trainers and learners working with the system, the runtime module

must offer at least the following functional components:

� Access control,

� Portal,

� Presentation platform,

� Communication platform.

In addition to these components that are jointly used by trainers and learners, the sys-

tem must offer personal teaching and learning environments that represent the “desk-

top” of the user working with the system. Administrators as well as trainers may be

entitled to use some kind of evaluation component to determine the success of users

working with the system.

Features that should be implemented by these functional components are described in

detail below:

3.2.3.1 Access control

Access control is needed to identify users and to enforce access privileges defined

according to the role a user adopts when working with the system. Thus access control

comprises the following building blocks: Authentication and Authorisation, user and

profile management, role management, the management of access privileges for users

and roles.

24

Optional accounting and billing facilities as well as access statistics and auditing might

be available.

3.2.3.2 Portal

Both trainers and learners access the system via a portal. The portal does not neces-

sarily have to be the same, but this is often the case. The portal must offer some way

of indexing the content provided. This could be realised by, e.g., offering a structured

catalogue and/or short summaries of the course-ware.

For didactical reasons, rankings and comments of authors, trainers, and learners on

content should be supported. The portal should provide a facility to publish news and

announcements. Usually, a search engine and a download facility are also included.

The portal might as well host the communication platform and the presentation plat-

form, which are described below. Personalisation requirements demand the ability to

adapt layout and content of the portal page on a per user basis.

3.2.3.3 Presentation platform

The presentation platform displays the content of teaching after the user has selected a

course from the portal. It typically allows browsing of content and should support the

addition of comments. Trainers should be able to add content during adaption of the

course-ware to local needs.

The presentation platform may allow access to a history and different variants of

course-ware. In that case a content management system would typically be involved

in content presentation. Learners and trainers might be entitled to add internal and

external links to related material and place comments and ratings to individual items.

In addition the presentation platform might offer printable or downloadable versions

of the teaching content.

25

Typically this platform is embedded in the portal described above.

3.2.3.4 Communication platform

The communication platform offers ways for contacting other learners, the trainer of a

course or other users, possibly allowing users to refer to a specific part of the content

when asking questions. Communication can be realised using e-mail or forums.

Some kind of “synchronous” communication might be offered as well, e.g., one could

think of a chat-forum, where students and trainers meet from time to time.

A list of frequently asked questions concerning the content of courses might be helpful,

as it saves trainers’ time.

3.2.3.5 Evaluation and logging

Evaluation is necessary to determine the degree of usage of parts of the system, and

the success that learners have in testing their knowledge on course completion. The

degree of usage could, for example, be determined by looking at the following figures,

which must be tracked by the system:

� Percentage of pages that have been displayed for a certain period of time,

� number of annotations made by learners,

� test results,

� usage of interactive components (simulations, experiments) within the system.

Of course these figures must be analysed further for significant correlations, as they

depend heavily on the content provided by the system and the knowledge that learners

have already accumulated beforehand.

26

3.2.4 Personalisation requirements

Section 2.1 describes the difficulties in addressing learners with different social back-

grounds and varying experience in using LMS for learning.

Training such a heterogenous group of learners is a great challenge for content authors

as well as for LMS vendors. Moreover authors must take into account that learners

may have accumulated varying knowledge before they start a course.

A way of meeting that challenge is to offer learners an individualised view of the LMS,

allowing beginners and experts to work with the content in ways that meet their experi-

ence with the system, as described in section 3.1. Aside from the content presentation

itself, other parts of the system should offer this kind of flexibility as well. For ex-

ample, search services could offer some kind of “advanced search” that offers expert

options, and learners who collaborate can use some kind of common desktop or allow

other users to share their personal notes on the content provided by the system.

This kind of behaviour is described by the term “personalisation”. In order to support

personalisation, the underlying LMS must be structured in a very flexible way, e.g.,

it should allow the modification of layout and content of all services presented on the

portal page on a per user basis. Ideally the LMS provides interfaces that allow the

extension of the base system by adding own features.

Supporting personalisation is a complex undertaking and has a significant impact on

the overall design of the underlying LMS.

From a user’s perspective personalisation results in a personal learning environment

for learners and optionally a personal teaching environment for teachers:

3.2.4.1 Personal teaching environment

The personal teaching environment addresses the needs of trainers by supporting the

adaptation of course-ware to local needs, the publication of annotations and the cre-

27

ation of messages and news for specific groups of learners. It is therefore embedded

in the portal page of a trainer and can be summarised as the “trainer-specific” features

that the portal offers.

3.2.4.2 Personal learning environment

The personal learning environment is the counterpart of the personal teaching environ-

ment for the learner. It offers support for personal and optionally sharable annotations,

the latter to allow groups of learners to cooperate and share their notes. The personal

learning environment is also responsible for storing bookmarks, self-test results, sim-

ulation parameters and experiment results that are individual to the learner.

3.2.5 Collaboration requirements

Partly because of the possible reduction of costs, institutions currently start to collab-

orate by simply broadcasting a lecture from one institution to another or by offering

shared e-learning courses.

Looking at the functional components defined in section 3.2.3 a close collaboration

results in complex requirements for the underlying learning environment.

A student who uses the LMS should be able to use local resources as well as the

resources of a remote institution. There should be no need to use different access

portals or user accounts. Ideally remotely stored data should be presented using the

local portal.

In order to support, e.g., resource sharing, we will look at the drawbacks of the usually

monolithic design of existing platforms.

In a sample scenario, two cooperating institutions each use monolithic LMS systems.

Both systems offer web-based portals for user access. These portals hide the complex-

ity of the underlying LMS systems with their functional components.

28

User

DBMS

DBMS

LDAP

LDAP

Institution A

Institution B

LDAP repositorysynchronisation

Figure 3.3: A minimal solution for LMS cooperation

In order to access features provided by the LMS system of the remote institution, a user

needs to access the portal of this LMS. This requires a second user-account or – for a

lage-scale cooperation – user-account synchronisation as depicted in figure 3.3. Ac-

cessing a second portal for additional functionality represents the absolute minimum

in terms of cooperation and fails in delivering the experience of an integrated envi-

ronment to the user. In addition the different look & feel of a second platform might

cause difficulties in handling the system for inexperienced users. Last but not least this

way of institutional cooperation complicates user cooperation and interaction between

users in different institutions as the two systems do not interact with each other at all.

A more tight cooperation of LMS platforms is necessary to support collaboration. Usu-

ally a user is not interested in using an additional portal or a second LMS at all, because

this itself does not offer any benefit. However a user may be interested in using specific

features or functional components of a different LMS installation, e.g., a digital library

with interesting literature or a feature which is not present in the local platform at all.

To allow one platform to access functional components of another platform directly

(without invoking a second portal), the platforms have to provide standardised APIs

29

which allow description, discovery and invocation of the functional components.

User

Institution A LMS

Institution B LMS

FC

FC

FC

FC

FC

FC

...

...

Figure 3.4: An approach for close LMS cooperation

The functional components (FC) in figure 3.4 may be part of a monolithic LMS system

with standardised APIs, but could also be implemented as individual applications.

3.2.6 Summary

We defined a number of requirements to be fulfilled by an LMS runtime environment.

These requirements focus mainly on the functional components the system is com-

prised of, as well as personalisation and collaboration support. They did not deal with

content delivery itself.

We will now take a look at existing standards and specifications for e-learning. These

standards mainly concentrate on the “content layer”, focusing on content display, in-

teroperability, and reusability. While we are primarily interested in the underlying

system architecture, the functionality of the “content layer” depends on the underly-

ing system infrastructure and thus may lead to additional requirements for the system

infrastructure.

30

3.3 Interoperability standards and specifications

Porting contents to different LMSs is a non-trivial operation as authors tend to use the

individual features of an LMS extensively, especially when creating interactive con-

tent. As content production is very expensive, interoperability is increasingly required

by authors as well as by customers who use course-ware.

Several standards and specifications tackle the problem of defining a way to provide

“LMS-independent” interactive content.

3.3.1 Learning Object Metadata

The IEEE Learning Technology Standards Committee (IEEE LTSC) developed Learn-

ing Object Metadata (LOM) [LTS02], the standard used to describe learning objects

in an interoperable way. The definition of LOM metadata has been significantly influ-

enced by the European project “ARIADNE”1 and the US-based EDUCAUSE project

“Instructional Management Systems” (IMS)2, recently renamed as IMS Global Learn-

ing Consortium, Inc.

The LOM standard is widely accepted by developers of learning material and related

software and establishes a common basis for current standardisation approaches aim-

ing at an increase of e-learning content portability. Data elements of the standard de-

scribe a learning object from several aspects and are grouped into nine categories that

together form the LOMv1.0 Base Schema. The categories, as described by [LTS02],

are:

a) The General category groups the general information that describes

the learning object as a whole.

1see http://www.ariadne-eu.org for details2see http://www.imsglobal.org for details

31

b) The Lifecycle category groups the features related to the history and

current state of this learning object and those who have affected this

learning object during its evolution.

c) The Meta-Metadata category groups information about the metadata

instance itself (rather than the learning object that the metadata in-

stance describes).

d) The Technical category groups the technical requirements and tech-

nical characteristics of the learning object.

e) The Educational category groups the educational and pedagogic

characteristics of the learning object.

f) The Rights category groups the intellectual property rights and con-

ditions of use for the learning object.

g) The Relation category groups features that define the relationship

between the learning object and other related learning objects.

h) The Annotation category provides comments on the educational use

of the learning object and provides information on when and by

whom the comments were created.

i) The Classification category describes this learning object in relation

to a particular classification system.

3.3.2 Dublin Core Metadata

The Dublin Core Metadata Initiative3 (DCMI) traces its roots to Chicago at the 2nd

International World Wide Web Conference, October 19944. The DCMI defines meta-

data vocabularies for all different kinds of resources to simplify the development of

intelligent resource discovery systems.

3See http://www.dublincore.org/ for details4The initial workshop however was held in Dublin, Ohio, March 1995.

32

As the LOM standard defines a relatively complete set of metadata properties for learn-

ing, education and training, the LTSC and the DCMI agreed to collaborate on the task

of metadata definition. This means that the DCMI follows the LTSC definitions of

metadata for the area of learning, while LTSC follows the more general definitions of

DCMI, where applicable.

DCMI metadata definitions are encoded using the Resource Description Framework

(RDF) (see [W3C04b]), which is an emerging standard syntax for expressing metadata

schemas on the Web.

3.3.3 ARIADNE

The Alliance of Remote Instructional Authoring and Distribution Network of Europe

(ARIADNE) Foundation was created to succeed the ARIADNE and ARIADNE II

European projects, which created tools and methodologies for producing, managing

and reusing computer-based pedagogical elements and telematics supported training

curricula.

The ARIADNE projects contributed heavily to the IEEE LOM metadata standard (see

section 3.3.1) and the ARIADNE Foundation is still involved in LOM development.

All tools developed by ARIADNE use LOM compliant metadata.

Figure 3.5 depicts the ARIADNE system architecture. The ARIADNE framework

consists of several authoring tools. These are shown in the upper section of the figure.

ARIADNE authoring tools are used to generate different kinds of content documents,

e.g., simulations, questionnaires and video clips. These documents are then validated

and stored in the ARIADNE knowledge pool. Trainers can access the knowledge pool

via a curriculum editor to assemble courses; learners use a special learner interface

to access courses within the knowledge pool. The ARIADNE core tools consist of

validator, knowledge pool system, curriculum editor and the learner interface.

33

SimulationAuthoring

Tool

QuestionnaireAuthoring

Tool

Auto-EvaluationAuthoring

Tool

PedagogicHypertextGenerator

VideoClip

Generator

Activedocuments

ExpositiveDocuments

Pedagogic Header GeneratorValidation Tool

CurriculumEditor

KnowledgePool System

LearnerInterface

Figure 3.5: ARIADNE system architecture according to [ARI02]

3.3.4 IMS Specifications

The IMS Global Learning Consortium specified interfaces that must be implemented

by vendors of LMS to support interoperability for content and content related prop-

erties. The IMS specifications cover a variety of aspects in the area of e-learning

and rely on the definitions of the LOM standard when referring to properties. IMS

heavily propagates the usage of the extensible markup language (XML) for defining

interchange formats as well as for data storage.

Altogether IMS has produced 10 different specifications to date:

� Accessibility

� Competency Definitions

� Content Packaging

� Digital Repositories

� Enterprise

� Learner Information Package

� Learning Design

� Metadata

� Question & Test

� Simple Sequencing

The IMS specifications mainly focus on the content provided by an LMS and define

34

requirements for LMS interfaces from this content-centric point of view. Requirements

are often relatively abstract, e.g., the Accessibility specification discusses the usability

of LMS content for disabled persons, proposing the possibility of enlarging and re-

colouring of the content of teaching on an individual basis. The specification does not

regulate the data formats to be used; it does suggest specific XML-based data formats,

e.g., for formulas the specification proposes the usage of MathML5.

As the IMS specifications probably provide today’s most comprehensive definition of

requirements for LMS content interoperability, we will give a brief description of the

areas covered by these specifications:

3.3.4.1 Content Packaging.

Content packaging [IMS01a] addresses the transfer of IMS defined information be-

tween different LMS. IMS defines XML schemas for all kinds of data to be stored

within an LMS. Content Packaging focuses on file structures to be created by one

LMS in order to transfer such data to another LMS, which then is able to interpret the

content received.

Metadata

Organisations

Metadata(sub)Manifest

Resources

Manifest

PHYSICAL FILES

(The actual Content,Media, Assessment,Collaboration, and

other files)

PACKAGEPackage Interchange File

Manifest File

Figure 3.6: Scope of IMS Packaging

5W3C Recommendation on XML-based formula definition, see http://www.w3.org/Math/ for details

35

Figure 3.6 depicts the scope of the IMS content packaging. In order to exchange con-

tent, a package interchange file, which is usually a ZIP archive, is used. This package

interchange file contains resources as well as metadata and organisational information

stored in a manifest file.

Content packaging is not only used for e-learning content, but also for other data to

be transferred from one LMS to another (see [IMS01b] for details). For example, in-

formation about learner accounts, described in the IMS Learner Information XML

Binding, can be transferred using the content packaging mechanisms. In order to

transfer information about one or even multiple learners, the LMS creates so called

Learner Information Package instances (LIP-i) from the learner data, usually stored in

a database. These LIP-is are XML documents that follow the IMS Learner Informa-

tion XML Binding and are located in a directory tree, allowing additional files (e.g.

JPEG images, . . . ) to be added if required. This directory tree is then packaged into a

package interchange file.

3.3.4.2 Digital Repositories.

The “IMS Digital Repositories Interoperability” specification [IMS03] defines a func-

tional architecture covering interactions between digital repositories and LMS (see

figure 3.7).

The specification aims at defining ways of accessing digital repositories through some

kind of standard interface. The current focus is on the ANSI/NISO Z39.50 standard,

mainly used for connecting library portals (see [ANS95] for details), and the SOAP

Protocol6, to connect repositories that do not support Z39.50.

The current version of the Digital Repositories Interoperability specification addresses

the interactions marked as “addressed by first phase” in figure 3.7.

6see http://www.w3.org/2000/xp/Group/ for details.

36

AccessManagement

Authenticate

Authorise

ControlAccess

ManageRights

Resolve

AuditObligations

Resource Utilizers

DISCOVER ACCESS USE(Query, Browse, Follow Path)

SEARCH GATHER REQUEST

STORE MANAGE EXPOSE

SUBMIT ALERT

DELIVER

Metadata Assets

Learner Creator Infoseeker Agent

Procurement

MakePayment

NegotiateTrade

Repositories

DirectoriesPeople

Organisations TradersRepositories

STORE MANAGE EXPOSE

Registries

Metadata VocabularyCompetencySTORE MANAGE EXPOSE

LegendEntity - Roles

Entity - Functional Components

Entity - Services

Interactions addressed by first phaseInteractions to be addressed by second phase

Figure 3.7: Scope of IMS DRI according to [IMS03], page 5

The specification mainly deals with searching repositories of different kinds and defin-

ing components to deal with different query languages and multi repository searches,

where results are aggregated subsequently.

However this IMS specification is incomplete, as the current version still does not

specify most of the interactions described in the figure.

3.3.4.3 Enterprise.

The IMS “Enterprise Information Model” [IMS02] defines interfaces for data exchange

between an LMS and Enterprise Systems (e.g., Human Resource Systems, Student

Administration Systems, . . . ) as depicted by figure 3.8.

IMS defines the properties and an XML schema that systems should use as a base for

data exchange. The IMS Enterprise specification proposes the use of a simple messag-

37

Enterprise System Enterprise System

LMS Client

IMS Enterprisespecification scope

Figure 3.8: Scope of the IMS enterprise specification

ing mechanism to exchange information, but a file-based exchange is also possible.

3.3.4.4 Others.

Other IMS specifications mainly deal with interoperability of the content of teaching

itself, e.g., the “IMS Question and Test Interoperability specification”, the “IMS Sim-

ple Sequencing specification” and others.

3.3.5 The Sharable Content Object Reference Model

The Sharable Content Object Reference Model (SCORM) is specified by the Advanced

Distributed Learning7 (ADL) initiative, founded by the Office of the US Secretary of

Defence. SCORM consists of two main parts: First, it defines a Web-based learning

“Content Aggregation Model” to model learning content in a vendor-neutral, reusable

way. Second, it specifies a “Run-Time Environment” for learning objects. SCORM

is a collection of specifications adapted from multiple sources to provide a compre-

hensive suite of e-learning capabilities that enable interoperability, accessibility and

re-usability of Web-based learning content.

7see http://www.adlnet.org/ for details

38

SCORM applies current technology developments to define a specific content model

by producing recommendations for consistent implementations for LMS vendors. It

is built upon the work of IEEE, IMS, ARIADNE and others to create one unified

“reference model” of interrelated technical specifications and guidelines in the area of

web-based e-learning content.

3.3.5.1 The SCORM content aggregation model.

SCORM defines a content aggregation model to describe the assembly of SCORM

compliant “learning experiences”, i.e., larger units of learning content, from existing

learning resources. The content aggregation model consists of three separate parts:

� Content Model

� Metadata

� Content Packaging

The Content Model. The Content Model describes the SCORM components that are

used to build a “learning experience” from reusable learning resources as well as how

these components can be aggregated to form such a “learning experience”. SCORM

defines the following components as specialisations of learning resources in general:

Assets, Sharable Content Objects (SCO) and Content Aggregations.

SCORM Assets are electronic representations of learning information, e.g., images,

text, web-pages, sounds or videos. Any data that can be displayed within a web-

browser can be considered as a SCORM asset. Assets can be described using SCORM

metadata, which simplifies reuse in other contexts.

Sharable Content Objects represent collections of SCORM assets, that use a special

asset to communicate with the SCORM adapter of the LMS in order to access or store

39

information. SCOs represent the lowest level of granularity a SCORM-based LMS

can access. SCOs are launched by the LMS, do not depend on other SCOs and can be

described by SCORM metadata.

Content Aggregations are used to form larger units of content, such as courses, chapters

or modules from SCOs. A content aggregation can be seen as a map of SCOs and

defines the sequence which is used for presenting the content to a learner. Content

aggregations can be described using SCORM metadata.

Metadata. The SCORM metadata complies with the IEEE LTSC LOM metadata

standard (see section 3.3.1 for details). SCORM allows metadata to be attached to

content aggregations, SCOs and assets.

The purpose of applying metadata to content aggregations is to support discoverability

of modules within a content repository and presentation of descriptive information

about aggregations of content seen as a single module.

Metadata can also be applied to SCOs embedded in such a content aggregation. This

allows a fine grained description of contents and simplifies reusability of SCOs as these

can be embedded in more than one content aggregation at any one time.

Applying metadata to “raw” content assets is useful for the creation of SCOs. Used in

this way, it helps authors to locate assets within a content repository.

Content Packaging. Content packaging describes a SCORM compliant way of de-

livering digital content, e.g., on a CD-ROM or in a ZIP-file. Content packaging is used

to exchange content between different authoring tools or LMS.

For this purpose SCORM complies fully with the corresponding IMS specification,

described in section 3.3.4.1. Additional specifications have been made to describe

SCORM SCOs and SCORM assets that have no counterpart in the IMS specifications.

40

3.3.5.2 The SCORM runtime environment.

Figure 3.9 depicts the SCORM runtime environment architecture that must be provided

by an LMS vendor. The runtime environment provides the necessary infrastructure to

embed and address learning content coded in SCOs.

APIAdapter

LMSServer

Javascript

SCO Asset

Browser

Learning Management System (LMS)

(1)

(2)

(3)

Client Side

Server Side

(1) Launch

(2) Data Model(3) API

Figure 3.9: Architecture of the SCORM runtime environment according to [Adv01],page 3-3

The Launch mechanism depicted in the figure describes a common way for LMS to

start Web-based e-learning resources. It defines the procedures and responsibilities for

establishing a connection between a learning resource and the LMS.

The API is a communication mechanism the LMS can use to monitor the current state

of an SCO, e.g., initialised, finished, or in an error condition. In addition the API is

used to get and set values between the LMS and the SCO, e.g., scores, time limits, user

data, etc.

The Data Model defined by SCORM is a basic set of “knowledge entities” or proper-

ties the LMS is entitled to offer and the SCOs can access via the API. The data model

represents the content that is communicated between LMS and SCO. It is the respon-

sibility of the LMS to maintain the state of the data elements defined within the data

41

model across sessions.

The API adapter to be provided by the LMS vendor must offer a SCORM compliant

API via JavaScript within the client Web-browser. The API adapter offers an interface

that serves several purposes:

� Execution state of an SCO

� State management in order to implement error control

� Data transfer between LMS and SCOs

Table 3.1 describes API calls that are used to notify the LMS of the current execution

state of an SCO.

Table 3.1: SCORM API for SCO execution state control

API CALL DESCRIPTION

LMSInitialize This function indicates to the API Adapter that the

SCO is going to communicate with the LMS. This

allows the LMS to initialise internally. It is a re-

quirement that an SCO calls LMSInitialize be-

fore is executes any other call.

LMSFinish This function is called by the SCO as soon as it has

finished communicating with the LMS. The SCO

can infer that all modified data has been stored per-

sistently within the LMS and the LMS can conclude

that the SCO has finished communicating.

When the LMS returns an error, the SCO can use the state management API calls to

find out what went wrong. These API calls are described in table 3.2.

42

Table 3.2: SCORM API for SCO state management


LMSGetLastError This API call allows the SCO to find out if an error

occurred during the execution of the last API call.

Each API call (except the state management calls)

resets this value. The function returns a numerical

error code.

LMSGetErrorString This API call delivers a verbal description of the nu-

merical error code specified. This is useful if the

SCO wants to perform some error output to the user.

LMSGetDiagnostic This API call allows vendors to provide additional,

vendor specific information on an error condition.

The main purpose of the SCORM API is to enable SCOs to access LMS data and

persistently store data in the LMS. API calls that allow exactly this are described in

table 3.3.

Table 3.3: SCORM API for SCO data exchange


LMSGetValue This API call allows the SCO to obtain informa-

tion from the LMS. The LMS offers a defined set

of property values that can be accessed by specify-

ing their names on calling LMSGetValue.

LMSSetValue This API call allows an SCO to send data to the

LMS. Property name and value have to be specified.

43

continued...


LMSCommit As the API adapter may cache values retrieved from

the LMS as well as data to be stored in the LMS,

LMSCommit ensures that the data sent to the LMS

by the SCO has been saved persistently.

Further details concerning SCORM can be found in [Adv01].

3.4 Existing e-learning environments

Many universities currently evaluate LMS platforms with the aim of introducing a

common learning-environment for different faculties in order to reduce maintenance

effort and costs. Several recent studies concentrate on the selection of LMS platforms,

some of them analysing more than 150 systems ([Sch03], [BHMH02]).

Unfortunately LMS products currently change and evolve very rapidly which makes

it difficult to come to a long-term decision. Thinking especially of the complex and

costly process of content migration due to the lack of standard support from most

platforms, this situation is very unsatisfactory (see chapter 3).

It is outside the scope of this work to perform an in depth analysis of LMS-systems like

[Sch03] summarises, but the following section gives a brief overview of the level of

support some popular LMS-platforms offer for the requirements defined in section 3.2.

The following platforms were chosen for the brief analysis:

� WebCT 3.68

� Blackboard9

8see http://www.webct.com for details9see http://www.blackboard.com for details

44

� Ilias 310

WebCT and Blackboard are two commercial LMS platforms that are currently espe-

cially popular with universities. WebCT has been originally designed for university

use and Blackboard has its roots at Cornell university. Ilias is a non-commercial and

open source system developed at the University of Cologne, Germany.

3.4.1 WebCT

3.4.1.1 Functional components

WebCT is a very flexible and feature-rich LMS. It supports several user-roles (author,

administrator, trainer, learner), but each user may be assigned just one single role.

Access privileges may be defined on a user or a role basis. The portal supports indexing

of course-ware, provides a course catalogue and summaries of course content as well as

news and announcements related to courses. However the portal does not allow users

to rank course contents or to insert comments on courses. The LMS allows teachers

and learners to add bookmarks in order to point to additional resources. For learner

collaboration, the system provides access to e-mail, chat, and forums. It also provides

an integrated address book. WebCT supports LOM meta-data and provides a very

basic SCORM support: a script allows one to package WebCT content in a SCORM

compliant way. WebCT is a member of the IMS consortium but does not state clearly

whether it currently supports all of the IMS specifications.

The table in appendix B.1 characterises WebCTs features according to the require-

ments defined in section 3.2.10see http://www.ilias.uni-koeln.de for details

45

3.4.1.2 Personalisation

WebCT does not support content annotation and offers no way of sharing notes be-

tween learners. Support for learner collaboration is realised by defining communities

on the WebCT web site, where learners can discuss topics related to a course. However

WebCT does not allow users to define private communities.

Figure 3.10: Configuration of a user’s “My WebCT” page

Learners may access self test results stored in WebCT but reviewing experiment and

simulation results is not supported. WebCT allows teachers to send messages to all

members of a course or other groups. Portals may not be personalised on a per-user

basis, for example by reducing functionality, but users can configure an individual

“My WebCT” page with information on courses booked and regularly used features

(see figure 3.10).

3.4.1.3 Collaboration

WebCT does not offer any APIs for institutional collaboration. The system is realised

as a monolithic application with an underlying database, which makes it difficult to

46

integrate the LMS with other software or to offer services to several LMSs.

3.4.2 Blackboard


Blackboard is a commercial LMS which offers a great variety of supportive features.

The system supports several user roles (Instructor, Teaching assistant, Grader, Course

builder, Student, Guest) where each user may be assigned exactly one role and pro-

vides a very flexible access control system. The portal displays a course catalogue, but

indexing or ranking of course-ware is not possible (see figure 3.11). Blackboard allows

the annotation of course-ware solely on course level, i.e., it is not possible to annotate

a certain page or content element. Learners may use private forums, e-mail or chat

for collaboration. An address book is also part of the portal. The look & feel of the

portal is not individually configurable, the design is selected for the whole institution.

However users may choose the language the portal gets displayed in.

Figure 3.11: The blackboard user portal

Blackboard uses IEEE LOM meta-data and states that the LMS supports the IMS spec-

ifications. Courses using the Microsoft LRN format (see [Mic] for details) that relies

internally on the IMS content packaging may be imported.

47

The table in appendix B.2 characterises Blackboards features according to the require-

ments defined in section 3.2.


Blackboard does not support fine grained content annotation and offers no way of shar-

ing notes between learners. Learners may collaborate using private forums to discuss

topics related to a course.

Blackboard allows teachers to send messages to all members of a course or other

groups. Like WebCT, portals can not be personalised on a per-user basis but users

can configure an individual home-page with information on courses booked.


Blackboard consists of a web server and a database. The system itself is implemented

mainly in Java. Blackboard provides no interfaces for institutional collaboration, but

it is possible to use one installation with customised layout for several institutions.

Blackboard offers the “Blackboard Building Blocks” – a Java API which allows one

to extend the LMS system and to access learner and course information. To use the

building blocks, a developer license must be purchased.

3.4.3 Ilias


Ilias is a LMS developed at the University of Cologne. It is written in PHP and pub-

lished under an open source licence. The system provides a course access portal as

well as user communication facilities and an integrated course-ware editor. A user

may be assigned several different roles. Initially the LMS provides roles for admin-

istrators, authors and learners, but other roles may be added as needed. The flexible

48

authentication and authorisation mechanism allows the definition of privileges based

on users and roles and provides a way of authenticating users against an LDAP server

in order to integrate the system into an existing infrastructure. The portal provides

a course-ware catalogue with index facility and content summary (see figure 3.12).

However user comments and ranking of content is not supported. Users may access

course content based on keywords using a search engine. The system also provides a

download facility for course material. Users may communicate using e-mail, forums

or chat. It is possible to define private forums for groups of learners. The system pro-

vides an integrated address book. Ilias states that they support LOM meta-data as well

as IMS packaging and the import of SCORM compliant learning objects.

Figure 3.12: The Ilias user portal

The table in appendix B.3 characterises Ilias’ features according to the requirements

defined in section 3.2.


Ilias allows learners to cooperate by offering open and closed group forums and online

chats. It is not possible to annotate content in Ilias. Users may store bookmarks,

but sharing of these bookmarks is not supported. Self test results can be reviewed by

49

learners, but Ilias has no support for handling simulation and experiment results. Ilias

offers a user tracking system and teachers can send messages to groups of learners.

Ilias does not support the personalisation of the portal on a per user basis.


Ilias consists of a database and a web server. The system is implemented in PHP

and currently offers no interfaces for system extension. However such an interface is

planned for a future version. User authentication and authorisation may be integrated

with existing systems using LDAP.

3.4.4 Conclusion


The brief evaluation performed in section 3.4 shows that the three platforms presented

do more or less fully fulfil the functional requirements defined in section 3.2.3.

However looking at personalisation and the ability of the systems to collaborate with

other institutions, this picture changes.


The systems allow a minimum of personalisation, e.g., changing the portal-language

or definition of individual colours and sometimes font-sizes.

None of the systems presented allows one to configure the portal on a per user basis in

order to display a different look & feel, e.g., for beginners and experts. The systems

also do not allow the configuration of different data sources for search, etc.

Blackboard allows extensions to the basic LMS with the so called “Building Blocks”

API while Ilias is open source and therefore extensible on a source code basis. There-

50

fore personalisable features can theoretically be added to these two systems. However

this is not what customers usually expect to do by themselves as implementing addi-

tional features is very costly and often complex. In the case of Ilias no one guarantees

that the APIs of future versions will remain unchanged. Remembering the rapid change

and evolution of the market these additional features would probably have to be reim-

plemented for a different platform if the institution decides to change. With the lack of

standardised APIs this is certainly not the way to go.


None of the systems presented offers APIs for collaboration of several installations.

The focus of the systems is clearly not on distribution. They all require a central

“LMS-server” where portal and database are located. All systems optionally offer

LDAP-based authentication so at least a single-sign-on solution for several installations

is possible, which is one of the building blocks for collaboration.

However the synchronisation of LDAP servers would have to happen outside the plat-

forms and using LDAP would not include sharing course or learner data like self-test

results and so on.

51

Chapter 4

Design

As defined in section 3.2, the requirements for an LMS runtime system are classified

into the following categories:

� Functional aspects

� Personalisation

� Collaboration in distributed scenarios

A brief analysis of three existing LMS systems (see section 3.4) showed that the three

platforms more or less fulfil the functional requirements defined, but deficiencies exist

with respect to personalisation and the flexibility needed to support collaboration with

distant institutions. We will therefore focus our design efforts on these two aspects.

4.1 A service-based LMS architecture

4.1.1 Architectural building blocks

The building blocks of the architecture are the functional components described in

section 3.2.3. As each functional component contains related business functionality,

52

e.g., search functionality or annotation functionality, it represents one or more use

cases in a use case model of the runtime system.

FCFC

FCFC

FC

FC

FC

Portal

Portal

User A

User B

FC

Portal

LMS functional component

LMS portal component

Figure 4.1: Cooperation of functional components

These functional components (represented by use cases) are the entities to be shared

across the cooperating LMSs, i.e., users of the LMS located at institution A could

directly access functional components of the system hosted at institution B.

Figure 4.1 depicts the principal interactions between functional components and por-

tal components involved in such a tight cooperation. Users access the system via a

portal component. This portal component connects to the functional components of

the system and interacts with them. In order to fulfil their tasks, functional compo-

nents can, in addition, interact with each other without involving the portal component

at all. The location of functional components is transparent to a user, i.e., functional

components may be located in different places or institutions. With such an approach

system boundaries become more and more invisible. In an extreme example configu-

ration each collaborating institution offers just a single portal component and one or

more functional components, accessing the rest of the “virtual LMS” via a common

53

network, e.g., the Internet.

To support personalisation in such a complex environment common guidelines for per-

user-personalisation have to be defined among the collaborating systems.

4.1.2 Overall system architecture

Since functional components are the business building blocks of the distributed LMS

runtime system, they must be implemented as services that can be accessed from re-

mote parts of the system as well as from co-located services.

In addition to the business functionality offered, the services must also provide a way

of identifying and discovering other parts of the distributed LMS runtime system.

4.1.2.1 The basic service interface

To successfully cooperate with each other, services should be able to query the type of

other services and additional information such as the location or textual description of

a service instance. Moreover, tasks like initialisation and termination are required to

run individual services.

This functionality is defined in a common base service interface that must be imple-

mented by all services (see figure 4.2).

interfacelmsServices::Service

+Class:string+Subclass:string+Name:string+Description:string+Version:short+ServiceLocation:string+Id:string

+ping:void+initialize:void+shutdown:void

Figure 4.2: The basic interface to be implemented by the services

54

The methods defined in the interface may be invoked without previous initialisation of

the service. Their implementation does not rely on a connection to other services in

the LMS.

The interface offers several read-only properties that allow other services to identify

the type and particular instance of a service they connect to. A detailed description of

these properties follows:

Class returns the service class of a service. Service classes represent a particular

functional component of the system. A service offers an interface which can be ad-

dressed after querying the service class. The following are the currently valid service

classes, the list may be extended on demand:

� annotation

� bookmark

� chat

� logging

� lookup

� mail

� news

� property

� iscorm

� search

� security

Subclass allows a service to advertise a further specialised interface. The possibil-

ity to offer a derived interface with additional functionality grants maximum flexibility

for service providers. In cases where a service does not know the service subclass, it

can still address the standardised interface described by the service class. The method

returns “none” if a service implements only the standardised interface.

Name returns the name of the service instance, e.g., “ACME Property Service”. The

name of a service is intended to be used by the portal or other services when presenting

55

services to the LMS users.

Description returns a textual description of the capabilities of the service. This

text can be presented to users who require information about the capabilites of func-

tional components of the LMS system.

Version returns the version number of the service interface. This is useful in case

the standard interface definitions change in the future. Currently all services return

“1”. Together with the Class() method this uniquely identifies the interface of a

service in the architecture.

ServiceLocation returns the location of the service instance, e.g., “Department

of Maths & Computing, Cork Institute of Technology, Ireland”.

Id returns an ID uniquely identifying the service instance. This string is not intended

to be read by humans.

In addition to the read-only properties each service must provide the following meth-

ods:

Ping() tests whether a particular service instance is alive. Vendors have to ensure

that a call to ping tests vital aspects of the service functionality, e.g., by executing a

test transaction on a database table.

Initialize() must be invoked before any business methods of the service can

be accessed.

Shutdown() must be invoked before a service instance gets destroyed. After

shutdown() has been called, the service stops responding to further queries.

56

4.1.2.2 Multiple service layers

Not all services in the distributed environment represent functional LMS components

as defined in section 3.2.3. Some provide assisting functionality, e.g., retrieving ref-

erences to other services, storing properties, logging certain events. Such services

are typically used by other services within the same institution as the response times

between services in different institutions may involve an unpredictable and/or unac-

ceptable delay.

We call this type of services infrastructure services to distinguish them from e-

learning services which represent functional components of the system.

E-learning services may use other e-learning services and infrastructure services to

fulfil their task. Infrastructure services do not depend on e-learning services but may

use other infrastructure services that are locally available.

In addition we differentiate between services which are solely available within an in-

stitution and services which are available across institutional boundaries.

Hence, our distributed LMS runtime system consists of three types of components:

� portal components

� e-learning services

� infrastructure services

E-Learning services and infrastructure services are tagged as either InnerInsti-

tutionalService or CrossInstitutionalService in order to define their

scope of availability.

From a logical point of view portal components are also e-learning services. They

communicate with other e-learning services and make use of infrastructure services

just as other e-learning services do. Moreover, they provide a (usually web-based)

57

portal for LMS users. The portal is individually implemented by the portal provider,

which allows for customisation of the LMS system.

E-learning services interact with users through the portal of the portal component, i.e.,

the portal service integrates the other e-learning services and thus is able to customise

their output.

Infrastructure services are available to the e-learning services in each institution. They

provide basic functionality for other services like the persistent storage of properties.

58

Aut

hent

icat

ion

Aut

horis

atio

n

Por

tal

Pro

perty

Sea

rch

Ann

otat

ion

SC

OR

M-A

PI

Mai

l

Look

upLo

g

Boo

kmar

kC

hat

Ann

ounc

emen

t

E-L

earn

ing

Ser

vice

s

Infra

stru

ctur

e S

ervi

ces

Per

sona

lisat

ion

Com

mun

icat

ion

Figu

re4.

3:T

hese

rvic

e-ba

sed

LM

Sar

chit

ectu

re

59

Figure 4.3 depicts the overall system architecture of the distributed LMS runtime en-

vironment.

We discuss this system architecture in more detail in the following sections. We start by

describing aspects common to all services like, e.g., data structures. We then discuss

the infrastructure services that form the basis of e-learning service interoperability.

Finally we look at the e-learning services, which represent functional components of

the distributed LMS.

4.2 Common data structures

Several data structures that are used by multiple LMS services have been defined glob-

ally.

4.2.1 The TServiceInfo structure

As described in section 4.1.2.1 services offer a set of read-only properties which allow

other services to identify a service of a particular class or a certain service instance.

In several cases many or all of these properties would be queried by a service, e.g.,

logging debug information. As the services communicate in a distributed environment,

each call costs a significant amount of time. For that reason, services may provide their

set of common service properties in the TServiceInfo structure when calling other

services.

The structure is depicted in figure 4.4. It reflects the read-only service properties de-

scribed in section 4.1.2.1. A service that provides information using the data structure

is responsible only for providing up-to-date information which is identical to reading

the read-only properties through the service methods provided.

60

Figure 4.4: The TServiceInfo structure

4.2.2 The TProperty structure

Several LMS services use properties to exchange or store information of different

kinds, e.g., on service lookup or when using the property service. Properties are iden-

tified by a well known property name. In addition a property contains a property value.

This value may be coded in any simple or complex data type. Hence, existing solutions

which deal with properties often offer a generic datatype as a container for property

storage, e.g., in Java java.lang.Object, or in CORBA CORBA::Any.

As our architecture shall be as independent as possible from the underlying implemen-

tation, the usage of a generic data type is difficult. However, such a generic type or

container is desirable when dealing with all the different kinds of properties to provide

maximum flexibility for service vendors.

Figure 4.5: The TProperty structure

As depicted in figure 4.5 the TProperty data structure consists of three elements: A

property name which identifies the property, a property value which holds the actual

property value coded as a string and a property type. The property type is of type int,

and contains one of the following possible values:

61

1 = boolean

2 = float

3 = int

4 = string

5 = complex

Within TProperty the value is always encoded as a string, following the directives

explained below. The guidelines for encoding boolean, float, and integer types reflect

the Java methods for float and integer conversion, i.e., in a Java-based environment

there is a very low effort involved converting these types.

� Boolean: the strings “true” and “false”, alternatively “1” and “0” are used

for TRUE and FALSE.

� IEEE 754 float: the property value contains the sign and magnitude (absolute

value) of the float value. If the sign is negative, the first character of the result is

“-”; if the sign is positive, no sign character appears in the property value. As

for the magnitude m:

– If m is infinity, it is represented by the characters “Infinity”; thus, positive

infinity produces the property value “Infinity” and negative infinity

produces the result “-Infinity”.

– If m is zero, it is represented by the characters “0.0”; thus, negative zero

produces the property value “-0.0” and positive zero produces the prop-

erty value “0.0”.

– If m is greater than or equal to 10�3 but less than 107, then it is represented

as the integer part of m, in decimal form with no leading zeroes, followed

by “.”, followed by one or more decimal digits representing the fractional

part of m.

62

– If m is less than 10�3 or greater than or equal to 10

7, then it is represented

in so-called “computerised scientific notation”. Let n be the unique integer

such that 10n <= m < 10n+1; then let a be the mathematically exact

quotient of m and 10n so that 1 <= a < 10. The magnitude is then

represented as the integer part of a, as a single decimal digit, followed

by “.”, followed by decimal digits representing the fractional part of a,

followed by the letter “E”, followed by a representation of n as a decimal

integer.

If the float value is NaN, the property value contains the string “NaN”.

� 32-Bit integer: the property value contains the sign and magnitude of the integer

value. If the sign is negative, the first element of the property value is “-”.

If the sign is not negative, no sign character appears in the property value. The

remaining characters of the property value represent the magnitude of the integer

value. If the magnitude is zero, it is represented by “0”.

� String: the string is stored in the property value. An empty string is encoded as

“”.

� A complex type: this type must be described by an XML schema followed by the

actual data. This information is then stored in the property value, thus allowing

self-describing property types of any complexity. Listing 4.1 defines a currency

data type which may be used in a complex property.

Listing 4.1: Sample complex property

<xsd:element name="internationalPrice">

2 <xsd:complexType>

<xsd:simpleContent>

4 <xsd:extension base="xsd:decimal">

<xsd:attribute name="currency" type="xsd:string"/>

6 </xsd:extension>

</xsd:simpleContent>

63

8 </xsd:complexType>

</xsd:element>

10 <internationalPrice currency="EUR">

500

12 </internationalPrice>

4.3 Infrastructure services

The infrastructure service interfaces presented in this section provide a common in-

terface for classes of LMS e-learning services. This allows institutions to exchange

infrastructure service functionality transparently.

interfacelmsServices::InfrastructureService




Figure 4.6: The interface to be implemented by infrastructure services

The base interface for infrastructure services is derived form the basic service interface

as depicted in figure 4.6. As infrastructure services fulfil rather primitive tasks, no

further extension to the basic service interface is necessary.

The architecture defines the following infrastructure services as mandatory:

� lookup

� property

64

� logging

� security

Mandatory in this case means that e-learning services can rely on at least one instance

of each of these infrastructure services to be present at any time in order to work

properly.

This set of mandatory infrastructure services has been chosen for the following rea-

sons:

A lookup service enables services to locate each other by assigning symbolic names

to addresses and is necessary for every type of distributed environment to function.

Comparable services in standardised distributed environments like CORBA or Java

RMI are the CORBA CosNaming service and the RMI registry.

The property service provides a centralised way of storing configuration information

for other services. A similar functionality is provided by the Windows Registry for

Windows applications. The main benefit of such a centralised configuration repository

is the provision of a unified access to configuration information used by applications

(or services) implemented by different vendors.

The main purpose of a centralised logging facility is to support cross-service debugging

during implementation and deployment of the distributed LMS.

Additional infrastructure services may be defined, but e-learning services should not

rely on their existence without special notice as they are not mandatory.

4.3.1 The lookup service

The purpose of the lookup service is to support services in searching and selecting

suitable service instances thereby enabling them to connect and start to cooperate.

65

The lookup service fulfils a task similar to the “yellow pages”-book in public telephony

or even more like a trading service. A good example of such a multi-purpose trading

service is the CORBA Trader (see [Obj00b]). In contrast to the CORBA Trader the

lookup service interface is more focused on providing a lookup facility for a distributed

LMS.

E-learning services can register themselves with a lookup service instance. On reg-

istration they provide information that might assist other services in deciding which

service instance to use, including the following set of standard properties:

� class

� subclass

� version

� location

� id

� name

An additional reference may be specified in the property wsreference. Costs for

the usage of the service may be provided in a property named costs. A service is

free to submit additional properties on registration which allows further specialisation.

Advanced search is supported, i.e., it is possible to narrow the search to services with a

particular class and/or subclass or to express more complicated constraints concerning

the properties defined.

Lookup services are encouraged to cooperate in order to allow services located at other

institutions to locate remote services. However the cooperation between lookup ser-

vices is out of the scope of the lookup service interface – it is the task of the lookup

service provider to enable different instances to find each other in order to exchange

their entries.

4.3.1.1 The lookup service interface

Figure 4.7 depicts the interface to be implemented by a lookup service.

66

Figure 4.7: The interface to be implemented by lookup services

A lookup service provides methods for service registration, de-registration and discov-

ery of other services.

On registration, the service passes at least the mandatory set of properties which may

be used by other services querying the lookup service. The lookup service returns a

registration ID which is used for identification on service de-registration.

The service provides two methods for service discovery. One method allows the defi-

nition of a set of properties the offers are tested for. The lookup service simply returns

the references and descriptions of all services which contain the properties and prop-

erty values specified. The other query method allows the definition of complex query

constraints, e.g., return the description and references of all services of a certain service

class and costs per call of less than 150.

4.3.1.2 The TOffer structure

Figure 4.8: The TOffer structure

The TOffer structure (Figure 4.8) stores the references to a registered service as well

67

as all the service properties specified on registration. These properties are encoded in

an Array of TProperty types. The first six properties reflect the standard service

properties, the seventh property reflects the costs of the service usage. Optionally,

additional properties that have been defined by the service vendor are available. When

accessing these properties, services can perform additional filtering in order to decide

which of the offered services to use.

4.3.1.3 The lookup service constraint language

The lookup service constraint language is equivalent to the OMG CORBA CosTrading

constraint language (see [Obj00b], appendix B). Constraints are defined in a String

which is passed to the lookup service when querying for services. A constraint may

consist of identifiers, operators and constants. Valid identifiers are names of properties.

The following operators may be used to define a constraint:

== equal

!= not equal

< less than

> greater than

<= less or equal

>= greater or equal

+ add

- subtract

* multiply

/ divide

˜ substring of

not logical not

and logical and

or logical or

For example, a constraint refining the query results to annotation services in the Cork

Institute of Technology, Ireland may look as follows:

"(class == ’annotation’) and (location == ’Cork Institute

of Technology, Ireland’)"

68

Constraints use the string representation of a value stored in the property value field of

a TProperty for comparison.

4.3.1.4 Dependencies and interactions with other services

The lookup service may rely on the logging service in order to log debugging informa-

tion and errors. In addition the lookup service may store information in the local prop-

erty service. Lookup services may cooperate across institution boundaries. However

such a cooperation is necessarily implementation-specific, and therefore not specified

in the lookup service interface. For example a lookup service may offer only a selec-

tion of the local e-learning services to other institutions or vendors may introduce fees

for service usage.

A proposal for the cooperation of different lookup services could be the “export” func-

tionality provided by CORBA Trader services (see see [Obj00b]).

4.3.2 The property service

The purpose of the property service is to allow other services to store persistent data

concerning configuration and personalisation. The property service is an infrastructure

service and thus only accessible from a local environment. As the service stores con-

figuration information other services may depend on, its presence is almost as mission

critical as the presence of the lookup service.

The property service allows other services to store and retrieve data in the form of

name-value pairs. These are encoded in the TProperty structure described in sec-

tion 4.2.2.

In addition the property service provides a callback mechanism for notifying other

services in case of property changes (addition, modification, deletion).

69

The LMS property therefore fulfils a similar task to the standardised CORBA CosProp-

erty service (see [Obj00a]), but offers enhanced functionality like, e.g., the callback

mechanism.

4.3.2.1 The property naming scheme

Services must follow a specific naming scheme when choosing a property name:

ie.cit.lmsServices.<ServiceClass>.<ServiceId>. ...

<ServiceClass> specifies the service class as defined in section 4.1.2.1.

<ServiceInstance> represents a unique identifier characterising the service in-

stance which stores the property. Properties which are to be used by more than one

service instance may be stored in

ie.cit.lmsServices.<ServiceClass>. ...

However a service vendor should use this kind of properties rarely as the choice of a

property service usually depends on the actual service location and there is no guaran-

tee that all services of a certain class or vendor will use the same property service.

Strictly enforcing this scheme avoids name clashes.

4.3.2.2 The property service interface

Figure 4.9 depicts the interface to be implemented by a property service.

The property service offers methods for property definition as well as getting and set-

ting of property values. In addition the LMS property service supports queries regard-

ing the existence of a property and supports operations on property sets (getting and

setting values, querying and deletion).

The method registerPropertyCallback() allows a service to register for a

notification if a property value has changed or a property with the name specified

70

Figure 4.9: The interface to be implemented by property services

has been deleted. To use this method, a service must implement the property service

Callback interface described below.

4.3.2.3 The callback interface

The Callback interface (Figure 4.10) is implemented by a service that wants to be

notified of property changes by the property service.

Figure 4.10: The property service callback interface

A reference to the interface is passed on registration. The property service then sends

a notification whenever the value of one of the selected properties changes.

4.3.2.4 The CBRegistration interface

A reference to an instance of CBRegistration is returned on callback registration.

Figure 4.11 depicts the CBRegistration interface.

71

Figure 4.11: The property service callback registration interface

The interface allows services to deregister a previously made callback notification.

After calling unregister() no more notifications are sent.

4.3.2.5 Dependencies and interaction with other services

The property service uses the local logging service for debug and error messages. No

other service dependencies exist.

4.3.3 The logging service

The purpose of the logging service is to provide a centralised system level logging

facility for LMS services located at the same institution. This eases debugging of

services as well as monitoring of LMS service installations. As many existing tech-

nologies already provide a logging facility, the main purpose of the logging service in-

terface is to provide a technology-neutral standard logging interface which may wrap

existing logging facilities. An example of an existing Java-based logging API is Log4J

from the Apache Foundation (see [Apa] for details).

The LMS logging service supports the following log levels:

� debug

� info

� warn

� error

� fatal

72

4.3.3.1 Guidelines for services using the logging service API

The log levels characterise the severity of a message. Using the centralised logging

facility, services should follow these guidelines:

� debug messages are intended for debugging purposes. These messages are sent

on entering each method specified in the service interface. Optionally, param-

eters may be passed in the debug message. However passwords must not be

logged at any time. The service may also log when leaving a method. The ser-

vice is free to log anything else of importance to someone who may want to

debug the service.

� info messages inform the administrator of the status of the service. This in-

cludes sending a info message on startup and before regular shutdown.

� warn messages issue warnings about possibly critical conditions, e.g., upcom-

ing memory shortage. Warn messages show that there might be a problem in the

future, but that the current status of the service is still normal.

� error messages are sent when an error occurs, e.g., an exception is thrown.

However the error is temporary or non-critical for the service.

� fatal messages are sent when a service has to shut down due to a critical error

condition. After a fatal message has been sent the service is possibly unavailable.

As in a distributed environment, calls to the logging service are remote invocations and

service vendors are asked to implement a local wrapper for logging calls to ensure that

only calls above a certain treshold are sent. This reduces network load and speeds up

service execution.

73

Figure 4.12: The interface to be implemented by logging services

4.3.3.2 The logging service interface

Figure 4.12 depicts the interface of the logging service.

The logging calls defined in the API supply information on the service, sending the

log message in a struct of type TServiceInfo which is depicted in figure 4.4 (see

section 4.2.1). The calling service is responsible for the correctness of the information

supplied.

4.3.3.3 Dependencies and interaction with other services

The logging service does not rely on any other services.

4.3.4 The security service

Security is a basic component of the LMS runtime system. In a distributed environ-

ment security is a big problem. Users and services must be able to identify themselves

as they need to be able to trust the services they rely on. Usually each of the cooper-

ating institutions has its own authentication information and its own way of managing

privileges; it will not like the idea of sharing security privileges and would prefer to

keep its own security domains.

74

Keeping local security domains enables the institution to introduce different levels of

trust and to deal with authorisation requests individually, e.g., differentiating between

local users and users from cooperating institutions.

Enforcing security is crucial in a distributed environment. All e-learning services de-

pend on a security service to check the access privileges of a user or another service.

The security service has two different interfaces:

� Authentication

� Authorisation

This reflects a common way of implementing security by separating authentication

from authorisation responsibilities.

In order to perform authentication/authorisation in the distributed LMS, services make

use of the authentication and authorisation service interfaces described below.

4.3.4.1 The underlying security model

We first define the semantics of the underlying security model.

Since the resulting interfaces must be able to wrap existing authentication and authori-

sation implementations we will take a look at standards defined for authentication/au-

thorisation.

ISO published a series of standards (ISO 10181-x) dealing with different aspects of

security. Within this series ISO 10181-3 [ISO96] is of special interest. The standard

defines an access control framework to be used within user level applications. The

framework defines four different roles for components participating in an access re-

quest:

� Initiators

75

� Targets

� Access Control Enforcement Functions (AEFs)

� Access Control Decision Functions (ADFs)

Initiators submit an access request to the AEF. The AEF then requests an access deci-

sion from the ADF and depending on the result of this decision the initiator’s request

is forwarded to the target. This system behaviour is shown in figure 4.13.

Initiator AEF

ADF

Target

submitaccessrequest

presentaccessrequest

decisionrequest decision

Figure 4.13: ISO 10181-3 Access Control Framework [ISO96]

ADFs require Access Control Decision Information (ADI) in order to make access con-

trol decisions. ADI consists of security relevant properties of the initiator, the target,

and the access request as well as information on the system and its environment.

Because AEFs usually do not know which information is relevant for the ADF they

usually just supply a standard set of Access Control Information (ACI). The ADF then

extracts the ADI from the ACI supplied.

Part of the ACI (the so called initiator ACI) is generated by an authentication compo-

nent not displayed in figure 4.13. This means that initiator authentication must happen

before the first authorisation request can be performed by an initiator. The part of the

ACI dealing with the request to be performed (the so called request ACI) is supplied

by the AEF. Information about the environment (the so called context ACI) can be sup-

plied by the AEF as well, but may also be partly accessible by the authorisation service

directly.

76

Interaction between authentication and authorisation

AEF

submitaccessrequest

InitiatorACI decision

authenticateInitialtor

AuthenticationService

AuthorisationService

ADF

InitiatorACI

(Initiator,Request,Context)

AnyService

AuthDB

AznDB

Figure 4.14: Authentication and Authorisation

Figure 4.14 depicts the procedure of authenticating a subject and authorising its re-

quest. This involves the authentication service as well as the authorisation service and

shows what kind of data is needed by which of the participating services to process

the request. The figure also shows the separation of authentication from authorisation

which makes it possible to implement these in two different services.

Enforcing the authorisation decision is the duty of the service implementing the busi-

ness logic. This provides maximum flexibility for the service provider. The AEF is

free to cache authentication data and the result of the authorisation decision in order to

optimise response times. However doing so holds a certain amount of risk because the

AEF has no knowledge of the internal structure of the ADF within the authorisation

service.

77

4.3.4.2 The authentication service

The AuthenticationService interface is derived from infrastructureService

and the authentication service does not rely on other services defined in the hierarchy.

The purpose of the authentication service is to provide authentication of subjects ac-

cording to an authentication method, e.g., userId/password, certificate-based authenti-

cations. Subjects are human users or other services.

The service provides a facility to revoke the authentication of a principal, e.g., on

logoff.

As the authentication service supplies the ACI to the ADF it provides an interface for

the authorisation service to query the ACI.

4.3.4.3 The authorisation service

The authorisation service interface hides the ADF. A LMS service queries the autho-

risation service to find out whether a client (a user or another service on behalf of a

user) is allowed to perform a certain task. The service passes a pointer to the ACI to

the ADF and specifies the task to be executed. The authorisation service then evaluates

the ACI and returns its decision to the service.

4.3.4.4 The security service interfaces

Common data structures

The authentication service returns an instance of TLoginContextHandle (see fig-

ure 4.15), when a user or service authentication has succeeded. This data structure acts

as a pointer to the ACI stored internally in the authentication service.

The TLoginContextHandle data structure consists of the TServiceInfo struc-

ture of the authentication service which performed the authentication, an integer value

78

identifying internal authentication information and a signature string which allows the

authentication service to guarantee the authenticy of the information provided.

To create the signature, a Pretty Good Privacy (PGP)1 compliant public-key algorithm

is used. Trusted public keys may be stored in the local property service in the property

ie.cit.lmsServices.authentication.<ServiceId>.key. Authenti-

cation services may however choose not to provide a signature at all.

Figure 4.15: The TLoginContextHandle data structure

The TLoginContextHandle data structure is passed on each invocation to an e-

learning service. This allows e-learning services to check for user authorisation when-

ever needed.

The authentication service API

Figure 4.16: The interface to be implemented by authentication services

The authentication service API provides different ways to authenticate users and other

services of the system. If the authentication is successful, an instance of TLogin-

1see http://www.pgpi.org/ or http://www.gnupg.org/ for details

79

ContextHandle is returned. This handle is then passed to the authorisation service

to allow the ADF to decide if a user is allowed to perform certain operations.

Each service must provide userId/password authentication for users and id/key authen-

tication for services. In addition an anonymous login must be provided.

To design an authentication interface that is as flexible as possible, a callback mecha-

nism has been introduced. This callback mechanism allows the authentication service

to request additional authentication information from the calling service. Therefore

the caller must implement the interface LoginCallback and pass a reference to the

authentication service when invoking loginWithCB.

The authorisation service API

Figure 4.17: The interface to be implemented by authorisation services

The authorisation service API provides just one operation that allows services to check

if a user or another service is allowed to perform an operation described by the string

target.

To name targets, services must follow a specific naming scheme:

ie.cit.lmsServices.<ServiceClass>.<ServiceInstance>

.<ServiceMethod>

<ServiceClass> specifies the the service class as defined in section 4.1.2.1.

80

<ServiceId> represents a unique identifier characterising the service instance. Tar-

gets which are to be used by all service methods are named

ie.cit.lmsServices.<ServiceClass>.<Subclass>.<ServiceId>.*

Targets which are to be used by all services of a class (and subclass) are named

ie.cit.lmsServices.<ServiceClass>.<Subclass>.*

When requesting authorisation, a service passes the TLoginContextHandle of

a user or service to the authorisation service. As stated above, this data structure

just acts as a pointer to the actual ACI stored in the authentication service. The

authorisation service is free to contact the authentication service which issued the

TLoginContextHandle in order to retrieve login details like user name or ser-

vice Id. This is done by invoking retrieveLoginDetails on the authentication

service interface. The authentication service then returns a property set containing the

relevant information. Service vendors are free to implement alternative ways of data

exchange between local authentication and authorisation services, e.g., shared memory

segments, etc.


The security services register with the local lookup service on startup. They store and

retrieve properties from the property service and log debug and error messages to the

local log service.

In addition to communication with the local infrastructure services, the authorisation

service may use an authentication service in oder to retrieve ACIs.

81

interfacelmsServices::eLearningService

+WSReference:string




Figure 4.18: The interface to be implemented by e-learning services

4.4 E-learning services

The base interface for e-learning services is derived from the basic service interface

(figure 4.18). E-learning services mainly represent functional components of the dis-

tributed learning management system. As e-learning services communicate across

instance boundaries they are accessible through an additional web-service interface.

The e-learning interface provides the read-only property WSReference which al-

lows other services to query the web-service reference of an e-learning service.

The architecture defines the following functional components as important e-learning

services:

� Annotation

� Bookmark

� SCORM API

� Search

The definition of additional service classes and therefore the future extension of this

architecture is likely. For example, the architecture already defines service classes for

communication services, e.g., Chat, News, and Mail. However, the functionality of

82

these services may be provided by using existing web-interfaces within an institution

or even common web-clients, e.g., MS Internet Explorer and Outlook Express or the

Mozilla browser suite and Mozilla Mail. The main benefit of including these services

into the architecture would be the “single sign on” provided by the security service.

These services may also be integrated directly into the access portal; accessing them

remotely via a dedicated API provides no additional benefit. Thus we will not include

the communication services in our architectural design.

4.4.1 The annotation service

The purpose of the annotation service is to allow users to store and retrieve textual

annotations to resources displayed on the web, e.g., web pages or parts of web pages.

Annotations can be shared among users, e.g., users who collaborate can allow others to

display their annotations. The annotation service offers an interface which is compliant

to the W3C Annotea approach (see [BKKS01] for details). This way existing Annotea

clients can be used to access the annotation service.

Annotea uses the Resource Description Framework2 (RDF) notation (see [W3C04b])

to store annotations as displayed in figure 4.19.

Figure 4.19: The W3C Annotea architecture

2See http://www.w3.org/RDF/ for details

83

An Annotea user is able to store annotations to web resources, fetch and display an-

notations, and modify annotations. An annotated resource is referenced using XML

X-pointers3.

4.4.1.1 Annotea architecture components

The Annotea infrastructure comprises client and server components. The client

is usually embedded in a web browser, e.g., Mozilla 1.4 (with annozilla-

extension) or W3C Amaya. A list of existing clients can be found in

http://www.w3.org/2001/Annotea/#Existing. Client and server communicate using a

set of Annotea protocols (Basically XMLencoded RDF over HTTP). These Annotea

protocols are described in http://www.w3.org/2001/Annotea/User/Protocol.html.

Listing 4.2: Sample Annozilla annotation

<rdf:RDF

2 xmlns:rdf=’http://www.w3.org/1999/02/22-rdf-syntax-ns#’

xmlns:NS0=’http://www.w3.org/2000/10/annotation-ns#’

4 xmlns:NS1=’http://purl.org/dc/elements/1.1/’

>

6 <rdf:Description rdf:about=’http://localhost:8080/wannot/Annotates/annotation/

server1/26’>

<rdf:type rdf:resource=’http://www.w3.org/2000/10/annotation-ns#Annotation’/>

8 <rdf:type rdf:resource=’http://www.w3.org/2000/10/annotationType#Comment’/>

<NS0:annotates rdf:resource=’http://dict.leo.org/’/>

10 <NS0:body rdf:resource=’http://localhost:8080/wannot/Annotates/body/server1

/26’/>

<NS0:context>http://dict.leo.org/#xpointer(string-range(/html[1]/body[1]/form

[1]/table[2]/tbody[1]/tr[1]/td[3]/table[1]/tbody[1]/tr[1]/td[2]/h3[1], &

quot;", 1, 60))</NS0:c

12 ontext>

<NS1:title>No title available</NS1:title>

14 <NS1:creator>Anonymous</NS1:creator>

<NS0:created>2004-01-26T15:43Z</NS0:created>

16 <NS1:date>2004-01-26T15:43Z</NS1:date>

</rdf:Description>

18 </rdf:RDF>

3see http://www.w3.org/XML/Linking for details

84

Listing 4.2 shows a sample RDF/XML-encoded annotation. Such an annotation gets

displayed in the Mozilla browser by adding a pencil to the place within the web-page

a browser points to (see figure 4.20).

Figure 4.20: Mozilla displaying an annotation (using Annozilla)

There are currently two implementations of annotation servers available in the public

domain: The W3C annotation service4, and an annotation service integrated into the

Zope application server5. However these implementations lack several features which

are necessary to integrate the annotation feature into an existing environment:

� User authentication is done individually (there is no standard defined by An-

notea)

� It is not possible to address several annotation servers with a single query (unless

individually implemented on the client side)

� Users are not able to control the sharing of their annotations with other users

(there is no privilege management)

4See http://annotest.w3.org/annotations for details.5See http://www.zope.org/Members/Crouton/ZAnnot/ for details.

85

4.4.1.2 Integration of Annotea into the infrastructure

To allow users of the distributed LMS to annotate course-ware, an W3C Annotea com-

pliant server component is integrated into the system.

Using the W3C Annotea approach has several advantages when compared with other,

often proprietary solutions:

� Annotea is an W3C project and all specifications are openly available. It is

therefore relatively easy to implement client components that may be integrated

into common web browsers.

� Annotea does not rely on modifications to the actual presentation portal or the

course-ware to be presented. The Annotea clients ask their Annotea server

for available annotations. These are interpreted on the client side and the web

browser modifies the web page to be presented in order to incorporate a link to

the annotation into the page. Presentation portal do not have to support Annotea.

� The client-side rendering enables Annotea to avoid the problem of annotations

modifying the content of the annotated page which then would have influence

on the construction of XPointers referring to further annotations to this page.

� Users are free to use the annotation facility with the client component of their

choice – no proprietary tools have to be installed.

In a distributed LMS it is possible that users access portals or services across insti-

tutional boundaries. When a user is registered in the security domain of one of the

cooperating institutions, all user-centric data is stored there. If the user accesses the

LMS from another institution, the portal component has to forward personal data to

the services of this remote institution. For annotations of course-ware this means that

annotations will have to be stored in different places, and may be aggregated transpar-

ently from different locations for display.

86

This is the reason for our decision to break down the Annotea server component into

two parts:

� The annotation service proxy

� The actual annotation server

These two components will be described in the following sections.

4.4.1.3 Overall annotation service architecture

The overall architecture of the LMS integrated Annotea compliant annotation system

is depicted in figure 4.21.

AnnoteaPlugin

Browser

LMS Portal

Client Side

Server Side

AnnotationServer

AnnotationServer

AnnotationServer

Web Page

AnnoteaProxy Web

Server

Figure 4.21: The overall annotation service architecture

The client browser uses an Annotea-enabled Web browser or a browser-embedded soft-

ware component (plug-in) to access the LMS annotation service. This Annotea client is

a standard software component available for common Web browsers like, e.g., Mozilla.

The Annotea client communicates with an Annotea proxy that is part of the LMS por-

tal. Communication between client and proxy is based on HTTP and the standardised

87

Annotea protocol set, annotations are encoded in RDF/XML and refer to annotated

documents using the XPointer technology.

The proxy is responsible for the communication with the actual LMS annotation servers.

These servers provide a standard interface for storing and querying of annotations.

4.4.1.4 The annotation service proxy

The internal design of the Annotea proxy is naturally vendor-specific, as the proxy is

part of the LMS portal. This allows the proxy to access the authentication information

used by the portal to identify active users, e.g., using HTTP sessions, browser cookies,

or other mechanisms.

The proxy is responsible for storing annotations in the annotation server responsible

for the user’s annotations and may aggregate annotations from several servers before

presenting them to the user.

Communication with the client is handled by the Annotea protocol set. Therefore the

proxy must offer a set of interfaces:

� A proxy interface is used by clients to retrieve information about annotations for

a specified URL (via HTTP GET) or to add new annotations (via HTTP POST).

� An annotation interface is used by clients to retrieve information about a specific

annotation (via HTTP GET), update information (via HTTP PUT) and delete an

annotation (via HTTP DELETE). An annotation is identified by its id.

� A body interface is used by clients to retrieve the content of an annotation based

on its id (via HTTP GET).

Probably the most important task of the proxy is the mapping of annotation URLs to

annotation service servers and vice versa. As annotations are divided into an anno-

tation header and an annotation body, the proxy must be able to locate an annotation

88

body based on the information provided in the annotation header. In addition it should

be possible for LMS users to share annotations no matter which portal URL the an-

notation proxy is located at. These goals are achieved by embedding a reference to

the annotation service server, storing an annotation which is referenced into the unique

annotation URL.

The Annotea Specifications require that each annotation object (annotation header and

annotation body) receive a unique URL which may be used to retrieve the annotation

object. The server may choose the format of this URL as long as the browser can

access it and retrieve the required data. Annotea servers which are compliant to the

distributed LMS architecture choose URLs in such a way that they contain a reference

to the annotation service server and the corresponding annotation id which is unique

per server:

http://www.lms-portal.org/annotations/<serverID>/<annotationID>

The proxy uses the local lookup service to find available annotation service servers. It

then uses the standardised annotation server interface for communication.

4.4.1.5 The annotation service server

The annotation service server is responsible for storing annotation information. The

existence of one annotation service server per security domain is mandatory, as anno-

tations should always be stored at the same location as other user-centric data. The

annotation proxy looks up the annotation service server of the security domain a user

belongs to, and tries to store a user’s annotations within this server.

On annotation retrieval, a proxy may aggregate the annotation information accessible

for one user by querying several annotation servers which may be located in different

security domains.

The annotation service server provides the annotation service interface for proxy com-

89

munication which is described in the following section.

4.4.1.6 The annotation service interface

The interface to be implemented by annotation service servers is depicted in figure 4.22.

Figure 4.22: The interface to be implemented by an annotation service server

The annotation server allows clients to post, retrieve and delete annotations to and from

Web pages. In addition the server interface provides a facility to query annotations

based on several criteria like URL, user-id, and content.


The annotation service proxy depends on the local lookup service to locate annotation

service servers. The servers depend on authorisation and authentication services and

may use the property and logging services for internal purposes.

90

4.4.2 The bookmark service

The purpose of the bookmark service is allow users to store bookmarks for web-pages

and to submit queries which return lists of bookmarks. The bookmarks stored in the

service are provided by a teacher or learners as an additional source of information

when working with a course. They point to web resources, just like an Internet browser

bookmark menu. The bookmark service uses the information which can be found in a

Netscape/Mozilla bookmark entry.

4.4.2.1 Composition of a bookmark entry

A simple bookmark entry comprises the information displayed in table 4.1.

Table 4.1: Information in a bookmark entry

PROPERTY TYPE

URL of the book-marked web-page String

Date of addition to the Set Long

Date of last access to bookmark entry Long

URL of Icon for the book-marked web-page String

char set of the book-marked web-page String

id String

Description String

The structure of such a bookmark entry is equivalent to the information stored in a

Netscape/Mozilla Bookmark-File. A sample entry of such an XML-encoded book-

mark file is displayed in source-code 4.3.

Listing 4.3: Sample entry of a Mozilla bookmark file

<DT>

2 <A HREF="http://www.mozilla.org/" ADD_DATE="961099870"

91

LAST_VISIT="1050348721"

4 ICON="http://www.mozilla.org/images/mozilla-16.png"

LAST_CHARSET="ISO-8859-1" ID="rdf:#$U+RSA2">The Mozilla Organization

6 </A>

</DT>

The bookmark file allows the storage of these basic entries in a hierarchy. The XML-

encoded file stores a hierarchy as displayed in sourcecode 4.4.

Listing 4.4: Sample Mozilla bookmark file

<!DOCTYPE NETSCAPE-Bookmark-file-1>

2 

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">

6 <TITLE>Bookmarks</TITLE>

<H1>Bookmarks</H1>

8

<DL><p>

10 <DT><H3 ADD_DATE="961112773" PERSONAL_TOOLBAR_FOLDER="true" ID="NC:

PersonalToolbarFolder">Personal Toolbar Folder</H3>

<DL><p>

12 <DT><A HREF="http://www.mozilla.org/" ADD_DATE="961099870" LAST_VISIT="

1050348721" ICON="http://www.mozilla.org/images/mozilla-16.png"

LAST_CHARSET="ISO-8859-1" ID="rdf:#$U+RSA2">The Mozilla Organization</

A>

<DT><A HREF="http://www.suse.de/" ADD_DATE="961112935" LAST_VISIT="

1053872696" ICON="http://www.suse.de/favicon.ico" LAST_CHARSET="ISO

-8859-1" ID="rdf:#$V+RSA2">SuSE - The Linux Experts</A>

14 </DL><p>

<HR>

16 ...

</DL><p>

The category definition serves as an identifier for the course and includes all the rel-

evant bookmarks for this course. The bookmark service offers an interface for book-

mark management (intended to be used by the teachers and students) as well as an

interface for bookmark query (intended to be used primarily by the students). Methods

for the addition of bookmarks overwrite existing bookmarks with the same identifier.

92

The addition of a bookmark file for a category with the same category-identifier re-

places all entries within this category.

4.4.2.2 Bookmark service data structures

The bookmark service provides several data structures which ease information ex-

change between the bookmark service and other services in the distributed LMS.

TCategory

The data structure TCategory is depicted in figure 4.23. TCategory contains

information on a bookmark category, e.g., a course or course subject. Such a category

is displayed as a bookmark folder in the Netscape/Mozilla browser.

Figure 4.23: The TCategory data structure

Each category has a name, a creation date and a unique category id. The date of

creation is stored numerically in a string, containing the number of milliseconds passed

since January 1st 1970.

TBookmark

The data structure TBookmark is depicted in figure 4.24. TBookmark contains

information on bookmark entries store within a bookmark category (see TCategory).

A TBookmark data structure consists of an bookmark URL, the bookmark creation

date and the date of last access, a string describing the charset of the bookmark entry,

an ID for the entry and the ID of the bookmark category this bookmark entry belongs

93

Figure 4.24: The TBookmark data structure

to. Optionally a textual description of the bookmark and an URL pointing to an icon

to be displayed with the bookmark may be given. All bookmark elements are stored as

strings, the date of creation and date of last access contain the number of milliseconds

passed since January 1st 1970.

4.4.2.3 The bookmark service interface

Figure 4.25 depicts the basic bookmark service interface.

Figure 4.25: The interface to be implemented by a bookmark service

The bookmark service interface offers three classes of methods:

� Handling of Netscape/Mozilla bookmark files

94

� Adding or removal of bookmarks or categories

� Searching for bookmarks

To support the usage of bookmarks with the native browser bookmark interface, i.e.,

independent of the LMS portal, the bookmark server allows the retrieval of a whole

category of bookmarks as a Netscape/Mozilla compliant bookmark file. This file may

be added to the local browser bookmarks by using the bookmark manager (see fig-

ure 4.26).

Figure 4.26: The Mozilla bookmark manager

The Mozilla bookmark manager also allows the export of groups of bookmarks into

a file which may then be added to the LMS bookmark service. This provides an easy

graphical way of creating bookmark sets for courses.

In addition, the service provides methods for handling bookmarks and categories using

the TCategory and TBookmark data structures to integrate the bookmark service

into an existing LMS portal without having to parse XML data structures. These meth-

ods may also be invoked to add or remove single bookmarks from a category or to

remove a whole category of bookmarks affecting all entries.

Finally, the bookmarks stored in the service may be searched for keywords. The service

provides different search methods, e.g., for searching in bookmark names or descrip-

tions, and methods for listing all categories stored within the bookmark service.

95


The bookmark service registers with the local lookup service on startup. It may store

and retrieve properties from the property service and log debug and error messages to

the local log service.

The bookmark service uses the local authorisation service to confirm the authorisation

of requests made by users or other services.

4.4.3 The ISCORM service

A service implementing the SCORM API has been added to the LMS e-learning ser-

vices because SCORM (Sharable Content Object Reference Model, see section 3.3.5

for details) currently is the most important approach for realising interactive LMS con-

tent.

The purpose of the ISCORM service is to allow SCORM enabled learning content to

access system and user properties from anywhere in the distributed learning environ-

ment.

To access the SCORM API in a monolithic LMS runtime environment, the content

accesses the SCORM javascript interface which is located in the users’ web browser.

The javascript interface then forwards the requests to the LMS and returns the result of

the request to the content object which initiated the request. This is possible because

all data necessary for answering SCORM requests is stored by the local LMS runtime

environment represented by the portal.

In a distributed environment the institution hosting a portal does not necessarily store

information on users and courses. Instead, user data is usually stored in the institution

which authenticated the user, e.g., the university a user studies at. Information on the

course content viewed by this user may be provided by a different institution.

96

Therefore a proxy component is introduced. The proxy is located at each LMS por-

tal and may be developped independently from the ISCORM service. The SCORM

javascript interface communicates with the proxy and the proxy is responsible for

looking up the relevant ISCORM services. As the proxy is part of the LMS portal

it knows about the identities of the users logged into the system via this portal and

is able to contact the ISCORM services responsible for storing data concerning these

users. Content-dependent information may be stored using the local ISCORM service.

4.4.3.1 Overall architecture of the ISCORM service

Figure 4.27 depicts the overall architecture of the ISCORM service, which has been

introduced in section 4.4.3

APIAdapter

ISCORMProxy

Javascript

SCO Asset

Browser

LMS Portal

(1)

(2)

(3)

Client Side

Server Side

(1) Launch

(2) Data Model(3) API

ISCORM Service

ISCORM Service

ISCORM Service

Figure 4.27: The overall ISCORM service architecture

The javascript interface is accessible from the web browser as soon as a user has cho-

sen a SCORM compliant course to view via the LMS portal. This interface forms

97

part of the portal component - just like the ISORM proxy it communicates with. The

javascript interface communicates solely with the ISCORM proxy component in the

local LMS portal. As the proxy is part of the portal it is able to retrieve the user login

data associated to the web browser session the javascript interface sends its request

from.

The proxy holds a list of ISCORM services of federated institutions and queries them

using the TLoginContextHandle of the current user. Afterwards the data re-

trieved from the ISCORM services is aggregated and then sent back to the javascript

interface. This allows the distributed LMS to store SCORM relevant user data wher-

ever the corresponding user account information is located. Data associated with a

course may be stored at the location of the course material.

The communication between the javascript interface and the proxy as well as the inter-

action between proxy and the rest of the portal are not standardised by our architecture.

This provides maximum flexibility for vendors implementing an LMS portal compo-

nent. However the standardised interface of the ISCORM service ensures compatibility

between ISCORM services of different vendors.

4.4.3.2 The ISCORM API service interface

The ISCORM service interface is depicted in figure 4.28.

The ISCORM service provides an interface to the API methods defined in the SCORM

specification (see section 3.3.5.2).

The LMSInitialize and LMSFinish methods are called as a user starts to work

with an SCORM compliant learning object. The proxy looks up the ISCORM services

available and initialises them. When the learning object is no longer required, the

ISCORM services are notified with LMSFinish. This allows the services, e.g., to

open and close database connections, and to track the numer of users currently using

the services.

98

Figure 4.28: The interface to be implemented by an ISCORM service

The LMSGetValue and LMSSetValuemethods may be used by the proxy to query

ISCORM services for property values or to store property values in an ISCORM ser-

vice. The proxy component may decide which service the queries are sent to. Usually

user related data is stored in an ISCORM service located at the user’s domain, whereas

learning object related data is stored locally, e.g., with the local ISCORM service, or

even directly by the proxy.

The methods which are provided for error condition investigation may be used by the

proxy component to forward errors which occurred within an ISCORM service to the

user.

Service providers are requested to follow the relevant SCORM specifications concern-

ing properties and error numbers in order to reach full SCORM compliance.


The ISCORM services register with the local lookup service on startup. They may

store and retrieve properties from the property service and log debug and error mes-

sages to the local log service.

The ISCORM services use the local authorisation service to seek authorisation of re-

quests made by ISCORM proxies located in the LMS portals.

99

4.4.4 The search service

The purpose of a search service is to provide a standard interface for performing

searches on resources not directly linked to courses, e.g., library catalogues, digital

libraries, web pages and so on.

The LMS search service provides a generic search interface which can be refined by

service vendors in order to enrich it with additional functionality.

By providing a generic base interface for a great variety of resources, the search service

acts in a similar manner as the Java Naming and Directory Interface (see [Sun], which

provides a generic interface to different kinds of naming and directory services.

Nowadays many resource collections provide public interfaces for content access. An

example of an existing Web-search facility is the Google SOAP API. Many digital

libraries also offer search interfaces, which may be wrapped by the LMS search service

interface.

The following section describes the data structures used by the search service to display

results.

4.4.4.1 The search service data structures

Figure 4.29 displays the data structure TSearchResult, which is returned as the

result of each search performed by the LMS search service.

Figure 4.29: The TSearchResult data structure

TSearchResult contains the query string supplied for the search, a boolean value

100

which is false in case the search did not return any results, an integer value which stores

the number of result elements of the search, and an array of result elements.

Each search result element, i.e., each entry in the list of results returned by the search

service, is represented by an instance of TSearchResultElement, displayed in

figure 4.30.

Figure 4.30: The TSearchResultElement data structure

A TSearchResultElement consists of a title string, a numerical ID, identifying

the result element uniquely within the result set, a textual description of the result,

and an array of properties which allows search services to supply more specific search

result data.

Different types of searches may require special properties. For that reason a set of

standard property names has been predefined:

� url for delivering a URL

� document for delivering a base/64 encoded document as payload

4.4.4.2 The search service interface

Figure 4.31 depicts the interface of the search service.

A search service mainly provides two methods for searching a resource, one of them

allowing a client to specify a maximum number of results to be displayed. This is often

useful, especially when dealing with web search engines which often deliver hundreds

or thousands of results.

101

Figure 4.31: The interface to be implemented by a search service


The search service registers with the local lookup service on startup. It may store and

retrieve properties from the property service and log debug and error messages to the

local log service.

The search service uses the local authorisation service to seek authorisation of requests

made by users or other services.

4.5 The portal

The LMS portal component acts as a proxy for user requests and allows LMS services

to present the functionality they offer to users using a common look & feel. The

portal connects to the available LMS e-learning services and processes user requests

according to the guidelines stored in the property service.

Services, being the functional components of the LMS system, provide an API which

allows the portal (or other services) to access information provided by a service or to

trigger a task. This however does not involve presentational aspects. It is the task of

the portal vendor to implement the user interface of the distributed LMS.

102

The portal itself does not provide a standardised API, but may implement the callback

APIs offered by several services. In addition the portal hosts proxy components that

allow client compontents of LMS services which use special protocols to access their

corresponding LMS server part. These proxies are used to connect annotation clients

and servers, and to forward SCORM API requests to the available ISCORM services.

The portal is also responsible for delivering the actual LMS content to a user. Content

usually is provided in learning modules, packaged in the local file system or a content

management system.

Property

SearchSecurity

Annotation

Search

Security

Lookup

User

Portal

Annotation ProxyISCORM Proxy

Lookup

Figure 4.32: The LMS portal accessing several LMS services

Figure 4.32 depicts a sample scenario in which a portal accesses several LMS ser-

vices. A user simply addresses the portal and its proxy components, which hides the

complexity of the underlying distributed LMS.

As different LMS implementations may exist in scenarios where a variety of institu-

tions cooperate, the design of the LMS portal, being the LMS core component, is not

affected by this architecture. This comprises routines for accessing content as well as

the overall portal layout.

103

At this stage, the architecture aims at unifying supportive features, which is a first step

to a full unification of LMS systems, and allows institutions to replace certain features

of the LMS system by other implementations without fear of data loss or having to

deal with interoperability problems.

4.6 Cross service personalisation

Cross service personalisation is a very difficult task, especially when dealing with ser-

vice implementations provided by different vendors.

A first step towards cross service personalisation is the introduction of the common

property service which stores configuration information. Its purpose is comparable to

the task the Windows Registry fulfils in terms of Windows system configuration.

The property service supports the configuration of user preferences for several ser-

vices, e.g., for the enforcement of global policies. A requirement therefore is a unified

naming scheme for policy names and values.

The introduction of a unified naming scheme with a large set of mandatory properties

may cause a loss of flexibility for service vendors. The definition of such a property set

is difficult as a great variety of services may be using the same basic service interface

for different purposes. Properties do not include enough semantics to allow anyone to

understand what exactly will happen when the property is modified.

In addition, properties may address different user groups and some limits should only

be changed by an administrator, others by an individual user.

In order to allow cross service personalisation, all these issues must be taken into

account when implementing a tool that allows configuration of service groups, either

globally, or on a per user basis. Note that a high level personalisation of the LMS may

be provided by the portal, which may allow distinct groups of users to “see” certain

parts of the system.

104

Chapter 5

Prototypical implementation

In order to verify the architectural concepts described in the design chapter, we have

implemented a selection of LMS services prototypically. Some of these services have

been implemented from scratch, for others we implemented an LMS interface wrapper

that delegates calls to existing software.

As described in section 4.3, e-learning services may rely on the existence of a min-

imum set of infrastructure services, namely, a lookup service, a logging service, a

property service, and a security service. In addition to these infrastructure services, the

prototype contains implementations of the following e-learning services:

� Annotation service

� Bookmark service

� Search services (Web, digital library)

We include a brief overview of the middleware technologies used to implement the pro-

totype, namely CORBA and WebServices (see sections 5.1.1 and 5.1.2) and describe

the integration of the implemented services into an existing LMS portal (section 5.2.3).

105

5.1 Technologies Used

The distributed LMS architecture presented in chapter 4 is in principle independent

of the underlying middleware used for implementing the system. A great variety of

middleware technologies exist today which differ in the target group they address and

their category of intended usage. Table 5.1 provides a brief overview of a selection of

middleware technologies that are important today.

Table 5.1: Overview on middleware technologies

MIDDLEWARE TARGET GROUP / PLAT-

FORM

REMARKS

CORBA Independent of plat-

form and programming

language

Often used as backbone

middleware, many sup-

portive services available

Java RMI Available for Java appli-

cations

Used to quickly connect

Java-based applications

Microsoft .NET Available for Microsoft

Windows platforms

New Microsoft middle-

ware technology, partly

based on WebServices

WebServices (SOAP) Independent of plat-

form and programming

language

Relatively new technol-

ogy, primarily used for

loosely coupled systems,

not many supportive ser-

vices

As the prototypical implementation of the distributed LMS architecture tries to inte-

grate existing functionality, it is desirable to focus on middleware technologies that

do not require one to use a certain programming language or operating system. We

106

will therefore focus on the two middleware technologies that are both programming

language and operating system independent, namely, CORBA and WebServices.

5.1.1 CORBA

The OMG1 Common Object Request Broker Architecture (CORBA) is an object-

oriented middleware technology. CORBA is independent of the underlying operating

system and provides language mappings to several common programming language.

The OMG Interface Definition Language (IDL) is a declarative language used to define

the interfaces of CORBA objects. An IDL compiler is used to translate the interface

into client-side stubs and server-side skeletons in the target programming language.

When a client wants to invoke server functionality, it must link to the generated stubs.

The stubs handle the preparation of the request and its parameters for the remote server

invocation, called marshaling. The request is then forwarded to the server where it gets

unmarshalled by the skeleton and then forwarded to the implementation.

The central component of a CORBA infrastructure is the Object Request Broker (ORB).

The ORB is responsible for locating and addressing CORBA objects, i.e., connecting

clients and servers and general communication-handling.

CORBA uses the General Inter ORB Protocol (GIOP), in case of TCP/IP networking

the IP mapping of GIOP, the Internet Inter ORB Protocol (IIOP) for communication

between clients and servers. IIOP is a binary protocol and usually does not rely on

fixed ports. This makes it difficult for CORBA to connect via the Internet to CORBA

objects located in cooperating institutions, as firewalls usually block communication

from outside.

In addition to the CORBA standard (see [Obj02a]), a very good introduction to CORBA

as well as an in-depth description of the C++ language mapping can be found in

1Object Management Group

107

[HV99] and [Bak97].

5.1.2 WebServices

SOAP is an XML-based communication protocol and encoding format for inter-appli-

cation communication. Originally created by Microsoft and Userland Software, it has

evolved through several generations. The current specification is SOAP 1.2. In June

2003 the W3C’s XML Protocol working group finished the process of defining SOAP

1.2 as an open standard (see [W3C03]).

SOAP is widely viewed as the backbone to a “new generation” of cross-platform and

cross-language distributed computing applications, termed WebServices. One of the

main benefits of WebServices is that they integrate seamlessly into the existing Internet

infrastructure. SOAP is a text-based protocol and may be transferred as payload of the

existing OSI layer seven protocols, like HTTP or SMTP.

Standard XML parsers can be used to interpret SOAP messages, and applications can

generate SOAP messages using standard XML APIs like, e.g., DOM [W3C04a], or

SAX2.

SOAP-based WebServices are significantly slower than CORBA (see [EPL02]) and

they do not provide the same number of additional services that more mature middle-

ware technologies do. For example, a mechanism to support transactions via SOAP is

currently still under definition.

Hence WebServices are currently mainly used for inter-organisational cooperation and

not internally as backbone middleware technology.

2See http://www.saxproject.org/ for details

108

5.1.3 Mapping between CORBA and WebServices

5.1.3.1 Overview

The OMG provided a first specification on “WSDL-SOAP to CORBA Interworking”,

including specifying a mapping for data types (see [Obj03]). However this specifi-

cation has not been widely adopted by product vendors – many vendors currently do

provide custom mappings, mainly by implementing just a subset of the OMG specifi-

cation. The main reason for this is that customers demand such a mapping, but until

recently there was no OMG standard available.

For the implementation of the prototype, the Apache AXIS 1.13 SOAP engine was

chosen as the WebServices platform. AXIS provides basic support for wrapping ex-

isting CORBA objects and offering the CORBA interface as SOAP WebService. For

this purpose, CORBA stubs of the services have to be deployed into AXIS. AXIS then

offers the methods provided by the stubs and generates a WSDL mapping. When a

call arrives, AXIS looks up the corresponding server object in the CORBA Naming

Service and calls the server using the CORBA stubs provided.

5.1.3.2 Mapping of data types

The mapping of data types between CORBA - more precisely the Java mapping of

the CORBA IDL interfaces - and SOAP is not trivial. Mappings of simple data types

are relatively easy (see table 5.2), but AXIS fails to map some of the complex types

provided by CORBA.

3See http://ws.apache.org/axis/ for details

109

Table 5.2: Mapping of simple data types between

WSDL and IDL

WSDL JAVA IDL

xsd:boolean boolean boolean

xsd:byte byte octet

xsd:decimal java.math.BigDecimal fixed

xsd:double double double

xsd:float float float

xsd:int int long

xsd:integer java.math.BigInteger fixed

xsd:long long long long

xsd:short short short

xsd:string java.lang.String string

Java types have been used for translation in table 5.2. As AXIS is able to offer Java

classes as WebServices, IDL interfaces may be used to generate a Java stub, which

is then offered as a WebService. The IDL to Java translation is defined in [Obj02b].

When mapping such Java stubs to WSDL files, AXIS does not need to know about the

stubs being stubs for a CORBA object. This works trouble-free for CORBA interfaces

that solely use the basic data types depicted in the table. For example, listing 5.1 shows

a simple CORBA interface.

Listing 5.1: The Service Base interface in CORBA IDL

# pragma prefix "cit.ie"

2

module lmsServices {

4

interface Service {

6

void ping();

110

8 oneway void initialize();

oneway void shutdown();

10

readonly attribute string Class;

12 readonly attribute string Subclass;

readonly attribute string Name;

14 readonly attribute string Description;

readonly attribute short Version;

16 readonly attribute string ServiceLocation;

readonly attribute string Id;

18 };

};

Listing 5.2 shows the corresponding WSDL-mapping of the Java stubs which has been

generated by AXIS. Compared to the IDL definition the WSDL mapping is very long.

Partially this is caused by the fact that Java is not the perfect basis for a WSDL defi-

nition, partially by the fact that WSDL files in general are more complex than a corre-

sponding IDL definition.

Listing 5.2: The Service Base interface in WSDL

<?xml version="1.0" encoding="UTF-8"?>

2 <wsdl:definitions targetNamespace="http://localhost:8080/axis/services/LMSService"

xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.

org/xml-soap" xmlns:impl="http://localhost:8080/axis/services/LMSService"

xmlns:intf="http://localhost:8080/axis/services/LMSService" xmlns:soapenc="

http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.

org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="

http://www.w3.org/2001/XMLSchema">

<wsdl:message name="ServiceLocationRequest">

4 </wsdl:message>

<wsdl:message name="SubclassRequest">

6 </wsdl:message>

<wsdl:message name="NameRequest">

8 </wsdl:message>

<wsdl:message name="NameResponse">

10 <wsdl:part name="NameReturn" type="xsd:string"/>

12 </wsdl:message>

<wsdl:message name="ClassResponse">

14 <wsdl:part name="ClassReturn" type="xsd:string"/>

111

</wsdl:message>

16 <wsdl:message name="pingRequest">

</wsdl:message>

18 <wsdl:message name="IdRequest">

</wsdl:message>

20 <wsdl:message name="DescriptionResponse">

22 <wsdl:part name="DescriptionReturn" type="xsd:string"/>

</wsdl:message>

24 <wsdl:message name="pingResponse">

</wsdl:message>

26 <wsdl:message name="VersionResponse">

<wsdl:part name="VersionReturn" type="xsd:short"/>

28 </wsdl:message>

<wsdl:message name="DescriptionRequest">

30 </wsdl:message>

32 <wsdl:message name="ServiceLocationResponse">

<wsdl:part name="ServiceLocationReturn" type="xsd:string"/>

34 </wsdl:message>

<wsdl:message name="VersionRequest">

36 </wsdl:message>

<wsdl:message name="IdResponse">

38 <wsdl:part name="IdReturn" type="xsd:string"/>

</wsdl:message>

40 <wsdl:message name="ClassRequest">

42 </wsdl:message>

<wsdl:message name="SubclassResponse">

44 <wsdl:part name="SubclassReturn" type="xsd:string"/>

</wsdl:message>

46 <wsdl:portType name="Service">

<wsdl:operation name="Name">

48 <wsdl:input message="impl:NameRequest" name="NameRequest"/>

<wsdl:output message="impl:NameResponse" name="NameResponse"/>

50 </wsdl:operation>

52 <wsdl:operation name="Version">

<wsdl:input message="impl:VersionRequest" name="VersionRequest"/>

54 <wsdl:output message="impl:VersionResponse" name="VersionResponse"/>

</wsdl:operation>

56 <wsdl:operation name="Subclass">

112

<wsdl:input message="impl:SubclassRequest" name="SubclassRequest"/>

58 <wsdl:output message="impl:SubclassResponse" name="SubclassResponse"/>

</wsdl:operation>

60 <wsdl:operation name="Description">

62 <wsdl:input message="impl:DescriptionRequest" name="DescriptionRequest"/>

<wsdl:output message="impl:DescriptionResponse" name="DescriptionResponse"/>


<wsdl:operation name="ServiceLocation">

66 <wsdl:input message="impl:ServiceLocationRequest" name="

ServiceLocationRequest"/>

<wsdl:output message="impl:ServiceLocationResponse" name="

ServiceLocationResponse"/>


<wsdl:operation name="Id">

70 <wsdl:input message="impl:IdRequest" name="IdRequest"/>

72 <wsdl:output message="impl:IdResponse" name="IdResponse"/>

</wsdl:operation>

74 <wsdl:operation name="ping">

<wsdl:input message="impl:pingRequest" name="pingRequest"/>

76 <wsdl:output message="impl:pingResponse" name="pingResponse"/>

</wsdl:operation>

78 <wsdl:operation name="Class">

<wsdl:input message="impl:ClassRequest" name="ClassRequest"/>

80 <wsdl:output message="impl:ClassResponse" name="ClassResponse"/>


</wsdl:portType>

84 <wsdl:binding name="LMSServiceSoapBinding" type="impl:Service">

<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"

/>

86 <wsdl:operation name="Name">

<wsdlsoap:operation soapAction=""/>

88 <wsdl:input name="NameRequest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="http://lmsServices" use="encoded"/>

90 </wsdl:input>

92 <wsdl:output name="NameResponse">


namespace="http://localhost:8080/axis/services/LMSService" use="

113

encoded"/>

94 </wsdl:output>

</wsdl:operation>

96 <wsdl:operation name="Version">


98 <wsdl:input name="VersionRequest">



100 </wsdl:input>

102 <wsdl:output name="VersionResponse">



encoded"/>

104 </wsdl:output>

</wsdl:operation>

106 <wsdl:operation name="Subclass">


108 <wsdl:input name="SubclassRequest">



110 </wsdl:input>

112 <wsdl:output name="SubclassResponse">



encoded"/>

114 </wsdl:output>

</wsdl:operation>

116 <wsdl:operation name="Description">


118 <wsdl:input name="DescriptionRequest">



120 </wsdl:input>

122 <wsdl:output name="DescriptionResponse">



encoded"/>

124 </wsdl:output>

</wsdl:operation>

114

126 <wsdl:operation name="ServiceLocation">


128 <wsdl:input name="ServiceLocationRequest">



130 </wsdl:input>

132 <wsdl:output name="ServiceLocationResponse">



encoded"/>

134 </wsdl:output>

</wsdl:operation>

136 <wsdl:operation name="Id">


138 <wsdl:input name="IdRequest">



140 </wsdl:input>

142 <wsdl:output name="IdResponse">



encoded"/>

144 </wsdl:output>

</wsdl:operation>

146 <wsdl:operation name="ping">


148 <wsdl:input name="pingRequest">



150 </wsdl:input>

152 <wsdl:output name="pingResponse">



encoded"/>

154 </wsdl:output>

</wsdl:operation>

156 <wsdl:operation name="Class">


158 <wsdl:input name="ClassRequest">

115



160 </wsdl:input>

162 <wsdl:output name="ClassResponse">



encoded"/>

164 </wsdl:output>

</wsdl:operation>

166 </wsdl:binding>

<wsdl:service name="ServiceService">

168 <wsdl:port binding="impl:LMSServiceSoapBinding" name="LMSService">

<wsdlsoap:address location="http://localhost:8080/axis/services/LMSService"

/>

170 </wsdl:port>

172 </wsdl:service>

</wsdl:definitions>

Mapping of complex types

Complex CORBA types are usually mapped to Java classes. This is not a problem for

AXIS as long as these classes follow the JavaBean pattern:

� The class provides a public default constructor.

� All attributes are public or provide getter and setter methods.

For example, the resulting class for the CORBA struct type follows the JavaBean

pattern. AXIS decomposes the class to its public members, which are represented by a

WSDL complex type. When a WebService which offers a CORBA struct is called,

a new instance of the Java class representing the CORBA struct is created (using the

default constructor) and the public members are set accordingly.

Unfortunately not all CORBA complex types are mapped to classes that follow the

JavaBeans pattern, e.g., the Java representation of IDL enum does not possess a public

116

default constructor, which currently makes an automated mapping impossible with

AXIS.

5.1.3.3 Implementation of Callbacks

In addition to the problems related to the mapping of data types, another huge problem

is the implementation of callbacks. WebServices clients are usually not aware of the

WebService engine forwarding the call to a CORBA server and vice versa. Hence, the

CORBA stub has to act as application proxy, implementing the callback interface the

server uses to notify a client and forwarding each call to the WebServices client which

again would have to implement the callback interface (and thus be a WebService as

well).

The implementation of callbacks might become easier as soon as the “CORBA to

WSDL/SOAP interworking specification” has been adopted by product vendors. For

now, calls that support callbacks are not supported in the WSDL mapping of the dis-

tributed LMS interfaces.

5.1.4 Possible usage scenarios for CORBA and WebServices

There are still serveral possible ways of realising communication between different

elements of our architecture when concentrating on CORBA and WebServices as mid-

dleware technologies.

As already described in sections 5.1.1 and 5.1.2 both technologies incorporate as well

advantages as disadvantages when being compared to each other.

Looking at SOAP as a middleware platform, the major problems consist of interop-

erability issues between different platforms4, performance problems and the lack of

features like built-in security and transaction support.

4See http://easysoap.sourceforge.net/interop/interop2a.html for details.

117

These disadvantages show, that WebServices are not the ideal platform to be used for

connecting all parts of the system. The focus of WebServices currently is more on

connecting loosely coupled parts of a system, where a major advantage is the ability to

cross existing firewalls as the protocol is implemented on top of existing layer seven

Internet protocols like, e.g., HTTP or SMTP.

In addition, the WSDL definition of WebServices interfaces does not support interface

inheritance. In order to extend an existing service base interface, a vendor would have

to keep track of the original functionality all by himself, which may be difficult and

error-prone for complex interfaces. This underlines that WebServices are not the right

technology to be used as core-middleware for the implementation of our architecture.

Looking at CORBA, one major problem is to allow CORBA calls to cross existing fire-

walls, as the IIOP protocol does not use well-known ports for connecting CORBA ob-

jects. Another problem is the rather tight coupling between CORBA objects. Services

which are located in different institutions may not be accessible at all times or could

require a restart – both scenarios cause trouble for CORBA clients using a specific

IOR which points at the corresponding server. In contrast WebServices just connect to

a pre-defined URI and do not care much about the receiver of their message as long as

there is a reply to their request.

An advantage of CORBA is the support for transactions and built-in security as well

as the interoperability and the invocation speed in general. CORBA IDL allows a clear

interface definition and supports interface inheritance, which makes the extension of

existing interfaces easy.

We chose to implement service communication within an institution using CORBA.

This allows us to use the advantages like transactions and security for tightly coupled

services like, e.g., e-learning services relying on local infrastructure services.

Cross-institutional services offer a CORBA interfaces as well as a WebService inter-

face. Local services are free to use the interface of their choice and thus make use of the

118

advantages provided by CORBA. For invocations which incorporate services of other

institutions the use of the WebService interface is recommended, as these services are

usually not tightly coupled and firewalls may be crossed easily.

5.2 Implementation of a prototype

The prototypical implementation of the distributed LMS architecture uses Apache

AXIS WSDL/SOAP WebService interfaces for connecting WebServices between dif-

ferent institutions. In addition IONA Orbacus5 4.1.2 is used to implement the CORBA

service interfaces for institution-internal communication. Orbacus provides a CORBA

Naming Service and a CORBA property service and is available for C++ and Java. The

Java version of Orbacus was used for the implementation of the prototype.

The infrastructure services, with the exception of the security service, only provide

a CORBA interface as the services are not accessed from other institutions. The e-

learning services and the security service provide both a CORBA and a WebService

interface. However the restrictions described in section 5.1.3.3 apply for the WebSer-

vice interface, i.e., the implementation of callbacks is currently not possible.

5.2.1 Infrastructure services

First, we are going to describe the implementation of the infrastructure services. Many

existing middleware architectures already contain standard components that fulfil a

similar task as the distributed LMS infrastructure services. Therefore the prototypical

implementation of the corresponding LMS infrastructure services makes use of exist-

ing middleware services by implementing a mapping between the interface of existing

middleware services and the interface defined in the distributed LMS architecture.5See http://www.orbacus.com for details

119

Startup

All prototypically implemented services follow the same startup procedure. They use

the CORBA CosNaming service (see [Obj02c]) for looking up other infrastructure ser-

vices in oder to avoid the problem of retrieving the initial reference of the LMS lookup

service. Services, which implement CrossInstitutionalService perform ad-

ditional initialisation steps, described in section 5.2.2.

On Startup all services register themselves in the local CORBA CosNaming service,

try to locate the logging service and send a startup message to the logging service. The

CORBA CosNaming service is later used by Apache AXIS for looking up CORBA

implementations of WebService interfaces. After initialize() has been called

the service is available for other LMS services. Figure 5.1 depicts this behaviour,

using the LMS property service as an example.

CORBA CosNamingServer

PropertyService

lookup LMS lookup service

lookup LMS logging service

<<create>>register LMS property service

LoggingService

initializelog(initialized)

Administrator

Figure 5.1: Initialisation of the LMS property service

5.2.1.1 The lookup service

The basis for the prototypical implementation of the LMS lookup service is the CORBA

CosTrading service (see [Obj00b]).

Figure 5.2 depicts the overall implementation design of the LMS lookup service.

120

LMS Lookup service

CORBAinterface

CORBA CosTrading service(JacORB 1.4.1)

LMS service

IIOP

IIOP

LMS Lookup service

CORBAinterface

CORBA CosTrading service(JacORB 1.4.1)

LMS service

IIOP

IIOP

Offerexchange

Figure 5.2: Overall implementation design of the LMS lookup service

The LMS lookup service implementation communicates with the CORBA CosTrading

service via IIOP.

The CORBA CosTrading service

The CORBA trading service provides a set of CORBA interfaces dealing with object

registration and object query.

CORBA objects may register with the CORBA trading service, providing their IOR6

and a set of properties that characterise the service being offered. At least one of-

fer type must be defined on service initialisation. An offer type describes the kind of

CORBA objects (characterised by their IDL interface) that are allowed to register with

the service using this offer type on registration. The offer type also specifies a set of

mandatory properties which each service registering with this offer type must to pro-

vide. Properties may be declared readonly, which prevents a CORBA object from

updating their values after registration. CORBA objects may in addition specify prop-

erties that are not mentioned in the offer type at all. However, using such additional

properties makes it difficult for other services to perform queries.

When querying the CORBA trading service, objects may specify properties and prop-

erty values which the resulting offers have to match. It is also possible to select all

6Interoperable Object Reference

121

services which provide a certain property or to supply a range of possible property val-

ues. In addition, the CORBA trading service is able to export offers to other CORBA

trading services.

The CosTrading service supports a number of policies that influence the behaviour

of the service when processing queries. Depending on the policy values set, offers

from other services may be considered (use proxy offers), the service may only

return offers that implement exactly the interface specified in the query, or derived

services may also be returned (exact type match), etc. The CosProperty ser-

vice also supports so called dynamic properties. The values of dynamic properties

are queried by the CosTrading service on demand, i.e., the CosTrading service in-

vokes the CORBA object to retrieve the value of a property when queried for offers

(use dynamic properties).

CORBA properties comprise a property name of type string and a property value

of type CORBA::any. CORBA::any is a container type that may contain any type

defined in CORBA IDL. Therefore CORBA properties are very flexible.

Interface mapping

As the CORBA trading service handles everything that is needed by the LMS lookup

service, mapping of the trading service interface to the LMS lookup service interface

is straightforward.

LMS properties are always stored in String notation, but comprise not only property

name and property value but also a property type. This type defines the data type of

the stringified value. In order to map LMS properties to CORBA properties, they are

converted to their corresponding CORBA data type. Table 5.3 shows this mapping in

detail.

122

Table 5.3: Mapping between LMS properties and CORBA

properties

LMS PROPERTY TYPE CORBA IDL TYPE

ie.cit.lmsServices.Tboolean boolean

ie.cit.lmsServices.Tfloat float

ie.cit.lmsServices.Tint long

ie.cit.lmsServices.Tstring string

On startup, the LMS lookup service registers an offer type with the CORBA trading

service. This offer type covers the basic service properties (see table 5.4).

Table 5.4: The offer type for LMS services

PROPERTY NAME PROPERTY TYPE FLAGS

class string MANDATORY READONLY

subclass string MANDATORY READONLY

version long MANDATORY READONLY

id string MANDATORY READONLY

location string MANDATORY READONLY

costs long NORMAL

wsreference string NORMAL

Service registration

When a service invokes registerService on the LMS lookup service, the prop-

erties sent with the registration approach are first checked for compliance with the

offer type, then converted to CORBA properties and forwarded to the CORBA trad-

ing service by invoking its export method. The result of this invocation is a reg-

123

istration ID which is sent back to the registering LMS service. An LMS service

can deregister using the ID which has been supplied on registration on invoking the

unregisterService method of the LMS lookup service. This method is mapped

to the withdraw method of the CORBA trading service.

Service lookup

The LMS lookup service provides two methods for service lookup: query-

ServicesWithProperties, and queryServicesWithConstraint. Both

methods are mapped to the query method of the CORBA trading service whereby

properties and constraints are converted to CORBA trading service constraints. As the

implementation relies on the underlying Trading Services for offer exchange, it is pos-

sible that the local Trading Service returns offers from different institutions. In order

to match the LMS architecture requirements, the following query policies are used:

� exact type match = false

� use dynamic properties = true

� use proxy offers = true

5.2.1.2 The property service

The basis for the prototypical implementation of the LMS property service is the

CORBA CosProperty service (see [Obj00a]).

Figure 5.3 depicts the overall implementation design of the LMS property service.

The LMS property service implementation communicates with the CORBA CosProp-

erty service via IIOP.

124

LMS Property service

CORBAinterface

LMS service

CORBA CosProperty service(Orbacus 4.1.2)

LMS service

IIOP

IIOPIIOP

Figure 5.3: Overall implementation design of the LMS property service

The CORBA CosProperty service

The CORBA property service provides a generic interface for storing and retrieving

properties, each consisting of a property name and an associated property value. The

property value is encoded in a CORBA any type, which allows the CORBA property

service to store any CORBA data type as a property.

Interface mapping

The interface offered by the CORBA property service is quite similar to the interface of

the LMS property service. This eases the mapping of the LMS property service inter-

face to that of the underlying CORBA property service. As described in section 5.2.1.1

the mapping of simple LMS properties to CORBA properties is relatively straightfor-

ward. The prototype does not support the mapping of complex LMS properties to the

corresponding complex CORBA types. Complex LMS properties are instead stored as

strings, leaving the interpretation of the content up to the service that uses the LMS

property service. Note that the prototypically implemented services do not use any

complex LMS properties.

The only part of the LMS property service interface that is not covered directly by

functionality provided by the CORBA property service is the ability of the LMS prop-

125

erty service to callback other services on property change.

As the LMS property service interface is invoked on each property change, the notifica-

tion of previously registered services is not problem. The LMS property service keeps

track of the notification requests and checks property names for matching properties in

case changes are performed.

5.2.1.3 The logging service

The LMS logging service does not use an existing implementation, but simply prints

out logging statements to the screen. This is mainly intended to be used for debugging

purposes.

Other implementations are free to store logging statements in a relational database, or

map them to an existing logging API like Log4J7.

The implementation of the logging service is straightforward: When a logging state-

ment is received, the logging service checks if the threshold that has been configured

globally for the service instance is lower than the level of the log message and either

prints the message to a log file or discards it accordingly.

5.2.1.4 The security service

The initialisation steps for the LMS security service are described in section 5.2.2.

The LMS security service consists of two parts:

� The authentication API utilising the authentication part of JAAS8

� The authorisation API

7See http://logging.apache.org/log4j/docs/ for details.8Java Authentication and Authorisation Services, see http://java.sun.com/products/jaas/ for details.

126

LMS authentication service

Service implementation

LMS service

JDBC

IIOP/SOAP

PostgresqlRDMBS

LMS authorisation service

JAASlogin manager

Principals

Figure 5.4: The overall security service implementation design

Figure 5.4 depicts the overall implementation design of the LMS security service. The

JAAS login module is plugged into the authentication service by specifying a Java

property when starting the virtual machine. The login module verifies user data by

comparing user names and passwords with the entries of the user database. The user

database is stored in a Postgresql9 RDBMS and accessed via JDBC. The JAAS login

module provides a callback facility that allows the login module to give feedback on

the authentication status of a user or to query additional information from a user. This

callback facility gets intercepted by the LMS authentication service which checks if

the required information is available locally, e.g., username, or password. In case the

information is not available but the login-call provides a callback-hook for itself, the

LMS authentication service forwards the callback to the calling service in order to

retrieve this information. This of course only works in scenarios where callbacks are

possible.

The LMS authentication service then generates a handle that points to the principal

information stored locally. This information is only accessible for authentication and

authorisation services.

Figure 5.5 depicts the central classes of the prototypical LMS authentication service.

AuthenticationService Impl is the CORBA interface implementation class.

9See http://www.postgresql.org/ for details

127

Figure 5.5: The central classes of the authentication service

This class accesses the LMSLoginModule that implements the JAAS LoginModule

interface. The login modules hosts the authentication principals, in our case the LMS-

Principal. Each principal reflects a currently logged-on user of the LMS. The ser-

vice accesses principal information via the login module. On logon the login module

connects to the database, verifies the user’s authentication information, and possibly

sends a callback to the service implementation in order to query for additional infor-

mation. On success, an instance of LMSPrincipal is created, which hosts the user’s

identity.

128

5.2.2 E-Learning services

The main LMS functionality is provided by the LMS e-learning services. These ser-

vices have partly been implemented from scratch and partly been based on existing

functionality.

In addition to the CORBA interfaces for institution-internal communication, all e-

learning services and the security service also offer their functionality using WSDL-

interfaces. In order to minimise the implementation effort for the prototype, these

WSDL interfaces get auto-generated from the existing CORBA skeletons by the Apache

AXIS platform using a so-called “CORBA provider”.

The main implementation design of a LMS e-learning service is depicted in figure 5.6.

LMS e-learning service

CORBAinterface

LMS service


LMS service

IIOP

IIOP

IIOP

CORBACosNaming

service

Apache AXISCORBAProvider

IIOP

WSDLinterface

SOAP

Figure 5.6: Principal architecture of an e-learning service

129

Remote LMS service invocation

The following steps are performed when a service requires some functionality provided

by an LMS e-learning service:

� service lookup

� if the e-learning service is located locally: CORBA invocation

� else invocation of WebService in partner institution

In an example scenario (depicted in figure 5.7), the LMS portal of institution A re-

quires information concerning the term “e-learning”. For reasons of clarity, calls to

authentication, authorisation, and property services have been omitted in the figure.

Institution Alookup service

Institution ALMS Portal

Institution Asearch service

Institution Bsearch service

Institution BAxis platform

query(SearchService)[A],[B]

doSearch("e-learning")

[results]

Institution BCORBA

CosNamingservice

resolve(search service)[IOR]


[results]

[results]


Figure 5.7: Invocation of an e-learning service

First, the LMS portal invokes the local lookup service and queries available search

services. In this scenario the lookup service returns two offers: one local search service

and one search service located in a cooperating institution. The LMS portal may now

check the users’ properties in order to determine if both search services should be

contacted. This is not displayed in the figure.

When evaluating the offers presented by the lookup service, the LMS portal may use

the ServiceLocation property of each offer to decide which service interface to

employ.

130

The LMS portal first invokes the query method of the institution A search service

using the LMS search services CORBA interface. The search service then checks

with the local authorisation service to see if the user on behalf of whom the portal is

performing the query is allowed to perform a search with this service. In case of a

positive response, the search service performs the query for the term “e-learning” and

returns the query results.

Afterwards the portal sends the same query to the institution B search service. As this

service is located in a cooperating institution, the WebServices interface of the service

is used, i.e., the call gets intercepted by the WebServices platform running in institution

B. The WebServices platform then queries the local CORBA CosNaming service for

the IOR of the LMS search service CORBA interface, instantiates a CORBA stub

and forwards the query to the services’ CORBA interface. This search service again

invokes the local authorisation service to decide whether the user is allowed to perform

the query. In case of a positive response, the search service performs the query for the

term “e-learning” and returns the query results to the WebService. The WebService

then evaluates the result which is encoded in CORBA data types, converts them to a

SOAP response and returns the result to the LMS portal of institution A.

Modification of the AXIS CORBAProvider

The Apache AXIS platform already provides a basic CORBA provider, which is able

to perform data type conversion, CosNaming lookup on CORBA objects, and their

invocation. Details concerning the CORBA object, e.g., names of stub classes, naming

service name, etc., are declared in an XML deployment descriptor. Listing 5.3 shows

an example of an AXIS deployment descriptor for a CORBA object.

Listing 5.3: A sample AXIS CORBA deployment descriptor

<?xml version="1.0" encoding="UTF-8"?>

2 <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache

.org/axis/wsdd/providers/java">

131

4 <service name="LMSWebSearchService" provider="java:CORBA">

<parameter name="InterfaceClassName" value="ie.cit.lmsServices.search.

SearchService"/>

6 <parameter name="HelperClassName" value="ie.cit.lmsServices.search.

SearchServiceHelper"/>

<parameter name="allowedMethods" value="ping, Class, Subclass, Name, Version,

Description, ServiceLocation, Id, WSReference, doSearch, doSearchMax"/>

8 <parameter name="ORBInitialHost" value="localhost"/>

<parameter name="ORBInitialPort" value="9000"/>

10 <parameter name="NameID" value="ie/cit/lmsServices/googlesearch/SearchService"/>

<parameter name="NameKind" value=""/>

12

<beanMapping qname="ns:TServiceInfo" xmlns:ns="http://lmsServices.cit.ie"

languageSpecificType="java:ie.cit.lmsServices.TServiceInfo"/>

14 <beanMapping qname="ns:TProperty" xmlns:ns="http://lmsServices.cit.ie"

languageSpecificType="java:ie.cit.lmsServices.TProperty"/>

<beanMapping qname="ns:TLoginContextHandle" xmlns:ns="http://security.

lmsServices.cit.ie" languageSpecificType="java:ie.cit.lmsServices.security.

TLoginContextHandle"/>

16 <beanMapping qname="ns:SearchResult" xmlns:ns="http://search.lmsServices.cit.ie"

languageSpecificType="java:ie.cit.lmsServices.search.SearchResult"/>

<beanMapping qname="ns:SearchResultElement" xmlns:ns="http://search.lmsServices.

cit.ie" languageSpecificType="java:ie.cit.lmsServices.search.

SearchResultElement"/>

18 </service>

</deployment>

InterfaceClassName and HelperClassName point AXIS to the stub classes

representing the CORBA object. ORBInitialHost and ORBInitialPort direct

the JDK ORB, which is used for instantiating the stubs, to the CosNaming service.

NameID and NameKind refer to the CosNaming name of the CORBA object.

AllowedMethods specifies which CORBA Methods should be available in the Web-

Service interface. This is useful in order to suppress CORBA-specific methods as well

as callback functionality.

The beanMapping statements help AXIS to map complex data types between Java

(which has previously been generated from CORBA IDL) and WSDL/SOAP as de-

132

scribed in section 5.1.3. The AXIS CORBAProvider only supports Names with

a single NameComponent. This is not practical for large installations as every-

body pollutes the root context by adding references. This is why we extended the

CORBAProvider to support CosNaming names with any number of NameComponents.

We chose to implement this in a Unix filesystem-like notation, by declaring the ‘/‘ to

be the separator for two NameComponents (see listing D.1 in the appendix). This

generates the constraint that NameIDs are not allowed to contain the ’/’ anymore.

Startup

The LMS e-learning services and the security service perform the same steps on startup

as the LMS infrastructure services (see 5.2.1). In addition they register with the local

lookup service when initialize is called.

They may however look up other services or perform additional initialisation tasks.

5.2.2.1 The annotation service

The LMS annotation service allows users to annotate Web pages and to share these

annotations with other users of the LMS. It is based on the W3C annotea approach,

which has been described in section 4.4.1 along with the overall LMS annotation ser-

vice architecture.

The LMS annotation service consists of two parts: the annotation proxy, which will

later be integrated into the LMS portal and the actual LMS annotation service server,

which stores annotations persistently.

The overall implementation design of the LMS annotation service is depicted in fig-

ure 5.8.

133

Service implementationJDBC

IIOP/SOAP

MySQLRDMBS

LMS annotation service server

LMS annotation service proxy

Web Browser

LMS portal

Figure 5.8: The overall annotation service implementation design

The annotation service proxy

The LMS annotation proxy is implemented as a Java web application. It provides three

different interfaces to fulfil the W3C Annotea specification:

� The proxy interface is used by clients to retrieve annotation information con-

cerning a specific URL (via HTTP GET) or to add new annotations for a URL

(via HTTP POST).

� The annotation interface is used to retrieve information about an annotation

(via HTTP GET), to update this information (via HTTP PUT) or to delete an

annotation.

� The body interface is used by clients to access an annotation body (via HTTP

GET).

The annotation proxy is responsible for the mapping between annotations and the LMS

annotation service server. Therefore, the client requests must be transformed into their

134

corresponding LMS annotation service server interface requests.

Annotea specifies annotations in an RDF-format, which must be interpreted by the

annotation proxy in order to forward the request to the LMS annotation service server

responsible for storing the data. The reply to an Annotea client must be encoded in

RDF as well. The proxy is responsible for the generation of an RDF document.

RDF handling is relatively complex. We therefore used a third party RDF library to

fulfil the task of reading and writing RDF. The Jena Toolkit10 developed by Hewlett

Packard is a Java library for parsing and generating RDF documents. Jena also offers

other features like persistence for RDF data and a reasoning subsystem (both not used

in our case).

After the annotation service proxy looks up several accessible LMS annotation service

servers, it has to aggregate the available annotations in order make them appear as

a single data source to users of the annotation system. The Annotea specification

requires each annotation object (both annotation information and annotation body) to

be served with a unique URL that can be used to retrieve the annotation object. The

format of this URL is left to the Annotea server.

In our case, the annotation proxy chooses annotation URLs in such a way that they

contain a unique LMS annotation server ID and the annotation ID (which is unique

per server). This way, the Proxy is able to address the server and the annotation id by

simply parsing the requested URL.

To keep the addressing scheme consistent, annotation information is addressed the

same way, but with a different preceding URL.

Let us take a look at the following example: The proxy discovered three LMS annota-

tion service servers: server1, server2 and server3. Server1 has an annotation with ID

equal to 10. The URL to access the annotation information will be similar to:

http://www.cit.ie/portal/annotations/server1-ID/10

10See http://www.hpl.hp.com/semweb/jena.htm for details

135

For accessing the annotation body, the URL would be something like:

http://www.cit.ie/portal/bodies/server1-ID/10

If the Proxy receives a request that asks for the annotation information for the anno-

tation found at the first URL, it simply parses the URL to locate the LMS annotation

service server responsible for the annotation.

ProxyServlet ServerMap AnnotationService AuthorisationService LCHMapper

Annotea Client

1.1: getServers

1.2.2: getUUIDForLCH

1.2.3: queryDB

1.2.1: isAuthorised1.2: getAnnotationsForURL

1: doGet

Figure 5.9: Retrieving annotations for a certain URL

Figure 5.9 depicts the process of retrieving the annotations for a certain URL. The

Annotea client issues a request to the Annotation Proxy Servlet located within the

LMS portal. The servlet retrieves an up-to-date list of available annotation servers

from its ServerMap class. The ServerMap is also responsible for mapping ref-

erences to instances of AnnotationService to IDs which are used to represent

the server within an annotation URL and vice versa. In the example depicted in fig-

ure 5.9 just one AnnotationService reference is returned. The servlet then in-

vokes getAnnotationsForURL on this service, supplying the URL which has

been posted by the client and the TLoginContextHandle of the current session’s

user. The AnnotationService checks with the AuthorisationService if

the user is allowed to retrieve annotations. In our example, this is the case. The

AnnotationService then converts the user’s login information to a string, by in-

136

voking getUUIDForLCH on the LCHMapper class. This string representation of a

unique user id is then used in connection with the URL for querying annotations in the

database. The service then returns all available annotations for the URL to the servlet.

These are then encoded in the Annotea RDF syntax and returned to the Annotea client

in order to be displayed in the user’s browser.

The annotation service server

The LMS annotation service server uses a MySQL database for persistent annotations

as depicted in figure 5.8.

The annotations are stored in a single database-table. Table 5.5 depicts the fields.

Primary key is the annotation id.

Table 5.5: The fields of the MySQL annotations table

FIELD ATTRIBUTES

annotation id INT NOT NULL AUTO INCREMENT

annotates TEXT NOT NULL

annotationContext TEXT

author TEXT NOT NULL

creation date VARCHAR(100) NOT NULL

modification date VARCHAR(100) NOT NULL

body is text TINYINT

body content TEXT DEFAULT NULL

Per default, a user is only allowed to see his own annotations to the LMS content.

However it is possible to share anntoations with other users. Sharing annotations re-

quires two steps: First the LMS user who intends to share his annotations has to grant

annotation access to others, second a user who wants to view shared annotations has

137

to enable the configuration option for viewing annotations shared by other users. Even

when using shared annotations users are still not allowed to delete annotations made

by other users of the distributed LMS.

HttpServlet...servlets.QueryServlet

-logger:ILogger

#doGet:void

-QueryThread

...servlets.ServerMap

-map:HashMap

+ServerMap+getServer:AnnotationService+getServerStatus:String

size:intservers:EnumerationpostServer:String

...servlets.ProxySettings

+HTTP_SUCCESSFULL:int+HTTP_NOT_FOUND:int+HTTP_XML_TYPE:String+HTTP_HTML_TYPE:String+LOGGER_ACTIVE:String+LOGGER_OUTPUT:String+SERVICE_INFO_PREFIX:String+SERVICE_BODY_PREFIX:String-instance:ProxySettings-logger:ILogger

-serverMap:ServerMap-rbSettings:ResourceBundle

+getInstance:ProxySettings-ProxySettings+getLogger:ILogger

+getServerMap:ServerMap+getProperty:String+toHTML:String-appendHtmlTitle:void-appendHtmlTable:void-appendHtmlRow:void-appendHtmlTableEnd:void

HttpServlet...servlets.BodyServlet

-logger:ILogger

#doGet:void

HttpServlet...servlets.ProxyServlet

-logger:ILogger

#doGet:void#doPost:void#doPut:void-saveAnnotation:void

HttpServlet...AnnotationServlet

-logger:ILogger

#doGet:void#doPost:void#doPut:void#doDelete:void-logDebugInfo:void

...convert.AnnoteaParser

-model:Model-iterator:ResIterator-currInfo:AnnotationInformation-currBody:AnnotationBody

+AnnoteaParser+AnnoteaParser+hasEntries:boolean+parseNextEntry:void+debugModelToLog:void+main:void

info:AnnotationInformationbody:AnnotationBody

...convert.AnnoteaWriter

-model:Model-defaultInfoPrefix:String-defaultBodyPrefix:String

+AnnoteaWriter+append:String+append:String+serializeRDF:void+serializeRDF:void+debugModelToLog:void-buildAnnotationURL:String

Figure 5.10: Important classes of the Annotation Proxy

Figure 5.10 depicts important classes of the Annotation proxy implementation. The

ProxySettings class stores reference to resources like, e.g, the ServerMap. This

class is accessed by the different Servlet classes displayed in the lower part of the

figure. AnnoteaWriter and AnnoteaParser are used to convert Annotations

from the internal data representation of the Annotation service to the Annotea RDF

notation and vice versa.

Problems with existing clients

The main advantage of implementing the LMS annotation service in an Annotea com-

pliant fashion is that the implementation does not have to worry about about different

138

client implementations. The W3C has integrated an Annotea client into its Amaya

browser, and Mozilla hosts the Annozilla project, a Mozilla plug-in that adds Annotea

client functionality to Mozilla 1.4.

Amaya implements all the functionality defined by the Annotea specification for An-

notea clients. However the Amaya browser is more a reference implementation than

a browser which can be used in today’s work, e.g., it does not support frames and

plug-ins.

So, currently the most convenient way of accessing Annotea-compliant annotations

is the Mozilla browser with Annozilla extension. Annozilla is still in an early beta

stage and works only with Mozilla 1.4. This is probably the reason for the following

annoying problems, when working with Annozilla:

� Annozilla sends the user an error message when an annotation has been posted

successfully.

� Annozilla currently is not capable of displaying annotations for web pages that

use frames. When creating an annotation for a frame-content page, Annozilla

correctly uses this URL. When querying annotations, Annozilla just sends a

query for the frame-URL, not for the URLs of the frame-content pages.

� Annozilla currently is not capable of interpreting the X-Pointers generated by

Amaya. This means, annotations for parts of pages that were created with

Amaya can not be associated with the part of the web-page they annotate.

� Annozilla sometimes displays two pencil icons for a single annotation instead of

just one.

Despite these problems, Annozilla is quite usable for a beta implementation.

139

5.2.2.2 The bookmark service

As described in section 4.4.2, the bookmark service allows the distributed LMS to

store browser bookmarks pointing to web sites with information related to the courses

presented. The LMS bookmark service allows users to use the Mozilla browser as

an authoring tool for bookmark collections. These bookmark collections may then be

imported into the LMS bookmark service. The service also allows users to export col-

lections of bookmarks to a file which may later be re-imported into the Mozilla browser

to allow users to access the LMS-generated bookmarks as native browser bookmarks.

Figure 5.11 depicts the overall implementation design of the LMS bookmark service.

The service uses a MySQL database as backend for storing the bookmarks.


LMS service

JDBC

IIOP/SOAP

MySQLRDMBS

LMS bookmark service

Figure 5.11: The overall bookmark service architecture

The LMS bookmark service accepts Mozilla bookmark files as input string in order to

import existing bookmark collections,. Mozilla allows users to embed any number of

bookmark categories into each other but the LMS bookmark service only supports one

category for each bookmark. Hence the prototypical implementation rejects bookmark

files with sub-categories.

As Mozilla bookmark files are encoded in an XML-like fashion, these files may easily

be parsed by the bookmark service. However standard XML parsers cannot be used for

140

this task, as the bookmark files do not represent fully valid XML and do not contain

an XML header. This is why we implemented our own parser class, based on the

publicly available kSOAP parser. This parser provides a relatively tolerant “legacy-

mode” which allows the parsing of Mozilla files.

When a bookmark file has been parsed successfully, the resulting bookmarks and cat-

egories are added to the MySQL database.

The service uses two tables in a MySQL database: the category table depicted in ta-

ble 5.6 and the bookmark table depicted in table 5.7.

Table 5.6: The fields of the MySQL categories table

FIELD ATTRIBUTES

category id VARCHAR(60) NOT NULL PRIMARY KEY

cat description TEXT NOT NULL

cat date creation TEXT

Table 5.7: The fields of the MySQL bookmarks table

FIELD ATTRIBUTES

bookmark id VARCHAR(60) NOT NULL

category id VARCHAR(60) NOT NULL

bk description TEXT NOT NULL

bk url TEXT NOT NULL

bk icon url TEXT NOT NULL

bk date creation TEXT

bk date access TEXT

bk charset TEXT

141

Figure 5.12 depicts the central classes of the prototypical implementation of the LMS

bookmark service.

The class BookmarkService Impl implements the CORBA interface of the LMS

bookmark service. On startup, the service instantiates an instance of Bookmark-

Main, which hosts the actual service implementation.

BookmarkMain accesses MozillaParser in order to parse incoming bookmark

files or to generate valid bookmark files. Internally, InternalBookmark and In-

ternalCategory are used for representing bookmarks and categories. These classes

provide methods to persist the included data into the relational database.

5.2.2.3 The service for searching the Web

The LMS web-search service implementation is based on the Google SOAP API11.

This API allows the use of the Google search engine from existing applications. The

Google service requires previous registration and allows 1000 queries per day using

an evaluation key without any charge. Users who need a greater search capacity may

purchase a license key from Google.

The LMS web search service maps the LMS search service API to the Google SOAP

API.

The overall implementation design of the LMS web search service is depicted in fig-

ure 5.13.

Mapping the results presented by the Google API to a LMS TSearchResult is

relatively easy. Google provides the results in a well-structured fashion. Each search

result element is equipped with a summary which is mapped to the description

of an LMS search result element. In addition, a property named url is added to each

search result element. This property contains the URL of the Google search result

element (see lines 16 to 21 of listing 5.4).11See http://www.google.com/apis/ for details.

142

Figure 5.12: The central classes of the bookmark service

143


LMS service

SOAP

IIOP/SOAP

LMS web-search service

Google SOAP API

Figure 5.13: The overall web-search service implementation design

Listing 5.4: The performTheSearch method

private TSearchResult performTheSearch(com.google.soap.search.GoogleSearch gs)

throws SearchFault {

2 TSearchResult result = new TSearchResult();

result.empty = true;

4 try {

java.util.Vector resultElements = new java.util.Vector();

6 com.google.soap.search.GoogleSearchResult googleResult = gs.doSearch()

;

com.google.soap.search.GoogleSearchResultElement[]

googleResultElements = googleResult.getResultElements();

8 for (int i = 0; i < googleResultElements.length; i++) {

result.empty = false;

10 result.numberOfResults = i;

TSearchResultElement re = new TSearchResultElement();

12 re.Id = i;

re.title = googleResultElements[i].getTitle();

14 re.description = googleResultElements[i].getSummary();

re.properties = new TProperty[1];

16 TProperty url = new TProperty();

url.type = ie.cit.lmsServices.Tstring.value;

18 url.name = "url";

url.value = googleResultElements[i].getURL();

20 re.properties[0] = url;

resultElements.add(re);

144

22 }

result.resultElements = (TSearchResultElement[]) resultElements.

toArray( new TSearchResultElement[0] ) ;

24 }

catch (com.google.soap.search.GoogleSearchFault e) {

26 log.error(e.getMessage());

throw new SearchFault();

28 }

return result;

30 }

The service uses the subclass web in order to identify itself as a web search service.

5.2.2.4 The service for searching a digital library

The service for searching a digital library is based on the Greenstone digital library

project. Greenstone is a digital library server based on the Apache Web server, perl,

and several Unix tools. Greenstone organises documents in “collections”, which may

be searched using a Web interface (see figure 5.14). In addition Greenstone provides a

CORBA interface that is depicted in listing D.3.

Figure 5.14: The Greenstone web interface

The LMS library search service maps the LMS search service API to the Greenstone

CORBA API.

145

The overall implementation design of the LMS library search service is depicted in

figure 5.15.


LMS service

IIOP

IIOP/SOAP

LMS lib-search service

Greenstone CORBA API

Figure 5.15: The overall lib-search service implementation design

It is straightforward to map the results presented by the Greenstone API to a LMS

TSearchResult. Greenstone provides much more information and metadata than

the LMS lib search service API needs. Each search result consists of metadata and

a list of documents, which represent the document content. Some of the metadata

returned is mapped to description of an LMS search result element. In addition,

a property named document is added to each search result element. This property

contains the document which Greenstone returned.

5.2.3 Integration into an existing LMS portal

All the services are integrated into a single existing environment to demonstrate the

functionality of the distributed LMS services described above and to illustrate the pos-

sibility of personalising these services. A major challenge was to identify an LMS

system that allows source code modification and is structured in a way that allows easy

integration of the LMS services.

146

As the main purpose of the resulting system is the demonstration of the distributed

LMS services, we decided to modify the existing “SCORM Version 1.2 Sample Run-

Time Environment Version 1.2.1”, which provides a working example of the Run-

Time Environment described in the ADL Sharable Content Object Reference Model

(SCORM) Version 1.212. The Run-Time Environment is not a complete functioning

Learning Management System (LMS), but rather an example of the Run-Time Envi-

ronment as it may be implemented within an LMS that uses Sharable Content Objects.

Necessary modifications to the Run-Time Environment

The Run-Time Environment is implemented as a Java web application, using Java

Server Pages and Servlets. In addition, Java Script is extensively used throughout the

Environment. System requirements are Microsoft Windows and the Internet Explorer

as Web Browser because the Environment uses the Microsoft ODBC bridge to store

data in an MS Access database. The Internet Explorer is required as the Java Script

commands are not implemented in a browser-independent fashion.

The Run-Time Environment provides a basic user authentication and two user roles:

“administrator” and “user”. When logged in as administrator, an administration menu

offers the possibility to create or delete users and to import or delete SCORM-compliant

courses. Users may subscribe to courses and view them, and the system remembers

which user viewed which course. Navigation within courses is implemented using the

SCORM API.

Several modifications had to be installed to use the Run-Time Environment for the

prototypical implementation. The Run-Time Environment was first modified to use a

JDBC driver instead of ODBC and to access a Postgresql database. All database tables

were re-implemented in Postgresql. Next, we fixed all the Java Script statements to

make the system usable with different Web browsers, as later especially Mozilla is

12See http://www.adlnet.org/screens/shares/dsp displayfile.cfm?fileid=815 for details

147

needed as a client for the LMS annotation service.

The result of our modifications was a rudimental LMS portal that could be run in a

Tomcat servlet container under Microsoft Windows or Linux.

Replacement of the authentication procedure

In the original Run-Time Environment, the Java Server Pages performed database

queries to authenticate a user or check a user’s role. This was done on login; other

parts of the system then accessed the session context of the user to discover his/her

authentication status and role.

The login procedure now invokes the LMS authentication service as depicted in list-

ing D.2. Line 4 of the listing shows that looking up available authentication services

has been encapsulated in the connector class. The invocation returns all the authenti-

cation services available in the local institution. Then the system tries to authenticate

the user with username and password until one authentication approach either fails

or succeeds. Services which are not accessible are ignored. If none of the local au-

thentication services is accessible, the authentication fails. The system still saves user

information in the session context since parts of the original Run-Time Environment

need this kind of information.

Integration of the bookmark and search services

The bookmark and search service are integrated into the Run-Time Environment by

adding additional menus to the main selection screen (see 5.16). A user may use

these menus to access the LMS bookmark or search services. In compliance with the

personal properties, these services may offer more or less functionality, e.g., teachers

might be allowed to add bookmark files but students may only be allowed to download

bookmarks.

148

Figure 5.16: Additional menus for service integration

Property settings may be configured via the properties menu. This menu also allows

users to share their annotations with other users of the distributed LMS.

Integration of the annotation service

The annotation service is integrated into the Run-Time Environment by adding the

proxy component to the web application. This way the annotation proxy is able to use

the session context of the portal, where a user’s TLoginContextHandle and other

information is stored for internal use. The proxy uses this information to identify the

user and to access pre-configured annotation servers. The only thing a user has to do

is to configure the local annotation client to use the URL of the proxy located within

his/her LMS portal.

5.3 Lessons learned

The prototypical implementation proves the general feasibility of our approach. How-

ever from the implementation point of view, some aspects should have been refactored

or defined in addition to the current architectural approach:

The architecture currently does not address the deployment of a distributed LMS sys-

tem consisting of independent e-learning services. This includes service dependencies

149

which may have to be checked automatically in order to support administrators on sys-

tem deployment. In addition the architecture currently does not support the migration

of system components between cooperating institutions. In a first step of institutional

cooperation one institution could, e.g., simply use the system of a different institution

but later, some of the system components could be replicated to this institution in order

to increase efficiency.

Especially in the context of the European Union supporting the creation of common

“virtual campuses” especially when incorpoating new EU-members which may cur-

rently not have the ability to host an LMS on their own, system migration becomes

more and more important13.

Additional service classes would ease the configuration and cross-service personalisa-

tion of the architecture. Especially important are an application level log service and a

system-wide configuration repository.

The application level log could be used for learner evaluation as well as for accounting

purposes, the system-wide configuration repository could be used to define system-

wide guidelines. The property service currently only supports institution-wide guide-

lines, which is not sufficient for a lage-scale deployment.

Additional definitions, e.g., for lookup service cooperation would be useful. The ar-

chitecture should also define a service discovery protocol which takes care of updating

service lists in a unified fashion.

Currently, there are no guidelines for portal-implementation. There should be at least a

definition of minimum-requirements concerning portal functionality and portal-service

interaction.

13See http://www.elearningeuropa.info/doc.php?id=4552&p1=1&p2=1&p3=1&p4=1&lng=1&doclng=1 for details.

150

Chapter 6

Summary and conclusions

6.1 Results

We developed the architecture of a distributed LMS which consists of a number of so

called e-learning services. The services represent the systems’ functional components.

In addition, underlying infrastructure services provide supportive functionality such

as service-lookup within an institution. Users access the system using an LMS portal

component that acts as a front-end for the LMS services.

The architecture focuses on the modularity, configurability and extensibility of LMS

services and supports institutional cooperation by allowing remote-access to LMS

services that implement the CrossInstitutionalService interface, specifi-

cally, the LMS e-learning services and the LMS security services.

Recent insights in learning theory show that the learners’ personal situation and in-

dividual precognition are important factors to learning success. The architectural ap-

proach supports personalisation by allowing a cross-service configuration of the LMS

services using a centralised property service. This means that the system may adapt to

a learner’s needs.

While existing e-learning environments provide a relatively good coverage of most

151

of the functional requirements defined in this work, they usually exclude the person-

alisation and collaboration areas particularly addressed in this work. The e-learning

environment is modelled as a distributed architecture with the functional components

represented by a collection of more or less independent services. The architecture

tries to standardise core interfaces for services belonging to different classes. These

interfaces may be further extended by service vendors in order to support enhanced

features.

Central access point for users is the LMS portal, which does not provide a standard-

ised API but acts as a proxy between users and the LMS services that implement the

functional components of the distributed LMS. The portal hides the complexity of the

underlying system to the user. Thus a new architecture for LMS is defined.

Vendors of existing e-learning environments may enhance their platform step by step

by moving functionality to independent LMS services while integrating these into the

existing LMS portal.

We implemented a selection of LMS services prototypically to prove the feasibility of

our architectural approach. These services were integrated into a single existing LMS

portal to demonstrate their flexibility, configurability and extensibility.

6.2 Related work

There are other approaches to unify LMS APIs: A first step towards the defini-

tion of standardised LMS APIs has been proposed by the Massachusetts Institute of

Technology ”Open Knowledge Initiative” (OKI) which came into existence in 2002

(see [Ope02]). The initiative aims at separating individual LMS subsystems, e.g.,

database access, security, logging, etc., by defining APIs for subsystems communica-

tion. However the OKI initiative concentrates on the development process of learning

management systems and tries to decouple functional components during develop-

152

ment. On deployment the resulting LMS is still a monolithic product - the APIs are

merely used internally.

The OKI initiative does not focus on concepts to support extensibility of LMS or to

enable institutional collaboration. It is basically a modularisation effort to enable LMS

vendors to implement new releases of their LMS systems more efficiently. However

the OKI initiative may be a first step towards an increased independence from system

vendors, as systems are likely to converge when they use the same APIs to connect their

internal subsystems. Viewed from this perspective, OKI may lay the foundations for a

broader adoption of the distributed LMS approach as proposed by our architecture.

6.3 External feedback

The architecture has been presented to Alexander Killing, the Head of Software De-

velopment of the Ilias group,1 in order to receive additional feedback on the general

design.

The Ilias team currently works on a major internal redesign of the system. Future work

will include the introduction of well-known internal APIs to reduce the complexity of

software development, which is especially important for open source software that

usually gets implemented by many distributed developers.

From the Ilias team’s point of view institutional collaboration and personalisation are

currently the major challenges in LMS development. In their opinion the architecture

models a possible way to go for LMS vendors. Basis for that would be the standardisa-

tion of stable service APIs by a well accepted body, e.g., the IEEE. This would enable

vendors to produce services which may then be plugged into existing systems without

having to fear incompatibilities or possible changes of the base interface.

Distribution of the LMS currently is also on the agenda of the Ilias team. However Ilias

1See http://www.ilias.uni-koeln.de/ios/index-e.html for details.

153

will first start by allowing institutions to share search functionality and content (which

is not relevant to this work), because the development team sees the greatest need for

institutional cooperation in these two areas. Major problem in regard to cooperation is

currently the implementation of user-role mapping across institutional boundaries.

Institutional cooperation will probably be realised by using WebServices as middle-

ware platform. In this respect the team will take a closer look at our architectural

approach.

In terms of personalisation, the Ilias team currently works on the interaction between

system components and the portal and looks for possible ways of defining abstract

user-interface requirements. In this context Ilias proposes an extension of our service

interface to allow services to specify their display requirements which are then im-

plemented on demand by the portal. This could be extended to a kind of workflow

definition which would enable the portal to interact with unknown service classes –

even without knowledge of the services interface details.

Summarised, our architectural approach is not at all utopistic. However a complete

virtualisation is probably not needed from the point of view of an LMS vendor. Ilias

would appreciate a common plug-in facility for LMS systems which could be realised

in a distributed fashion. From the LMS vendors’ point of view it is very important to

hide the complexity of such a system from the institutions who plan to use it. This

requirement would demand several additions to the existing architecture as depicted in

section 5.3.

6.4 Future prospects

Future work should include the definition of additional service classes and the incor-

poration of the IMS specifications concerning content display with the aim of unifying

LMS portals. In addition, services dealing with user identities should provide addi-

154

tional interfaces for IMS compliant data exchange with other systems in order to make

system migration easier. In addition, the architecture should be refactured according

to the issues listed in section 5.3.

As WebServices and related technologies develop, an interface redesign with the aim

of an enhanced WebServices support may be interesting. One may also consider imple-

menting business processes which incorporate several LMS services, possibly making

use of emerging technologies like the Business Process Execution Language for Web-

Services (see [ACD+03]). Such processes could be introduced to perform complex

administrative tasks or to associate services that were independent from each other.

This would introduce another layer of abstraction on top of the existing architecture.

The implementation of a process model at this abstraction layer could then be used for

integration of the learning management system with other enterprise software.

155

Bibliography

[ACD+03] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann,

K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana.

Business Process Execution Language for Web Services, Version 1.1, May

2003. http://www-106.ibm.com/developerworks/webservices/library/ws-

bpel/.

[Adv01] Advanced Distributed Learning Initiative. Sharable Content Object Ref-

erence Model Version 1.2 – The SCORM Runtime Environment, Oct 2001.

[Alt91] J. L. Alty. Multimedia – what is it and how do we exploit it? In People

and Computers VI. Proceedings of the HCI’91 Conference, number 3 in

British Computer Society Conference Series, pages 31–44, Cambridge,

1991. Cambridge University Press.

[ANS95] ANSI/NISO. Information Retrieval (Z39.50): Application Service Defi-

nition and Protocol Specification, z39.50-1995 edition, 1995.

[Apa] The Apache Foundation, http://logging.apache.org/log4j/docs/. Log4j

Project.

[ARI02] Ariadne Foundation for the European Knowledge Pool.

http://www.ariadne-eu.org/en/system/index.html, 2002.

[Bak97] Sean Baker. CORBA distributed objects using Orbix. Addison-Wesley,

1997.

156

[Ben88] J. Benjamin. A history of teaching machines. American psychologist,

(43):703–712, 1988.

[BHMH02] P. Baumgartner, H. Haefele, and K. Maier-Haefele. E-Learning Praxis-

handbuch. Auswahl von Lernplattformen. Studien Verlag, Vienna, 2002.

(in German).

[BKKS01] Art Barstow, Jose Kahan, Marja-Riitta Koivunen, and Ralph Swick. An-

notea: A Generic Annotation Environment Using RDF/XML. In Proceed-

ings Of The Tenth International World Wide Web Conference, WWW10.

ACM, 2001.

[EPL02] Robert Elfwing, Ulf Paulsson, and Lars Lundberg. Performance of SOAP

in Web Service Environment Compared to CORBA. In Proceedings of the

Ninth Asia-Pacific Software Engineering Conference (APSEC 02). IEEE,

2002.

[FM90] P. M. Fischer and H. Mandl. Toward a psychophysics of hypermedia. In

D.H. Jonassen and H. Mandl, editors, Designing Hypermedia for Learn-

ing, number 67 in NATO ASI Series. Series F: Computer and Systems

Sciences, pages XIX–XXV. Springer, Berlin/Heidelberg, 1990.

[Gag87] R. M. Gagne, editor. Instructional technology: Foundations, chapter In-

structional Technology: A History, pages 11–48. Lawrence Erlbaum As-

sociates, Hillsdale, NJ, 1987.

[HV99] Michi Henning and Steve Vinoski”. Advanced CORBA Programming with

C++. Addison Wesley, 1999.

[IMS01a] IMS Global Learning Consortium, Inc. IMS Content Packaging Informa-

tion Model, Aug 2001.

157

[IMS01b] IMS Global Learning Consortium, Inc. Using IMS Content Packaging to

Package Instances of LIP and Other IMS Specifications, Aug 2001.

[IMS02] IMS Global Learning Consortium, Inc. IMS Enterprise Information

Model, Jul 2002.

[IMS03] IMS Global Learning Consortium, Inc. IMS Digital Repositories Interop-

erability – Core Functions Information Model, Version 1.0 Final Specifi-

cation, Jan 2003.

[ISO96] ISO/IEC 10181-3: Information technology – open systems interconnec-

tion – security frameworks for open systems: Access control framework,

1996.

[JJ86] R. T. Johnson and D. W. Johnson. Action research: Cooperative learning

in the science classroom. Science and Children, 24:31–32, 1986.

[Jon90] D. H. Jonassen. Towards a constructivist view of instructional design.

Educational Technology, pages 32–34, September 1990.

[Jon91] D. H. Jonassen. Objectivism versus constructivism: Do we need a new

philosophical paradigm? Educational technology: Research & Develop-

ment, (39):5–14, 1991.

[JPW99] D. H. Jonassen, K. L. Peack, and B. G. Wilson. Learning with technology.

A constructivist perspective. Merill - Prentice Hall, Upper Saddle River,

NJ, 1999.

[Ker01] M. Kerres. Multimediale und telemediale Lernumgebungen. Oldenbourg,

Munich, 2001. (in German).

[KR79] E. Konig and H. Riedel. Unterrichtsplanung I. Konstrunktionsgrundlagen

und -kriterien. BELTZ, Weinheim, 1979. (in German).

158

[Lip89] R. C. Lippert. Expert systems: Tutors, tools, and tutees. Journal of

Computer-Based Instruction, 1(16):11–19, 1989.

[LTS02] IEEE Learning Technologies Standards Committee. Learning Object

Metadata (LOM) Standard V1.0, 2002.

[Mic] Microsoft, http://www.microsoft.com/elearn/support.asp. The Microsoft

LRN 3.0 Toolkit.

[MV87] H. Maturana and F. Varela. Der Baum der Erkenntnis, Die biologischen

Wurzeln unserer Erkenntnis. Goldmann, Bern, 1987. (in German).

[NS90] D. Nix and R. Spiro, editors. Cognition, education and multimedia: Ex-

ploring ideas in high technology, chapter Cognitive flexibility, random

access instruction, and hypertext: Theory and technology for non-linear

and multi-dimensional traversal of complex subject matter., pages 163–

205. Lawrence Erlbaum Associates, Hillsdale, NJ, 1990.

[Obj00a] Object Management Group. Property Service Specification, 1st edition,

2000. http://www.omg.org/docs/formal/00-06-22.pdf.

[Obj00b] Object Management Group. Trading Object Service Specification, 1st

edition, 2000. http://www.omg.org/docs/formal/00-06-27.pdf.

[Obj02a] Object Management Group. Common Object Request Bro-

ker Architecture: Core Specification, 3.0 edition, 2002.

http://www.omg.org/docs/formal/02-12-06.pdf.

[Obj02b] Object Management Group. IDL to Java Language Mapping Specifica-

tion, 2002. http://www.omg.org/docs/formal/02-08-05.pdf.

[Obj02c] Object Management Group. Naming Service Specification, 2002.

http://www.omg.org/docs/formal/02-09-02.pdf.

159

[Obj03] Object Management Group. CORBA to WSDL/SOAP Interworking

Specification, 1st edition, 2003. http://www.omg.org/docs/formal/03-11-

02.pdf.

[Ope02] Open Knowledge Initiative, Massachusetts Institute of Tech-

nology. What is the Open Knowledge Initiative?, 2002.

http://web.mit.edu/oki/learn/whtpapers/.

[Pav27] I. P. Pavlov. Conditioned reflexes. Oxford University Press, Oxford, 1927.

[Rie91] H. Riedel. Neufassung eines Modells der Internoperation. Grundlagen-

studien aus Kybernetik und Geisteswissenschaft, (32):16–27, 1991. (in

German).

[Sal79] G. Salomon. Interaction of media, cognition and learning. Jossey-Bass,

San Francisco, 1979.

[Sch03] R. Schulmeister. Lernplattformen fuer das virtuelle Lernen – Evaluation

und Didaktik. Oldenbourg, Munich, 2003. (in German).

[Ski58] B. F. Skinner. Teaching machines. Science, (128):969–977, 1958.

[SSK03] M. Schmid, J. Stynes, and R. Kroeger. Architektur einer dienstebasierten,

personalisierbaren Laufzeitumgebung fuer Lernumgebungen. In A. Bode,

J. Desel, S. Rathmayer, and M. Wessner, editors, DeFLI 2003: Die 1.

e-Learning Fachtagung Informatik, Proceedings, volume P-37 of GI-

Edition Lecture Notes in Informatics, pages 225 – 229. Gesellschaft fuer

Informatik, Koellen Druck+Verlag, Sep 2003. (in German).

[SSK04] M. Schmid, J. Stynes, and R. Kroeger. A Distributed Architecture for

Learning Management Systems Supporting Institutional Collaboration. In

World Conference on Educational Multimedia, Hypermedia and Telecom-

munications (ED-MEDIA), 2004, Proceedings. Association for the Ad-

160

vancement of Computing in Education, Jun 2004. (accepted as full pa-

per).

[Sun] Sun Microsystems, Inc., http://java.sun.com/products/jndi/. The Java

Naming and Directory Interface.

[W3C03] W3C. SOAP Version 1.2 - W3C Recommendation, June 2003.

http://www.w3.org/TR/soap12-part0/.

[W3C04a] W3C. Document Object Model (DOM) Level 3 Core Spec-

ification - Proposed W3C Recommendation, Feb 2004.

http://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/.

[W3C04b] W3C. RDF/XML Syntax Specification - W3C Recommenda-

tion, Feb 2004. http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-

20040210/.

161

Appendix A

Publications

Two papers have been published in connection with this work:

� The first publication ([SSK03]) has been published as a short paper and has been

presented on the first German conference on e-learning and computer science

(DeLFI 2003) in Munich on September 17, 2003.

� The second publication ([SSK04]) has been accepted for publication as a full

paper for the World Conference on Educational Multimedia, Hypermedia &

Telecommunications (ED-MEDIA 2004) in Lugano, Switzerland, June 21-26,

2004.

A-1

Appendix B

Features of existing LMSs

B.1 WebCT

Table B.1: WebCT 3.6 features

FEATURE DESCRIPTION STATUS

USER-ROLE SUPPORT

Authorp

Administratorp

Trainerp

Learnerp

ACCESS CONTROL

Authenticationp

Authorisationp

user & profile mgmt.p

role management Only one role is allowed per userp

Access privileges f. users & rolesp

PORTAL

B-1

continued...


Indexing of course-ware Glossary & index per coursep

cataloguep

summariesp

rankings & comments �

news & announcementsp

search engine, downloads �

personalisable layout & content Users can select the courses to be

displayed on their login page

p

PRESENTATION PLATFORM

browsing of contentp

own comments �

adaptation to local needs Language selectionp

course-ware history �

addition of links, ratings, bookmarks Bookmarks can be set by teachers

and individual learners

p

printable versions, downloads �

COMMUNICATION PLATFORM

E-mailp

Forumsp

Address bookp

Chatp

FAQ �

STANDARD COMPLIANCE

IEEE LOMp

B-2

continued...


IMS No statement, but member of IMS

Global

(�)

SCORM Very basic support: WebCT pro-

vides a script to package content

in a SCORM compliant way.

(�)

B.2 Blackboard

Table B.2: Blackboard features


USER-ROLE SUPPORT

Authorp

Administratorp

Trainerp

Learnerp

ACCESS CONTROL

Authenticationp

Authorisationp


role management Only one role is allowed per userp


PORTAL

Indexing of course-ware �

cataloguep

B-3

continued...


summaries �



search engine, downloads �

personalisable layout & content Users can select courses to be dis-

played on their login page

p



own comments Comments may only be added on

a course basis, not on individual

pages

p

adaptation to local needs Language is configurablep


addition of links, ratings, bookmarks �

printable versions, downloads �


E-mailp

Forums the system supports private

“rooms” for student collaboration

p

Address bookp

Chatp

FAQ �

STANDARD COMPLIANCE

IEEE LOMp

B-4

continued...


IMS Blackboard states that it supports

the IMS specifications

p

SCORM �

B.3 Ilias

Table B.3: Ilias 3 features


USER-ROLE SUPPORT

Authorp

Administratorp

Trainer Not available by default, but flexi-

ble role concept allows addition

p

Learnerp

ACCESS CONTROL

Authenticationp

Authorisationp


role managementp


PORTAL

Indexing of course-warep

cataloguep

summariesp

B-5

continued...




search engine, downloadsp

personalisable layout & content �



own commentsp

adaptation to local needs Several languages for localisation

available

(p

)


addition of links, ratings, bookmarks �

printable versions, downloadsp


E-mailp

Forumsp

Address bookp

Chatp

FAQ �

STANDARD COMPLIANCE

IEEE LOMp

IMSp

SCORMp

B-6

Appendix C

IDL interface definition

C.1 The service base interfaces

C.1.1 The abstract service interface

Listing C.1: The abstract service interface

#ifndef SERVICE_IDL

2 #define SERVICE_IDL

4


6

/**

8 * All service interfaces are located within the eLerningService module.

* They are derived form the interface Service that provides basic functionality

10 * common for all eLearning related services

*

12 * @author Markus Schmid

* @version 1.0

14 */

16 module lmsServices {

18 /**

* The Service interface provides basic functionality common for all

C-1

20 * services.

*


* @version 1.0

24 * @stereotype Idl-Interface

*/

26 abstract interface Service {

28

/**

30 * Provides a way of testing the communication with the service on

* application level

32 */

void ping();

34

readonly attribute string Class;

36 readonly attribute string Subclass;

readonly attribute string Name;

38 readonly attribute string Description;

readonly attribute short Version;

40 readonly attribute string ServiceLocation;

readonly attribute string Id;

42

oneway void initialize();

44 oneway void shutdown();

};

46

struct TServiceInfo {

48 string Serviceclass;

string Subclass;

50 string Name;

string Description;

52 short Version;

string ServiceLocation;

54 string Id;

};

56

58 typedef string TPropertyName;

typedef string TPropertyValue;

60

typedef short TPropertyType;

C-2

62 const short Tboolean = 0;

const short Tfloat = 1;

64 const short Tint = 2;

const short Tstring = 3;

66 const short Tcomplex = 4;

68

/**

70 * @stereotype struct

*/

72

struct TProperty {

74 TPropertyName name;

TPropertyValue value;

76 TPropertyType type;

};

78

80 typedef sequence<TProperty> TProperties;

typedef sequence<TPropertyName> TPropertyNames;

82 typedef sequence<TPropertyValue> TPropertyValues;

};

84 #endif

C.1.2 The abstract infrastructure service interface

Listing C.2: The abstract infrastructure service interface

#ifndef INFRASTRUCTURESERVICE_IDL

2 #define INFRASTRUCTURESERVICE_IDL

4 # pragma prefix "cit.ie"

#include "service.idl"

6 /*

* @author Markus Schmid

8 * @version 1.0

*/

10


12

C-3

14 /**

* Provides common functions for basic services that are used by other

services

16 * Infrastructure services are typically used locally

* @stereotype Idl-Interface

18 */

20 abstract interface InfrastructureService : Service {

};

22

};

24 #endif

C.1.3 The abstract e-learning service interface

Listing C.3: The abstract e-learning service interface

#ifndef ELEARNINGSERVICE_IDL

2 #define ELEARNINGSERVICE_IDL



6

/*


* @version 1.0

10 */


14

/**

16 * Provides common functions for sophisticated services, that are intended

* direct communication with users or agents that represent users


*/

20

abstract interface eLearningService : Service {

22 };

};

24 #endif

C-4

C.1.4 The abstract inner-institutional service interface

Listing C.4: The abstract inner-institutional service interface

#ifndef INNERINSTITUTIONALSERVICE_IDL

2 #define INNERINSTITUTIONALSERVICE_IDL



6

/*


* @version 1.0

10 */


14 /**

* The InnerInstitutionalService interface provides functionality common for

all

16 * services which are solely addressed within an institution.

*


* @version 1.0


*/

22

abstract interface InnerInstitutionalService {

24 };

};

26 #endif

C.1.5 The abstract cross-institutional service interface

Listing C.5: The abstract cross-institutional service interface

#ifndef CROSSINSTITUTIONALSERVICE_IDL

2 #define CROSSINSTITUTIONALSERVICE_IDL



C-5

6

/*


* @version 1.0

10 */


14

16 /**

* The CrossInstitutionalService interface provides functionality common for

all

18 * services which are also addressed accross institution boundaries.

*


* @version 1.0


*/

24 abstract interface CrossInstitutionalService {

readonly attribute string WSReference;

26 };

28

};

30 #endif

C.2 The inferfaces of essential infrastructure services

C.2.1 The lookup service interface

Listing C.6: The lookup service interface

#ifndef LOOKUPSERVICE_IDL

2 #define LOOKUPSERVICE_IDL

4 #include "service.idl"

#include "infrastructureService.idl"

6 #include "innerInstitutionalService.idl"

C-6


10 /*


12 * @version 1.0

*/

14


16

/**

18 * The lookup module hosts interfaces to provide access to the lookup service

*


* @version 1.0

22 */

24

module lookup {

26 typedef boolean TSuccess;

typedef string TRegisterId;

28 typedef string TConstraint;

30 /**

* The TOffer structure represents a result returned by the lookup service

32 *

* @stereotype struct

34 */

struct TOffer {

36 string reference;

string WSReference;

38 lmsServices::TProperties properties;

};

40 typedef sequence<TOffer> TOffers;

42 exception InvalidReference { };

exception InvalidProperties { };

44 exception InvalidClass { };

exception InvalidSubclass { };

46 exception InvalidConstraint { };

48 /**

C-7

* The lookup service interface with operations to register and locate

service references

50 *


52 * @version 1.0


54 */

interface LookupService : InfrastructureService, InnerInstitutionalService

{

56

/**

58 * Register a reference to an LMS service

*

60 * properties have to include the set of standard service properties.

* In addition the method allows services to supply additional

62 * properties, other services may look for when querying the lookup

* service. A service vendor can specify specific properties for all

64 * services offered, which would, e.g., allow to prefer the use of

* services of the same vendor. In case the reference to the service

66 * is invalid, the method throws an InvalidReference

* exception, in case the properties are invalid, it throws

68 * InvalidProperties.

*

70 * @return registration ID

*

72 * @exception InvalidReference is thrown when reference is not a valid

CORBA Object

* @exception InvalidProperties is thrown when a property in the set

is null

74 */

TRegisterId registerService(in string reference,

76 in string WSReference,

in lmsServices::TProperties properties)

78 raises (InvalidReference, InvalidProperties);

80

/**

82 * DeRegister a reference to an LMS service

*

84 * allows services to unregister from the lookup service using the

* ID provided on registration.

86 *

C-8

* @return boolean indicating the success of the operation

88 */

TSuccess unregisterService(in TRegisterId id);

90

/**

92 * send a query to select services with certain properties defined

*

94 * allows services to look for other services with

* certain properties defined. In case a service uses this method to

96 * look for services of a certain class, it can specify the

* "class"-property as part of the array of properties supplied

98 * with the call. Any number of services may be returned by this

* call. In case the properties passed are invalid, the method throws

100 * an InvalidProperties exception.

*

102 * @return sequence of TOffer structs containing the service offers

selected

*

104 * @exception InvalidProperties is thrown when the properties are null

or invalid

*/

106 TOffers queryServicesWithProperties(in lmsServices::TProperties

properties)

raises(InvalidProperties);

108

/**

110 * send a query to select services that fulfill certain constraints

*

112 * allows services to look for other services supplying

* a constraint string which defines in detail how the result should

114 * look like. For example it is possible to look for the cheapest

* search service available at a certain location. Constraints are

116 * to be defined in the CORBA trader service constraint-language In

case

* the constraints defined are invalid, the method throws an

118 * InvalidConstraint exception.

*

120 * @return sequence of TOffer structs containing the service offers

selected

*

122 * @exception InvalidConstraint is thrown when the constraints are

invalid

C-9

*/

124 TOffers queryServicesWithConstraint(in TConstraint constraint)

raises(InvalidConstraint);

126 };

};

128 };

#endif

C.2.2 The logging service interface

Listing C.7: The logging service interface

#ifndef LOGGINGSERVICE_IDL

2 #define LOGGINGSERVICE_IDL





10 /*


12 * @version 1.0

*/

14


16

module logging {

18

/**

20 * The logging service interface enables other services to log data in a

centralised way

*

22 * The interface offers several oneway interfaces (for performance reasons

)

*


* @version 1.0


*/

C-10

28 interface LoggingService : InfrastructureService,

InnerInstitutionalService {

30 /**

* The LogLevel to be specified when using the logging service

32 *

*/

34 enum Level {

LDEBUG,

36 LINFO,

LWARN,

38 LERROR,

LFATAL

40 };

42 /**

* Log request for a debug message

44 *

*/

46 oneway void debug(in TServiceInfo info, in string message);

48 /**

* Log request for a info message

50 *

*/

52 oneway void info(in TServiceInfo info, in string message);

54 /**

* Log request for a warn message

56 *

*/

58 oneway void warn(in TServiceInfo info, in string message);

60 /**

* Log request for a error message

62 *

*/

64 oneway void error(in TServiceInfo info, in string message);

66 /**

* Log request for a fatal error message

68 *

C-11

*/

70 oneway void fatal(in TServiceInfo info, in string message);

72 /**

* General Log request

74 *

*/

76 oneway void log(in TServiceInfo info, in Level loglevel, in string

message);

};

78 };

};

80 #endif

C.2.3 The property service interface

Listing C.8: The property service interface

#ifndef PROPERTYSERVICE_IDL

2 #define PROPERTYSERVICE_IDL





10 /*


12 * @version 1.0

*/

14


16

18 /**

* The property module hosts interfaces and data structures to address a

20 * property service used by other services

*


* @version 1.0

C-12

24 */

26 module property {

typedef boolean TSuccess;

28

/**

30 * Exception thrown when the property name specified is illegal or

undefined

*/

32

exception InvalidPropertyName { };

34

/**

36 * Exception thrown when the property type specified is illegal or

undefined

*/

38

exception InvalidPropertyType { };

40

/**

42 * Exception thrown when the property to be created already exists

*/

44

exception ConflictingProperty { };

46

/**

48 * Exception thrown when the property specified does not exist

*/

50

exception PropertyNotFound { };

52

/**

54 * Enum describing the kind of event that caused the callback

*/

56 enum TEvent {

modified, deleted

58 };

60

/**

62 * Callback interface to be implemented by calling services

*

C-13


*/

66

interface Callback {

68 void notify(in TPropertyName PropertyName, in TEvent event);

};

70

/**

72 * An instance of CBRegistration is returned when a callback is registered

*


*/

76 interface CBRegistration {

void unregister();

78 };

80

82 /**

* The PropertyService interface provides a basic service for storing

84 * and retrieving properties

*


* @version 1.0


*/

90

interface PropertyService : InfrastructureService,

InnerInstitutionalService {

92

/**

94 * Defines a new property and assigns a value to it

*

96 * allows a service to register a property with the

* name specified. The method throws a InvalidPropertyName

98 * exception in case the name specified is invalid or a

* ConflictingProperty exception in case a property with this

100 * name already exists.

*

102 * @exception ConflictingProperty is thrown when the property to be

created already exists

*

C-14

104 * @exception InvalidPropertyName is thrown when the property name

specified is illegal or undefined

*

106 * @exception InvalidPropertyType is thrown when the property type


*/

108

TSuccess defineProperty(in ::lmsServices::TPropertyName propertyName,

110 in ::lmsServices::TPropertyType propertyType,

in ::lmsServices::TPropertyValue propertyValue) raises

112 (InvalidPropertyName, InvalidPropertyType, ConflictingProperty);

114 /**

* Defines a set of new properties and assigns values to them

116 *

* allows a service to define multiple properties in an atomar

118 * operation. The method throwsInvalidPropertyName in case one or more

of the property names

* specified are invalid and ConflictingProperty in case one ore

120 * more property with a conflicting name already exists.

*

122 * @exception ConflictingProperty is thrown when one of the properties

to be created already exists

*

124 * @exception InvalidPropertyName is thrown when a property name


*

126 * @exception InvalidPropertyType is thrown when a property type


*/

128

TSuccess defineProperties(in ::lmsServices::TProperties properties)

raises

130 (InvalidPropertyName, InvalidPropertyType, ConflictingProperty);

132 /**

* Deletes a property name and its assigned value

134 *

* allows a service to delete a property with the name passed. The

method

136 *throws a InvalidPropertyName exception in case the property

*name is invalid and a PropertyNotFound exception in case the

C-15

138 *property specified does not exist.

*

140 * @exception PropertyNotFound is thrown when the property specified

does not exist

*



*/

144

TSuccess deleteProperty(in TPropertyName propertyName) raises

146 (InvalidPropertyName, PropertyNotFound);

148 /**

* Sets the value of an existing property

150 *

* allows to set a new value for an existing

152 * property. The method throws a InvalidPropertyName

* exception in case the property name specified is invalid and a

154 * PropertyNotFound exception in case the property does not

* exist.

156 *

* @exception PropertyNotFound is thrown when the property specified

does not exist

158 *

* @exception InvalidPropertyName is thrown when the property name


160 */

162 TSuccess setPropertyValue(in ::lmsServices::TPropertyName propertyName

, in ::lmsServices::TPropertyType propertyType,

in ::lmsServices::TPropertyValue propertyValue) raises

164 (InvalidPropertyName, PropertyNotFound);

166 /**

* Sets the values of existing properties

168 *

* allows to set new values for a set of existing properties in an

atomar

170 * way. In case one or more of the property names specified is invalid

* the method throws an InvalidPropertyName exception, in case

172 * one of the properties does not exist, it throws a

* PropertyNotFound exception.

C-16

174 *

* @exception PropertyNotFound is thrown when a property specified does

not exist

176 *

* @exception InvalidPropertyName is thrown when a property name


178 */

180 TSuccess setPropertyValues(in ::lmsServices::TProperties properties)

raises

(InvalidPropertyName, PropertyNotFound);

182

/**

184 * Retrieves the value of an existing property

*

186 * allows a service to retrieve the value of a property. In case the

property

* name passed is invalid this method throws an

188 * InvalidPropertyName exception, in case the property does not

* exist it throws a PropertyNotFound exception.

190 *


does not exist

192 *



194 *

* @exception InvalidPropertyType is thrown when the property type of

the property is illegal or undefined

196 */

198 ::lmsServices::TPropertyValue getPropertyValue(in ::lmsServices::

TPropertyName propertyName)

raises(InvalidPropertyName, InvalidPropertyType, PropertyNotFound);

200

/**

202 * Retrieves the type of an existing property

*

204 * @exception PropertyNotFound is thrown when the property specified

does not exist

*

C-17



*

208 * @exception InvalidPropertyType is thrown when the property type of

the property is illegal or undefined

*/

210

::lmsServices::TPropertyType getPropertyType(in ::lmsServices::

TPropertyName propertyName)

212 raises(InvalidPropertyName, InvalidPropertyType, PropertyNotFound);

214

/**

216 * Retrieves the value of existing properties

*

218 * @exception PropertyNotFound is thrown when a property specified does

not exist

*



*

222 * @exception InvalidPropertyType is thrown when a property type of the

property is illegal or undefined

*/

224

::lmsServices::TPropertyValues getPropertyValues(in ::lmsServices::

TPropertyNames propertyNames)

226 raises(InvalidPropertyName, InvalidPropertyType, PropertyNotFound);

228 /**

* Returns true, if a property with the specified name already exists

230 *



232 */

234 boolean isPropertyDefined(in ::lmsServices::TPropertyName propertyName

) raises

(InvalidPropertyName);

236

/**

C-18

238 * Returns true, if all the properties with the specified names already

exist

*



*/

242

boolean arePropertiesDefined(in ::lmsServices::TPropertyNames

propertyNames)

244 raises(InvalidPropertyName);

246 /**

* Registers a callback to enable the property service to notify in

case a property changes

248 *



250 *


does not exist

252 */

254 CBRegistration registerPropertyCallback(in ::lmsServices::

TPropertyName propertyName,

in Callback cb) raises(InvalidPropertyName, PropertyNotFound);

256

/**

258 * Registers a callback to enable the property service to notify in

case a property changes

*



*

262 * @exception PropertyNotFound is thrown when a property specified does

not exist

*/

264

CBRegistration registerPropertiesCallback(in ::lmsServices::

TPropertyNames

266 propertyNames, in Callback cb) raises

(InvalidPropertyName, PropertyNotFound);

268 };

C-19

};

270

};

272 #endif

C.2.4 The security service interfaces

Listing C.9: The security service interfaces

#ifndef SECURITYSERVICE_IDL

2 #define SECURITYSERVICE_IDL



6 #include "crossInstitutionalService.idl"


10 /*


12 * @version 1.0

*/

14


16

/**

18 * The security module hosts interfaces and data structures useful for

security

* and authorisation

20 *


22 * @version 1.0

*/

24

module security {

26

typedef boolean Success;

28

struct TLoginContextHandle {

30 long handle;

TServiceInfo info;

C-20

32 string signature;

};

34

interface AuthorisationService : InfrastructureService,

CrossInstitutionalService {

36 typedef boolean Success;

38 Success isAuthorised(in TLoginContextHandle lch, in string target);

};

40

42 /**

* Exception thrown on invoking an operation with insufficent privileges

44 * @stereotype exception

*/

46

exception NoPrivileges { };

48 exception AuthenticationFailure { };

exception NoSuchUser { };

50

interface LoginCallback {

52 string request(in string what);

};

54

56 /**

* The AuthenticationService interface provides a basic service for

security and authorisation

58 * of users. It supports user roles, user groups and security domains.

*


* @version 1.0


*/

64

interface AuthenticationService : InfrastructureService,

CrossInstitutionalService {

66

/**

68 * allows a user to supply userId

* and password in order to log onto the system. On failure, the

70 * method throws an AuthenticationFailure exception

C-21

*

72 * @exception AuthenticationFailure is thrown

* when the authentication failed for some reason

74 */

TLoginContextHandle loginWithUserIdPassword(in string userId, in

string password) raises (AuthenticationFailure);

76

/**

78 * allows a user to supply userId

* and password in order to log onto the system. In addition,

80 * the calling entity supplies a callback interface, the authentication

* service may use to ask for additional properties. On failure, the

82 * method throws an AuthenticationFailure exception.

*



86 */

TLoginContextHandle loginWithUserIdPasswordCB(in string userId, in

string password, in LoginCallback cb) raises (

AuthenticationFailure);

88

/**

90 * allows a user to log onto the system supplying a callback interface,

* the authentication service may use to ask for additional properties

. On failure, the

92 * method throws an AuthenticationFailure exception.

*



96 */

TLoginContextHandle loginWithCB(in LoginCallback cb) raises (

AuthenticationFailure);

98

/**

100 * allows a service to supply id and key in

* order to log onto the system. On failure, the method throws an

102 * AuthenticationFailure exception.

*



106 */

C-22

TLoginContextHandle loginWithIdKey(in string id, in string key) raises

(AuthenticationFailure);

108

/**

110 * allows a service to supply id and

* key in order to log onto the system. In addition, the calling

112 * entity supplies a callback interface, the authentication service may

* use to ask for additional properties. On failure, the method throws

an

114 * AuthenticationFailure exception.

*



118 */

TLoginContextHandle loginWithIdKeyCB(in string id, in string key, in

LoginCallback cb) raises (AuthenticationFailure);

120

/**

122 * allows a user

* or service to log into the system as guest, i.e, without having any

124 * privileges.

*



128 */

TLoginContextHandle loginAnonymous() raises (AuthenticationFailure);

130

/**

132 * logs off a

* previously logged-on user or service.

134 */

Success logout(in TLoginContextHandle lch);

136

/**

138 * may be used by

* authorisation services to retrieve login data pointed to by the

login

140 * handle.

*

142 * @exception NuSuchUser is thrown

* when the TLoginHandle is invalid or outdated

144 */

C-23

lmsServices::TProperties retrieveLoginDetails(in TLoginContextHandle

lch) raises (NoSuchUser);

146 };

148 };

};

150 #endif

C.3 The interfaces of important e-learning services

C.3.1 The annotation service interface

Listing C.10: The annotation service interface

#ifndef ANNOTATIONSERVICE_IDL

2 #define ANNOTATIONSERVICE_IDL


#include "eLearningService.idl"


#include "securityService.idl"

8


10

/*


* @version 1.0

14 */


18

/**

20 * The annotation module hosts interfaces to access an Annotea compliant

annotation service

*


* @version 1.0

24 */

C-24

26 module annotation {

28 /**

* The annotation service interface with operations to access an annotea

compliant annotation server

30 *


32 * @version 1.0


34 */

36 interface AnnotationService : eLearningService, CrossInstitutionalService

{

typedef boolean TSuccess;

38

/**

40 * Information stored on an annotation

*/

42

struct AnnotationInformation {

44

/**

46 * Numerical ID identifying the anntoation

*/

48

long annotationId;

50

/**

52 * URI of the resource annotated

*/

54

string annotates;

56

/**

58 * Author of the annotation

*/

60

string author;

62

/**

C-25

64 * Context of the annotation (more precise location within the

resource specified by the URI - XPOINTER)

*/

66

string annotationContext;

68

/**

70 * Time the annotation was created

*/

72

string created;

74

/**

76 * Time the annotation was last modified

*/

78

string modified;

80

string bodyURL;

82

};

84

struct AnnotationBody {

86

/**

88 * Numerical ID identifying the anntoation

*/

90 long annotationId;

92 /**

* Content-Type of the annotation body (text or link to external

page)

94 */

boolean contentIsText;

96

/**

98 * Content of the annotation

*/

100 string content;

102 };

C-26

104

typedef sequence<AnnotationInformation> AnnotationInfos;

106

/**

108 * Thrown if an annotation to the resouce was already posted before by

the same user

*/

110

exception ConflictingAnnotation { };

112

/**

114 * Thrown if the annotation information specified is corrupt

*/

116

exception InvalidAnnotationInformation { };

118

/**

120 * Thrown if the annotation body specified is corrupt

*/

122

exception InvalidAnnotationBody { };

124

/**

126 * Thrown is the query string specified is corrupt

*/

128

exception InvalidQueryString { };

130

/**

132 * Thrown if no annotation could be found for the header specified

*/

134

exception NoSuchAnnotation { };

136

/**

138 * Post a new annotation to the service

*

140 * @exception ConflictingAnnotation is thrown if an annotation to the

resouce was already posted before by the same user

*

142 * @exception InvalidAnnotationInformation is thrown if the annotation

header specified is corrupt

C-27

*

144 * @exception InvalidAnnotationBody is thrown if the annotation body

specified is corrupt

*

146 * @exception ::lmsServices::security::NoPrivileges is thrown in case

the user is not allowed to perform this operation

*/

148

AnnotationInformation postAnnotation(in ::lmsServices::security::

TLoginContextHandle lch, in string annotates, in string

annotationContext, in boolean contentIsText, in string content)

150 raises

(ConflictingAnnotation, InvalidAnnotationInformation,

152 InvalidAnnotationBody,::lmsServices::security::NoPrivileges);

154 /**

* Query annotations for the URI given

156 *

* @exception InvalidQueryString is thrown if the url specified is

corrupt

158 *

* @exception ::lmsServices::security::NoPrivileges is thrown in case


160 */

162 AnnotationInfos getAnnotationsForURL(in ::lmsServices::security::

TLoginContextHandle lch,

in string url) raises

164 (InvalidQueryString,::lmsServices::security::NoPrivileges);

166

/**

168 * Query annotation headers for the query string given

*

170 * @exception InvalidQueryString is thrown if the query string

specified is corrupt

*



*/

174

C-28

AnnotationInfos queryAnnotations(in ::lmsServices::security::


176 in string query) raises

(InvalidQueryString,::lmsServices::security::NoPrivileges);

178

/**

180 * Retrieve infrmation on an annotation specified

*

182 * @exception NosuchAnnotation is thrown when there is no anntotation

with this ID

*



*/

186

AnnotationInformation getAnnotation(in ::lmsServices::security::


188 in long annotationId) raises

(NoSuchAnnotation,::lmsServices::security::NoPrivileges);

190

192 /**

* Download annotation body for the annotation specified

194 *

* @exception NoSuchAnnotation is thrown if no annotation could be

found for the header specified

196 *



198 */

200 AnnotationBody downloadAnnotation(in ::lmsServices::security::


in long annotationId) raises

202 (NoSuchAnnotation,

::lmsServices::security::NoPrivileges);

204

/**

206 * Delete the annotation specified

*

208 * @exception NoSuchAnnotation is thrown if no annotation could be

found for the header specified

C-29

*



*/

212

TSuccess deleteAnnotation(in ::lmsServices::security::


214 in long annotationId) raises

(NoSuchAnnotation,

216 ::lmsServices::security::NoPrivileges);

};

218 };

};

220 #endif

C.3.2 The bookmark service interface

Listing C.11: The bookmark service interface

#ifndef BOOKMARKSERVICE_IDL

2 #define BOOKMARKSERVICE_IDL





8


10

/*


* @version 1.0

14 */


18 module bookmark {

20 /**


22 */

C-30

struct TBookmark {

24 string url;

string dateOfCreation;

26 string dateOfLastAccess;

string iconUrl;

28 string charset;

string id;

30 string description;

string categoryId;

32 };

34

typedef sequence<TBookmark> TBookmarks;

36

/**

38 * @stereotype struct

*/

40 struct TCategory {

string dateOfCreation;


string id;

44 };

46

typedef sequence<TCategory> TCategories;

48

50 /**


52 */

54 interface BookmarkService : eLearningService, CrossInstitutionalService {

/**


*/

58 exception InvalidSyntax { };

60

/**


*/

64 exception NoSuchBookmark { };

C-31

66 void addBookmarkFile(in ::lmsServices::security::TLoginContextHandle lch, in

string bookmarkFile) raises(InvalidSyntax,


68

void addBookmark(in ::lmsServices::security::TLoginContextHandle lch,in

string url, in string iconURL, in string charset, in string id, in

string description, in string categoryId) raises (

70 ::lmsServices::security::

NoPrivileges);

72 void deleteBookmark(in ::lmsServices::security::TLoginContextHandle lch, in

string categoryId, in string bookmarkId)

raises(NoSuchBookmark,


76 TCategories getListOfCategories(in ::lmsServices::security::

TLoginContextHandle lch) raises (::lmsServices::security::NoPrivileges);

78 TCategories findInCategories(in ::lmsServices::security::TLoginContextHandle

lch, in string searchphrase) raises (::lmsServices::security::

NoPrivileges);

80 TBookmarks getListOfBookmarks(in ::lmsServices::security::

TLoginContextHandle lch, in string categoryId) raises (::lmsServices::

security::NoPrivileges);

82 TBookmarks findBookmarks(in ::lmsServices::security::TLoginContextHandle lch

, in string searchphrase) raises (::lmsServices::security::NoPrivileges)

;

84 TBookmarks findBookmarksInCategory(in ::lmsServices::security::

TLoginContextHandle lch, in string categoryId,

in string searchphrase) raises (::lmsServices::security::NoPrivileges);

86

string getBookmarksAsFile(in ::lmsServices::security::TLoginContextHandle

lch, in string categoryId) raises (::lmsServices::security::NoPrivileges

);

88 };

};

90 };

#endif

C-32

C.3.3 The ISCORM service interface

Listing C.12: The ISCORM service interface

#ifndef ISCOMSERVICE_IDL

2 #define ISCORMSERVICE_IDL





8


10

/*


* @version 1.0

14 */


18

/**

20 * The iscorm module hosts interfaces to provide access to a scorm service

*


* @version 1.0

24 */

26 module iscorm {

28 /**

* The scorm service interface with operations to access learning object

scorm data

30 *


32 * @version 1.0


34 */

36 interface IScormService : eLearningService, CrossInstitutionalService {

C-33

38 typedef string TBoolean;

40 /**

* Initialise the LMS (first call by SCORM object)

42 *



44 */

46 boolean lmsInitialize(in ::lmsServices::security::TLoginContextHandle

lch, in string empty) raises

(::lmsServices::security::NoPrivileges);

48

/**

50 * Finish communication with the LMS (all resources are cleared

afterwards)

*



*/

54

boolean lmsFinish(in ::lmsServices::security::TLoginContextHandle lch

, in string empty) raises

56 (::lmsServices::security::NoPrivileges);

58 /**

* Retrieve a SCORM property value

60 *



62 */

64 string lmsGetValue(in ::lmsServices::security::TLoginContextHandle lch

, in string property) raises


66

/**

68 * Set a SCORM property value

*



*/

C-34

72

boolean lmsSetValue(in ::lmsServices::security::TLoginContextHandle

lch, in string property,

74 in string value) raises(::lmsServices::security::NoPrivileges);

76 /**

* Commit settings to the LMS

78 *



80 */

82 boolean lmsCommit(in ::lmsServices::security::TLoginContextHandle lch

, in string empty) raises


84

/**

86 * Retrieve last error occurred

*



*/

90

long lmsGetLastError(in ::lmsServices::security::TLoginContextHandle

lch) raises


94 /**

* Retrieve a string explanation to the error number supplied

96 *



98 */

100 string lmsGetErrorString(in ::lmsServices::security::

TLoginContextHandle lch, in long errorNumber)

raises(::lmsServices::security::NoPrivileges);

102

/**

104 * Retrieve a vendor dependent explanation to the error

*

C-35



*/

108

string lmsGetDiagnostic(in ::lmsServices::security::

TLoginContextHandle lch, in long errorNumber) raises


};

112 };

};

114 #endif

C.3.4 The search service interface

Listing C.13: The search service interface

#ifndef SEARCHSERVICE_IDL

2 #define SEARCHSERVICE_IDL





8


10

/*


* @version 1.0

14 */


18

/**

20 * The search module hosts interfaces and data structures to perform searches

on different types of knowledge bases

*


* @version 1.0

24 */

C-36

26 module search {

typedef string TDocumentIdentifier;

28

/**

30 * Element of a search result set


32 */

34 struct TSearchResultElement {

36 /**

* the Number of the search result within the result set

38 */

40 long Id;

42 /**

* the Title of the Search result

44 */

46 string title;

48 /**

* textual description of the search result (summary / abstract)

50 */


54 /**

* further result properties

56 */

58 lmsServices::TProperties properties;

};

60

62

/**

64 * Result set of a search


66 */

C-37

68 typedef sequence<TSearchResultElement> TSearchResultElements;

70 struct TSearchResult {

72

/**

74 * the query string that produces this result set

*/

76

string queryString;

78

/**

80 * the number of results in this set

*/

82

unsigned long numberOfResults;

84

/**

86 * true if the search returned no results

*/

88

boolean empty;

90

/**

92 * Returns a sequence of result elements

*/

94

TSearchResultElements resultElements;

96 };

98

/**

100 * The basic search service interface with operations common for all kinds

of searches

*


* @version 1.0


*/

106

interface SearchService : eLearningService, CrossInstitutionalService {

C-38

108

/**

110 * Thrown in case the query string is invalid or empty

*/

112

exception InvalidQueryString { };

114

/**

116 * Thrown in case of an invalid maximum number of search results

*/

118

exception InvalidMaximumResultNumber { };

120

/**

122 * Thrown in case the search service encounters some internal error

*/

124

exception SearchFault { };

126

/**

128 * Perform a search operation and return a search result

*

130 * @exception InvalidQueryString is thrown in case the query string is

invalid or empty

*

132 * @exception SearchFault is thrown in case the search service

encounters some internal error

*



*/

136

TSearchResult doSearch(in ::lmsServices::security::TLoginContextHandle

lch, in string queryString) raises

138 (InvalidQueryString, SearchFault,


140

/**

142 * Perform a search operation and return a search result of the

maximum size of maxResults elements

*

C-39

144 * @exception InvalidQueryString is thrown in case the query string is

invalid or empty

*

146 * @exception InvalidMaximumResultNumber is thrown in case of an

invalid maximum number of search results

*

148 * @exception SearchFault is thrown in case the search service

encounters some internal error

*



*/

152

TSearchResult doSearchMax(in ::lmsServices::security::

TLoginContextHandle lch, in string queryString,

154 in unsigned short maxResults) raises

(InvalidQueryString, InvalidMaximumResultNumber, SearchFault,


};

158 };

};

160 #endif

C-40

Appendix D

Other source codes

D.1 The modified AXIS CORBAProvider

Listing D.1: Modification to the AXIS CORBAProvider

...

2 /**

* A basic CORBA Provider

4 *

* @author Davanum Srinivas ([email protected])

6 * Modified my Markus Schmid (added support for several name components)

*/

8 public class CORBAProvider extends RPCProvider

{

10 protected static Log log =

LogFactory.getLog(CORBAProvider.class.getName());

12

private static final String DEFAULT_ORB_INITIAL_HOST = "localhost";

14 private static final String DEFAULT_ORB_INITIAL_PORT = "900";

...

16 protected static Log entLog =

LogFactory.getLog(Constants.ENTERPRISE_LOG_CATEGORY);

18

public static final String OPTION_ORB_INITIAL_HOST = "ORBInitialHost";

20 public static final String OPTION_ORB_INITIAL_PORT = "ORBInitialPort";

public static final String OPTION_NAME_ID = "NameID";

22 public static final String OPTION_NAME_KIND = "NameKind";

D-1

public static final String OPTION_INTERFACE_CLASSNAME = "InterfaceClassName";

24 public static final String OPTION_HELPER_CLASSNAME = "HelperClassName";

...

26 protected Object makeNewServiceObject(MessageContext msgContext,

String clsName)

28 throws Exception

{

30 String orbInitialHost = getStrOption(OPTION_ORB_INITIAL_HOST,msgContext.

getService());

if (orbInitialHost == null)

32 orbInitialHost = DEFAULT_ORB_INITIAL_HOST;

String orbInitialPort = getStrOption(OPTION_ORB_INITIAL_PORT,msgContext.

getService());

34 if (orbInitialPort == null)

orbInitialPort = DEFAULT_ORB_INITIAL_PORT;

36 String nameId = getStrOption(OPTION_NAME_ID,msgContext.getService());

String nameKind = getStrOption(OPTION_NAME_KIND,msgContext.getService());

38 String helperClassName = getStrOption(OPTION_HELPER_CLASSNAME,msgContext.

getService());

40 Properties orbProps = new Properties();

orbProps.put("org.omg.CORBA.ORBInitialHost", orbInitialHost);

42 orbProps.put("org.omg.CORBA.ORBInitialPort", orbInitialPort);

ORB orb = ORB.init(new String[0], orbProps);

44 NamingContext root = NamingContextHelper.narrow(orb.

resolve_initial_references("NameService"));

46 /* MS

* Added to allow any number of Naming-Context components in a Name

delimited by /

48 */

50 java.util.StringTokenizer nct = new java.util.StringTokenizer(nameId, "/")

;

org.omg.CosNaming.NameComponent [] ncs;

52 int tokens = nct.countTokens();

54 ncs = new org.omg.CosNaming.NameComponent[tokens];

56 for (int i = 0; i < tokens; i++) {

org.omg.CosNaming.NameComponent nc = new org.omg.CosNaming.

NameComponent(nct.nextToken(), nameKind);

D-2

58 ncs[i] = nc;

}

60

/* MS End

62 */

64 org.omg.CORBA.Object corbaObject = root.resolve(ncs);

try {

66 Class helperClass = ClassUtils.forName(helperClassName);

Method narrowMethod = helperClass.getMethod("narrow", new Class[] {org

.omg.CORBA.Object.class});

68 Object targetObject = narrowMethod.invoke(null, new Object[] {

corbaObject});

return targetObject;

70 }

catch (Exception e) {

72 e.printStackTrace();

throw(e);

74 }

}

D.2 The portal login procedure

Listing D.2: Run-Time Environment access of the LMS authentication service

...

2 LMSServices.TLoginContextHandle lch = null;

LMSServices.AuthenticationService[] authServices = new LMSServices.

AuthenticationService[0];

4 authServices = connector.getAuthenticationServices();

if (authServices != null)

6 {

for (int i = 0; i < authServices.length; i++) {

8 try

{

10 lch = authServices[i].loginWithUserIdPassword(UserName, Password);

if (lch != null) {

12 session.putValue("USERID", UserName);

session.putValue("LOGINCONTEXTHANDLE", lch);

14 //Default values

D-3

session.putValue("FIRSTNAME", new String());

16 session.putValue("LASTNAME", new String());

session.putValue("RTEADMIN", new String("false"));

18 session.putValue("USERDOMAIN", new String());

//Check for actual values and overwrite default

20 LMSServices.TProperty[] loginProperties = new LMSServices.

TProperty[0];

loginProperties = authServices[i].retrieveLoginDetails(lch);

22 for (int j = 0; j < loginProperties.length; j++) {

if (loginProperties[j].getName().equals("firstname"))

24 session.putValue("FIRSTNAME", loginProperties[j].

getValue());

if (loginProperties[j].getName().equals("lastname"))

26 session.putValue("LASTNAME", loginProperties[j].

getValue());

if (loginProperties[j].getName().equals("admin"))

28 session.putValue("RTEADMIN", loginProperties[j].

getValue());

if (loginProperties[j].getName().equals("location"))

30 session.putValue("USERDOMAIN", loginProperties[j].

getValue());

}

32 action = null;

break;

34 }

}

36 catch (LMSServices.NoPrivileges ex)

{

38 action = "invalidpwd";

break;

40 }

catch (Exception ex)

42 {

ex.printStackTrace();

44 //service not available - skip and ignore

}

46 }

}

48 ...

D-4

D.3 The Greenstone IDL interface

Listing D.3: The Greenstone IDL interface

// basic elements for text

2

module gsdlInterface {

4

typedef sequence<unsigned short> usString;

6

typedef sequence<string> stringSeq;

8

struct corbatext_t

10 {

usString text;

12 unsigned short encoding;

unsigned long length;

14 };

16 typedef sequence<corbatext_t> corbatext_tarray;

18 typedef corbatext_tarray corbatext_tset;

20 struct corbatext_tmap

{

22 corbatext_tarray names;

corbatext_tarray values;

24 };

26 // standard error values

28 enum corbaComError

{ corbaNoError,

30 corbaAuthenticationFailure,

corbaProtocolError,

32 corbaConfigurationError,

corbaSystemProblem

34 };

36 //

// getColInfo response

38 //

D-5

40 struct corbaShortColInfo

{

42 corbatext_t name;

corbatext_t host;

44 long response;

};

46

struct corbaColInfoResponse

48 {

corbaShortColInfo shoftInfo;

50 boolean isPublic;

boolean isBeta;

52 unsigned long buildDate;

corbatext_tarray ccsCols; // Added 05/04/2000

54 corbatext_tarray languages;

unsigned long numDocs;

56 unsigned long numWords;

unsigned long numBytes;

58 corbatext_tmap collectionMeta;

corbatext_tmap format;

60 corbatext_tmap building;

corbatext_t httpdomain ; // Added 27/07/2000

62 corbatext_t httpprefix; // Added 27/07/2000

corbatext_t receptionist;

64 };

66 //

// getDocument request

68 //

70 struct corbaDocRequest

{

72 corbatext_t OID;

corbatext_t docType;

74 corbatext_t docFormat;

};

76

//

78 // getDocument response

//

80

D-6

struct corbaDocResponse

82 {

corbatext_t doc;

84 };

86 enum corbaFilterType

{

88 booleanType,

integerType,

90 enumeratedType,

stringType

92 };

94 enum corbaFilterRepeatable

{

96 onePerQuery,

onePerTerm,

98 nPerTerm

};

100

struct corbaFilterOption

102 {

corbatext_t name;

104 corbaFilterType type;

corbaFilterRepeatable repeatable;

106 corbatext_t defaultValue;

corbatext_tarray validValues;

108 };

110 typedef sequence<corbaFilterOption> corbaFilterOptionList;

112 struct corbaFilterOptionsResponse

{

114 corbaFilterOptionList options;

corbatext_tarray names;

116 };

118 //

// structures for filter call

120 //

122 struct corbaOptionValue

D-7

{

124 corbatext_t name;

corbatext_t value;

126 };

128 typedef sequence<corbaOptionValue> corbaOptionValue_array;

130 struct corbaFilterRequest

{

132 corbatext_t filter;

corbaOptionValue_array filterOptions;

134 corbatext_tarray docSet;

long filterResultOptions;

136 corbatext_t requestParams;

corbatext_t refParams;

138 corbatext_tset fields;

boolean getParents;

140 };

142 struct corbaTermInfo

{

144 corbatext_t term;

long frequency;

146 corbatext_tarray matchTerms;

};

148

typedef sequence<corbaTermInfo> corbaTermInfo_array;

150

struct corbaMetadataInfo

152 {

corbatext_t params;

154 boolean isRef;

corbatext_tarray values;

156 long id;

long parentid; // dodge for avoiding pointers for the moment

158 };

160 typedef sequence<corbaMetadataInfo> corbaMetadataInfo_array;

162 struct corbaMetadataInfo_map

{

164 corbatext_tarray names;

D-8

corbaMetadataInfo_array values;

166 };

168 typedef sequence<long> corbaDocFreq_array;

170 struct corbaResultDocInfo

{

172 corbatext_t OID;

long resultNum;

174 long ranking;

long termsMatched;

176 long phraseMatched;

corbaDocFreq_array docFreq;

178 corbaMetadataInfo_map metadata;

corbatext_t classifierMetadataType; // Added 05/04/2000

180 long classifierMetadataOffset; // Added 05/04/2000

corbaMetadataInfo_array metaparents;

182 };

184 typedef sequence<corbaResultDocInfo> corbaResultDocInfo_array;

186 enum corbaIsApprox

{

188 resultExact,

resultApprox,

190 resultMany

};

192

struct corbaFilterResponse

194 {

long numDocs;

196 corbaIsApprox isApprox;

corbaTermInfo_array termInfo;

198 corbaResultDocInfo_array docInfo;

};

200

interface corbaiface

202 {

boolean initialise(inout corbaComError error);

204 void configure(in corbatext_t key, in corbatext_tarray cfgline,

inout corbaComError error);

206 void collectionList(inout corbatext_tarray collist,

D-9


208 void hasCollection(in corbatext_t corbaCollection, inout boolean has,


210 void ping(in corbatext_t collection, inout boolean wasSuccess, inout

corbaComError error);

void getDocument(in corbatext_t collection,

212 inout corbaDocRequest request, inout corbaDocResponse

response,


214 void getCollectInfo(in corbatext_t collection,

inout corbaColInfoResponse response,

216 inout corbaComError error);

void getFilterInfo(in corbatext_t collection,

218 inout corbatext_tarray filterNames,


220 void getFilterOptions(in corbatext_t collection,

in corbatext_t option,

222 inout corbaFilterOptionsResponse response,


224 void filter(in corbatext_t collection,

in corbaFilterRequest request,

226 inout corbaFilterResponse response,


228 };

230 };

D-10