Architecture Overview

From wiki.gpii
Jump to: navigation, search

Note: This page is out of date. Please see GPII Architecture Overview for an overeview of the GPII's technical architecture.

The Cloud4all/GPII Architecture Illustrated

GPII Program Flow-small.png


Quick Overview

The purpose of Cloud4all/GPII architecture is to enable the personalization of desktop, mobile, and web applications and content based on the user's needs and preferences. Here's how it works:

  • The user starts the process by describing their needs and preferences to the system using an editor, wizard, or discovery aid (sometimes referred to as a "Preferences Discovery Aid & Editor").
  • From there, the system is able to automatically configure a mobile device, computer, or web site with the user's preferred applications (for example, a screen reader) and settings (e.g. their preferred voice speed). Web content will be automatically adapted to suit the user's preferences as well.
  • When the user approaches a GPII/Cloud4all-enabled device, such as a computer at a library or their new smartphone:
  1. The user offers a key (a unique string) to the the device using a range of techniques such as:
    1. a USB device (flash drive or special device)
    2. an NFC ring or phone or other NFC Tag
    3. typing in a special string on the keyboard
    4. a continually changing key code
    5. etc.
  2. The User Listener component, typically running on the local device, will detect this key and send it to the Flow Manager.
  3. The Flow Manager will orchestrate the process of configuring the device by bring together:
    1. The user's preferences (from the Preferences Server)
    2. The range of applications and access features (Solutions) available to the user either on the local device, on the web, or in the cloud (from the Solutions Registry)
    3. Information about the device's characteristics and the user's working environment (with their permission) (from the Device Characteristics Reporter)
  4. The Matchmaker is the part of the system that makes decisions about how to meet the needs of the user. It is responsible for:
    1. Matching the user's preferences with the available solutions
    2. Resolving device, context, and environment-specific conditions for those settings
    3. Assembling a list of the the features and applications that need to be configured on the device
  5. The list of solutions and their settings is then passed to the Lifecyle Manager, which manages the process of configuring settings
  6. The Lifecycle Manager, in turn, invokes a set of Lifecycle Handlers and Settings Handlers that do the actual launching and setting of applications and access features.


This architecture is design to be flexible, loosely coupled and portable. Many of the components in the system can be run either on the local device or on a server, ensuring that administrators and users of the Cloud4all/GPII system have the flexibility to deploy it differently depending on various requirements. As a result, all communication between components in the system is handled via a REST API.

Description of Components

Flow Manager

The Flow Manager is the event-driven, asynchronous orchestrator of the personalization workflow. Today, it is implemented as a very small web server that runs on the local device and is responsible for bringing together the various components in the system and invoking them at the appropriate points in the process. In the future, some of the Flow Manager's responsibilities will be distributed between both the local device and the cloud. More information on the Flow Manager's API can be found here: Flow Manager API.

User Listener

The User Listener is the first step in the process of customizing a device or application to the user's needs and preferences. The user shares their key with the listener, which is then responsible for starting the process personalization. Since users may want to stay as anonymous as possible, this key is a random, unique, opaque string—not necessarily a personal ID.

There will be different types of User Listeners available, such as (RFID tag readers, USB key readers, 2D barcode readers, username/password-based login, face recognition, voice recognition, etc.) Currently, there are two implemented User Listeners:

  • RFID Reader
  • USB Drive Reader


Matchmaker

The Matchmaker is responsible for deciding which solutions and settings will best meet the user's needs. To do this, it takes into account:

  1. the user's preferences
  2. the applications, features, and assistive technologies available on their current device and out on the cloud
  3. information about the user's device, environment, and context

Invoked by the Flow Manager, the Matchmaker will return a comprehensive list of Solutions and settings for the user, which is in turn passed on to the Launch Manager. This information will then be used to invoke the relevant Settings Handlers and Launch Handlers.

The Cloud4all/GPII architecture currently ships with a default Matchmaker, and several others are in active development:

  • A statistical Matchmaker
  • A rule-based Matchmaker


Lifecycle Manager

