2
Overview of Form Services

2.1 Introduction

The Oracle9i Application Server is a scalable, secure, middle-tier aplication server. It enables you to deliver web content, host web applications, and connect to to back-office applications. Form Services are an integral part of the Oracle9i Application Server bundle, which provides the technology to fully realize the benefits of Internet computing. This chapter provides an overview of Form Services architecture, specifically as it relates to deploying forms over the Internet.

Form Services are a new generation of development tools that enable you to deploy new and existing Oracle Forms applications on the World Wide Web. You can deploy applications on an internal company intranet, an external company extranet, or on the Internet.

Form Services are an application server optimized to deploy Oracle Forms applications in a multi-tiered 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.2 Form Services Architecture

Form Services use a three-tier architecture to deploy database applications. Figure 2-1 shows the three tiers that make up the Form Services architecture:

• The client tier contains the Web browser, where the application is displayed.

• The middle tier is the application server, where application logic and server software are stored.

• The database tier is the database server, where enterprise data is stored

Figure 2-1 Form Services architecture

2.3 Form Services Components

Form Services is a middle-tier application server for deploying complex, transactional forms applications to the Internet. Developers can build new applications with Oracle Forms Developer and deploy them to the Internet with Form Services. Developers can also take existing applications that were previously deployed in client/server and move them to a three-tier architecture without changing the application code.

Form Services consists of three major components, as shown in Figure 2-2:

• The Forms Applet, which is downloaded to the client and viewed in the browser

• The Forms Listener, which resides on the middle tier

• The Forms Runtime Engine, which also resides on the middle tier

Figure 2-2 Three-tier configuration for running a form on the Web

2.3.1 Forms Applet

When a user runs a Forms session over the Web, a thin Java-based Forms applet is dynamically downloaded from the application server and automatically cached on the Java client machine.

The Forms applet provides the user interface for the Form Services Runtime Engine. As an extensible, optimized Java applet, it operates inside the framework of the client's Web browser. It handles user interaction and visual feedback, such as information that is generated when navigating between items or when checking a check box. It is responsible for rendering the application display and contains no specific application logic.

The same Java applet code can be used for any Form, regardless of size or complexity. This means that you do not have to write Java code for every application or Form that you want to deploy on the Web.

2.3.2 Forms Listener

The Forms Listener acts as a broker between the Java client and the Form Services runtime process. It takes connection requests from Java client processes and initiates a Form Services Runtime process on their behalf. The listener can also maintain a pool of running engines that stand ready to make the connection from the Java client complete as quickly as possible.

2.3.3 Forms Runtime Engine

The Forms Runtime Engine manages application logic and processing. It maintains a connection to the database on behalf of the Java client. It uses the same Forms, Menus, and Libraries files that are used for running in client/server mode. No application code changes are required to deploy a legacy client/server application to the Internet.

The Forms Runtime Engine plays two roles: when it is communicating with the client browser, it acts as a server by managing requests from client browsers; when it is communicating with the database server, it acts as a client by querying the database server for requested data.

2.4 Form Services in Action

To start and run a Forms application on the Web, users will employ a Java-enabled Web browser to access a URL. Figure 2-3 and the text that follows show and explain the sequences of events that occur during the process flow involving the Form Services.

Figure 2-3 Form Services process flow

When a user runs a Forms application on the Web, the following sequence of events occurs:

1. The user accesses the URL of an HTML page that indicates a Forms application should be run.

2. The HTML page is downloaded to the Web browser. If needed, the client will also download the Java archive file containing the Forms applet. The Forms applet will be instantiated and the parameters from the HTML page will be used to determine which Forms application will be run.

3. The Forms applet sends a request to the Forms Listener (which resides on a specific port of the machine from which the Forms applet was downloaded).

4. The Forms Listener contacts the Forms Runtime Engine and connects to a Form Services runtime process. If included in the HTML page, Forms command-line parameters (such as form name, user ID and password, database SID, menu name, and so on) and any user-defined Form Builder parameters are passed to the process by the Forms Listener.

5. The Listener establishes a connection with the Runtime Engine, and sends the connection information to the Forms applet.

6. The Forms applet then establishes a direct connection with the Runtime Engine.

7. The Forms applet and Runtime Engine then communicate directly, freeing the Listener to accept startup requests from other users. The Forms applet displays the application's user interface in the main window of the user's Web browser.

8. The application running on the Runtime Engine communicates directly with the database.