Parent topic: Architecture of the Genero Application Server
Product Overview / Architecture of the Genero Application Server

Architecture overview

The architecture of the Genero Application Server uses dispatchers and proxies for optimal reliability, performance and integration in web servers.

The role of the dispatcher is to forward each new incoming request to the appropriate proxy (html5proxy, gwcproxy, gdcproxy, or gwsproxy). The dispatcher handles the GAS configuration and keep a persistent session table of all proxies it has started. In case of failure, the web server restarts the dispatcher, which uses the session table to reconnect to the proxies (and therefore to the applications).


The figure shows a single Web server interacting with a single GAS dispatcher. The GAS dispatcher is interacting with four VMProxies, which are then interacting with six DVMs. On the back end is a single database server. Communication between the Web Server and the GAS dispatcher is either FastCGI, ISAPI, or Servlet; Internet protocol is used between the GAS dispatcher and the VMProxies, and the DVM protocol is used bewteen the VMproxies and the DVMs.

Figure 1. GAS with VMProxy Architecture

Components

Note: The Genero Application Server and the Genero BDL runtime should be installed on the same machine.

How it works: the high-level overview

  1. In order to request an application, the end-user enters a URI that specifies which application to surface (based upon the GAS configuration file and application configuration files). For example, the alias to serve up the GWC demo application via a web server would be http://mywebserver/gas/wa/r/gwc-demo.In development environments, it is possible to exclude the Web Server. For more information, see Architecture for Development (Standalone GAS).

  2. The Web Server routes the request to the GAS dispatcher. GAS dispatchers refer to the connectors in charge of dispatching a GAS request to the appropriate proxy. There are different GAS dispatchers, each designed for a specific Web Server. For example, the fastcgidispatch.exe is for use with FASTCGI-compliant Web Servers such as Apache, while the isapidispatch.dll is for the Information Internet Services (IIS) Web Server.

  3. The GAS Dispatcher starts the VMProxy to handle the request. Each session requesting an application results in a VMProxy starting up; as a result, you will likely see multiple proxies running concurrently. The type of proxy started (html5proxy, gwcproxy, gdcproxy or gwsproxy) will depend on the application being requested. The dispatcher will route to the correct proxy. The dispatcher tracks the session and proxy information in a persistent session table. The presence of this information in the session table ensures that if a dispatcher is killed or restarted, the information needed to return to the proxy and running application is still present. For more information on the responsibilities of the GAS dispatcher, see GAS Dispatcher responsibilities.

  4. The VMProxy then launches the DVM for the requested application. It handles any child DVMs, keeps the DVM connections up, and handles the requests and responses appropriate for the type of proxy. For more information of the VMProxy responsibilities, see VMProxy responsibilities.

  5. The DVM interacts with the database server, as needed.

GAS Dispatcher responsibilities

The GAS Dispatcher is responsible for:

The GAS Dispatcher is stateless. As a result, you have reliability.

Here the list of dispatchers:

VMProxy responsiblities

In general, a VMProxy is responsible for:

Additional responsibilities depend on the VMProxy type:

Parent topic: Architecture of the Genero Application Server