Runtime Model

There are a number of components to the web-deployed forms runtime environment. The best way to understand what the components are responsible for and how they work together is to examine the lines of communication during the two main events: startup and runtime.

STARTUP STEPS
The first step in starting a form is the client request, via a URL (uniform resource locator), to the application server for a startup HTML file. The startup HTML file contains special HTML tags that start the JVM and ensure that the proper Java class files are available for the session. There are examples of the HTML startup file in the online documentation as well as in the Forms directory. The file uses different tags for Internet Explorer and for Netscape but you can embed both commands in a single file. The web listener on the application server determines that the URL indicates a standard static HTML file, retrieves the HTML from the file system, and sends it to the client browser.
The Forms 6i install loads two types of files that are used when starting up the first form. These are loaded into the forms60/admin/server directory. The first type of file is the startup file, which has two manifestations. BASE.HTM (used for appletviewer or native browser applets) and BASEJINI.HTM (used when JInitiator is used to display the form) contain values that affect the startup, some of which are specified as replaceable parameters. These files work the same way as the STARTUP.HTML file described above, but they work with the second type of file, the configuration file, to fill in the values of the various startup parameters that can be used in this environment. The configuration file, called FORMSWEB.CFG, contains the same type of parameters. Values that are assigned to the parameters in this file are used for the replaceable parameters in the startup files. The sample HTM files that are used should be complete enough that you would not need to change them. Oracle recommends that you make changes to the parameter values in the configuration file. This will allow you to keep different configuration files for different applications and customize the parameters for each application. There is more information on the contents and workings of these files in the OIN document Deploying Forms Applications to the Web with Forms Server document (Help→Manuals in the Form Builder). The next set of steps handles the startup of the Forms runtime and the form itself. The tags in the HTML file indicate that JInitiator will be used to display the form through the standard plug-in extension mechanism provided by the browser. They also indicate the Java class files that are required by the Java applet and that the applet start a connection with the Developer Forms Server listener (through the serverArgs and serverPort parameters). This information in the HTML file is sent to the web listener, which passes the request for a connection to the Forms Server Listener so that the Forms Server Listener can establish the connection with the client. The Java class files are retrieved from the application server (if they have not been cached on the client machine) and sent to the client browser. The browser starts the Forms client applet session as a separate window or as a window embedded in the browser. The Forms client contacts the server to request a runtime session. The Forms Server Listener then starts up a Forms Runtime Engine or Forms servlet session.

RUNTIME STEPS
The Forms Server Listener breaks the connection between the web listener and browser and sets up a TCP/IP socket connection directly from the Forms Runtime Engine to the browser. The form running in that session accesses forms and other files in the file system and communicates with the database through a standard SQL*Net or Net8 connection. The Forms client session is a child process of the browser session.