The Runtime Process of a Oracle Forms

In this article we will discuss how a Oracle Form runs in a server and how the client machines access them.

Oracle Forms applications are deployed to the web through a three-tier architecture. Application logic and the Forms Services Runtime Engine reside on the middle-tier application server. All trigger processing occurs on database and application servers, while user interface processing occurs on the Forms client. End users can run Forms Developer applications in a Web browser.

Before discussing the runtime process, lets go through the Forms Services Architecture in brief. Forms Services consists of four major components: the Forms Servlet, the Java client (Forms Client), the Forms Listener Servlet, and the Forms Runtime Engine.

The Forms Servlet is a Java servlet(class) that is capable of creating a dynamic HTML file in the client browser.

The Java client or Forms client(applet) is nothing but a set of Java classes that are downloaded to the client machine when any Form application is called in the client machine for the first time. This component is only responsible to display the Form in the Browser and send the user interactions to the middle tier. You do not have to deploy a separate Java applet for each application. The same generic applet is used to run any Forms Services application, regardless of its size and complexity.

The Forms Listener Servlet is a Java servlet that runs in a Web server equipped with a servlet engine, such as OC4J. The Forms Listener Servlet is in charge of managing the creation of the Forms Runtime process for each client and managing the network communications that occur between the client and its associated Forms Runtime process, through the Web server.

The Forms Runtime Engine is a process on the Application Server that is started by the Forms Listener Servlet. The Forms Runtime Engine handles all the application logic and Forms functionality and executes the code written into the application.

Users request a Form application in their Web browsers by entering a URL that points to the application. Forms Services then generates an HTML file that downloads a Java applet to the client machine. This small applet is capable of displaying the user interface of any form, while the application logic is executed on the middle tier.

The URL to invoke an application must have the following format:

Where http is a protocol, dummysite.com is the host, 8888 is the port number and forms90/f90servlet is forms servlet alias.

We should have a Java Runtime Environment(JRE) in the client machine to run our Forms. We can use JInitiator, a plug-in that provides a JRE capable of running the Forms applet.

The below is the complete process how we can access a Form application through web:

1] The user accesses the Forms application through a URL in the web browser.

2] In the middle tier, Oracle HTTP Server or OC4J receives an HTTP request from the browser client and contacts the Forms Servlet.

3] The Forms Servlet dynamically creates an HTML page in the client machine containing all the information to start the Forms session.

4] The Oracle HTTP Server or OC4J downloads a generic applet to the client machine if the Form is called for the first time. The client machine caches the applet so that it can run future Forms applications without downloading it again.

5] The applet in the client machine contacts the Forms Listener Servlet in the middle tier to start the session. The Forms Listener Servlet starts an instance of the Forms Runtime Engine on the Forms Server (middle tier).

6] The Forms Listener Servlet establishes a connection with the Runtime Engine, which connects to the database if needed and loads application executable files.

7] The Forms applet displays the Form in the main window of the user’s Web browser.

8] The Forms Listener Servlet, working through OC4J or the HTTP Server, manages communication between the Forms applet and the Runtime Engine.