Up
Why Deploy on the Web?
Architecture for Web Deployment
Configuration
Security
Deploying an Application
Improving Your Application Interface

Architecture for Web Deployment

The following table lists the components of the architecture for Web deployment, and describes the role of each component. Later sections describe How Web Deployment Works at Runtime and How Links Between Pages Work.

The browser initiates the request through the web server.
The application server runs the main Dynamic 4GL program. The term application server can refer to either the physical computer or the software process that runs the application. For Dynamic 4GL, the process is named fglrun.
The database server handles interactions with your Informix database (for example, Informix Dynamic Server).
The web server spawns and communicates with the client.
The HTML client (fglcl) handles communication with the HTML server.
The HTML server (fglhtmld) handles and controls the HTML client's runner.
The application server process (runner) reads and interprets the application P-Code.

The fglhtmld server process and the fglcl client process communicate with one another and with external components such as the Web server and the application server process in order to execute 4GL programs with data supplied through an HTML document.

Additional points to notice about this architecture are the following:

  • The HTML server usually runs on the application server computer.
  • The HTML client always runs on the same computer as the web server.
  • The entire architecture can exist on the one computer, but this is not typically the case.

The following figure shows an overview of the software architecture:

 

How does Dynamic 4GL work?

The following components are shown in the figure:

  • Application Server: The server (fglrun) that runs the main Dynamic 4GL program.
  • Web Server: The server (httpd) that makes web pages available to browsers.
  • HTML client: The Dynamic 4GL client.
  • WTK: The Windowing Tool Kit. This is the HTML client on Windows platforms.
  • ASCII terminal, local intranet: The HTML client can also reside on other platforms.
  • HTML server: fglhtmld.

How Web Deployment Works at Runtime

The following figure shows an overview of the process followed by the HTML client, HTML server, and web server as your application starts.

How Web Deployment Works at Runtime

(This description omits network security details.)

The steps are as follows:

  1. The HTML server process, fglhtmld, starts and listens to the TCP/IP ports that you defined in the configuration file, fglcl.conf (the default value is 6500).

    This action:

    can be done manually (e.g. on a development system) or
    can be automated:
    On Unix systems, it is normal to see such daemons under the control of the inetd daemon, which controls and supervises system and communication daemons.
    On Windows NT, such programs are services (however, as of version 1.00.xx, the server is not a system service).

  2. A browser issues a request to the web server.
  3. The web server (also called httpd) communicates via TCP/IP, usually on port 80.
  4. The web server detects that a request has been made to a 4GL program rather than a static HTML page. In this case, it will create an instance of the HTML client (fglcl).
  5. According to the HTML client's configuration file and the argument given by the web server, the client can now contact and fetch information from the web server.

    Communication between the client and the server is through sockets.

  6. If this is a new request, the HTML server creates a new instance of the application server process, named fglrun. If this is a continuation of a previous process, it sends the data to the application server handling this browser client. In either case, a new web page is created from the output of the application server.
  7. The HTML server sends a message to the new application server process and receives a reply.
  8. The HTML server processes the message from the application server process.

    Communication between the server, the HTML server (fglhtmld), and the application server process (fglrun) is done with anonymous pipes.

  9. The HTML server sends the web page to the client.
  10. The HTML client sends the web page to the web server.
  11. The page is then sent to the browser in the same way as a normal HTML page.

    Communication between the the web server and the browser uses the HTTP protocol.

  12. The application server process receives information from the HTML server (fglhtmld) that terminates it (the program ends, or the user exits the program).
  13. The server receives termination information from the application server process and sends the normal termination page to the client. The client sends this page to the web server, which sends it to the browser in the same way as a normal HTML page.
  14. The session ends.

How Links Between Pages Work

The HTML client stops after each transaction. A link, however, must be made as a follow-up.

Links between pages are based on the process id (enciphered) of the application server process (fglrun) and a sequence number.

Nothing appears on the client side, so you cannot copy and paste the URL to another browser. The only visible item is the application name, which has the form: fglcl?appname or fglcl.exe?appname.