An Easy Way to Integrate SCORM Compliancy into Component based Learning Management Systems Pascal Bauler, Fernand Feltz, Nicolas Médoc, Wilfried Vandenberghe Centre de Recherche Public – Gabriel Lippmann Cellule de Recherche, d’Etude et de Développement en Informatique 162a, Avenue de la Faïencerie L-1511 Luxembourg
[email protected] [email protected] [email protected] [email protected] One of the most promising integration efforts of several emerging e-Learning standards was realised by the Advanced Distributed Learning (ADL) initiative, financed by the US Office of the Secretary of Defence. It resulted in the Shared Content Object Reference Model (SCORM) [8], which during the past years gained enough industry support to become the de-facto standard in e-Learning.
ABSTRACT This paper presents a general architecture on how to integrate SCORM compliancy into a component based Learning Management System (LMS), by partially reusing existing ADL libraries. It also explains how the ADL specifications influence the design choices and it illustrates the final architecture in a practical example by describing the integration of the SCORM component into OpenUSS. Key characteristics of this architecture are its modularity and its readiness to support new versions of the SCORM reference model with the possibility to integrate adaptive e-Learning techniques at a later time. This new architecture was designed and implemented in the context of a research project realised at the Centre de Recherche Public – Gabriel Lippmann.
This paper shows a new approach on how to integrate SCORM compliancy into component based LMSs. A key benefit of this new architecture is its reusability, which is validated in practice by adding SCORM compliancy into an open-source platform. The complete system is currently used to support the evening courses organised by the Luxembourg Lifelong Learning Center (LLLC). The LLLC is the most important institute for lifelong learning in Luxembourg, with 4000 subscriptions per year.
KEY WORDS e-Learning, Learning Objects, Architecture, Standards, SCORM, Open-Source
2 General approach 1 Introduction
2.1 Keeping control of the complexity
During the past years the e-Learning community developed a strong need for open and flexible standards, and for independency between course authoring and content distribution by means of Learning Management Systems (LMS) through Internet technologies. Due to the high cost related to content development, content reuse and especially fine-grained content reuse became an important topic, finally leading to the concept of learning objects [1], [2]. Several of those initiatives resulted in standards like IMS [3], AICC [4], LOM [5], Ariadne [6], Dublin Core [7]…. However none of those standardisation efforts succeeded in providing an overall solution. It became clear that only a combination of several technologies could meet the needs mentioned above.
Integrating SCORM compatibility into a LMS is usually considered as being a complex and resource intensive operation. In addition SCORM is an evolving reference model, which is enhanced and improved on a regular basis. This is even stressed by the changing of the SCORM version numbering, allowing the various subcomponents to evolve independently [9]. As a consequence a key objective of a modular integration approach is to avoid the re-implementation of the SCORM specification and to rather limit the development efforts to the integration part. Meeting this objective is facilitated by ADL, who made a reference SCORM implementation freely available in the form of the SampleRTE1 [10]. The ADL SampleRTE is 1
Sample Run-Time Environment, a SCORM reference implementation provided by ADL 461-087
177
not a full functional LMS, but it contains several interesting libraries implementing SCORM specific parts. Tasks like manifest validation or course imports, which are not performance critical, can be reused without major modifications to the ADL libraries. However, operations accessed by many users, such as course navigation, communication between LMS and learning objects (defined as Shared Content Objects (SCO) in the ADL specifications) have to be adapted and optimised in order to deliver satisfying performance in high load environments. In general, the ADL libraries are very useful and they highly reduce the development efforts. The main development task consists in conceiving a wrapper architecture build around the SCORM libraries, which is easy to integrate into an existing LMS.
Presentation Layer LMS front-end
Specification Layer Abstract Interface between Presentation and Business Layer
Business Layer SCORM Content aggregation ADL libraries
SCORM Runtime Environment
Persistency layer Database
Filesystem
Figure 1: General architecture of the SCORM component
2.2 A Component based architecture In order to facilitate integration into an existing LMS, modularity is a key aspect. The proposed architecture designs an independent component, which is supposed to be flexible enough to integrate into Web enabled LMSs. For sure, some adjustments are required at presentation level, but those changes are minor compared to the overall solution. From a technical point of view, our developments are based on the Enterprise Java Open Source Architecture (EJOSA) [11], which describes an effective way to realise complex Enterprise Java applications.
2.3 Flexibility for future reuse. As SCORM [12] is constantly and rapidly evolving, a key aspect of the proposed architecture is flexibility required to easily adapt and to support new releases of the SCORM reference model. Some adaptations remain mandatory to fit to a new SCORM version, but these changes should be limited to extending parts of the wrapper components to handle the newly added features. For instance the changes required for supporting SCORM 2004 [13] consist in extending the sequencing engine [14] to take the new sequencing rules introduces in SCORM 2004 into account. Currently only a few SCORM 2004 compliant contents are available, and the content developers will take some time to shift to SCORM 2004. As a consequence the proposed solution has to be flexible enough to host, within a single LMS, contents build around different SCORM versions.
The Enterprise Java Open Source Architecture (EJOSA) The EJOSA architecture supports the effective development of J2EE2 based web applications and consists in subdividing complex components into four layers. The presentation layer (layer 1), delivers WEB based front-ends. It accesses the business logic (layer 3) realised using Enterprise Java Bean technologies through a specification middleware (layer 2). The fourth layer guarantees data persistency by storing relevant information into a database system. The same four layers are also present in the SCORM component, where the proposed architecture puts the focus onto the business and onto the specification layer. The business layer implements the wrapper components build around the ADL libraries. The specification layer contains no special logic but acts as an interface to decouple the presentation and the business layer. A more detailed explanation of the overall architecture is shown in the 3rd chapter giving in-depth explanations. The general architecture is shown on figure 1.
3 In depth study of the proposed architecture The above section describes the general design considerations and the goals of realising a reusable SCORM component and integrating it into the LMS used by the LLLC. The remaining parts of the document review step by step the design process and explain the various design decisions taken during the realisation phase. 3.1 Implementation Context The validity of the proposed architecture was proven by integrating SCORM 1.2 compliancy into OpenUSS3, a
2
3
Java 2 Enterprise Edition as defined by SUN Microsystems
Open University Support System, developed at University of Münster 178
J2EE based open source LMS using the EJOSA architecture.
The Open University Support Systems (OpenUSS) The OpenUSS LMS [17] developed at the University of Münster, implements the component based EJOSA architecture, which is sub-divided into foundation and extension components. The foundation components offer basic functionalities like user management, faculty and training-session organisation, whereas the extension components offer advanced features like handling access to course contents, discussion groups or chat sessions. Extensions can be considered as fully independent components, loosely coupled to the OpenUSS LMS. The integration mainly consists in linking the extension components to the LMS at presentation level and in accessing required information handled by the foundation components.
The Sharable Content Object Reference Model 1.2 (SCORM 1.2) After identifying the need to integrate SCORM compliancy into OpenUSS, an in depth study of the SCORM 1.2 specification and an analysis of the reference implementation provided by ADL were mandatory. This study concluded that two major topics had to be addressed, the SCORM Content Aggregation Model and the SCORM Runtime Environment. The Content Aggregation Model [15] takes care of the course packaging and of the meta-data management. It also makes sure that imported course contents respect the SCORM specifications. The SCORM Runtime Environment [16] defines the interaction between LMS and SCOs4. This guarantees platform independency of SCORM courses and content portability between different LMSs. As a consequence a SCORM component has to handle the student access to the SCORM compliant learning objects, which consists in managing the user profiles, implementing sequencing and tracker engines and by this way taking care of the display of SCORM compliant contents as well as the bi-directional communication between SCO and LMS. The overall structure of the SCORM reference model is shown on figure 2.
Integrating SCORM into OpenUSS As a consequence SCORM compliancy of OpenUSS could only be achieved by developing a SCORM extension component accessing on one hand foundation classes and on the other hand the course content management component (lecture extension). This type of integration made the access to SCORM contents transparent, however it required minor changes to the lecture component. At presentation level, access to a SCORM course is handled exactly in a similar way as the access to any other type of document.
File Access (*)
Mailing
Course Administration Service
Runtime Environment (**)
Chat
Testing/ Assessment Service
File Upload (*)
Discussion
Content Aggregation Model SCORM content package
Content Aggregation (**)
Lecture Component
SCORM component
Extension components
other extension components
(*) modified existing components (**) newly added components
Meta-data Sequencing Service SCOs
Student Local Content Repository Management
Assistant
Faculty
Enrollment
other foundation components
Foundation components
Figure 3: Interactions of the SCORM component into OpenUSS.components
Learner Profile Service Tracking Service
Learning Management System
Delivery Service
Figure 3 shows the components accessed by the SCORM module. Interactions with the Lecture component are mainly required for importing courses and for accessing the course contents. The Student Foundation Component is accessed when building and maintaining the user profile at SCORM level.
API Instance
Runtime Environment
SCORM Content
Figure 2: The SCORM reference model
3.2 Design choices and realisation As mentioned above SCORM is subdivided into several subcomponents, including the Content Aggregation Model as well as the Runtime Environment, which both highly influence the design of the SCORM component.
4
Sharable Content Object, learning objects as defined by ADL in the SCORM specification 179
objects. This operation, trivial at a first glance, reveals to be pretty complex. The complexity mainly results from the strong need to offer complex tracking and sequencing mechanisms, allowing a direct and fine-grained communication between SCOs and LMS. A key issue addressed by ADL, when defining this type of communication, was to minimize the impact onto the content development process and to only introduce a minimal amount of additional work for the content developers. As a consequence, the complexity of this communication protocol is mainly transferred into the LMS and realisation is left to the LMS providers. The process of accessing a SCO is illustrated on figure 5. At first, the student navigates to the content management module. This functionality is handled by the lecture component in OpenUSS. Then the student selects the material he wants to access. The lecture component accesses the student profile and checks if the student already subscribed to the specific SCORM course. If a positive answer is returned, the actual status is extracted from the LMS, in order to let the student continue his training session where he previously stopped it. Otherwise the student is subscribed into the course, by creating the student profile.
3.2.1 Content Aggregation Model At LMS level, the content aggregation part mainly consists in validating the SCORM package, extracting relevant data and importing this information into the LMS. These operations are generally described as importing SCORM content into the LMS. The general framework of the course import is specified by ADL. The LMS providers however, freely define the data structures storing imported contents. The process of generating and creating the SCORM packages is not handled at LMS level and is left to the authoring tools. The sequence diagram describing the import of SCORM contents into OpenUSS is described on figure 4. At first the teacher accesses the Lecture Component in charge of managing all learning material related to the selected course. Then he selects a specific SCORM package and indicates explicitly that the imported data should be considered as being a SCORM course. At teacher level, no other operations are required. First the back-end application extracts the main meta-data file (SCORM manifest) and analysis this file in order to determine the SCORM version of the package. Next the appropriate ADL libraries are invoked to validate this manifest. If validation fails the course is not imported, otherwise the meta-data are imported into the data structures of the LMS. Finally the various learning objects (SCOs) are extracted one by one and are imported into the LMS. Reusing existing and freely available ADL libraries reduces the complexity related to implementing manifest validation and data extraction. Another advantage of reusing ADL code was to minimize the development and debugging phase and to avoid incorrect interpretation of the huge SCORM specification.
Content Access, Sequencing and Navigation The next operation consists in starting the training session, by transferring control of all further data exchanges between student and the SCORM course to the allocation (prestation) subcomponent and by launching the begin action. This ends the direct communication between the OpenUSS core system and the SCORM component. All further operations are handled independently by the SCORM component managed by the allocation sub-component.
ADL libraries Teacher
LMS Content Mngt front-end
SCORM file upload
SCORM import facade
delegate further actions
SCORM meta-data validation / exploitation
Validate SCORM manifest Extract manifest
Student
Persistency layer
SCORM course
Identify SCORM version and validate
display SCO
extract manifest
User action: next SCO
Tracker
MetaData
Student Profile
subscribe student to SCORM course
Get course meta-data Get/create user profile delegate
Save manifest Extract SCO1
OpenUSS lecture cmpt
Allocation Component SCORM SCORM Seq ue RT RT nc er (F-E) (B-E)
begin action
access first SCO
SCO URI
update student profile
handle action
update user profile
extract SCOs Save SCO1
next SCO
access next SCO
Extract SCO2 Save SCO2
display SCO
SCO URI
Figure 4: Importing a SCORM content Figure 5: General behaviour of the SCORM Runtime environment
3.2.2 Runtime Environment.
After subscribing to the desired course and delegating further control to the allocation subcomponent, the training session is started. First of all the course and SCO
The runtime environment is mainly in charge of managing user/student access to the SCORM contents and of tracking the user/student interactions with the learning
180
meta-data are accessed in order to identify the next learning object to access. This operation is realised by means of the sequencer component. The sequencer module implements the logic for identifying the first SCO to display. Explicit access to the meta-data is delegated to the tracker module. Once the correct SCO identified the information is returned to the SCORM front-end component, which then directly accesses and displays the appropriate SCO in the browser.
3.3 Preparing for future changes Due to the high industry support of the SCORM reference model, SCORM is constantly evolving and new functionalities are added on a regular basis. When designing the SCORM component presented in this paper, special care was taken to implement a flexible solution capable of supporting future SCORM versions. Analysing the history of SCORM shows that mainly the sequencing component was frequently subject to change. Changing the sequencing policy also requires adaptation of the meta-data associated to the SCORM courses. To take this evolution into account, the manifest is parsed before validation, in order to identify the actual SCORM version. An abstract factory [18] instantiates the appropriate Java objects in charge of validating the metadata, extracting the SCOs, selecting the appropriate sequencer and tracker engines. Even more care is required concerning the selection of a specific sequencer. A helper class is in charge of selecting the appropriate sequencer, which organizes navigation throughout the various SCOs. By default, this selection process is indicated by the content developer, is specified in the meta-data file and is extracted at course import by the ADL libraries. The SCORM specification allows some flexibility at this level. Due to this modular design, adding a new sequencer simply consists in implementing the desired sequencing policy and in updating the helper class in order to specify when the newly added sequencing has to be used.
User Profiling User actions are intercepted and handled by the allocation subcomponent. Handled actions include, but are not limited to the access to other SCOs or the end of a learning session. Depending on the triggered action, user profiles are updated and/or the sequencer is re-invoked in order to load the next SCO to display (lower part of figure 5). As mentioned above, SCORM is not limited to displaying learning contents but it also guarantees feedback to the LMS, from the SCO and from actions performed on the SCO. This communication is clearly specified by ADL and is achieved by adding well-defined JavaScript code into the SCO. This code then interacts with a hidden Applet loaded together with the SCO. All this information exchange is specified by ADL (by reusing the AICC data model) and the appropriate libraries can be reused. The technical realisation of the communication protocol between Applet and LMS however is not specified and is left to the LMS provider. We decided to send a serialized Java object from the applet to the LMS by communicating with a servlet component at server side. This servlet extracts relevant data and accesses the persistency level implemented by means of EJB5. Figure 6 illustrates this communication process and shows that all exchanges between SCO and LMS are stored at database level. Student browser API Instance
WEB extract SCO data model
SCORMFactory + SCORMFactory + createManifestParser + createSequencer + createTracker + createSCODataModel + createAPIAdapter
Web Application Server Facade
SCORM helper classes
SCORM1p2Factory
SCO data model
+ SCORM1p2Factory + createManifestParser + createSequencer + createTracker + createSCODataModel + createAPIAdapter
SCORM specified communication
SCO
Java Applet
SCO data model (local copy)
Servlet
EJB
DB
SCORM2004Factory + SCORM2004Factory + createManifestParser + createSequencer + createTracker + createSCODataModel + createAPIAdapter
Abstract Factory managing course import Sequencer
commit changes SCO data model
LinearSequencer
Figure 6: Communication between SCO and LMS
ChoiceSequencer ADL1p2Sequencer
ADL1p2LinearSequencer
ADL1p2ChoiceSequencer
Extensible sequencing engines
Figure 7: Flexibility of proposed architecture
5
Enterprise Java Beans as defined in the J2EE specification 181
[5] W. Hodgins, IEEE Standard For Learning Object Metadata 1484.12.1, http://ltsc.ieee.org/wg12/, accessed on September 21st 2004. [6] E. Duval, E. Forte, K. Cardinaels, B. Verhoeven, R. Van Durm, K. Hendrix, M. Wentland-Forte, N. Ebel, M. Macowicz, K. Warkentyne, F. Haenni, The ARIADNE Knowledge Pool System, Communications of the ACM 44, 2001 5, pp 73-78 [7] Dublin Core Metadata Initiative, Dublin Core Metadata Initiative, http://dublincore.org, accessed on September 21st 2004. [8] ADL, SCORM History, accessed on August 1st 2004, http://www.adlnet.org/index.cfm?fuseaction=SCORMHistory. [9] S. Thropp, SCORM 2004, Proceedings of the 1st International Plugfest, Zürich, CH, 2004 [10] ADL, SCORM 1.2 Sample Run-Time Environment version 1.2.2, http://www.adlnet.org accessed on September 20th 2004. [11] L. Dewanto, Enterprise Java Open Source Architecture, JAX2003 [12] ADL, SCORM 1.2 Overview, http://www.adlnet.org accessed on September 20th 2004. [13] ADL, SCORM 2004 Overview, http://www.adlnet.org accessed on September 20th 2004. [14] ADL, SCORM 2004 Sequencing and Navigation, http://www.adlnet.org accessed on September 20th 2004. [15] ADL, SCORM 1.2 Content Aggregation Model, http://www.adlnet.org accessed on September 20th 2004. [16] ADL, SCORM 1.2 Runtime Environment, http://www.adlnet.org accessed on September 20th 2004. [17] OpenUSS, Open University Support System, http://www.openuss.org accessed on September 20th 2004. [18] Gamma, Helm, Johnson, Vlissides, Design Pattern (Addison-Wesley, 1995). [19] W. Blackmon, J. Brooks, E. Roberts, D. Rehak, The Overlap and Barriers between SCORM, IMS Simple Sequencing, and Adaptive Sequencing, Carnegie Mellon University 2004 [20] A. Paramythis, S. Loidl-Reisinger, Adaptive Learning Environments and e-Learning Standards, EJEL Vol. 2 Issue 1 2004 (Electronic Journal of eLearning) (http://www.ejel.org) [21] O. Conlan, V. Wade, M. Gargan, C. Hockemeyer, D. Albert, An Architecture for integrating Adaptive Hypermedia Services with Open Learning Environments, ED-MEDIA2002, 2002 1, pp 344-350.
With this modular design as shown on figure 7, we meet the objective of realising a component ready to integrate adaptive e-Learning techniques. 4 Conclusion and future perspective Today the SCORM reference model can be considered as the de-facto standard in e-Learning. All major commercial LMS support the SCORM reference model. Unfortunately the ADL specifications are pretty complex and adding SCORM compliancy is usually time consuming and resource intensive. This paper we describes a general approach to implement a SCORM component, which can be easily extended and integrated in any component based LMS. The paper also gives the practical illustration of adding SCORM compliancy to OpenUSS, an open source J2EE based LMS. Due to some well through design choices, the coding of major parts of the SCORM complexity could be avoided by reusing the freely available ADL libraries. By this contribution providing facilities usable by a maximum of LMSs to integrate SCORM compatibility into their systems, we hope to help reducing the gap between commercial LMS vendors and open source projects with limited resources. In a first phase we expect to further extend the sequencing module by supporting Simple Sequencing introduced in SCORM 2004. We also see the big potential of conceiving advanced sequencing engines, which are no longer limited to identify the next SCO to access, through a combination of basic sequencing rules and student responses [19]. Such advanced sequencing engines, could access several independent and distributed data sources (like learning repositories, statistical information, advanced user profiles), and propose alternative and selfadapting learning plans to the student. These advanced sequencing engines have the potential to bridge the gap between instructional and adaptive e-Learning [20] by dynamically aggregating learning objects collected from various repositories. This research domain, first results have been obtained by the EASEL project and were published in [21], but a lot of progress is still required to obtain production class solutions.
References: [1] G. Knolmayer, E-Learning Objects, Wirtschaftinformatik 46 2004 3, pp 222-224 [2] K. Verbert, E. Duval, Towards a Global Component Architecture for Learning Objects: A Comparative analysis of Learning Object Content Models, Proceedings of the EDMEDIA 2004, 2004 pp 202-208 [3] IMS Global Learning Consortium Inc., IMS Resource List Interoperability. Best Practice and Implementation Guide http://www.imsglobal.org/rli/rliv1p0/imsrli_bestv1p0.html, accessed on September 20th 2004 [4] S. Bergstrom, CMI Guidelines for Interoperability AICC, http://www.aicc.org/docs/tech/cmi001v4.pdf, accessed on September 15th 2004
182