Located on the user's device, the Lifecycle Manager receives the list of appropriate solutions and settings from the Matchmaker and manages the process of setting them up. This configurable process generally includes:

  1. Taking a snapshot of the device's current settings, so they can be restored later
  2. Invoking the Settings Handler appropriate for each solution
  3. Launching each solution
  4. Stopping each solution when the user is done
  5. Restoring the previous settings (if required) once the user is finished

Each of these activities is accomplished by a Lifecycle Handler, which are functions that can be registered with the architecture and are responsible for performing a single, specific task of the configuration workflow.


Settings Handlers

Settings Handlers are a type of Lifecycle Handler that are responsible for configuring the settings of an application, access feature, or assistive technology. They are often, but not always, specific to a particular platform. Platform-specific Settings Handlers typically interface with the operating system's built in APIs for storing settings (such as the Registry on Windows and GSettings on Linux). Others are capable of configuring standard formats such as XML and JSON files.

Settings Handlers are configured declaratively, and assistive technology developers will typically use the ones that are built in to the system. In cases where the default Settings Handlers aren't sufficient, developers can choose to write their own Settings Handlers and hook them into the GPII Personalization Framework.

Out of the box, the Cloud4all/GPII architecture ships with the following Settings Handlers:

  • XML files
  • JSON Files
  • Linux GSettings
  • Linux DBus
  • Windows Registry
  • Windows SystemParametersInfo


Preferences Server

The Preferences Server stores user preferences. These preferences include general preferences ("I prefer high contrast"), context-specific preferences ("In the evening, I want the text to be 1.5x larger"), and application-specific settings ("I want X screenreader to read at Y speed").

The Preferences Server is a web-based service that provides a REST API for accessing preferences in a JSON format. Preferences will be represented according to a new version of the AccessForAll ISO 24751 standard.


Solutions Registry

The Solutions Registry is a comprehensive source for information about applications, access features, and assistive technologies. It can be queried to determine which solutions are available to the user on their particular platform. The Solutions Reporter consists of declarative information about a solution, how it is configured, and what features it provides. This information can then be used to make a successful match with the user's needs and preferences.

This list of solutions will include both those locally available (AT installed on computers, features built into the OS) and available via the cloud (services that the user is subscribed to or free services listed as preferable).

In order to register their software with the Solutions Reporter, developers need simply to create a standard JSON file called a Solutions Description, which will contain:

  • a name, ID, and other basic information about the assistive technology
  • the name of a built-in Settings Handler suitable for how it stores its settings
  • a Settings Transformation Map, which describes how to map standard AccessForAll user preferences into the assistive technology's native settings format

Device Characteristics Reporter

The Device Characteristics Reporter provides information about the user's device. This includes operating system, versions, and the list of applications currently installed. It will also provide information about the device's capabilities, such as screen resolution and size, support for features such as HTML5, and the availability of devices such as microphones and cameras, etc.

Over time, the Device Characteristics Reporter will be harmonized with evolving standards such as W3C Media Queries and more.


GPII/Cloud4all Personalization Framework Reference Implementation

Components

Each component in the GPII Personalization Framework reference implementation is developed using a standard cross-platform technology stack. Components are written in JavaScript and hosted within the Node.js runtime environment. Node.js is a highly scalable, event-driven system that can run on all major desktop platforms—Mac, Windows, and Linux—as well as mobile platforms such as Android. It is commonly used as a server-side web development toolkit, but can be used to create any kind of local or connected application. It features prominently within the development tools offered on desktop and mobile platforms such as Windows 8.

Due to this design, all components have the ability to run across platforms without recoding. For those features of the GPII system that are platform-dependent (the bindings to the Operating System Settings Store or the USB User Listener, for example) thin platform-specific shims will be written in the language and toolkits most appropriate for the platform and then wrapped in JavaScript. All other components in the system are insulated from platform-specific dependencies.


Messaging and Payloads

Components in the GPII Personalization Framework take input data and produce output in a simple JSON (JavaScript Object Notation) format. JSON is the lowest common denominator of interchange formats: it's widely supported and can be trivially parsed by any programming language and toolkit available today. It has a simple and lightweight syntax and maps directly to standard data structures. It is ideal for representing user preferences and application settings, and enables them to be easily transformed into other formats for interoperability.

