Adaptive Technology Resource Centre, University of Toronto
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
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
configure these third party technologies, platform dependence cannot be
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.
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.
The purpose of the Control Hub is to act as a coordinator and relay
among the other modules of the system. In particular, it:
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.
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.
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.
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.
Copyright © 2003-2006 Adaptive Technology Resource Centre,
University of Toronto.
All rights reserved.
Last modified: Feb 20, 2006. Joseph Scheuhammer.