5 Using OracleAS Forms Services with the HTTP Listener and OC4J

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:

Section 5.1, "OC4J Server Process"
Section 5.2, "Performance/Scalability Tuning"
Section 5.5, "Load Balancing OC4J"
Section 5.6, "Using HTTPS with the Forms Listener Servlet"

5.1 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 Section 5.2, "Performance/Scalability Tuning").

Figure 5-1, "OC4J Architecture and Forms Services" shows how Forms Services uses the OC4J architecture:

Figure 5-1 OC4J Architecture and Forms Services

HTTP request flow from OC4J to Forms Runtime Process.

5.2 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 Oracle Application Server Disk 1 CD or OTN at http://www.oracle.com/technology/documentation/.

5.3 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.4 Set the MaxClients Directive to a High value

You can let the HTTP Listener determine when to create more HTTPD daemons. Therefore, set the MaxClients 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.

MaxClients=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.5 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 Oracle Application Server Disk 1 CD or OTN at http://www.oracle.com/technology/products/ias/.

For more Forms-specific information, see the Oracle Developer Suite and Oracle Application Server Release Notes.

The following images illustrate four possible deployment scenarios:

Figure 5-2: Balancing incoming requests between multiple OC4J engines on the same host as the Oracle HTTP Listener.
Figure 5-3: Balancing incoming requests between multiple OC4J engines on a different host to the Oracle HTTP Listener.
Figure 5-4: Balancing incoming requests between multiple OC4J engines on multiple different hosts and multiple different hosts each running an Oracle HTTP Listener.
Figure 5-5: 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 Multiple OC4J engines on the same host as the Oracle HTTP Listener

Multiple OC4J instances and HTTP listener on the same host.

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

Many OC4J instances on different hosts from HTTP listener.

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

Many hosted OC4J instances, many hosted HTTP listeners.

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

HTTP listeners, different hosts; OC4J instances same host.

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

5.6 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.7 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.8 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 computer 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:

Start Oracle Wallet Manager
Open ORACLE_HOME/Apache/Apache/conf/ssl.wlt/default/ewallet.p12
Select menu option Export Wallet under the Operations menu
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 B, "JInitiator".

5.9 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.10 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 /forms, such as https://myserver.com/forms/frmservlet?config=myApp.

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

5.11 Oracle Forms Services and SSL

By default, the HTTPS port is not enabled when installing Oracle Application Server 10g. There are two steps to enable SSL: enable the HTTPS port in Oracle HTTP Server, then enable Web Cache to accept HTTPS connections from Oracle HTTP Server.

Note:

If you've coded your Forms application such that the logon dialog appears (because you haven't specified the user/password as part of the configuration for the application you're running) and you're not running your application with SSL/HTTPS, you should be aware that there is a potential security issue. The password that is entered in the logon dialog will be sent across the network.

5.11.1 Configuring Oracle HTTP Server to use SSL

When you enable Oracle HTTP Server to use SSL, you modify a portion of the Oracle Process Manager and Notification Server (OPMN) configuration file. After you've modified and saved this file, you will need to restart OPMN processes.

To configure Oracle HTTP Server to use SSL:

Open ORACLE_HOME/opmn/conf/opmn.xml in a text editor and find this block of code:

 <ias-component id="HTTP_Server">
    <process-type id="HTTP_Server" module-id="OHS">
            <module-data>
                    <category id="start-parameters">
                            <data id="start-mode" value="ssl-disabled"/>
                    </category>
            </module-data>
    <process-set id="HTTP_Server" numprocs="1"/>
</process-type>
</ias-component>

Change the start-mode parameter value to ssl-enabled:

 <ias-component id="HTTP_Server">
    <process-type id="HTTP_Server" module-id="OHS">
            <module-data>
                    <category id="start-parameters">
                            <data id="start-mode" value="ssl-enabled"/>
                    </category>
            </module-data>
    <process-set id="HTTP_Server" numprocs="1"/>
</process-type>
</ias-component>

Force OPMN to reload the modified opmn.xml configuration file:

opmnctl reload

5.11.2 Configuring Oracle Web Cache to use SSL

Use the Web Cache Admin page to enable HTTPS connections from Oracle HTTP Server.

To configure Web Cache to use SSL:

