Utilizing Forms ServicesThere are four main components of Forms Services. The Forms Runtime Engine is essentially the same as the client/server Runtime of Forms 6i. Two of the other components are Java servlets, and one is the Java applet that displays the application's user interface.
The components of Forms Services are:
~ Forms Servlet
~ Forms Client
~ Forms Listener Servlet
~ Forms Runtime Engine
Comparing Architecture: Client-ServerIn cleint/server architecture, the Forms Runtime Engine must be installed on every client. In addition, the executable files are installed on each client as well. This makes it difficult to easily deploy an upgraded application, and access to the application is restricted to those machines on which the software is installed.
Comparing Architecture: Forms ServicesThe application server in Forms Services architecture is comparable to the client in client/server architecture, because that is where the Forms Runtime Engine is installed and runs. However, another tier is added in Forms Services architecture: that of the client browser. Forms Runtime no longer must be installed on every client, but only on the application server machine.
When a client browser sends an HTTP request for a Forms applications, only the User Interface layer is downloaded to the client machine as a generic Java applet, which is known as the Forms Client. Most of the processing takes place on the application server, but the Java applet knows how to display the UI for any form. After it is downloaded, it is cached on the client machine, so it never needs to the downloaded again.
Applications are easily deployed to the application server machine and can be accessed by any Web client with proper authentication.
Running a Form: Starting a Run-Time Session1) The user accesses the URL that indicates that a Forms application should be run.
2) The Oracle HTTP Server receives an HTTP request from the browser client and forwards the request to OC4J (Oracle Containers for J2EE), because the /forms/frmservlet path matches the OC4J mount directive for the Forms Servlet in the fomrs.conf file. OC4J maps the request to the Oracle Forms application, whose context root is /forms. It maps the request to the Forms Servlet by using the servlet mapping frmservlet specified in the web.xml file.
3) The Forms servlet dynamically creates an HTML page containing all the information to start the Forms session. The Forms Servlet (running in OC4J) processes the request as follows:
a. Opens the servlet configuration file. If the configFileName parameter is not specified, the default configuation file forms/server/formsweb.cfg is used.
b. Determines which configuration section to use from the formsweb.cfg file. For example, if the URL contains the query parameter config=test, it uses the [test] section.
c. Determines which base HTML file to use, based on the type and platform of the browser that made the request and the settings of various parameters in to formweb.cfg file (specifically, baseHTMLjinitiator, baseHTMLjpi, and baseHTML)
d. Performs variable substitution in the base HTML file, as follows:
Whenever a variable (like %myParam%) is encountered, the Forms Sevlet looks for a matching URL query parameter (for example, &myParam=xxx). If there is no matching URL query parameterr, it looks for a mattching parameter in the formsweb.cfg file. If a matching parameter is found, the %myParam% varible is replaced with the parameter value.
e. Sends the contents back as an HTML page to the user's Web browser. Depending on which base HTML file the Forms Servlet selected, the HTML page sent back to Web browser contains an Applet tag, object tag, or an Embed tag to start up the Forms applet. The Forms applet runs in a JVM, either the Web browser's native JVM or a plug-in JVM (like Oracle JInitiator or Sun's Java plug-in). If the base HTML file selected was for a plug-in, and if the user does not already have that plug-in installed, the user is prompted to install the plug-in. In the case of JInitiator, the download location is under the virtual path /forms/jinitiator (a virtual path defined in the forms.conf file).
4) OHS downloads a generic applet to the client after checking that it has not already been downloaded. The client caches the applet so that it can run future Forms applications without downloading it again. The location of the applet is specified by the applet codebase and archive parameters. For example, if the user is running the Oracle JInitiator, the applet code is loaded from the forms/java/frmall_jinit.jar file. The virtual path definition in the forms.conf file for /forms/java allows the applet code to be loaded from the Web server.
5) The client applet contacts the Forms Listener Servlet to start the session.
6) The Forms Listener Servlet starts an instance of the Forms Runtime Engine (frmweb) on the Forms Services Machine (middle tier). The Forms Listener Servlet passes to Forms Runtime any command-line parameters (such as form name, user ID and password, database, and so on) and any user-defined Forms Builder parameters that were included in the HTML file. The Forms Listener Servlet establishes a connection with the Runtime Engine.
7) The Runtime Engine connects to the database if needed and loads application executable files.
8) The Forms applet displays the application's user interface in the main window of the user's Web browser.
9) The Forms Listener Servlet, working through OHS, manages communication between the Forms applet and the Forms Runtime Engine.
Role of the Forms ServletHTTP requests for a Forms application are directed to the Forms Servlet, which is a Java servlet that creates the HTML file that initiates the download of the Forms applet and starts the application. The Forms Servlet also plays a part in single sign-on, but its main role is dynamically constructing the HTML file that starts the application.
OC4J invokes the Forms Servlet, passes the request object to it, and then passes the response object that returns the servlet's output to the client. The output from the Forms Servlet is an HTML file that invokes the Forms Client.
The Forms Servlet constructs the HTML file dynamically by merging information from the following sources:
~ Forms base THML file (basejini.html or other)
~ Forms Web configuration file (formsweb.cfg by default)
~ Application's URL parameters
The base HTML file contains variables for certain parameters. Values for those parameters can be supplied either by the Forms Servlet configuration file (formsweb.cfg by default) or by the URL itself. Values supplied in the URL take precedence over those supplied by the formsweb.cfg file.
For example, the formsweb.cfg file may define the parameter form=orders.fmx. if you send an HTTP request for the Forms Servlet withour specifying any parameter in the URL, the Orders form runs. If however, the URL requests to run the Customers form (http://server:port/forms/frmservlet?form=customers.fmx), then the Customers form runs.
Role of the Forms ClientThe Forms Client is the generic Java applet that is downloaded from the application server by the HTML file that starts the Forms application. It consists of a set of Java classes contained in JAR file. When downloaded, the Forms Client cached on the client machine and does not need to be downloaded again.
The Forms Client runs within the Java Runtime Environment on the client machine. It can display any form, regardless of the form's size and complexity.
Responsibilities of the Forms ClientThe Forms Client performs the following tasks:
~ Displays the form's user interface
~ Processes user interaction back to Forms Services
~ Processes incoming messages from Forms Services
Role of the Forms Listener ServletThe Forms Listener Servlet is a Java servlet that runs within OC4J. The mod_oc4j component of the Oracle HTTP Server directs HTTP requests for the Forms Listener Servlet directly to servlet instances.
Responsibilities of the Forms Listener ServletThe Forms Listener Servlet is in charge of:
~ Starting a Forms Runtime process for each client
~ Managing the network communications that occur between the client and its associated Forms Runtime process, through the Web server
This means that the client sends HTTP requests and receives HTTP responses from the Web server (Oracle HTTP Server) process itself. Because Oracle HTTP Server acts as the network endpoint for the client, there is no need to expose additional server machines and ports at the firewall.
Benefits of the Forms Listener Servlet~ Broad range of firewalls and proxies supported: With no direct connection between the client and the Forms Runtime process, this architecture supports any firewall or proxy that is able to work with any standard persistent servlet.
~ No protocol restriction:Although use of HTTP/1.1-compliant proxies provides better performance, this architecture works well with proxies implementing ony HTTP/1.0.
~ No extra process to manage: Because OC4J automatically instantiates the servlet, there is no need to start and stop a service or process.
~ No specififc certificate to purchase and manage for SSL deployment:The HTTPS connection exists only between the client browser and the Web server: there is no specific configuration at the Forms Services level.
~ Support for standard load-balancing techniques:Load balancing is performed for the Web server: there is no Forms-specific load balancing.
Role of the Forms Runtime EngineThe Forms Runtime Engine is a process on the Application Server that is started by the Form Listener Servlet. You cannot start the Forms Runtime Engine directly, as you could when running a Forms application in client/server mode with previous Forms versions. However, it performs a similar function to the client/server Forms Runtime Engine except that the user interface is handled by the Java-based Forms Client.
The Forms Runtime Engine has the following responsibilities:
~ Loads the Forms application files (.fmx, .mmx, .plx or .pll) and handles all the application logic and Forms functioanlity, executing the code that has been written into the application.
~ Connects to and communicates with the Oracle database
~ Manages requestes from the Forms Client and sends metadata to client to describe the user interface.
Selecting a Java Runtime EnvironmentA Web browser can run a Java applet because the browser provides a Java Runtime Environment (JRE). The JRE consists of:
~ Java virtual machine (JVM): A software execution engine that safely and compatibly executes the byte codes in Java class files.
~ Java core classes~ Supporting filesBecause the Forms Client uses advanced features, not all Web browsers are able to natively run the Forms client. To support these advanced features, the client machine must use one of the supported JREs. You can view the latest information on supported clients on OTN:
http://otn.oracle.com/products/forms/htdocs/10g/clientsod_forms10g.html.
You may choose to use JInitiator because it is certified with more browsers and all patch levels of Forms. When Forms Services is configured properly, JInitiator is automatically downloaded to the client machine when the user requests a Web page that requires it. The plug-in installs automatically if the browser is Internet Explorer; the user is prompted to install the downloaded plug-in if the browser is Netscape.
Configuring Forms Services to Use JinitiatorTo configure Forms Services to download JInitiator, you set a few parameters in the Forms Servlet configuration file. By default, the Forms Servlet is configured to use JInitiator. Below are the default values that relate to JInitiator 1.3.1.22:
~ To define the page displayed to users of Netscape to assist them in downloading and installing Jinitiator: jinit_download_page=/forms/jinitiator/us/jinit_download.htm
~ To specify the version of JInitiator to download and to use:Jinit_classid=clsid: CAFECAFE-0013-0001-0022-ABCDEFABCDEF
Jinit_exename=jinit.exe#Version=1,3,1,22
Jinit_mimetype=application/x-jinit-applet;version=1.3.1.22
~ To specify the base HTML file to use with JInitiator:baseHTMLjinitiator=basejini.htm
~ To specify the Java client (applet code) to use with JInitiator: Archive_jini=frmall_jinit.jar
The values to use for jinit_classid, jinit_exename, and jinit_mimetype for a particular JInitiator version can be found in the file jinit-version.ini (or jinit-version.txt) in the \jinit\us subdirectory of the Oracle Application Server or Oracle Developer Suite installation.
