Web-4-All Architecture

Joseph Scheuhammer
Adaptive Technology Resource Centre, University of Toronto

Introduction

The purpose of this document is to provide a brief overview of Web-4-All's architecture.

The Web-4-All system is made up of a number of independent modules. They are independent in the sense that each performs its own function without regard to how the others are operating, except where they interface. This document describes the role of each module and how it interacts with the rest of the system.

The architecture is diagrammed in Figure one. The arrows indicate the flow of information. The nature of the information is described below in the section for each module. A module drawn in dashed outline (e.g., Server) indicates that it is not implemented in the current Web-4-All system, but shows how the system could be expanded.

Figure 1. Web-4-All Architecture

The majority of the system is written in JavaTM in order to ensure platform independence. The exceptions are at the front and back ends of the system, shown at the top and bottom, respectively, of Figure one.

At the front end, for example, Web-4-All can use smart cards to store user preferences. Smart card technology is significantly dependent on factors such as the smart card chip, the chip's operating system, the card reader device, and OS-specific software for that card reader. As a result, Web-4-All is not platform independent with respect to its smart card interface.

At the back end, the preferences and configuration plug-ins are designed for specific third party software that runs on a particular operating system. Examples include IBM's Home Page Reader and the ATRC's onscreen keyboard, both for the Windows operating system. Since plug-ins configure these third party technologies, platform dependence cannot be avoided.

Nonetheless, Web-4-All was designed to minimize platform dependencies, especially within its core, and to push dependencies out to the fringe where Web-4-All interacts with the OS and its hardware.

Preference Loader Module

The preferences document is stored using XML. Web-4-All uses the "accessForAll" schema of the IMS Learner Information Package, or LIP. The accessForAll branch of the LIP is referred to herein as the "AccLIP".

The purpose of the Preferences Loader is to read and write the user's preferences document. The Preferences Loader has a generic API so as to not be bound to any particular storage medium. Examples of such media are smart cards, local file systems, and network servers. Web-4-All has two implementations of the Preferences Loader API, one for smart cards, and the other for the file system. The current smart card implementation of the Preferences Loader API is uses the OpenCard framework (www.opencard.org).

A word of caution: In actual fact, the smart card Preferences Loader does not store a full AccLIP document on the smart card due to the limited memory available (it can be as little as 2k bytes). The smart card Preferences Loader contains a low memory-binding device that transforms a full AccLIP into a reduced vocabulary version. That version is then compressed before being stored on the smart card. The reverse is also true. When the preferences document is read from the card, the smart card Preferences Loader decompresses and then expands the preferences to the full AccLIP vocabulary. As such, a preferences document retrieved directly from the smart card is not an AccLIP document. The document must first pass through the low memory-binding device (or something functionally equivalent), in order to retrieve the full AccLIP elements and their attributes. Note this is done only because of the limited memory available on smart cards. The low memory binding software need not be used for a hard disk or file server implementation of the Preferences Loader.

Control Hub

The purpose of the Control Hub is to act as a coordinator and relay among the other modules of the system. In particular, it:

acquires a preferences document from the Preferences Loader.
requests that the Preferences Loader store a preferences document.
requests that the Preferences Wizard Manager launch a wizard to create a new preferences document, or edit an existing one.
request that the Configuration Manager configure the workstation based on a preferences document.

In Figure one, there is an octagon labelled "Plug-in Information" that feeds into the Control Hub. This is not a module of the system per se, but represents data that the Control Hub consults on behalf of the Preferences Wizard Manager and Configuration Manager. Specifically, this data contains information about the various plug-ins that the two managers invoke.

Preferences Wizard Manager

The Preferences Wizard Manager has two purposes. First, it has a built-in preferences wizard that enables users to create or edit preferences documents. In this regard it allows users to set "universal" or "common" preferences for different types of adaptive technology. For example, screen readers typically have a setting for volume, and the built-in wizard has a dialog for such a setting. In point of fact, the built-in wizard has preference dialogs for all of the AccLIP's generic control and display preferences.

Secondly, the AccLIP allows additional preferences to be set for specific third party applications. The Preferences Wizard Manager has a plug-in feature enabling third parties to create a link to their own preferences wizard so users can set preferences that are specific to that application.

The responsibility of a Preferences Wizard Manager plug-in is twofold. It must launch the third party preferences wizard and return any settings back to the Preferences Wizard Manager. These specific third party preferences must be returned in the form specified by the AccLIP. The Preferences Wizard Manager then incorporates them into the preferences document.

Configuration Manager Module

The purpose of the Configuration Manager is to configure the work station and third party technologies according to the preferences document, and to launch a Web browser. It does this by matching what the user has requested in terms of assistive technologies and what is actually present on the system as closely as possible. It determines the latter by querying the Control Hub for information about configuration plug-ins. When it finds the plug-in that best matches the user's preference settings, it passes the relevant portion of the AccLIP to that plug-in, leaving it to perform the bulk of the work.

The AccLIP information passed to a configuration plugin includes generic preferences set by the built-in preferences wizard, and any specific preferences set by an external third party preferences wizard. Configuration plug-ins are expected to transform all relevant settings from the AccLIP into a form that the third party technology understands, configure that technology, and launch it. When the user indicates that they are terminating the session (e.g., by removing their smart card), the plug-in resets and shuts down the third party software. The Configuration Manager calls upon the plug-in to perform its clean up based on some event that indicates that the user is finished.

Summary

This describes the essential features of the Web-4-All system. The following documents provide additional details about the various components and how to implement preference wizard and configuration plug-ins.