You are here

Developing a federated repository with RESTful web services

21 January, 2016 - 14:46

In the construction of distributed information systems the Web services were widely used but today we can see that the traditional Web services that used technologies based on WSDL and SOAP are being replaced by RESTful Web services. Examples of these transitions can be seeing in Google, Amazon, Flickr, Yahoo and YouTube. All this Web sites had WSDL files to describe their Web services and now they have changed to RESTful Web services.

Representational State Transfer (REST) is an architectural style that induces desirable properties, such as performance, scalability, and modifiability that enable Web services to work best on the Web. In the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links on the Web. The resources are acted upon by using a set of simple, well-defined operations. The REST architectural style constrains any architecture to a client/server architecture, and is designed to use a stateless communication protocol, typically HTTP. In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol. RESTful provides four basic methods for interaction with resources, which are: GET (obtain resources) PUT (introduce a new resource), POST (modify a resource) and DELETE (delete a resource).

media/image9.png
Figure 13.9 LORA-REST: A RESTful Service Oriented Architecture 

With the idea of adapting the SQI and SPI specifications to RESTful we have changed and  simplify our architecture (Figure 13.9). The main characteristics of the layers are:

  • Layer 1 comprises all RESTful Web services associated to each repository. This RESTful Web services enable access to learning objects described by his metadata. With the GET method, the RESTful Web service enables the system to access to the stored learning data (by its metadata), this method replaces the query SQI methods. With the PUT method, the RESTful Web service enables the system to publish new learning objects in the repository. With the DELETE method, the RESTful Web service enables the system to delete a learning object or his metadata. With the PUT and DELETE methods we complain with the SPI specification.
  • Layer 2 comprises the federated search services. They use the RESTful Web servicesprovided by layer 1 to get and handle the data provided by them. To make a federated search we only need the URL of each repository, and then we use the GET method (with the search criteria of metadata) in the RESTful Web service in each repository and handle all information provided by the repositories. With the results of each repositorythe system must classify and filter this information.
  • Layer 3 corresponds to the presentation layer of the system. All the interfaces that offeraccess to the system will be found here. The system has two primary functions: search learning objects in the federated repositories and add a new repository. If we want comply with the SPI specification we must add two new operations, publish and delete a learning object.

The first step in the design of a system that uses RESTful is to define the data it handles. In the case of repositories of learning objects, data will be as follows. Learning objects are composed of internal elements (resources according to SPI) and metadata describing them. We recommend that the metadata is described using the LOM standard. According to the SPI specification a resource may have 0 or n metadata that describe it. To transfer a resource by reference, its URL must be specified, so the repository will access the address where the resource is in order to include it to the repository.

To adapt the SQI specification to RESTful can perform federated searches in various repositories of learning objects, we only need the URL of the repository in which we want to launch queries. When the user makes a query to one repository it expands this search to the repositories that it has associated. Because we use RESTful, our repository has the role of a client that searches in other repositories. This operation is transparent to the user.

With these requirements we have make a prototype to illustrate how we can develop a RESTful repository. We have designed a database with four tables that represent resources, its metadata, external repositories and external resources. We have transformed these tables in persistent Java classes and from these classes we have developed the RESTful Web services that give access to them. In figure 10 we can see these four persistent classes with his attributes.

media/image10.png
Figure 13.10 RESTful prototype data model 

The RESTful Web services for these classes include the methods GET, PUT, POST and DELETE to keep up to date the information in the repository and to comply with the SQI and SPI specifications. We have added a RESTful Web service that enables downloading, inserting and deleting a file associated with a learning object. We have developed the prototype using the NetBeans IDE for the Java programming language as it has useful tools to program and test RESTful Web services.

Figure 13.11 shows a query to search for metadata records that contain the text “Java” in the“keyword” field of LOM. In this figure we can identify three important areas that are: area 1 is a navigable tree that represents the data of our repository; area 2 allows making queries to the metadata stored in the repository; area 3 shows the results in XML of the query we have made.

media/image11.png
Figure 13.11 RESTful metadata query and results 

One important thing to highlight is the possibility of the navigation between our data, for example if we are browsing metadata of one learning object we can access to the resource to which it is associated with. Figure 13.12 and Figure 13.13 show this, in Figure 13.12 we are accessing a concrete metadata with the identifier “JEE1MD” and with the URI:

http://localhost:8080/RSQPI/resources/lometadatas/JEE1MD/“; and if we want to access to the resource associated with this metadata (Figure 13.13) we only need its URI, that is: “http://localhost:8080/RSQPI/resources/lometadatas/JEE1MD/loresource/”.

media/image12.png
Figure 13.12 XML metadata representation 
media/image13.png
Figure 13.13 XML resource representation 

In the Figure 13.14 we present a direct access to a file that represents a packaged learning object. In this case the way of accessing the file is via the identifier of a resource, because in the information of a resource we have the “filename” field, so the Web service uses this filename to retrieve the physical file. In this example we are using the URI: “http://localhost:8080/RSQPI/resources/lofile/JEE1/”.

media/image14.png
Figure 13.14 Retrieving the file of a packaging learning object