3
Preview of Configuration Choices

3.1 Introduction

This chapter previews the choices you will face during the configuration of Forms Server and offers descriptive information to assist you in understanding the differences between options. Configuration choices include:

• Socket connection, HTTP connection, or HTTP with SSL (secure sockets layer) connection?

• Viewing forms in Internet Explorer using the native JVM, or viewing forms in Internet Explorer or Netscape Navigator using Oracle JInitiator or AppletViewer?

• Load balancing or standalone configuration?

• Forms Servlet or CGI implementation?

3.2 Sockets, HTTP, or HTTPS

The Forms Server can be used in three modes for deploying applications:

• Sockets

• HTTP

• HTTPS (HTTP 1.1 with SSL)

Refer to Section 9.3, "Deploying Forms Server in your Network Environment" for more detailed information on the best implementation of Forms Server in your specific network environment.

3.2.1 Sockets

Like many other Internet-based technologies, Forms Server was originally designed to use sockets for communication. A sockets connection uses a standard programming interface to TCP/IP.

A simple way to think of sockets is to imagine a numbering system for programs that communicate over the network. Typically these programs have a client part and a server part that share a common socket number. The server listens at the common socket port for requests from the client. Communication between the client and server parts of a program are done over what is called a socket connection.

Here is a typical example of socket use: A client sends a request to a URL that has a non-standard port number (for example, http://www.xyz.com:9000). This means the client browser will attempt to connect to socket number 9000. This also means that there is a server running on www.xyz.com that listens for connections on port 9000.

The socket mode of deployment is efficient and simple to use. The Forms Server runs on a networked host machine, and it listens on a specified socket or port for connections from the client running on a user machine. For this method to work, the client and server machines must be able to see, or communicate with, one another directly on the network. It is not possible to use a server-side proxy in this mode.

Note:

A server-side proxy is a method for keeping the machine running the server software unknown or anonymous when it is connected or providing services to the Internet. It is a security feature that is invisible to a client and used to thwart unauthorized access to the server.

If the server and the client are separated by an unsecured network, such as the Internet, socket-based deployment has potentially severe security implications.

3.2.2 HTTP

Note: :

For client browsers using Oracle JInitiator, version 1.1.7.30 of JInitiator is required to use the HTTP and HTTPS modes.

In HTTP mode, communication is also accomplished through a socket connection, but it is an HTTP socket connection. The Forms Server listens for HTTP connections from a client rather than for proprietary connections via sockets. All internal messaging between the Forms Server and the client is encapsulated in HTTP packets.

An HTTP socket connection makes it possible for sites to allow secure communication between clients and servers through a firewall. Sites that allow only HTTP traffic can deploy Forms applications through their existing firewall with little or no change to the configuration. The fact that a proxy is used is completely transparent to the client. As far as the client knows, it has a direct connection to the Forms Server.

In the presence of a firewall, the socket mode will not work. To make a socket mode connection work through a firewall, the specific sockets or ports used by the Forms Server would have to be open and available on the firewall, which would expose your network to any traffic that locates the open socket. This essentially pierces the firewall and defeats its purpose.

HTTP is one of the most widely used protocols for deploying applications on the Internet. Organizations can lock-down their firewalls and allow only HTTP traffic, which greatly enhances the security of their private networks. Most firewall companies support the HTTP standard in their products, and many organizations are willing to allow HTTP traffic in and out of their private networks.

3.2.3 HTTPS

In HTTPS mode, communication is accomplished through an HTTP socket connection, as described in Section 3.2.2, "HTTP". However, with HTTPS, SSL (secure sockets layer) is implemented as well.

Note:

For client browsers using AppletViewer, the HTTPS connection mode is not supported.Note: :

For client browsers using Oracle JInitiator, version 1.1.7.30 of JInitiator is required to use the HTTP and HTTPS modes.

A Forms Server can use SSL as a transport protocol to provide privacy, integrity, and server authentication. SSL works at the transport level, which is one level below the application level. This means that SSL can encrypt and decrypt messages before they are handled by application-level protocols such as Telnet, FTP, and HTTP.

• Privacy is accomplished by encrypting messages between clients and servers, which protects messages from being read by unintended recipients.
  Servers and clients can support 128-bit or 40-bit encryption. If you have a server using 128-bit encryption, then clients that use 40-bit encryption cannot connect unless you set the environment variable FORMS60_HTTPS_NEGOTIATE_DOWN to TRUE. (The default setting is FALSE.) See Section 5.3, "Customizing Environment Variables" for details. When you set this environment variable to TRUE, the server will always use the highest level of encryption supported by the client that is attempting to connect. If set to FALSE, clients that support encryption levels lower that the server's cannot connect. The following table shows sample implementations:

  Server encryption level	Client encryption level	FORMS60_HTTPS_NEGOTIATE_DOWN setting	Connection possible?
  128-bit	40-bit 128-bit	TRUE	Yes, 40-bit encryption for some clients and 128-bit for other clients
  128-bit	40-bit	FALSE	No
  40-bit	128-bit	TRUE	Yes, 40-bit encryption
  40-bit	40-bit	TRUE	Yes, 40-bit encryption
  40-bit	40-bit	FALSE	Yes, 40-bit encryption

  Integrity protects messages from being altered. If altered, messages cannot be decrypted correctly.

  Server Authentication is the process of a client machine verifying that a server is who it claims to be. For example, when a client sends confidential data to a server, the client can verify that the server is secure and is the correct recipient of the client's confidential data. Server authentication is accomplished using digital certificates. When a client browser connects to a server, the server presents its certificate for verification. A certificate is issued by a third party, called a certificate authority (CA).

  For Internet Explorer client browsers using the native JVM, any certificate trusted by the browser can be used. If you want to use a CA that is not trusted by the browser by default, see the CA's instructions. Also, you will need to install Oracle Wallet Manager on the Forms Server in order to create certificate requests and manage certificates. See Section 5.7, "Setting Up the HTTPS Connection Mode" for details.

  For client browsers using JInitiator, Oracle Forms Server 6i HTTPS mode trusts (by default) certificates issued by the following CAs:

  • VeriSign, Inc. - Class 1, 2, 3 Public Primary Certification Authority

  • RSA Data Security Inc. - Secure Server Authority

  • GTE CyberTrust Solutions Inc.- CyberTrust Global Root

  • GTE Corporation.- CyberTrust Root

  If you want to use another CA or another type of certificate, additional configuration steps are required because the certificate will not be trusted by default. Also, you will need to install Oracle Wallet Manager on the Forms Server in order to create certificate requests and manage certificates. See Section 5.7, "Setting Up the HTTPS Connection Mode" for details.

3.3 Client Browser using Native JVM, Oracle JInitiator, or AppletViewer

Users can view Oracle Forms applications on the Web using one of the following browser configurations:

• Native JVM (using Internet Explorer 5)

• Oracle JInitiator plug-in (using Netscape Navigator or Internet Explorer)

• AppletViewer

Note:

For client browsers using AppletViewer, the HTTPS connection mode is not supported.Note: :

For client browsers using Oracle JInitiator, version 1.1.7.30 of JInitiator is required to use the HTTP and HTTPS modes.

3.3.1 Native JVM Using Internet Explorer 5

Oracle provides a Microsoft-specific signed CAB file (f60all.cab) that allows the Oracle Forms Java applet to run as a trusted applet inside of Internet Explorer 5. This browser option alleviates the need to perform any end user configurations of the browser.

Refer to Section B.3, "Internet Explorer 5 with Native JVM" for more information.

3.3.2 Oracle JInitiator

Oracle JInitiator runs within a Web browser. It provides the ability to specify the use of a specific Java Virtual Machine (JVM) on the client rather than using the browser's default JVM. Oracle JInitiator does not replace or modify the default JVM provided by the browser. Rather, it provides an alternative JVM in the form of a plug-in.

Oracle JInitiator is Oracle's version of JavaSoft's Plug-In. It runs as a plug-in for Netscape Navigator and as an ActiveX component for Internet Explorer.

Oracle provides two JAR files (f60all.jar and f60all_jinit.jar) that group and zip classes together for efficient delivery across the network to the client. f60all_jinit.jar is an extra-compressed JAR file that can be used only with Oracle JInitiator to provide increased performance at download time. Once on the client, the files are cached for future use.

Note: :

For client browsers using Oracle JInitiator, version 1.1.7.30 of JInitiator is required to use the HTTP and HTTPS modes.

Refer to Section B.4, "Oracle JInitiator" for more information.

3.3.3 AppletViewer

Users can also view applications using the AppletViewer. The AppletViewer is a Java Developer Kit (JDK) component that client machines use to view applications running on the Forms Server.

Note:

For client browsers using AppletViewer, the HTTPS connection mode is not supported.

Refer to Section B.5, "AppletViewer" for more information on running applications with the AppletViewer.

3.4 Load Balancing or standalone configuration

Forms Server includes load-balancing capabilities to optimize hardware resources for scaling from one to thousands of users with unprecedented performance. With load balancing, when you approach the limits of your hardware, rather than upgrading or replacing a machine, you simply add more machines to run your application and spread the load across several machines.

Refer to Chapter 12, "Load Balancing Considerations" for specific information on implementing load balancing.

3.5 Forms Servlet or CGI implementation

The Forms Servlet and Forms CGI components are both installed with Forms Server. Both the servlet and CGI implementations provide load balancing and can create HTML files on the fly.

The primary differences between servlet and CGI implementations are:

• With servlets, HTML files are created on the fly more quickly than with CGI, especially in high-traffic networks.

• With servlets, multiple end-user browser configurations can be used. The Forms servlet automatically detects the client browser type and generates the HTML page on the fly, determining the correct tags and the correct archive.

Both the servlet and CGI implementations use the formsweb.cfg file to define configuration parameters.

3.6 What's Next

After deciding what your choices are, you can configure the necessary Forms Server components. Refer to Chapter 4, "Installing Forms Server" for information about using the Oracle Universal Installer to install the Forms Server. Refer to Chapter 5, "Configuring the Forms Server" for more information about configuring the Forms Server.