Open the Web Cache Manager page. If you configured OracleAS Web Cache during installation, you can access it as http://hostname.domain:port. Its default port is 4000, or as the Web Cache HTTP Listen port number as listed in:
- Solaris: ORACLE_HOME/install/portlist.ini
- Windows: ORACLE_HOME\install\portlist.ini
Login as the application server administrator.
Locate the Port section in the navigator frame and click Listen Ports.
Click Add.
From the For Cache dropdown list, select the target Web Cache.

Enter the following information, as shown in Table 5-1:

Table 5-1 HTTPS Port Configuration Information

Setting	Description
IP Address	Any valid IP address
Port Number	443
Protocol	HTTPS
Require Client-Side Certification	Enable or disable client-side certificates.Select Require Client-Side Certificate to enable OracleAS Web Cache to require browsers to provide SSL certificates. You'll need to import ewallet.p12 file from `webcache/wallet/default`. A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user's public key and must be digitally signed by a trusted certificate authority.
Wallet	Enter the directory location of the wallet. This directory must contain an existing wallet. This wallet is used for administration, invalidation, and statistics monitoring of HTTPS requests for sites hosted by OracleAS Web Cache.Oracle recommends entering the location, even if the default is being used. The default location is `ORACLE_HOME/webcache/wallets/default`.

Note:
When selecting and using client-side certification, you must use Sun Java Plug-in 1.4.2 or later. Visit http://java.sun.com/ for more information.
Click Apply Changes.
Restart Web Cache.

5.11.3 Running a Form with SSL

Running a Forms application that uses an HTTPS port requires a certificate to be imported. If you access Web Cache through port 4443, you need to import the Web Cache certificate. If you access Oracle HTTP Server through port 4444, you need to import the Oracle HTTP Server certificate.

To import the Web Cache certificate:

Open ORACLE_HOME\webcache\wallets\default
- Windows: Invoke Wallet manager launch.exe
- Solaris: owm
Open ORACLE_HOME\WebCache\wallets\default.
Enter welcome as the password.
Select Auto Login.
Select FOR TEST PURPOSES ONLY.
Choose [Operations]-[Export Trusted Certificate] and provide a name.
Open this file in a text editor and copy all of its contents and append it to C:\Program Files\Oracle\JInitiator 1.3.1.21\lib\security\certdb.txt.
Run the Form Servlet as https://computer.mycompany.com:4443/forms/frmservlet.
Verify that the JInitiator log window shows the HTTPS protocol.

To import the Oracle HTTP Server Certificate:

Invoke Wallet manager:
- Windows: Invoke Wallet manager launch.exe
- Solaris: owm
Open ORACLE_HOME\Apache\Apache\conf\ssl.wlt\default.
Enter welcome as the password.
Select Auto Login.
Select FOR TEST PURPOSES ONLY.
Choose [Operations]-[Export Trusted Certificate] and provide a name.
Open this file in a text editor and copy all of its contents and append it to C:\Program Files\Oracle\JInitiator 1.3.1.21\lib\security\certdb.txt.
Run the Form Servlet as https://computer.mycompany.com:4444/forms/frmservlet.
Verify that the JInitiator log window displays the HTTPS protocol.

5.11.4 Configuring SSL with a Load Balancing Router

Running a Forms application that uses an HTTPS port requires a certificate to be imported. If a Forms server is behind a load balancing router, and SSL terminates at it, you need to import the certificate from the load balancing router.

Follow these steps to enable SSL with your Forms applications over a load balancing router:

Open the Security Alert dialog by opening https://mycomputer.us.oracle.com:443/forms/frmservlet in a Web browser.
Click View Certificate.
Click the Details tab in the Certificate dialog.
Click Copy to File...
In the Welcome page of the Certificate Export Wizard, click Next.
In the Export File Format page, select Base-64 encoded X.509 (.CER), then click Next.
Enter a file name such as c:\temp\forms, then click Next.
Click Finish.

A message appears saying that the export was successful.
Click OK.
Close the Certificate Export Wizard, but keep the Security Alert dialog open.
Open c:\temp\forms.cer in a text editor.
Copy the contents of the file into JInitiator's certdb.txt file in lib\security.
Save certdb.txt.
Reopen the Security Alert dialog and click Yes.