5
Using OracleAS Forms Services with the HTTP Listener and OC4J

5.1 Introduction

Oracle Application Server Containers for J2EE (OC4J) is a complete J2EE (Java 2 Platform Enterprise Edition) server written entirely in Java that executes in a standard Java Runtime Environment (JRE). It provides a complete J2EE environment that contains, among other things, an OC4J Web container.

This chapter contains the following sections:

5.2 OC4J Server Process

In a simple scenario, the Forms Servlet renders the start HTML file and provides the information about the Forms Listener Servlet to the client. An HTTP request is then received by the Oracle HTTP Server Listener, which passes it off to the Forms Listener Servlet running inside OC4J. The Forms Listener Servlet establishes a Forms Server runtime process and is responsible for on-going communication between the client browser and the runtime process. As more users request Oracle Forms sessions, the requests are received by the Oracle HTTP Server Listener. The HTTP Listener again passes them off to the Forms Listener Servlet, which will establish more runtime processes. The Forms Listener Servlet can handle many Forms runtime sessions simultaneously. While there is, of course, a limit to the number of concurrent users, the architecture presents a number of opportunities for tuning and configuration to achieve better performance (see Performance/Scalability Tuning).

OC4J runs using the following architecture:

Figure 5-1 OC4J Architecture and Forms Services

Text description of mod_oc4j.gif follows.

Text description of the illustration mod_oc4j.gif

5.3 Performance/Scalability Tuning

