This section looks at the following topics:
The GAS works with a user agent/front end, a Web server, the Genero Web Client daemon (gasd), a Dynamic Virtual Machine (DVM), and a database server to provide Web applications to the user.
The components involved are shown in the diagram above.
Communication is bi-directional, with information flowing back to the user agent.
In development, it is typical to have the user agent (browser) connect directly to the application server, bypassing the Web server and Connector. For production, it is recommended that you include the Web server in your GAS solution.
The user agent, Web server, Genero BDL, and database server are not included. For information about supported third-party software, refer to System Requirements (in the section Installation).
The diagram above provides another look at connections between a user agent, the client front end, and a DVM. It also identifies which files are needed by each engine.
When running an application, there are two methods of connecting to the application server:
Direct connection allows the user agent to connect directly to the Application Server, without using a Web Server. Direct connection is provided to simplify the architecture of development environments. It is not recommended for production environments.
Notes:
When you connect through a Web Server, the GAS Connector routes requests from the Web server to an application server. Connectors are available in two forms:
For example, if you installed the connector in the cgi-bin directory of your web server, you'll access your application using the URL:
http://server:port/cgi-bin/fglccgi/wa/r/application
or for Windows systems:
http://server:port/cgi-bin/fglccgi.exe/wa/r/application
The IIS connector is named fglcisapi.dll. To access to your application through this connector, you use the syntax:
http://server:port/scripts/fglcisapi.dll/wa/r/application
The following diagram illustrates the possible path of an application request.
The Client sends a request to the Web Server. There are two methods that the client might use to identify which Web Server to send the request to. It can make a DNS request, and the DNS request can specify which Web Server to send the request to. The DNS database can be updated while monitoring the Web Servers for availability. The other solution is to use hardware (layer switch) that dispatches the load and monitors the system.
The Web Server starts the GAS Connector (which is on the same physical machine as the Web Server). For the initial connection, the GAS Connector reads from its configuration file (connector.xcf) and randomly chooses from the list of available Application Servers. If the selected Application Server does not respond, it attempts to connect to the next available Application Server, and so on until a successful connection is established.
The Application Server attaches to an available Dynamic Virtual Machine (DVM) to handle the request. If no DVM is available to process the request, the Application Server attempts to create a new DVM to process the request.
The Virtual Machine connects to the Database (or Database Cluster or Replica).
When you define a Web Service application, you specify execution parameters that determine the number of DVMs available at any one time to service a request for that Web Service. These parameters are defined in the Application Server configuration file.
When you define a Web Service application, the EXECUTION element sets the runtime environment for that application by specifying the parameters for executing the Web Service application. This application configuration can either reference a predefined SERVICE_APPLICATION_EXECUTION_COMPONENT (and inherit the runtime environment settings defined for that component) or the individual execution elements can be explicitly set for the application.
Within the EXECUTION element, the POOL element sets the limitations regarding the number of Virtual Machines that are attached to a Web Service. You specify three values within a POOL element:
For the discussion that follows, assume the following values have been specified for the three pool elements for a Web Service applicaiton:
START=3
MIN_AVAILABLE=2
MAX_AVAILABLE=5
When the Genero Application Server first starts, the START element defines how many DVMs to start for a particular Web service. For our example, this means that 3 DVMs are started.
In addition to the POOL elements mentioned above, a Web Service application definition also includes a DVM_FREE timeout. The DVM_FREE timeout, specified in seconds, is used to shut down a DVM that has no request to process. After DVM_FREE seconds pass, if there are no requests to process, the DVMs are released to reach MIN_AVAILABLE. For this example, one DVM is released.
As a request come in, if there are no available DVMs free to process the request, then a DVM is launched to process the request. For example, if six requests come in, then six DVMs are started to process those six requests.
Once a request is completed, the DVM is immediately released to reach the MAX_AVAILABLE number. It does NOT wait for DVM_FREE to release the DVM. In our example, this reduces the total number of DVMs to five.
After DVM_FREE time, if there are no more requests to process, then the DVMs are released to reach MIN_AVAILABLE number.
The only way to limit the number of DVMs is to use the MaxLicenseConsumption attribute within the SERVICE_LIST element. This attribute limits the amount of DVMs that can be concurrently running across all applications referenced by the SERVICE_LIST element.
When this attribute is used, a DVM can be placed in the queue waiting for an available DVM. Once in the queue, request waits in the request queue until a DVM becomes available and is able to process that request OR the REQUEST_QUEUE timeout is reached. If the REQUEST_QUEUE timeout is reached, the Genero Application Server returns an error message and logs "REQUEST_QUEUE timeout expired".
For example, if MaxLicenseConsumption=5 and a new request comes along, then that request waits in the request queue until a DVM becomes available and is able to process that request OR the REQUEST_QUEUE timeout is reached.
