How Does the Application Dispatcher Work?

Overview of How the Application Dispatcher Works

The SAS/IntrNet Application Dispatcher enables you to offer the power of SAS to Web users without having them install client software on every desktop. Here's a summary of how it works:

Users enter information in an HTML form using their Web browser and then submit it. The information is passed to the Web server, which invokes the first component of the Application Dispatcher, the Application Broker.
The Application Broker accepts data from the Web server and sends it to the second Application Dispatcher component, the Application Server.
The Application Server invokes a SAS program that processes the information.
The results of the SAS program are sent back through the Application Broker and Web server to the Web browser and the awaiting users.

The following diagram, which is described in detail later, illustrates how the Application Dispatcher submits and processes a communication request.

A Request Is Submitted to the Application Broker

Web users submit information and processing requests via their Web browsers. The interface to the Application Dispatcher is usually an HTML form that users access from their Web browser, but users can also access the Application Dispatcher through a hypertext link that contains the URL and required parameters that are necessary to run the program.

Depending on the design and purpose of the form, users can

formulate queries by selecting items from lists, check boxes, or radio buttons
specify analysis variables, processing options, and reporting options by selecting items from lists, check boxes, or radio buttons, or by completing text entry fields
input data by completing text entry fields

When a user selects the Submit button or a hypertext link, the Web browser sends the information to the Web server, which immediately invokes the Application Broker. The Application Broker is a Common Gateway Interface (CGI) program that runs on any Web server that supports the CGI standard. The Application Broker then forwards the request to the Application Server.

In addition to providing the user interface, the HTML form provides

the location of the Application Broker, as defined in the ACTION= attribute of the HTML FORM tag
the name of the service that is used to process the request, as specified in the _SERVICE field
the name of the program that executes the request, as specified in the _PROGRAM field
generic name and value information that is contained in optional fields

To learn how to enter these fields in HTML code and how to make your own Application Dispatcher form and its associated SAS code, see The Input Component and The Program Component.

The Application Broker Processes the Request

The Web server invokes the Application Broker each time a user submits a request. The location of the Application Broker CGI program is provided by the ACTION= attribute in the HTML form or by the HREF= attribute in a hypertext link.

The _SERVICE field in the request specifies the service name. The Application Broker reads its configuration file to get the definition of the requested service. The Application Broker then connects to an Application Server that is associated with the service. Application Dispatcher currently supports three types of services:

Socket Service

specifies one or more Application servers that run permanently on the SAS Server and wait for a request. The Application Broker either picks an available server or queries the Load Manager for an idle server.

Pool Service

identifies multiple servers (a pool of servers) that might be running. The Application Broker contacts the Load Manager in order to find an available Application Server. If no server is available, the Load Manager can start a new server that then handles the request. After the request is completed, the new server is added to the service pool and is available for future requests.

Launch Service

enables the Application Broker to launch a new Application Server for each new request. The Application Server runs on the Web server machine and terminates when the request is complete.

The Application Broker forwards information from input fields and any configuration information that is specified in the Application Broker configuration file. For socket services, the configuration file also specifies the machine name or IP address and the TCP/IP port name or number that receives the request.

The Application Server Processes the Request

It can be helpful for you to know the specific steps that the Application Server performs when it handles a request. This information can be useful when you are enhancing server performance or performing administrative tasks. The following list describes how the Application Server processes a request:

After the Application Server is started, it listens on the TCP socket for a request.
When the server receives a request, it examines the _PROGRAM parameter to determine the type and location of the program that is being run. If the Application Server does not find the program, it generates an error page that displays in the user's browser.
The server creates macro variables and a SAS Component Language (SCL) list that contains the input name/value pairs so that the program can access them.
The Application Server creates a _WEBOUT fileref connection so that SAS can send data back to the browser.
The server runs the program, cleans up, and then waits for a new request. If the server was started for a launch service and no session was created by the user program, the server exits immediately.

Program Output Is Sent to the Application Broker

The program output is sent directly to the Application Broker by using a predefined file reference. The format of the output is defined by the HTTP standard. See HTTP Headers for more information.

As the Application Broker receives the program output, it does a quick consistency check on the HTTP headers and sends the results back to the Web server, which streams the results back to the browser. Because of the streaming, results begin to appear in the browser before the program has finished processing.

How does the Load Manager Work?

You can use the Load Manager, which is a separate, optional process, to optimize the use of Application Dispatcher resources on a network. The Load Manager can route requests to available idle servers and start additional available servers as needed.

The Load Manager listens for requests from Application Brokers for Application Servers that are idle.
If a server is not designated as being busy, it is allocated to the requesting Application Broker.

When the Application Server receives the job, it notifies the Load Manager that it is busy processing the request. The following diagram illustrates how the Application Server notifies the Load Manager after it has received a request.

After completing the job, the Application Server again notifies the Load Manager that it is free to work on another request. The following diagram illustrates how the Application Server notifies the Load Manager after it is free to process the next request.

If no servers are free, the request is queued by the Load Manager until a server becomes available or until the time-out value is reached. For pool services, the Load Manager can start a new server to process the request. The following diagram illustrates how the Load Manager starts a new server to process the request.

Pool Services Diagram - queuing a server

The new server is then added to the pool of servers for that service. The following diagram illustrates how a new server is added to the pool of servers.

By using a Load Manager to maintain the state of Application Servers, requests are distributed to idle servers. Each Application Server notifies the Load Manager when it starts and completes a job by using the Load Manager socket address that is passed by the Application Broker. This data is used by the Load Manager during subsequent requests to determine which Application Servers are busy and to direct the Application Broker to use an available idle server.

Note: If the Load Manager is not installed, the Application Broker randomly selects an Application Server to process the request. Random selection of an Application Server is adequate for low-traffic environments. However, as traffic increases, requests can become stalled while waiting for a busy server even if another server is idle.