Components

An overview of the core components to the auto-personalization is given in the below diagram.

Components of the GPII architecture

Ordered components of the Cloud4all/GPII architecture

Given the very flexible implementation and use of the architecture, the individual components, their role and location will vary depending on the configuration of the system (e.g. whether it’s running in all-local, hybrid or all cloud mode). A concrete example of a deployment layout can be seen in the next diagram involving the remaining Cloud4All/GPII components.

Most of Cloud4all components and its most common deployment location

Cloud4all/GPII components and ordinary deployment location

The components have been implemented to varying degrees of maturity based on their complexity, familiarity, role and importance within the overall auto-personalization process. The maturity of a component is based on several factors, such as:

  • Factoring and design, degree of modularity, maintainability, and degree of coupling and environment independence
  • Code quality via peer reviews
  • Unit and acceptance test coverage
  • Production-grade persistence strategies
  • Implementation of a stable Application Programming Interface (API)

The components developed in Cloud4All/GPII range from initial prototypes, which are early versions using for example mock data or unstable APIs, to stable components with full unit and acceptance tests coverage and stable, documented APIs.

Given its prominent role in the architecture and the need to understand this to also understand the overall architecture flow and orchestration, the Flow Manager and several of its configurations has been described in the above.

The following table describes tasks accomplished by most important Cloudall components as well as their maturity level (some of them are out of the figure above):

Component

Brief Description

Default Location

Maturity Level

Flow Manager The central orchestrator of the real-time framework, responsible for instantiating dependencies, firing lifecycle events, and securing communications channels amongst components. Local and Cloud Stabilizing
Matchmaker Framework A matchmaking-specific flow orchestrator that provides a facade interface between the Flow Manager and the matchmaking subsystem. Is responsible for distributing and manipulating payloads amongst each step in the matchmaking process. Cloud Stabilizing
Matchmaker Dispatcher Dispatches requests to an appropriate matchmaker instance (such as the rule-based or statistical matchmakers). Provides an abstraction layer for pluggable decision-making strategies regarding which matchmaker is best suited to the current user and situation. Cloud Prototype
Rule-Based Matchmaker A Matchmaker implementation that operates a set of expert rules in order to infer the appropriate solutions and settings to provide the user with. Cloud Stabilizing
Statistical Matchmaker A Matchmaker implementation that uses statistical inference to determine application settings based on the behaviour of similar users. Cloud Stabilizing
Context Evaluator Evaluates a preference set’s contexts and conditions directives, returning only the portions that match the current device and environmental context. Local and Cloud Stabilizing
User Listeners (various) A variety of strategies for responding to user key-in requests. Currently, USB drives and NFC tags are supported on Windows, Linux and Android at varying levels of maturity. Local Stabilizing-Stable (depending on implementation)
Lifecycle Manager Responsible for coordinating the set-up process of the local device’s assistive technologies and access features. Invokes lifecycle actions and settings handlers. Stores the state required to restore the system on logout. Local Stabilizing
Settings Handlers (various) Multiple strategies responsible for pushing settings to applications on a local device (e.g. via writing to settings files or invoking OS registry API calls). A variety of settings handlers have been implemented for both platform-specific persistence mechanisms as well as cross-platform forms such as XML, JSON, and INI. Local Emerging-Stable (depending on implementation)
Lifecycle Actions Multiple strategy components that are responsible for performing setup-related tasks such as starting and stopping applications, creating and deleting files, and other actions required for system configuration. Includes both cross-platform and platform-specific implementations. Local Stabilizing
Device Reporter Reports information about the user’s device, including the operating system version and the list of applications that are currently installed. Local Emerging
Preferences Server Framework Responsible for orchestrating the the flow related to serving, filtering, and ontologizing preferences. Serves as a facade for the preferences subsystem. Cloud Stabilizing
Preferences Server Stores preference sets in JSON format and provides a REST API for creating, updating, deleting, and reading preferences sets. Access to the preference server is protected by the authorization server and abstracted by the Flow Manager and Preferences Server Framework. Cloud Stable
Ontology Handler Responsible for transforming preference sets into different formats and ontologies based on client requirements. Cloud Stabilizing
Authorization Server Validates application tokens and secrets, grants access to preference sets, and filters out portions of a preference set based on user privacy policies. Cloud Emerging
Transformer Transforms arbitrary JSON documents based on a set of declarative “lensing” rules (which are also expressed as JSON documents). Local and Cloud Stable
Context Aware Server Streams real-time environment data from location-specific sensors or “motes,” such as ambient brightness and noise. Cloud Stable
Environment Reporter Reports real-time environment data using the local sensor hardware installed on a device (such as the brightness sensor, microphone, webcam, etc.) Local Prototype (Emerging on Android)
Preferences Management Tool (PMT) A web application that provides a comprehensive user interface for editing user preferences, account information, and other personal information. Cloud Stabilizing
Personal Control Panel (PCP) A panel or “dashboard” that allows the user to refine or adjust the results of the matchmaking process directly. Local Emerging
Solutions Registry Stores comprehensive information about all solutions integrated with Cloud4All, including how to set their settings, launch them, and how to transform preferences into their custom settings format. Cloud Prototype
Semantic Alignment Tool (SAT) Provides a means for describing and aligning different types of assistive technology ontologies using semantic web principles. Seeds preference term, solutions, and ontology data to other components in the architecture, including the Preference Terms Dictionary, Solutions Registry, and Ontology Server. Cloud Stable
Service Synthesizer Tool (SST) Synthesizes web-based assistive technologies and services to create new adaptations on the fly. Cloud Stabilizing
Unified Listing A comprehensive, GPII-wide database listing information about all assistive technologies and access features. Cloud Emerging
Preference Terms Dictionary A community dictionary where preference terms can be defined, registered, and browsed. Cloud Emerging