Designing a repository with Service Oriented Architecture

Available under Creative Commons-ShareAlike 4.0 International License.

In order to solve interoperability problems it is necessary to define a software architecture which is able to assume certain functions, mainly e-learning systems interoperability (integration) and the reusability of learning objects (Otón S. et al, 2010).

Any developed e-learning architecture should have the following characteristics:

Bellow we present an architecture that solves these problems. From the perspective of interoperability it is based on the main standards and specifications that should be used to guarantee interoperability and reusability of learning objects in repositories. These standards are shown in (Table 13.2), arranged by category.

Web services allow the companies to wrap their business processes publishing them as services; to subscribe to other services and to interchange information among different organizations. Thanks to the maturity achieved by this technology, together with the great expansion it has suffered, its use has gone from being an advantage to be a primary market need.

Web services and SOA architecture constitute a very suitable technology for the implementation of repositories that manage learning objects which are located in different stores of didactic resources, since it offers a clear access to those distributed objects which are in repositories based on different storage and metadata technologies through a single interface.

We suggest a multilayer (or multilevel) architecture, called LORA (Learning Object Reusability Architecture), comprising 3 levels (Figure 13.4). Each of these levels has a fixed role for the correct working of the universal distributed repositories which can be implemented together. These levels are basically fixed by the use of the SQI specification. It is an interface that establishes the search methods that any search system should have (not just in e-learning environments), so that the interoperability of the resulting search system can be guaranteed.

Figure 13.4 LORA: A Service Oriented Architecture 

The main features of the architecture are:

• It is a fully interoperable with all other systems and repositories. This not only means that the system can launch searches over other SQI-compliant systems or repositories, but these repositories or systems may also launch searches over LORA-associated repositories. This enables to make content accessibility and reusability as wider and complex as desired.
• It expedites the process of searching learning content. It presents two kinds of searches (which are associated with the implemented PLQL levels-- ProLearn Query Language).
• This enables a more accurate search level, because the system allows key field-based searches (PLQL level 0) and metadata-based searches (PLQL level 1).
• It is also possible to adapt it to any present or future set of metadata. LORA will only require changing a configuration to virtually adapt the system to any set or subset of metadata. This feature is not available in any other system and it is critical for the system interoperability.

The layers of the LORA system were presented in Figure 13.3 . The rest of this section is devotedto describe each of these layers. Standards and/or recommendations employed on each layer are specially highlighted. A summary of them is presented in Table 13.3.

Table 13.3 Standards used by LORA

STANDARD	LAYER 1	LAYER 2	LAYER 3
IEEE LOM	X
IMS CC	X
IMS RLI	X
IMS VDEX	X
IMS DRI	X	X	X
CEN SQI	X	X
CEN SPI	X
IMS AF	X	X	X
IMS LIS	X	X
IMS GWS	X	X

 

The main characteristics of the layers are:

• Layer 1 comprises all Web services associated to each repository. The IMS GWS (General Web Services) (IMS GWS, 2005) recommendation was employed to build this layer. It determines the way in which Web services are developed and the way in which they interact with each other. These Web services enable the access to learning objects described by the IEEE LOM (Learning Object Metadata) and packaged according to IMS CC (Common Cartridge). In order to access to this data, specifications SQI (Simple Query Interface) and SPI (Simple Publishing Interface) are employed. SQI defines the Web methods to be developed. These methods allow the system to access to the stored learning data. SPI establishes the set of methods to define the way to publish the learning objects in a repository. Moreover, semantic techniques are used to search data. The IMS VDEX (Vocabulary Definition Exchange) (IMS VDEX, 2004) specification has been adopted to tag this metadata and create vocabulary categories. IMS RLI (Resource List Interoperability) (IMS RLI, 2004) is used to arrange, describe and interchange lists of resources included by each learning object. Finally the IMS LIS (Learning Information Services) (IMS LIS, 2010) has been used to make effective every data interchange.
• Layer 2 comprises the federated search services. They use the services provided bylayer 1 to get and handle the data provided by them. Consequently, they also use the SQI specification. Since they are also Web services, they were also developed according to IMS GWS. This layer will also handle all information provided by the repositories, so the use of the IMS LIS specification is also required. In addition to the services requiring SQI methods, another set of services have been developed in order to classify and filter information, and to manage the repositories associated to the search engine. It should also be noted that this layer may be called by other search systems, so it can also be the target of outside calls.
• Layer 3 corresponds to the presentation layer of the system. All the interfaces thatoffer access to the system will be found here. Besides, all the aforementioned specifications, IMS DRI (Digital Repositories Interoperability) (IMS DRI, 2003) and IMS AF (Abstract Framework) (IMS AF, 2003) have also been adopted for this layer. IMS DRI defines the features that a repository must offer in order to be interoperable and allow access to its hosted content. IMS AF (Abstract Framework) presents an abstract representation of the set of services that should be used to build an e-learning system in its broader sense, so this specification was the main source to determine the required service.