In this paper, we present a new architecture for Learning Object Repositories [5], based on web services. We have re-designed the ARIADNE Knowledge Pool System based on the architecture presented here [2]. The goal of our architecture is to facilitate interoperability with other repositories and to enable experimentation with new techniques like Peer-to-Peer and Federated Search.
Learning Objects, Digital libraries, SOAP, XML, Web Services.
In this paper, we will propose a new architecture for Learning Object Repositories (LOR’s) [5]. Learning objects in this context should be understood as reusable content components for education and training. Associated to these learning objects are standardized metadata, so that the objects can be managed, searched, etc. [3].
The ARIADNE Knowledge Pool System (KPS) is a star-shaped distributed LOR. Some of the learning objects and all metadata are replicated at the different local pools. One of the main strengths of the ARIADNE community is that it cooperates in creating a large pool of reusable learning content [2].
In recent years, many LOR’s have been developed. In order to realize a ‘critical mass’ of content and users, we want to enable interoperability between the different systems. This requires a simple interface to a LOR. Also, the ARIADNE community has developed a number of tools that build upon our KPS as a LOR. These tools currently depend too much on the KPS structure, so that it will be difficult to make them work with other LOR’s.
The main objective of the proposed new architecture is to provide an API for accessing LOR’s. The tools relying on such an API are independent of the internal structure of the LOR. This will enable interoperability between LOR’s, and with other tools. To achieve this goal, our KPS will expose the API through a set of related Web Services, accessed using the Simple Object Access Protocol (SOAP) [1].
In the following sections, we will describe of the most relevant components. The LOR makes up the core architectural component, other components can then be plugged into this SOAP enabled LOR.
The basic functionality of this component is to store learning objects together with related LOM metadata. New LO’s can be inserted into the LOR, and the metadata can be queried. We have to distinguish between free and authenticated services: in our Knowledge Pool System, read access to metadata (getting, querying) is free; write access to metadata and read/write access to learning objects requires user authentication.
This API will allow other applications to introduce new Learning Objects and related metadata into the Knowledge Pool. The metadata conforms to a LOM profile, as defined in an XML schema. In the future, we will consider also the support for other schemas (profiles of this profile, or other schemas).
| Arguments | Description |
| GetXMLSchema | free, stateless |
| No arguments | Returns the XML-schema that describes the metadata schema being used (i.e. the XML-binding of LOM). |
| newLearningObject | authenticated, stateless |
| Document: File Metadata: XML Login: String Password: String |
With this service, users can enter new learning objects into the KPS. The operation can only succeed if the metadata is validated by the XML schema retrieved via the getXMLSchema service. |
The following services included in the API will allow queries and downloads of learning objects.
| Arguments | Description |
| getDocument | authenticated, stateless |
| ID: String Login: String Pw: String |
Returns the document identified by the given ID. |
| getMetaData | free, stateless |
| ID: String | Returns the metadata of the specified Learning Object. The result is an XML-binding of LOM that satisfies the XML schema retrievable with getXMLSchema. |
| simpleQuery | free, stateful |
| Keywords: String[] | This method executes a simple query and temporarily stores the results on the server. It returns the number of query results together with a key that can be used to collect these results. The query consists of a number of keywords. All metadata fields will be searched for containment of these keywords. |
| advancedQuery | free, stateful |
| Query: XML | This method executes an advanced query and temporarily stores the results. It also returns a number of results and a key. The format of the query hasn’t been specified yet. |
| getResults | free, stateful |
| key: String from: int to: int |
This method requires a previous invocation of either simpleQuery or advancedQuery. Given a certain key, one can than request e.g. results 10 to 19 of a query recently executed. |
We make a clear distinction between the query tool and the indexation tool. Someone who wants to focus on information visualization will use the query API while somebody interested in (automatic) indexation of documents will be mainly interested in the indexation API.
The ARIADNE Web-Based Learning Environment [4] is a Learning Management System. It provides facilities like course management and exploitation during e-learning sessions. WeBLe makes use of two services provided by the KPS: (i) it needs to get the metadata of given Learning Objects (getMetadata service), and (ii) since the WeBLE caches learning objects from the KPS, it needs to get documents (getDocument service).
As the number of repositories for storing Learning Objects increases, the problem of interoperability becomes more and more important. In the following sections, we will describe how the API defined for the ARIADNE Knowledge Pool can be used to build Peer-to-Peer and Client-Server (Federated Search) oriented architectures, interoperable with other learning objects repositories.
A P2P application has both client and server characteristics. This enables the reuse of components defined in the previous section. To do this, we will define a new layer that acts as a gateway between the query and indexation component and the LOR. The following tasks are delegated to this layer:
Queries: When this layer receives a query either from the query component or from another peer, it will execute this query locally using the LOR API. It will also forward the query to other known peers. The results coming from both local and other peers are finally offered to the initiator of the query.
Indexation: The peer layer could also take care of replication. When a user e.g. inserts a new learning object using the indexation interface, the P2P layer catches this request. Next, it decides on which peer the LO should be stored.
We will investigate next how this P2P-layer can provide interoperability with other client/server LOR’s.
The layer introduced between Knowledge Pool and indexation and query tools, can also implement Federated Search (FS). In a Federated Search system, queries are sent to different LOR’s. The FS engine then merges the results received by these LOR’s.
A Federated Search layer can also be used as middle layer in our architecture without having to modify anything of the other tools. The engine can accept queries from the Query tool and pass them to the LOR as well as to a number of other systems.
At the time writing, a prototype of newLearningObject, getDocument, getMetaData, simpleQuery and getResults has been implemented. We use Apache Axis, as this tool facilitates the deployment of web services, offers functionality to automatically generate a WSDL description of a service, etc. Also we are currently developing a new query tool. This query tool has become more flexible, as the (complex) structure of the database has been abstracted away.