Revision as of 17:58, 22 November 2013

Objective

The Application Services Layer is an existing framework of the gCube system, acting as a middleware between the gCube lower level services and the presentation layer. Its activities scope differs from the one of the gCube Client Libraries in that it is designed not only to wrap gCube's complexity but also to provide higher complexity functionalities such as a Session Mechanism and aggregation of access to multiple services. It's architecture allows for extensibility of the framework for access to resources that fall under new functional categories or for provision of facilities that support multiple APIs based on various specifications. Within this section, ASL will be revisited in terms of:

• Principles and Architecture
• Procedures for its evolution, adoption, use and evaluation

Framework Principles

• ASL targets a framework for supporting higher level interactions
  • Provides global Session Management to enforce intercommunication between application components and allow stateful invocations
  • Covers the application logic needed to fulfill presentation requirements
  • Provides accounting information for use by applications
• ASL provides higher complexity functionalities
  • Aggregates access to multiple services
  • Speeds up gCube system's performance by caching fequently used and rarely modified resources
• Whatever lies in ASL shall handle connectionless invocations
• ASL talks to Client Libraries or directly to gCube services
• All applications talk to ASL in a similar way
  • ASL hides all gCube implementation - applications over ASL depend directly only on it
  • Applications over ASL don't deal with topics like scope or security (this information is kept within the internal session and handled transparently)
• Higher level functionalities for supporting HTTP API should better be hosted in ASL.
• Extensibility rules
  • Access to to resourses that fall under new functional categories should be implemented in framework extensions.
  • Implementations of facilities for supporting specifications should be implemented in framework extensions.

Framework Architecture

ASL consists of ASL Core and ASL Extensions. ASL Core is the group of basic functionality on which developers can build their own extensions. In brief, the groups of functionalities covered by the main ASL architectural components are listed below:

• ASL Core:
  • Session Management
  • Discovery and Services Invocation
  • Security - Authentication
  • Common functionality (ex. handling generic resources)
• ASL Extensions:
  • Application Driven Facilities
    • Cover the functionality needed by specific applications
    • Cover the application logic needed to fulfill presentation requirements
• Extensions assisting standards (ex. OAI-PMH)

Procedures

In this section the procedures that need to be defined adopted for the framework extension, use and evaluation are listed and are expected to be gradually analyzed within the framework revisit and evolution:

• Control use and development of ASL
• Check compliance with fundamental rules
• Coordination of design and extension of ASL
• Management procedures covering topics for framework changes, profiling and deployment, distribution, etc.