Components in the system communicate with each other using simple REST (REpresentational State Transfer) conventions over the HTTP protocol. Each component is represented as a "resource" available at a unique URL. This approach specifically avoids a dependence on language or toolkit-specific messaging APIs that would prevent cross-platform compatibility. The system can easily be extended with new components and features by adding defining new URLs, and the dependency between components is configured, not hard-coded. Most importantly, it is trivial to move components between the local system and the web, ensuring that the system works as well in highly connected, cloud-hosted environments as it does without an Internet connection.

{
    "preferences": {
        "url": "http://gpii.net/preferences/%db/user/%token"
    },
    "deviceReporter": {
        "url": "http://localhost:8081/device"
    },
    "solutionsReporter": {
        "url": "http://localhost:8081/solutions"
    },
    "matchMaker": {
        "url": "http://localhost:8081/match?%query"
    },
    "launchManager": {
        "url": "http://localhost:8081/launch?%query"
    }
}

Local components are hosted within a single Node.js instance that responds only to internal HTTP requests. Implementers of the GPII Desktop system need only redeploy a local component to a remote web server and update a plain text configuration file in order to re-partition the system according to their needs.


Platform-Specific Bindings

Most operating systems, desktop and mobile alike, provide a central means and API for storing application settings. While the GPII Personalization Framework will support a wide variety of means for configuring application settings, the easiest way for an application developer to integrate with the system is to use the API provided by their operating system. Built-in Settings Handlers will be available for these APIs, so developers need only create a configuration file providing the GPII Framework with the information it requires to find, understand, and set their application's settings.

Most operating system Settings Stores are event-based: they provide a built-in, system-level event or notification that informs applications whenever their settings are changed in the store. Applications should listen for these events and, if already running, ensure that their application responds correctly to the new settings.

Deployment

With the exception of the components that are designed to bind with platform-specific APIs, any component in the system can be located either locally on the device or out on the web. For example, some Settings Handlers and User Listeners are bound to the local device, though others are cross-platform. The Flow Manager, Preferences Server, Matchmaker, and Solutions Registry can easily move between locations. It's simply a matter of updating a configuration file for the Flow Manager.

Default Deployment Layout

This is the default deployment layout of the Cloud4all/GPII architecture, but does not represent all of the possible places that any component could reside. For example:

  • Preferences can be on the server, or a USB drive, or in a phone, or in an NFC ring, or other
  • Matchmaking can be done locally, on the server, or distributed across both locations
  • Content transformation and transcoding can be done on the server, on the local device, or distributed


Web

  • Preferences Server
  • Solutions Registry
  • Cloud-based Flow Manager
  • Standalone Matchmakers

Cross-platform capable, but installed locally

  • Flow Manager
  • Device Reporter
  • Matchmaker
  • Ontology Server
  • Transformer
  • Lifecycle Manager
  • XML and JSON File Settings Handlers

Platform-specific and installed locally

  • USB Drive User Listener (Windows and Linux implementations)
  • Registry SettingsHandler (Windows)
  • SystemParametersInfo SettingsHandler (Windows)
  • GSettings Settings Handler (Linux GNOME)
  • GSettings Lifecycle Handler (Linux GNOME)
  • DBus Settings Handler (Linux)
  • INI Settings Handler (Windows)
  • SPI Settings Handler (Windows)

It's important to recognize that each component in the system doesn't be its own server. By default, we have two web servers:

  1. one that runs on the local device and is fully firewalled and secure
  2. a second server that contains both the the cloud-based Preferences Server the Solutions Registry

When components are co-located in the same application, they are able to communicate via direct function calls (without the overhead of REST). This, too, is a configurable aspect of the Flow Manager.

We expect mobile devices can be supported on most platforms using the same approach. iOS is always a more complex issue due to Apple's very restrictive terms, but a comparable implementation using Apple's own JavaScript runtimes should be possible to implement.

See also