Overview

General Architecture

WebSubmit is a framework for a secure, Web-based interface that provides access to diverse applications across a (heterogeneous) cluster of networked computers. A simple transaction model governs the way in which resources are accessed and utilized, and a security framework has been put in place to determine whether a client is allowed to perform transactions. The software itself is the combination of a collection of CGI scripts (written with the aid of Don Libes' cgi.tcl library) and a large body of Tcl code to provide functionality for these scripts. It is modular, flexible and extensible; hooks exist for including existing CGI code and for developing and adding new applications. The code is highly portable and can be modified to suit the needs of a given site quickly and easily.
Figure 1: The basic WebSubmit architecture. A client contacts the WebSubmit server using a Web browser, which then forwards requests to any number of target computing resources.
 

Transaction Model

WebSubmit is designed as a tool to help users accomplish specific tasks on one or more computer systems. Each of these tasks is achieved within a basic three-party transaction model (see Figure 1): (1) the client that is attempting to access resources, (2) the WebSubmit server that formats and routes client requests, and (3) the target computer on which the request (or task) is processed. The client uses a Web browser to form a secure connection with the WebSubmit server's master page, then loads the application module for the task of interest. This module is presented as a simple HTML form that the user fills out and then submits to the WebSubmit server. The server processes the form, performs error checking on the input data, and then executes the task specified. Output from the request is then returned to the user's browser for viewing. This process is detailed in Figure 2.
Figure 2:A simple WebSubmit transaction. The client connects to the WebSubmit master page and then selects the link for the desired application module. The module is an HTML form, which is filled out and submitted to the server. The server processes the raw form data and sends an action request to the target system. The system executes commands based on form data, then returns the output to the server, which is then forwarded back to the user's browser.

In principle, any type of client system (UNIX, PC, Macintosh) could be used to connect with the WebSubmit server, provided the browser software on the client supports the Secure Sockets Layer (SSL) protocol and HTML 3.0. The WebSubmit server resides on a single UNIX machine running an HTTP server configured to provide the necessary security facilities.  The WebSubmit server is configured to interact with a group of one or more target systems (hereafter referred to as the WebSubmit cluster) specified by the administrator of the system. For security reasons, modules can interact only with systems within this cluster.
 

Primary Interface

The primary interface to WebSubmit consists of a master page containing links to all of the application modules available on your site.  This main entry point is generated using the websubmit.cgi script; the URL to access this script depends on how you have configured your HTTP server to reference the WebSubmit CGI scripts (see the section on Installation).   websubmit.cgi generates three separate frames (using link.cgi, master.cgi, and footer.cgi).  The central frame (master page) contains links to application modules and its appearance is controlled using a master database.  The frame along the left border of the browser (the toolbar) contains links to WebSubmit information, information relevant to modules, a configuration module, and all application modules.  The footer contains a mail link to the WebSubmit administrator, thus allowing users to send bug reports or comments on the system.
 

Modules

Modules provide the functional interfaces in WebSubmit that allow users to accomplish tasks on remote systems.   Each separate module is generated from a CGI script, either hand-written by developers in the scripting language of choice, or automatically-generated using the WebSubmit form generation facilities.  The master database is used to specify the way in which a form is generated (manual or auto).   The module is presented to the user as an HTML form, which is filled out and submitted to the server for processing.   The server then executes commands related to the content submitted by the user.   There is a collection of modules that are applicable to all systems within the WebSubmit cluster: file transfer, file editing, and simple command execution.  These modules are contained in the WebSubmit distribution and can be used at any site.  Platform- or application-specific modules are used to perform more focused tasks.  Templates modules are included with the distribution that deal with job submission on systems that use Load Leveler, NQS, or LSF as their batch queuing systems.  Additional modules can be developed on an as-needed basis and simply plugged into the WebSubmit master page using the master database.

In an effort to address the needs of both advanced and novice users, some application modules have a modality assocaited with them.  The modules can be switched between two modes (BASIC and ADVANCED) depending on the needs of the user.   The difference between the two modes is basically just in the set of form elements that are presented to the user.  In general, modules added to the WebSubmit hierarchy by other developers will not possess this functionality, although it could be added in principle.
 

Configuration

The WebSubmit system was designed around the philosophy that different sites have different needs in terms of application modules.    The master database provides not only for adding new modules, but also for activating and deactivating existing modules so that they don't appear in the interface.  In addition, users at a given site may wish to configure the interface so that only certain modules appear on the master page.  A special configuration page (accessed through the toolbar) allows users to activate and deactivate modules for their own interface, as well as controlling the mode in which forms appear by default (only valid for modal forms).  User configuration information is changed by accessing the script config.cgi.
 

Authentication

The WebSubmit system is used to execute commands on remote systems for a  specified user.  As such, it is imperative to obtain the true identity of the user accessing the system.   WebSubmit provides seamless access to a whole group of computer systems (the cluster), but only requires users to enter a single password when they initially log in to the WebSubmit system.  The secure WebSubmit server was designed to be used with an HTTP server that requires bi-directional authentication (client-to-server and server-to-client) using the Secure Sockets Layer (SSL) protocol.   The server places the client certificate into the CGI environment, which allows for analysis by WebSubmit.  Valid WebSubmit users are given access to the system as long as their certificate data matches that contained in a local WebSubmit authentication database.  Details on the security architecture and maintenace of the authentication database can be found in the section on Authentication.
 

Databases

Databases serve as a simple technique for storing data about various aspects of WebSubmit configuration and functionality.   They are human-readable, can be easily accessed and modified, and can contain data for a wide array of uses.  Two of the primary aspects of WebSubmit (the master page and authentication) are controlled via simple databases.  In addition, they can be used for automatic form generation, automatic form processing, and automated task construction.  The databases in WebSubmit are ASCII files that contain a collection of records.  Each record possesses a unique key (atomic or composite) and a group of attributes, specified using colon-delimited fields.  More information on databases and their use and configuration in WebSubmit can be found in the sections on Data Storage Implementation, the Master Page, and Authentication.
 

Sessions

As previously stated, each module is an HTML form filled out by the user.  Each time a user fills out a form, this constitutes a session for that module.  To aid users with form input, sessions can be archived and restored as desired.  System-wide and user default sessions exist for many of the forms provided with the WebSubmit distribution, and these default values are loaded each time a module is accessed.  In addition, users can save named sessions in a library for each module and then load them at a later time.  This reduces the amount of effort required to fill out forms, especially if the form input does not vary greatly from invocation to invocation.  A more detailed discussion of sessions can be found in Sessions.