9.2 OracleAS Forms Services

For many years , OracleAS Forms Services has been one of the most popular 4GL development environments for Oracle database applications. OracleAS Forms Services was designed originally to be closely integrated with the Oracle database. As we mentioned, OracleAS Forms Services uses PL/SQL as the language for its extended logic. The same Oracle sales team that provided the Oracle database was also able to helpfully supply this development tool. But, as the technology environment evolved, OracleAS Forms Services was caught in a bind. Like many client-server tools, OracleAS Forms Services split the runtime functionality of its applications between the client and the server.

The new environment of Internet computing required a slightly different deployment model. To address this new requirement, the OracleAS Forms Services development team created a new deployment model in 1997 with Release 4.1. In this new model, a Java applet talks to a Java servlet on a server. That server, in turn , calls the OracleAS Forms Services runtime. With this new deployment model, OracleAS Forms Services deployment was transformed from a two-tier client-server architecture into a three- tier web-based architecture.

9.2.1 How It Works

The interaction between a web client and an Oracle Forms application through OracleAS Forms Services is shown in simplified form in Figure 9-1.

Figure 9-1. Simplified OracleAS Forms Services architecture

Interaction proceeds as follows :

1. The initial contact is between a browser and the Oracle HTTP Server instance, with a URL that indicates an Oracle Forms application. The Oracle HTTP Server instance forwards the URI request through mod_oc4j to the Oracle Forms servlet, which is run in an OC4J instance.

2. The Oracle Forms servlet starts by creating some HTML, based on the application and the browser type. This HTML is passed to the Oracle Forms Listener servlet.

3. The Oracle Forms Listener servlet passes the HTML back to the client. The servlet also creates an Oracle Forms runtime process (written in C) for the application.

4. The HTML passed to the client starts the client-side applet and spawns a client request for a particular form.

5. Once the connection between the Oracle Forms Listener and the client is established, further interaction between the client and the runtime process is done through the Oracle Forms Listener servlet. At this point, the Oracle Forms servlet is no longer needed.

A single Oracle Forms Listener servlet can manage communications between multiple clients and their runtime processes.

Developers can still use the familiar Oracle Forms development environment, but they now deploy Oracle Forms applications as browser-based clients connecting over the Internet or an intranet to a middle tier of Oracle Application Server. This new architecture also brings other features with it, as we explain in subsequent sections.

OracleAS Forms Services applications use a default HTML template to pass environment variables to the browser, but you can also create your own templates by modifying the default template to include either hardcoded values for parameters or dynamic parameters from the Oracle Forms configuration file.

9.2.2 Running Oracle Forms Services Applications

Once you create an application in Oracle Forms Developer, it can be deployed through OracleAS Forms Services. You have to create a configuration for the application either manually or through a portion of the Oracle Enterprise Manager 10 g Application Server Control tool (described in Chapter 3). For more information on using Oracle Enterprise Manager to manage OracleAS Forms Services, see Section 9.2.3.

When a user wants to run an OracleAS Forms Services application, the interaction proceeds as follows, from the user 's point of view:

1. The user sends a URL (containing the pathname) to the Oracle Forms servlet. This URL also contains the name of the configuration file or the name of a section of the configuration file.

2. Based on the configuration file, the Oracle Forms servlet returns an HTML page, which is specific for the type of browser being used by the client.

3. The HTML page loads a client-side applet, which runs in a JVM on the client.

The Java client-side applet is used to display OracleAS Forms Services forms and can display multiple forms simultaneously .

The Oracle Forms applet on the client requires a specific version of a JVM to run properly. Because the native JVM on a particular browser may not be appropriate, Oracle supplies a client-side plug-in called Oracle JInitiator. Oracle JInitiator allows the use of an alternative JVM to run the client-side Oracle Forms applet as a plug-in to Netscape Navigator or Microsoft Internet Explorer.

Some parts of a particular form are common across all users accessing that form, such as screen definitions and application logic. Once these parts are loaded for a form, subsequent users of the same form can share these entities in memory, with only their private application data requiring its own dedicated memory.

The architecture for OracleAS Forms Services is different from the standard client-server architecture, and that fact has implications for the performance of applications. In the multitier OracleAS Forms Services environment, the limiting performance factor is frequently the bandwidth from the client to the middle tier. For this reason, OracleAS Forms Services applications optimize the communications between the client and the middle tier. For instance, OracleAS Forms Services applications bundle events together after each navigation event. These event bundles interact between the OracleAS Forms Server and the back-end database without having to communicate with the client applet.

Although each individual user has a OracleAS Forms Services runtime process, you can have multiple instances of OracleAS Forms Services. Because the Oracle Forms servlets are standard OC4J applications, you can use any of the normal load-balancing options for OC4J for these Oracle Forms Listeners.

You can create a pool of runtime engines for a particular application in the configuration file for the application. The runtime engines in this pool service users for the application. You can configure a number of instances to be started when an administrator starts the application from Application Server Control, as we discuss in the following section.

9.2.3 Managing OracleAS Forms Services

The Application Server Control tool lets you set parameters to control the operation of an OracleAS Forms Services application. For example, you can control the look and feel of the client portion of the application or the specific title of a particular HTML page returned to the client. The configuration file can also be used to provide different versions of the same application in different languages.

For most parameters, you can override the value in the configuration file by including the parameter in the URL that calls the OracleAS Forms Services application. You can also specify parameters that can't be overridden for a particular application in this configuration file.

Oracle Enterprise Manager gives you an easy interface for managing the underlying configuration files used by OracleAS Forms Services. You can still manually edit these files, but after making changes, you will have to stop all the DCM processes, as well as Oracle Enterprise Manager, to have the changes recognized by Oracle Enterprise Manager. If you don't do this, any subsequent changes made through Oracle Enterprise Manager will simply overwrite the manually changed configuration files.

You can have multiple configurations in separate sections of the configuration file. You might want to do this if different users have different versions of the OracleAS Forms Services application.

Many different parameters shape the appearance and behavior of your OracleAS Forms Services application. A comprehensive list of these parameters is beyond the scope of this book. Please refer to the OracleAS Forms Services documentation for more information.

The portion of Application Server Control that handles OracleAS Forms Services can be used to limit access to OracleAS Forms Services. You can disallow any new user connections to these services on a particular server, or you can kill specific user sessions.

9.2.4 Configuring Security

OracleAS Forms Services can be configured to use the OracleAS Single Sign-On capability of Oracle Application Server without additional code. In Oracle Application Server, OracleAS Single Sign-On uses the identity management that is based on the Oracle Internet Directory. Although Oracle Forms applications have traditionally used a database username and password for security, the Oracle Forms Listener servlet can take this information and use the Oracle Internet Directory to implement OracleAS Single Sign-On with an OracleAS Forms Services application. Because the handling of OracleAS Single Sign-On is done by the OracleAS Forms servlets, not in the Oracle Forms Runtime Process, existing Oracle Forms applications can take advantage of OracleAS Single Sign-On without any modification. In fact, the form itself is unaware of whether OracleAS Single Sign-On was used, although the form can acquire this information if your logic requires it.

You can create user accounts with connect information in the Oracle Internet Directory, which in turn creates Resource Access Descriptors (RADs) once a user connects to OracleAS Forms Services. As of the Oracle Application Server 10 g release, you can configure OracleAS Forms Services to allow all users to create their own RADs on the fly if none exists; previous releases returned an error in such cases. Also new in Oracle Application Server 10 g is the fact that updating a password in the database automatically updates the RAD information in the Oracle Internet Directory.