Revision as of 14:38, 4 May 2012

Introduction

ASL HTTP Front End assist a layer of the system Integration and Interoperability Framework. It offers HTTP APIs to expose a subset of its JAVA API facilities for supporting high level standards. It consists of a set of servlets that support HTTP methods and operates on top of the JAVA libraries. The objective of this framework layer involves access points that cover series of services, can pass through ASL for session handling and/or expose HTTP standards compliant interfaces. The framework targets clients submitting HTTP requests and handling HTTP responses. Such clients are components external or internal to the system that have come in an agreement with the HTTP services implementers about the data/format they are expecting and the response they will be giving out, or will be implementing standard HTTP specifications offered by the HTTP front end of the system. ASL HTTP Front End is the outcome of the retrospection of the previous version of Application Services Layer HTTP API that was mandated by the need for formalization and extensibility of the framework.

Reference Architecture

The architecture of this layer is driven by the needs for provision of access to resources that fall under specific functional categories. More specifically, it consists of a set of servlets for which each access point covers a series of services. In the existing implementation, those components cover mostly the fundamental functionality needed by the end-users. Extensions in the existing framework can either provide access to resources of other functional categories or offer a standard HTTP based API adhering to a widely used specification, to support interoperability needs. All the components within the existing framework use common functionalities implemented for caller authentication.

External Architecture

HTTP Front End aims at providing access to higher level functionality, frequently compliant to web standards. Most probably each access point covers a series of services and requires interaction with lower level components in the system architecture to achieve resources aggregation. The system layer that offers this kind of access to multiple services as well as a session mechanism that can be exploited within different applications’ interactions is the ASL (Application Services Layer). Therefore, the HTTP layer is logically placed above it and offers a subset of its functionality. In the image below, the framework of ‘layers’ of gCube system is depicted, clarifying the place of this set of interfaces in the system architecture.

Internal Architecture

HTTP Front End is composed by web applications based on Java Servlet technology. By revisiting the architecture of the existing implementation of ASL HTTP Front End, the need for extensibility drives the decision for division of the only application into a set of smaller applications that can proliferate within the framework. An HTTP application in the new version of this layer can logically group related functionalities. The grouped functionalities address demanding tasks that need access to multiple services and a sequence of logical steps to complete. In the context of this decision, the architecture of the existing implementation consists of the following new system components:

ASL_HTTP_InformationRetrieval

Aggregates mandated functionality to perform a gCube search

• • listing of searchable collections
  • retrieval of information about searchable collections
  • listing of search types
  • listing of languages
  • listing of searchable fields
  • submission of search query
  • retrieval of search results

ASL_HTTP_ContentAccess

Aggregates functionality for accessing gCube content

• • retrieval of information about content
  • retrieval of content
  • retrieval of metadata
  • retrieval of thumbnails

ASL_HTTP_InfrastructureLogin

ASL HTTP Infrastructure Login component aggregates needed functionality for logging into the system and in an infrastructure scope. It allows the clients to retrieve the necessary information for logging into the system and it uses the internal ASL Session mechanism to prevent the need for passing the credentials every time in subsequent calls. The authentication of the user is performed through communication with ASL authentication facility that is independent from specific applications and authentication providers and uses a pluggable mechanism to specify "authentication modules". The set of servlets consisting this component provide the following functionalities:

• user authentication – logging in Infrastructure
• listing of infrastructure scopes
• logging in an Infrastructure scope

Specifications Implementations

Implementations of HTTP Standards placed in separate application components

• • ASL_HTTP_OAIPMH
  • ASL_HTTP_OpenSearch

Implementations offering common functionality to all HTTP applications

Based on the functionality, each servlet overrides the doGet and doPost methods of HttpServlet

Authentication Modes

Web Standards and Infrastructure Requirements