How delegation works

This section gives details about the delegation process.

Following steps are performed when an delegation occurs:

  1. An application or web service start is requested. The type of request is defined by the /ua/r, /wa/r, /ja/r, or /ws/r path segments in the URI.
  2. The Genero Application Server dispatcher passes the request to the REST service identified as the delegation service. The delegation service is specified in the application's configuration. The delegation service is written in Genero and managed by the Genero Application Server as a standard REST Web service. The delegation service should reside on the same GAS as the application.
  3. The REST service instructs the Genero Application Server to either:
    • Refuses the start of the application or service.
    • Allows the application to start. The delegate service is able to add some environment variables to give additional information to the allowed application.
    • Allows for a service to any request forwarded to it. All Web service requests are in /ws/r so they all go to the delegate service.

The delegation REST service refuses the start of the application or service

In this scenario, the delegation REST service refuses the start of the application or service. The REST service communicates with the user agent in HTTP using the com.HTTPServiceRequest object. For example, it could return an XHTML form asking for a user name and password to grant access to the application or service.


Diagram shows the communication path from the user-agent to the dispatcher, from the dispatcher to the REST service GWSProxy. When the service refuses to start the application, the response is sent back to the user agent (by way of the dispatcher). The steps are detailed in the surrounding text.

Figure 1. REST service communicates with User Agent but does not start the application or service

In this figure:
  • (1) Start a new application or service of the form /wa/r, /ja/r or /ws/r.
  • (D) Delegate application or service start to the service described in the configuration file (xcf).
  • (2) Forward the request to REST service for delegation process
  • (A) REST program responds directly to the User Agent (with a login page, for instance).
  • (3) (4) Response is sent back to the User Agent.

The delegation REST service allows the start of the application or service

In this scenario, the delegation REST service allows the start the application or service as if launched directly from the user agent.


Diagram shows the communication path from the user-agent to the dispatcher, from the dispatcher to the REST service GWSProxy, back to the dispatcher, which then starts the application or service. All subsequent communication is between the application or service and the user agent (by way of the dispatcher). The steps are detailed in the surrounding text.

Figure 2. REST service approves application or service start

In this figure:
  • (1) Start a new application or service of the form /wa/r, /ja/r, or /ws/r.
  • (D) Delegate application or service start to the service described in the configuration file (xcf).
  • (2) Forward request to REST service for delegation process
  • (B) Genero REST program allows to start the proxy (login and password are correct, for instance).
  • (3) (4) Response is sent back to the User Agent.
  • (5) REST program response with HTTP code 307 and description string.
  • (C) Dispatcher detects REST command and starts the proxy
  • (6) Dispatcher forwards response from REST program to proxy
  • (7) (8) Any request is forwarded to the proxy without going to the REST service (excepted for GWS that starts a new delegation process).
To allow the application to start, the Genero REST service returns a specific HTTP code and description to the dispatcher using the com.HTTPServiceRequest object. When the dispatcher gets such an HTTP response from the REST service, it starts a new proxy and forwards the request to it, as if no delegation had taken place.