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 incoming requests to the appropriate proxy (uaproxy or gwsproxy). The dispatcher handles the GAS configuration and keeps 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).

Figure: GAS with VMProxy Architecture

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 between the VMproxies and the DVMs.

Components

  • Web Server
  • GAS Dispatchers
  • VMProxies
  • DVMs
  • Database Server

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 launch (based upon the GAS configuration file (as.xcf) and application configuration files). For example, the alias to serve up the Genero Web client demo application via a web server would be http://mywebserver/gas/ua/r/demo. In development environments, it is possible to exclude the web server using the standalone dispatcher (httpdispatch).

    The GAS supports the redirection of the start of an application or service to a delegation service to perform some controls to authenticate a user before granting access and starting an application.

  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 Tomcat®, while the isapidispatch.dll is for the Microsoft® 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 (uaproxy or gwsproxy) will depend on the application being requested. The dispatcher will route to the correct proxy and track 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.

  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.

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