Architecture

Information Flow Diagram

The Client Control Request and Control Translation Service form a pair of modules running on the client and server machines respectively. These modules could be run independently of the Session/Resource Allocation Check module and would allow a single user to control the Hardware Interface.

The Client Control Request is run in a standard Web browser. The initial coding for this project will be JavaScript embedded in HTML. The Control Translation Service is run on the server through an Apache Web server. Initial coding will be in PHP.

The Hardware Interface talks directly to the hardware, either through a serial link over RS232, or TCP/IP through Ethernet - depending on the hardware. Initial coding will be in a scripting language such as Bash (or Perl or Python) depending on what drivers are available.

These 3 modules taken together form a simple control system for a piece of hardware using a Web browser.

The Session/Resource Allocation Check module sits between the Client Control Request and Control Translation Service. It checks that the user has access to the given resource and, if they do, passes the information on and, if they don't, passes an error page back. It is implemented through the Apache Web server, initially in PHP.

The queuing system itself is implemented as a separate pair of Client Control Request and Control Translation Service modules. In this instance, the Control Translation Service module controls the resource allocation tables instead of a Hardware Interface. The Client Control Request module passes one piece of control information when it first connects (which resource the user wants) and then polls at intervals determined by the Control Translation Service. In effect, the queue is a virtual resource which is always available and times out when the resource the user requested becomes available - thus passing control on.