The steps for tuning the Forms Listener Servlet are similar to steps for tuning any high throughput servlet application. You will have to take into account resource management and user needs for optimal tuning of your particular Forms Services configuration. For more information, see Oracle Application Server Performance Guide (available on OracleAS Disk 1 CD or OTN at http://otn.oracle.com/docs/products/ias/content.html).

5.3.0.1 Limit the number of HTTPD processes

To avoid spawning too many HTTPD processes (which is memory consuming) set the following directive in the Oracle HTTP Listener configuration file (httpd.conf):

KeepAlive Off

If you must use KeepAlive On (for example, for another application), make sure that KeepAliveTimeout is set to a low number (for example, 15 seconds, which is the default).

5.3.0.2 Set the MaxClient directive to a High value

You can let the HTTP Listener determine when to create more HTTPD daemons. Therefore, set the MaxClient directive to a high value in the configuration file (httpd.conf). However, you need to consider the memory available on the system when setting this parameter.

MaxClient=256 means that the listener can create up to 256 HTTPD processes to handle concurrent requests.

If your HTTP requests come in bursts, and you want to reduce the time to start the necessary HTTPD processes, you can set MinSpareServers and MaxSpareServers (in httpd.conf) to have an appropriate number of processes ready. However, the default values of 5 and 10 respectively are sufficient for most sites.

5.4 Load Balancing OC4J

The Forms Listener Servlet architecture allows you to load balance the system using any of the standard HTTP load balancing techniques available.

The Oracle HTTP Server Listener provides a load balancing mechanism that allows you to run multiple OC4J instances on the same host as the HTTP process, on multiple, different hosts, or on any combination of hosts. The HTTP Listener then routes HTTP requests to the OC4J instances.

The following scenarios are just a few of the possible combinations available and are intended to show you some of the possibilities. The best choice for your site will depend on many factors.

For a complete description of this feature, refer to the OC4J chapter in the Oracle Application Server Performance Guide (available on OracleAS Disk 1 CD or OTN at http://otn.oracle.com/docs/products/ias/content.html).

For more Forms-specific information, see the OracleDS Forms Developer and OracleAS Forms Services Release Notes.

The following images illustrate four possible deployment scenarios:

Balancing incoming requests between multiple OC4J engines on the same host as the Oracle HTTP Listener.
Balancing incoming requests between multiple OC4J engines on a different host to the Oracle HTTP Listener.
Balancing incoming requests between multiple OC4J engines on multiple different hosts and multiple different hosts each running an Oracle HTTP Listener.
Balancing incoming requests between multiple OC4J engines on a single host but with multiple different hosts each running an Oracle HTTP Listener.

Figure 5-2 Case 1: Multiple OC4J engines on the same host as the Oracle HTTP Listener

Text description of the illustration oc4ja.gif

Figure 5-3 Case 2: Multiple OC4J engines on a different host to the Oracle HTTP Listener

Text description of the illustration oc4j2.gif

Figure 5-4 Case 3: Multiple OC4J engines and multiple Oracle HTTP Listeners on different hosts

Text description of the illustration oc4j3.gif

Figure 5-5 Case 4: Multiple Oracle HTTP Listeners on different hosts with multiple OC4J engines on one host

Text description of the illustration oc4j4.gif

For more information about tuning and optimizing Forms Services with the HTTP Listener and OC4J, see Oracle Application Server Performance Guide (available on OracleAS Disk 1 CD or OTN at http://otn.oracle.com/docs/products/ias/content.html).

5.5 Using HTTPS with the Forms Listener Servlet

Using HTTPS with Oracle Forms is no different than using HTTPS with any other Web-based application.

5.5.0.3 Server Requirements

HTTPS requires the use of digital certificates. Because Oracle Application Server Forms Services servlets are accessed via your Web server, you do not need to purchase special certificates for communications between the Oracle Forms client and the server. You only need to purchase a certificate for your Web server from a recognized Certificate Authority.

5.5.0.4 Client Requirements: Using HTTPS with Oracle JInitiator

If your end users are running Oracle JInitiator as the Web browser JVM, then you need to check that the Root Certificate Authority of your Web site's SSL certificate is one of those defined in the JInitiator certdb.txt file.

The certdb.txt file is usually found under c:\program files\oracle\jinitiator <version>\lib\security on the machine where JInitiator was installed.

Note: If you are running with Oracle Application Server Web Cache enabled (which is usually the case), you should use the file <OracleAS_HOME>/webcache/wallets/default/b64certificate.txt. If you are not running with Web Cache (that is, you are accessing the Oracle HTTP Server directly) you will need to create the demo root certificate file as follows:

1. Start Oracle Wallet Manager

2. Open <ORACLE_HOME>/Apache/Apache/conf/ssl.wlt/default/ewallet.p12

3. Select menu option Export Wallet under the Operations menu

4. Save as text file "demoCertCA.txt"

Once you have the required certificate file, you should follow the instructions to configure JInitiator to use the certificate (appending it to JInitiator's certdb.txt file).

For more information about Oracle JInitiator, see Appendix A, "JInitiator".

5.6 Using the Hide User ID/Password Feature

With Oracle Application Server Forms Services, the userid parameter value is not included in the HTML generated by the Forms Servlet.

By default, this feature enables Forms Services to:

Specify the user/password@database using a parameter called "userid" (not case-sensitive). This is already done if you are using the default baseHTML files, which are provided when Oracle Forms is installed. They contain syntax like "userid=%userid%".
Use the Forms Servlet rather than static HTML files.

5.7 Using an Authenticating Proxy to Run Oracle Forms Applications

The default configuration as set up by the Oracle Application Server installation process supports authenticating proxies. An authenticating proxy is one that requires the user to supply a username and password in order to access the destination server where the application is running. Typically, authenticating proxies set a cookie to detect whether the user has logged on (or been authenticated). The cookie is sent in all subsequent network requests to avoid further logon prompts.

If users are running Netscape with JInitiator, there are certain configuration requirements necessary to ensure that the proxy's authentication cookie gets sent with all requests to the server. The basic requirement is that every URL that JInitiator has to access (for the Jar files AND for the Forms Listener Servlet) MUST be under the document base of the HTML page. This is achieved by using the Forms Servlet to generate the page, invoking it using a URL under /forms90, such as https://myserver.com/forms90/f90servlet?config=myApp.

The codebase and server URL values set up by the Oracle Application Server installation process are /forms90/java and /forms90/l90servlet. As these are under the document base of the page (/forms90), authenticating proxies will work.

5 Using OracleAS Forms Services with the HTTP Listener and OC4J