a service-based architecture for learning management ... · the distributed lms are called...
Post on 24-Jul-2020
2 Views
Preview:
TRANSCRIPT
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
API CALL DESCRIPTION
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
API CALL DESCRIPTION
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...
API CALL DESCRIPTION
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
3.4.2.1 Functional components
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.
3.4.2.2 Personalisation
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.
3.4.2.3 Collaboration
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
3.4.3.1 Functional components
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.
3.4.3.2 Personalisation
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.
3.4.3.3 Collaboration
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
3.4.4.1 Functional components
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.
3.4.4.2 Personalisation
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.
3.4.4.3 Collaboration
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
� 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
interfacelmsServices::Service
+Class:string+Subclass:string+Name:string+Description:string+Version:short+ServiceLocation:string+Id:string
+ping:void+initialize:void+shutdown:void
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.
4.3.4.5 Dependencies and interactions with other services
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
interfacelmsServices::Service
+Class:string+Subclass:string+Name:string+Description:string+Version:short+ServiceLocation:string+Id:string
+ping:void+initialize:void+shutdown:void
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.
4.4.1.7 Dependencies and interactions with other services
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 <!-- This is an automatically generated file.
It will be read and overwritten.
4 DO NOT EDIT! -->
<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
4.4.2.4 Dependencies and interactions with other services
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.
4.4.3.3 Dependencies and interactions with other services
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
4.4.4.3 Dependencies and interactions with other services
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"/>
64 </wsdl:operation>
<wsdl:operation name="ServiceLocation">
66 <wsdl:input message="impl:ServiceLocationRequest" name="
ServiceLocationRequest"/>
<wsdl:output message="impl:ServiceLocationResponse" name="
ServiceLocationResponse"/>
68 </wsdl:operation>
<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"/>
82 </wsdl:operation>
</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">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/LMSService" use="
113
encoded"/>
94 </wsdl:output>
</wsdl:operation>
96 <wsdl:operation name="Version">
<wsdlsoap:operation soapAction=""/>
98 <wsdl:input name="VersionRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lmsServices" use="encoded"/>
100 </wsdl:input>
102 <wsdl:output name="VersionResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/LMSService" use="
encoded"/>
104 </wsdl:output>
</wsdl:operation>
106 <wsdl:operation name="Subclass">
<wsdlsoap:operation soapAction=""/>
108 <wsdl:input name="SubclassRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lmsServices" use="encoded"/>
110 </wsdl:input>
112 <wsdl:output name="SubclassResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/LMSService" use="
encoded"/>
114 </wsdl:output>
</wsdl:operation>
116 <wsdl:operation name="Description">
<wsdlsoap:operation soapAction=""/>
118 <wsdl:input name="DescriptionRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lmsServices" use="encoded"/>
120 </wsdl:input>
122 <wsdl:output name="DescriptionResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/LMSService" use="
encoded"/>
124 </wsdl:output>
</wsdl:operation>
114
126 <wsdl:operation name="ServiceLocation">
<wsdlsoap:operation soapAction=""/>
128 <wsdl:input name="ServiceLocationRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lmsServices" use="encoded"/>
130 </wsdl:input>
132 <wsdl:output name="ServiceLocationResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/LMSService" use="
encoded"/>
134 </wsdl:output>
</wsdl:operation>
136 <wsdl:operation name="Id">
<wsdlsoap:operation soapAction=""/>
138 <wsdl:input name="IdRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lmsServices" use="encoded"/>
140 </wsdl:input>
142 <wsdl:output name="IdResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/LMSService" use="
encoded"/>
144 </wsdl:output>
</wsdl:operation>
146 <wsdl:operation name="ping">
<wsdlsoap:operation soapAction=""/>
148 <wsdl:input name="pingRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lmsServices" use="encoded"/>
150 </wsdl:input>
152 <wsdl:output name="pingResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/LMSService" use="
encoded"/>
154 </wsdl:output>
</wsdl:operation>
156 <wsdl:operation name="Class">
<wsdlsoap:operation soapAction=""/>
158 <wsdl:input name="ClassRequest">
115
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lmsServices" use="encoded"/>
160 </wsdl:input>
162 <wsdl:output name="ClassResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/LMSService" use="
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
Service implementation
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]
doSearch("e-learning")
[results]
[results]
doSearch("e-learning")
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.
Service implementation
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
Service implementation
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.
Service implementation
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...
FEATURE DESCRIPTION STATUS
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...
FEATURE DESCRIPTION STATUS
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
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
Indexing of course-ware �
cataloguep
B-3
continued...
FEATURE DESCRIPTION STATUS
summaries �
rankings & comments �
news & announcementsp
search engine, downloads �
personalisable layout & content Users can select courses to be dis-
played on their login page
p
PRESENTATION PLATFORM
browsing of contentp
own comments Comments may only be added on
a course basis, not on individual
pages
p
adaptation to local needs Language is configurablep
course-ware history �
addition of links, ratings, bookmarks �
printable versions, downloads �
COMMUNICATION PLATFORM
E-mailp
Forums the system supports private
“rooms” for student collaboration
p
Address bookp
Chatp
FAQ �
STANDARD COMPLIANCE
IEEE LOMp
B-4
continued...
FEATURE DESCRIPTION STATUS
IMS Blackboard states that it supports
the IMS specifications
p
SCORM �
B.3 Ilias
Table B.3: Ilias 3 features
FEATURE DESCRIPTION STATUS
USER-ROLE SUPPORT
Authorp
Administratorp
Trainer Not available by default, but flexi-
ble role concept allows addition
p
Learnerp
ACCESS CONTROL
Authenticationp
Authorisationp
user & profile mgmt.p
role managementp
Access privileges f. users & rolesp
PORTAL
Indexing of course-warep
cataloguep
summariesp
B-5
continued...
FEATURE DESCRIPTION STATUS
rankings & comments �
news & announcementsp
search engine, downloadsp
personalisable layout & content �
PRESENTATION PLATFORM
browsing of contentp
own commentsp
adaptation to local needs Several languages for localisation
available
(p
)
course-ware history �
addition of links, ratings, bookmarks �
printable versions, downloadsp
COMMUNICATION PLATFORM
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
# pragma prefix "cit.ie"
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.
*
22 * @author Markus Schmid
* @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
module lmsServices {
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
4 # pragma prefix "cit.ie"
#include "service.idl"
6
/*
8 * @author Markus Schmid
* @version 1.0
10 */
12 module lmsServices {
14
/**
16 * Provides common functions for sophisticated services, that are intended
* direct communication with users or agents that represent users
18 * @stereotype Idl-Interface
*/
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
4 # pragma prefix "cit.ie"
#include "service.idl"
6
/*
8 * @author Markus Schmid
* @version 1.0
10 */
12 module lmsServices {
14 /**
* The InnerInstitutionalService interface provides functionality common for
all
16 * services which are solely addressed within an institution.
*
18 * @author Markus Schmid
* @version 1.0
20 * @stereotype Idl-Interface
*/
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
4 # pragma prefix "cit.ie"
#include "service.idl"
C-5
6
/*
8 * @author Markus Schmid
* @version 1.0
10 */
12 module lmsServices {
14
16 /**
* The CrossInstitutionalService interface provides functionality common for
all
18 * services which are also addressed accross institution boundaries.
*
20 * @author Markus Schmid
* @version 1.0
22 * @stereotype Idl-Interface
*/
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
8 # pragma prefix "cit.ie"
10 /*
* @author Markus Schmid
12 * @version 1.0
*/
14
module lmsServices {
16
/**
18 * The lookup module hosts interfaces to provide access to the lookup service
*
20 * @author Markus Schmid
* @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 *
* @author Markus Schmid
52 * @version 1.0
* @stereotype Idl-Interface
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
4 #include "service.idl"
#include "infrastructureService.idl"
6 #include "innerInstitutionalService.idl"
8 # pragma prefix "cit.ie"
10 /*
* @author Markus Schmid
12 * @version 1.0
*/
14
module lmsServices {
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
)
*
24 * @author Markus Schmid
* @version 1.0
26 * @stereotype Idl-Interface
*/
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
4 #include "service.idl"
#include "infrastructureService.idl"
6 #include "innerInstitutionalService.idl"
8 # pragma prefix "cit.ie"
10 /*
* @author Markus Schmid
12 * @version 1.0
*/
14
module lmsServices {
16
18 /**
* The property module hosts interfaces and data structures to address a
20 * property service used by other services
*
22 * @author Markus Schmid
* @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
64 * @stereotype Idl-Interface
*/
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
*
74 * @stereotype Idl-Interface
*/
76 interface CBRegistration {
void unregister();
78 };
80
82 /**
* The PropertyService interface provides a basic service for storing
84 * and retrieving properties
*
86 * @author Markus Schmid
* @version 1.0
88 * @stereotype Idl-Interface
*/
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
specified is illegal or undefined
*/
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
specified is illegal or undefined
*
126 * @exception InvalidPropertyType is thrown when a property type
specified is illegal or undefined
*/
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
*
142 * @exception InvalidPropertyName is thrown when the property name
specified is illegal or undefined
*/
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
specified is illegal or undefined
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
specified is illegal or undefined
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 *
* @exception PropertyNotFound is thrown when the property specified
does not exist
192 *
* @exception InvalidPropertyName is thrown when the property name
specified is illegal or undefined
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
206 * @exception InvalidPropertyName is thrown when the property name
specified is illegal or undefined
*
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
*
220 * @exception InvalidPropertyName is thrown when a property name
specified is illegal or undefined
*
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 *
* @exception InvalidPropertyName is thrown when the property name
specified is illegal or undefined
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
*
240 * @exception InvalidPropertyName is thrown when a property name
specified is illegal or undefined
*/
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 *
* @exception InvalidPropertyName is thrown when the property name
specified is illegal or undefined
250 *
* @exception PropertyNotFound is thrown when the property specified
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
*
260 * @exception InvalidPropertyName is thrown when a property name
specified is illegal or undefined
*
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
4 #include "service.idl"
#include "infrastructureService.idl"
6 #include "crossInstitutionalService.idl"
8 # pragma prefix "cit.ie"
10 /*
* @author Markus Schmid
12 * @version 1.0
*/
14
module lmsServices {
16
/**
18 * The security module hosts interfaces and data structures useful for
security
* and authorisation
20 *
* @author Markus Schmid
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.
*
60 * @author Markus Schmid
* @version 1.0
62 * @stereotype Idl-Interface
*/
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.
*
84 * @exception AuthenticationFailure is thrown
* when the authentication failed for some reason
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.
*
94 * @exception AuthenticationFailure is thrown
* when the authentication failed for some reason
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.
*
104 * @exception AuthenticationFailure is thrown
* when the authentication failed for some reason
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.
*
116 * @exception AuthenticationFailure is thrown
* when the authentication failed for some reason
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.
*
126 * @exception AuthenticationFailure is thrown
* when the authentication failed for some reason
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
4 #include "service.idl"
#include "eLearningService.idl"
6 #include "crossInstitutionalService.idl"
#include "securityService.idl"
8
# pragma prefix "cit.ie"
10
/*
12 * @author Markus Schmid
* @version 1.0
14 */
16 module lmsServices {
18
/**
20 * The annotation module hosts interfaces to access an Annotea compliant
annotation service
*
22 * @author Markus Schmid
* @version 1.0
24 */
C-24
26 module annotation {
28 /**
* The annotation service interface with operations to access an annotea
compliant annotation server
30 *
* @author Markus Schmid
32 * @version 1.0
* @stereotype Idl-Interface
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
the user is not allowed to perform this operation
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
*
172 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
174
C-28
AnnotationInfos queryAnnotations(in ::lmsServices::security::
TLoginContextHandle lch,
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
*
184 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
186
AnnotationInformation getAnnotation(in ::lmsServices::security::
TLoginContextHandle lch,
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 *
* @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
198 */
200 AnnotationBody downloadAnnotation(in ::lmsServices::security::
TLoginContextHandle lch,
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
*
210 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
212
TSuccess deleteAnnotation(in ::lmsServices::security::
TLoginContextHandle lch,
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
4 #include "service.idl"
#include "eLearningService.idl"
6 #include "crossInstitutionalService.idl"
#include "securityService.idl"
8
# pragma prefix "cit.ie"
10
/*
12 * @author Markus Schmid
* @version 1.0
14 */
16 module lmsServices {
18 module bookmark {
20 /**
* @stereotype struct
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;
42 string description;
string id;
44 };
46
typedef sequence<TCategory> TCategories;
48
50 /**
* @stereotype Idl-Interface
52 */
54 interface BookmarkService : eLearningService, CrossInstitutionalService {
/**
56 * @stereotype exception
*/
58 exception InvalidSyntax { };
60
/**
62 * @stereotype exception
*/
64 exception NoSuchBookmark { };
C-31
66 void addBookmarkFile(in ::lmsServices::security::TLoginContextHandle lch, in
string bookmarkFile) raises(InvalidSyntax,
::lmsServices::security::NoPrivileges);
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,
74 ::lmsServices::security::NoPrivileges);
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
4 #include "service.idl"
#include "eLearningService.idl"
6 #include "crossInstitutionalService.idl"
#include "securityService.idl"
8
# pragma prefix "cit.ie"
10
/*
12 * @author Markus Schmid
* @version 1.0
14 */
16 module lmsServices {
18
/**
20 * The iscorm module hosts interfaces to provide access to a scorm service
*
22 * @author Markus Schmid
* @version 1.0
24 */
26 module iscorm {
28 /**
* The scorm service interface with operations to access learning object
scorm data
30 *
* @author Markus Schmid
32 * @version 1.0
* @stereotype Idl-Interface
34 */
36 interface IScormService : eLearningService, CrossInstitutionalService {
C-33
38 typedef string TBoolean;
40 /**
* Initialise the LMS (first call by SCORM object)
42 *
* @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
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)
*
52 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
54
boolean lmsFinish(in ::lmsServices::security::TLoginContextHandle lch
, in string empty) raises
56 (::lmsServices::security::NoPrivileges);
58 /**
* Retrieve a SCORM property value
60 *
* @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
62 */
64 string lmsGetValue(in ::lmsServices::security::TLoginContextHandle lch
, in string property) raises
(::lmsServices::security::NoPrivileges);
66
/**
68 * Set a SCORM property value
*
70 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
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 *
* @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
80 */
82 boolean lmsCommit(in ::lmsServices::security::TLoginContextHandle lch
, in string empty) raises
(::lmsServices::security::NoPrivileges);
84
/**
86 * Retrieve last error occurred
*
88 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
90
long lmsGetLastError(in ::lmsServices::security::TLoginContextHandle
lch) raises
92 (::lmsServices::security::NoPrivileges);
94 /**
* Retrieve a string explanation to the error number supplied
96 *
* @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
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
106 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
108
string lmsGetDiagnostic(in ::lmsServices::security::
TLoginContextHandle lch, in long errorNumber) raises
110 (::lmsServices::security::NoPrivileges);
};
112 };
};
114 #endif
C.3.4 The search service interface
Listing C.13: The search service interface
#ifndef SEARCHSERVICE_IDL
2 #define SEARCHSERVICE_IDL
4 #include "service.idl"
#include "eLearningService.idl"
6 #include "crossInstitutionalService.idl"
#include "securityService.idl"
8
# pragma prefix "cit.ie"
10
/*
12 * @author Markus Schmid
* @version 1.0
14 */
16 module lmsServices {
18
/**
20 * The search module hosts interfaces and data structures to perform searches
on different types of knowledge bases
*
22 * @author Markus Schmid
* @version 1.0
24 */
C-36
26 module search {
typedef string TDocumentIdentifier;
28
/**
30 * Element of a search result set
* @stereotype struct
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 */
52 string description;
54 /**
* further result properties
56 */
58 lmsServices::TProperties properties;
};
60
62
/**
64 * Result set of a search
* @stereotype struct
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
*
102 * @author Markus Schmid
* @version 1.0
104 * @stereotype Idl-Interface
*/
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
*
134 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
136
TSearchResult doSearch(in ::lmsServices::security::TLoginContextHandle
lch, in string queryString) raises
138 (InvalidQueryString, SearchFault,
::lmsServices::security::NoPrivileges);
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
*
150 * @exception ::lmsServices::security::NoPrivileges is thrown in case
the user is not allowed to perform this operation
*/
152
TSearchResult doSearchMax(in ::lmsServices::security::
TLoginContextHandle lch, in string queryString,
154 in unsigned short maxResults) raises
(InvalidQueryString, InvalidMaximumResultNumber, SearchFault,
156 ::lmsServices::security::NoPrivileges);
};
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 (dims@yahoo.com)
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
inout corbaComError error);
208 void hasCollection(in corbatext_t corbaCollection, inout boolean has,
inout corbaComError error);
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,
inout corbaComError error);
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,
inout corbaComError error);
220 void getFilterOptions(in corbatext_t collection,
in corbatext_t option,
222 inout corbaFilterOptionsResponse response,
inout corbaComError error);
224 void filter(in corbatext_t collection,
in corbaFilterRequest request,
226 inout corbaFilterResponse response,
inout corbaComError error);
228 };
230 };
D-10
top related