2 Introduction to Oracle Forms Services

This guide provides information about deploying applications with Oracle Forms Services. When you choose to deploy applications to a network, there are many decisions to be made about how you to go about it. This guide provides information about those decisions and offers suggestions and methods for configuring your system for Web deployment of your applications.

Oracle Fusion Middleware is the application server for the Oracle Database and applications built with Oracle development tools. By leveraging a common technology stack, Oracle Fusion Middleware can transparently scale an Oracle Database by caching data and application logic in the middle tier.

2.4Oracle Forms Services

Oracle Forms Services is a comprehensive application framework optimized to deploy Forms applications in a multitiered environment. It takes advantage of the ease and accessibility of the Web and elevates it from a static information-publishing mechanism to an environment capable of supporting complex applications.

2.4.1 How Oracle Forms Services Launches a Forms Application

When a user first starts an Oracle Forms application by clicking a link to the application's URL, the baseHTML file is read by the Forms servlet. Any variables (%variablename%) in the baseHTML file are replaced with the appropriate parameter values specified in the formsweb.cfg file, and from query parameters in the URL request (if any).

You can easily modify the configuration files with Oracle Enterprise Manager Fusion Middleware Control as your needs change. The following sections describe the processes that are involved in deploying and running a typical Forms application.

The middle tier, in the center of the image, is the application server, where application logic and server software are stored.

The database tier, in the lower portion of the image, is the database server, where database server software is stored.

Figure 2-1 Oracle Forms Services Architecture

2.6Oracle Forms Services Components

Oracle Forms Services is a middle-tier application framework for deploying complex, transactional forms applications to a network such as an intranet or the Internet. Developers build Forms applications with Forms Developer and deploy them with Forms Services. Developers can also take current applications that were previously deployed in client/server and move them to a three-tier architecture. Some minor changes in application code may be required when moving to a three-tier architecture.

As shown in Figure 2-2, the three-tier configuration for running a form consists of:

The Client, at the top of the image, resides on the client tier

The Forms Listener servlet, in the center of the image, resides on the middle tier

The Forms Runtime process, also resides on the middle tier

Figure 2-2 Three-tier configuration for running a form

2.6.1Forms Listener Servlet

The Forms Listener servlet is a broker between the Java client and the Forms Runtime process. It takes connection requests from Java client processes and initiates a Forms Runtime process on their behalf.

Figure 2-3 illustrates how the client sends HTTP requests and receives HTTP responses from Forms Services. Oracle Forms Services uses the Forms Listener servlet to start, stop, and communicate with the Forms Runtime process. In this image, the client is to the left. In the center of the image, the HTTP Listener acts as the network endpoint for the client, keeping the other server computers and ports from being exposed at the firewall.

The Forms Runtime process, in the right side of the image, executes the code contained in a particular Forms application. The Forms Listener servlet manages the creation of a Forms Runtime process for each client and manages the network communications between the client and its associated Forms Runtime process. The Forms Listener servlet replaces the Forms Listener provided in previous releases of Oracle Forms.

Note:

The Forms Listener servlet is configured for you during the Oracle Fusion Middleware installation process.

Figure 2-3 Architecture using the Forms Listener Servlet

2.6.2Forms Runtime Process

The Forms Runtime process plays two roles: when it communicates with the client browser, it acts as a server by managing requests from client browsers and it sends metadata to the client to describe the user interface; when it is communicating with the database server, it acts as a client by querying the database server for requested data.

For each Oracle Forms session, there is one Oracle Forms Runtime process on the application server. This process is where Oracle Forms actually runs, and manages application logic and processing. It also manages the database connection; queries and updates data; runs any PL/SQL in the Form; executes triggers; and so on. It uses the same forms, menus, and library files that were used for running in client/server mode.

The Forms Runtime process also contains the Java Virtual Machine (JVM) to run Java in your application. As an optimization feature, the JVM is started if the Forms application uses the Java Importer. In 10g, the JVM pooling feature is used only by the Java Importer. In 11g, Forms Runtime Process no longer creates a separate JVM when it calls Reports. Instead, if a JVM controller is configured for a form, the form can use the shared JVM when calling Reports. This results in a reduction of memory consumption, freeing more resources on the server. For more information about managing JVM usage and pooling, see Chapter 10, "Configuring and Managing Java Virtual Machines."

Scripting on this page enhances content navigation, but does not change the content in any way.