Forms Server Architecture

Last updated on September 19th, 2015 at 06:38 am

Forms Server Architecture

Forms Server use a three-tier architecture, consisting of the following components:
• Client – A Java Applet running on the client PC that handles the UI presentation.
• Middle tier – The Web Listener and the Form runtime that handles the logic.
• Database tier – Data-intensive logic and data management.

The Forms runtime consists of several components:
• The Forms Server listener (f60srvm) on the middle tier. There is one process per database instance; it is used by new users to connect, and by HTTP for reconnections.
• The Forms Server runtime processes (f60webmx) on the middle tier. There is one process per currently connected user session. There may also be a pool of pre-spawned processes, waiting to be allocated to new users; this improves startup performance. In addition, there may be processes left from terminated sessions, particularly where the client has been killed instead of exiting cleanly. These processes should timeout and be closed down in due course.
• The client Java code consists of the Forms and Extended Windowing Toolkit (EWT) classes. EWT is Oracle’s Java toolkit, used by Forms to create and manage Java UI components such as windows, text items, tree controls and tabs. Each version of Forms requires a specific version of EWT; the EWT version will often be upgraded in Forms patchsets.
• In Applications, standard Forms functionality on the client PC has been extended by using Java Beans, which allow Applications developers to execute their own Java code on the client.

How the connection works
Step 1
The URL is run from a browser session via an HTTP request. If using the dynamic HTML method, the Listener calls the Forms CGI Cartridge to generate the HTML page dynamically. This involves replacing tokens within a base HTML file with parameters passed in the URL, or defaulting to values specified in the appsweb.cfg file.
If Forms load balancing is used, the Forms CGI Cartridge requests load information from the Load Balancing Server process, and uses this to dynamically modify the serverHost HTML parameter, so the user connects to the least loaded middle tier.
Step 2
The HTML page is returned to the client browser. Viewing the HTML page source in a browser should show valid HTML/Javascript, with the tokens having been replaced by valid data. Using Single Sign-on, it is not easy to view the HTML source, as the browser window’s menu has been disabled for security reasons.
Steps 3 and 4
Next, the browser reads the applet tags, mime types and other elements in the HTML page. It then launches the JInitiator plug-in, as defined by the MIME type, to replace the browser’s default JDK. JInitiator then launches the Forms Applet specified by the applet tags. First, it downloads the jar files specified in the archive tag via the WebDB or Apache listener. Once the jar files have been downloaded, the Forms Applet is started up.
Step 5
The Forms Applet is started up. It reads the serverPort, serverHost, and connectMode HTML parameters, and connects to the Forms listener using the host, port and protocol specified.
A connection is established with the Forms Listener process. A new Forms runtime process is forked, or, if applicable, the next free pool process is used. The socket connection between the Forms Applet and Forms Listener is handed off to the Forms runtime process, so the Applet communicates directly with the runtime process.

Leave a Reply