Oracle9i Application Server Overview Guide Release 1.0.2 Part Number A87353-01 |
Library | Service | Contents | Index

# 3
Developing Applications for
Oracle9i Application Server

Oracle9i Application Server provides several options for developing and deploying applications by using various programming languages and communication protocols.

This chapter demonstrates how you can use Oracle9i Application Server to build your applications through the following topics:

- Content Publishing

- Business Logic

## Content Publishing

### Static Content

The simplest Web sites consist of static pages where a client request returns HTML content that does not change after its initial display. Typically, a simple Web site identifies an HTTP request, responds by sending the requested content to the client, and returns a resulting response to the Oracle HTTP Server powered by Apache.

See Also: Oracle HTTP Server documentation in the Oracle9i Application Server Documentation Library.

### Dynamic Content

Usually, the most interesting content requires more complex functionality, which typically consists of dynamic content delivered from the server. Server-side components run on the server and generate output which is then sent to the client browser. Oracle9i Application Server supports a variety of technologies for developing and deploying dynamic content, including:

- Common Gateway Interface (CGI) Applications

- Perl Scripts

- XML

- Servlets

- JavaServer Pages

- PL/SQL Server Pages

- Oracle Reports Services

#### Common Gateway Interface (CGI) Applications

Web content developers can write CGI programs that fetch data and produce entire Web pages within the same application. These applications typically contain scripts that mix application logic with presentation logic. Application logic manipulates the data while presentation logic formats the content. The separation of HTML content from application logic makes script based applications, such as CGI applications, easier to develop, debug, and maintain.

There are two categories of scripting applications: client-side and server-side scripting. Client-side scripts run in the client's Web browser. Server-side scripts run on the server, fetching and manipulating data. The resulting data is embedded in the HTML page, which is then sent to the client's Web browser.

In Oracle9i Application Server, the Oracle HTTP Server uses mod_cgi to receive requests for a Common Gateway Interface (CGI) application, the server invokes an operating system shell that runs the application and uses the CGI to deliver any accompanying data to the application. Every time the server receives a request for a CGI application, it starts a new process to run the application.

Oracle9i Application Server fully supports CGI applications, providing the middle-tier environment to meet the demands for performance and scalability when running Web applications. However, CGI applications are most useful for processing simple forms on a small scale.

#### Perl Scripts

Perl is an interpreted language with powerful text processing capabilities, which makes it ideal for parsing requests from clients and generating dynamic HTML. Perl scripts contain the logic to produce the dynamic portions of Web pages that run as requested by a client Web browser.

The Perl Interpreter embedded in the Oracle HTTP Server provides a performant, internal interpreter for running Perl scripts. The Perl Interpreter receives and runs Perl scripts through mod_perl, an Oracle HTTP Server module that delegates the handling of HTTP requests to run Perl programs. Using mod_perl, the interpreter links directly with the Oracle HTTP Server daemons, eliminating outside network communication and reducing access time.

Upon receiving a request, the interpreter loads, compiles, and caches the Perl script. The script remains in the cache as long as the server remains running, so subsequent requests for the same script do not have to recompile. If the script has been modified in any way, then the cache purges the original script and compiles and stores a fresh copy of the modified script.

See Also: Apache Software Foundation documentation at `http://www.apache.org` for general information about Perl and the Perl module in Oracle HTTP Server. Apache mod_perl documentation in the Oracle9i Application Server Documentation Library.

#### XML

XML (Extensible Markup Language) is a flexible and standard way to create common document formats for building and deploying Web content. As with CGI scripts, XML data separates the content and structure from the presentation, making it easy to present the data in a variety of layouts and applications.

Oracle9i Application Server allows you to generate XML on the middle tier, invoke server-side components to access the database, run applications, process the information, and deliver the content to the client Web browser. The Oracle XML Developer's Kit (XDK) provides support for reading, manipulating, transforming, and viewing XML documents for Java applications.

The Oracle XDK includes a set of XML parsers to process XML documents for Java. The parser's job is to verify that the XML is well-formed and to validate the XML by comparing it to an existing Document Type Definition (DTD). After this verification and validation phase, the parser manipulates the XML documents into a useful format for applications. Oracle also provides several products that support automatic generation of classes from DTD elements and ways to programmatically use class methods to construct XML documents.

XML also gives you a common format for transferring data between databases. You can generate XML from multiple databases to a common, extensible XML document type. You can use XML to give context to words and values, identifying elements as data. For example, you can identify elements for data such as names, addresses, and contact information. When you collect data from several sources using these common elements, you can easily integrate the data into a common format for a specific application.

See Also: Oracle XML Developer's Kit documentation in the Oracle9i Application Server Documentation Library.

#### Servlets

Servlets are Java applications that run in a server-side environment and service HTTP requests from client browsers. While servicing client requests, servlets can use common Java technologies to increase their functionality. For example, a servlet using JDBC can connect to a database and execute a query. The servlet can then format the result of the query in an HTML table and return it to the client.

##### Advantages of Using Servlets

The ability to use existing Java code and standard APIs makes servlets a powerful tool for servicing requests. Other advantages of using servlets are

- servlets, as a Java-based technology, are platform and Oracle HTTP Server independent. A servlet that is compliant with Sun's servlet specification can run on any Oracle9i Application Server node without any modifications.

- servlets often perform better than CGI applications because requests can reuse an existing Java Virtual Machine (JVM). This saves system resources that can otherwise be used to start up and shut down the JVM for each request.

- database connections can remain open for a session reducing the overhead of reconnecting to the database with each request.

- free servlet instances are reused to service new requests instead of creating new instances.

##### Developing Servlets

Developing servlets requires a compiler, a debugger, and access to the standard and servlet Java libraries. These libraries are installed with Oracle9i Application Server. You can also use integrated development environments, such as Oracle JDeveloper, which provide a set of tools that help in developing and deploying servlets.

##### Processing Servlet Requests

In Oracle9i Application Server, servlets run in the Oracle HTTP Server component. The mod_jserv module forwards requests from the Oracle HTTP Server to Apache JServ. Apache JServ is the Java servlet engine designed to service servlet requests from the Oracle HTTP Server. The JVM processes the servlet and returns the output to mod_jserv. The mod_jserv module then returns the response to the client. This process is illustrated in Figure 3-1.

#### Figure 3-1 Control Flow for a Servlet in the Oracle9i Application Server

1. The Oracle HTTP Server receives a request for a servlet from a client.

2. The Oracle HTTP Server dispatches the request for a servlet class to the mod_jserv module.

3. The mod_jserv module forwards the request to the servlet engine. If the engine is not already running, then mod_jserv will spawn one and initialize the servlet.

4. The servlet engine translates the incoming request into a request object. The engine then creates a response object and passes both objects to the servlet class.

5. The servlet class executes and generates response data. This data is passed to the servlet engine in the servlet response object. The response then travels back to the client through the mod_jserv module and Oracle HTTP Server.

   See Also: Java Servlet API Specification version 2.0 at `http://java.sun.com` Apache JServ documentation in the Oracle9i Application Server Documentation Library.

#### JavaServer Pages

JavaServer Pages (JSP), as specified by Sun Microsystems, offer an easy to use and convenient method for developers to add dynamic content to an HTML file by using Java code and some special tags. The ability to use existing Java code and standard APIs make JSP a powerful tool for generating dynamic HTML pages. This allows Java developers to simplify their applications because presentation logic can be handled by the JSP. To use a new presentation method, such as a new HTML tag, you only change your JSP. The underlying Java code will not need any modifications since it only delivers the data to the JSP.

##### Advantages of Using JSP

Since JavaServer pages are platform independent, any JSP that is compliant with the Sun Microsystems JSP specification can run on any Oracle9i Application Server node without modification.

OracleJSP, the Oracle translator and runtime engine for JavaServer Pages, supports the following enhancements available to JSP developers:

- More data types to increase the functionality of embedded logic.

- Two options, primitive types (PT) or java.lang objects. Only objects can be stored in the scope object, therefore, values of PT cannot have a valid scope and cannot be stored in a JSP scope object. Wrapper classes in the java.lang package are objects that cannot be declared in a JSP usebean statement because the wrapper classes do not follow the JavaBean model and do not provide a null constructor.

- JSP Markup Language (JML) offers an alternative to the JSP scripting syntax. This supports non-Java developers who want to create dynamic Web pages.

- XML and XSL support developers who want to create XML pages instead of HTML pages.

##### Deploying JSP Applications

Since the servlet engine compiles pages on request, you must test your pages by requesting them through the Oracle HTTP Server in Oracle9i Application Server. Some integrated development environments, such as Oracle JDeveloper, provide built-in debugging environments for JSP.

##### Processing JSP Requests

In Oracle9i Application Server, JavaServer Pages run in the Oracle HTTP Server component. The Oracle HTTP Server forwards the request through the servlet environment (mod_jserv and the Apache JServ servlet engine) to OracleJSP. The translator processes the JavaServer Pages and compiles any embedded code. The output returns along the originating path to the client. This process is illustrated in Figure 3-2.

#### Figure 3-2 Control Flow for a JavaServer Page in the Application Server

1. The Oracle HTTP Server receives a request for a JSP from a client.

2. The Oracle HTTP Server dispatches the request for a servlet class to the mod_jserv module.

3. The mod_jserv module forwards the request to the Apache JServ servlet engine.

4. The servlet engine translates the incoming request into a request object. The servlet engine then creates a response object and passes both objects to OracleJSP.

5. The OracleJSP parses the JSP file and executes the embedded application logic.

6. The result is passed from the OracleJSP to the Apache JServ servlet engine in the servlet response object. The response then travels back to the client through the mod_jserv module and Oracle HTTP Server.

   See Also: JavaServer Pages Specification version 1.0 at `http://java.sun.com` OracleJSP documentation in the Oracle9i Application Server Documentation Library.

#### PL/SQL Server Pages

Oracle PL/SQL Server Pages (PSP) is Oracle's PL/SQL dynamic server-side scripting solution for Web application development. Oracle PSP includes the PL/SQL Server Pages Compiler and the PL/SQL Web Toolkit. Oracle PSP enables PL/SQL users to develop Web pages with dynamic content by embedding PL/SQL scripts in HTML. PSPs separate application logic (embedded PL/SQL scripts) from the layout logic (HTML) making the development and maintenance of PL/SQL Server Pages easy. By using this method, content developers design the static portions of Web pages in HTML, then add scripts that generate the dynamic portions of the pages. In addition, PSP tightly integrates with the database so it is easy to retrieve, manipulate, and present data.

##### Advantages of Using PSP

PL/SQL Server Pages provide server-side scripting with traditional database operations and programming logic for developing Web-based applications. The advantages of using PL/SQL Server Pages include the following:

- Oracle PSP supports HTML and HTML authoring tools with added dynamic content or applications. You can start with an existing Web page or with an existing stored procedure to create dynamic Web pages that perform database operations and display the results.

- Typically, PL/SQL Server Pages display in a Web browser. By default, Oracle8i PL/SQL transmits files as HTML documents, so that the browser formats them according to the HTML tags. Files can also be retrieved and interpreted by a program that can make HTTP requests, such as a Java or Perl application.

- The PL/SQL Web Toolkit allows you to build PL/SQL code that produces formatted output. You can specify the output format as XML, a MIME type, or plain text, depending on the technology supported in the user's browser.

- You can run insert, update, and delete operations within PL/SQL Server Pages. As with any program that is expected to return results as HTML, such pages should include some output to confirm that the operation is successful or to show the updated state.

- You can share procedures, constants, and types across different PL/SQL server pages, and compile them into a separate package in the database.

- To handle database errors that occur when the script runs, you can include PL/SQL exception-handling code within a PSP file, which may launch another PSP to handle or to report the error.

##### Developing PSP Applications

Developers use the Oracle PL/SQL Web Toolkit to develop their PSP applications. The PL/SQL Web Toolkit contains a set of packages you can use in stored procedures to retrieve request information, construct HTML tags, and return header information to the client.

PL/SQL Server Pages compile to PL/SQL stored procedures. Compiling an HTML file as a PL/SQL Server Page produces a stored procedure that outputs the exact same HTML file. The PSP is an HTML file mixed with PL/SQL procedures combining all the content and formatting of your Web page. The HTML file contains text and tags interspersed with PSP directives, declarations, and scripts.

##### Deploying PSP Applications

Oracle8i PL/SQL and mod_plsql in Oracle9i Application Server provide support for deployment and performance of your PL/SQL Server Pages. By deploying PSPs on the middle-tier, the server centrally manages the application logic saving in administration and maintenance costs and optimizing performance of your PL/SQL applications. Oracle HTTP Server forwards PL/SQL request(s) to the PL/SQL engine with the plug-in mod_plsql. Applications invoke PL/SQL scripts and stored procedures to retrieve data from a database, then generate HTML pages that return the data to the client browser.

Once the PSP has been compiled into a stored procedure, you can run it by retrieving an HTTP URL through a Web browser. The virtual path in the URL depends on the way that mod_plsql is configured.

The `POST` and `GET` methods in the HTTP protocol tell browsers how to pass parameter data to the applications. The `POST` method passes the parameters directly from an HTML form and are not visible in the URL. The `GET` method passes the parameters in the query string of the URL. You can use the `GET` method to call a PSP from an HTML form, or you can use an HTML link to call the stored procedure with a given set of parameters.

##### Processing PSP Requests

The process of handling a PL/SQL Server Page is illustrated in Figure 3-3.

#### Figure 3-3 Control Flow for a PSP in the Oracle9i Application Server

1. The Oracle HTTP Server receives a PL/SQL Server Page request, through Oracle Web Cache, from a client browser.

2. The Oracle HTTP Server routes the request to mod_plsql.

3. The request is forwarded by mod_plsql to Oracle8i PLSQL. By using the configuration information stored in your Database Access Descriptor (DAD), mod_plsql connects to the database, prepares the call parameters, and invokes the PL/SQL procedure in the database.

4. The PL/SQL procedure generates an HTML page using data and stored procedures accessed from the database.

5. The response is returned to mod_plsql.

6. The Oracle HTTP Server sends the response, through Oracle Web Cache, to the client browser.

   See Also: Oracle8i Application Developer's Guide - Fundamentals in the Oracle Database Documentation Library.

#### Oracle Reports Services

Oracle Reports Services enables you to deploy new and existing reports within the Oracle9i Application Server multitiered architecture. All report processing, administration, and maintenance occurs on the server, which dramatically simplifies the client configuration and reduces the client storage and processing requirements. Oracle Reports Services supports all of the major industry standard Web output formats, making it easy for users to view reports in their favorite Web browser.

Oracle Reports Services supports output in the following industry standard formats:

PDF | Adobe Portable Document Format provides high quality output that users can view on the Web and easily print.
HTML and HTMLCSS | HTML without cascading style sheets provides output that can be viewed in any HTML 3.0 compliant browser. HTML with cascading style sheets (HTMLCSS) provides higher fidelity output, but it requires an HTML 3.0 compliant browser that supports style sheets.
XML | XML (Extensible Markup Language) stores report definitions. If you apply different XML report definitions at runtime, then you can customize report formats for different users or purposes.

##### Processing Report Requests

Oracle Reports Services uses the Oracle9i Application Server multitiered architecture to publish and run report requests on the Web. Figure 3-4 shows Oracle Reports Services residing on the same machine as Oracle HTTP Server. Alternatively, you may distribute the Oracle Reports Services across multiple machines by running the Reports Server on a separate machine. If you choose to use this distributed architecture, then the Oracle HTTP Server and the Reports Web CGI or Reports Servlet components must always reside on the same machine.

#### Figure 3-4 Control Flow for a Report Request in the Oracle9i Application Server

Note: This diagram depicts Oracle Reports Services in a three-tiered architecture. You may also run Oracle Reports Services in a distributed four-tiered architecture.

1. When a client requests a report from their Web browser, the browser passes the request to Oracle HTTP Server on Oracle9i Application Server.

2. Oracle HTTP Server invokes either the Reports Web CGI or the Reports Servlet, depending on the configuration.

3. The Reports Web CGI or the Reports Servlet parses the request, handles the login transaction, converts the report to command-line format, and submits the request for execution by the Reports Server.

4. The Reports Server checks its output cache for an existing response to the request. If the cache has an acceptable output, then the Reports Server immediately returns that output. If the cache does not have the acceptable output, then the Reports Server processes the request with the database.

5. The Reports Server receives and queues the job request. When one of the runtime engines becomes available, the Reports Server sends the command line to that runtime engine for execution. The runtime engine runs the report.

6. The Reports Web CGI or Reports Servlet receives the report output from the Reports Server.

7. The Reports Web CGI or Reports Servlet sends the output to Oracle HTTP Server.

8. Oracle HTTP Server sends the report output to the client's Web browser.

##### Deploying Reports

When deploying reports in a Web environment, you should consider the following:

- choose the Report Web CGI or Reports Servlet: You must install and configure either the Reports Web CGI or Reports Servlet to handle the transmission of job requests and output between your Oracle HTTP Server and Oracle Reports Services. Oracle9i Application Server supports both CGI and Java applications.

- choose the location of the Reports Server: You can deploy Oracle Reports Services in Oracle9i Application Server using a three-tiered or four-tiered architecture. When using a three-tiered architecture, the Reports Server resides on the same machine as Oracle HTTP Server. This requires more system resources, since all processing occurs on a single machine. In a four-tiered architecture, the Reports Server resides on a machine separate from Oracle HTTP Server, spreading the resource requirements across multiple machines. However, if you choose to have the Reports Server and Oracle HTTP Server on different machines, then the transmissions to the Reports Web CGI and the Reports Servlet must travel across a network resulting in greater network traffic.

- configure request handling for optimal performance: Oracle Reports Services handles report requests using dynamic management of runtime engines. You can specify a maximum number of runtime engines to handle your requests with optimal performance for your server. When Oracle Reports Services receives a request to run a report, the server launches a runtime engine to handle the request. Each runtime engine resides in memory to run additional report requests over a period of time. A runtime engine automatically removes itself from memory when it is either idle for a specified amount of time to free up system resources. After removal, the Reports Server replaces it with a new engine.

  See Also: Oracle Reports Services documentation in the Oracle9i Application Server Documentation Library.

## Business Logic

The Oracle9i Application Server provides support for running applications with advanced functionality such as business logic, scalability, and performance. The following topics are covered in this section:

- Java Servlets, Applications, and Enterprise JavaBeans

- Global Transactions Including Oracle Database Cache and the Origin Database

- Oracle Forms Services

### Java Servlets, Applications, and Enterprise JavaBeans

Java code can be deployed for execution on either one of two Java runtime environments in Oracle9i Application Server:

- Apache JServ running on the Java Development Kit Java Virtual Machine (JDK JVM), or

- Oracle8i JVM.

  Note: Java applications running in either one of these environments on Oracle HTTP Server can communicate with Java applications in Oracle8i JVM.

#### Running Java on the JDK JVM

Apache JServ supports running servlets and JSPs. When deploying Java applications on the JDK JVM, you should consider the following:

- Conversational State

- JNI Access

- Stateful vs. Stateless Applications

##### Conversational State

Applications that are stateless or hold on to minimal conversational state will benefit from the responsiveness of the JDK JVM.

##### JNI Access

If your Java application requires access to the Java Native Interface, then you must use the JDK JVM. JNI access is not supported in Oracle8i JVM.

##### Stateful vs. Stateless Applications

When comparing the JDK JVM with Oracle8i JVM, the terms stateful and stateless are useful.

A stateful application maintains session state information within its runtime environment between successive client calls.

A stateless application maintains no state information within its environment. It may, however, refer to state information in a common store such as a database or a browser.

The JDK JVM scales by giving quick performance to many clients, since stateless Java applications do not need to maintain state information. This works well for stateless Java applications because the JVM does not get weighted down by holding onto a lot of state. However, stateful applications force the JDK JVM to perform a lot of concurrent memory management when multiple users access the system. Managing state may inhibit the scalability of the JDK JVM. Figure 3-5 and Figure 3-6 illustrate the effects of adding clients to a JDK JVM for both stateful and stateless Java applications.

#### Figure 3-5 Adding Clients to JDK JVM for Stateful Java Applications

#### Figure 3-6 Adding Clients to JDK JVM for Stateless Java Applications

Oracle8i JVM is a session-based JVM that handles stateful applications with good performance, depending on the hardware capacity. As Oracle8i JVM segregates clients' memory spaces, the JVM can garbage collect each user's memory space independently. This architecture avoids concurrent garbage collection, which often constitutes the major scalability bottleneck when running heavily stateful applications on a typical JVM.

#### Figure 3-7 Adding Clients to Oracle8i JVM with Stateful Java Applications

#### Running Java on Oracle8i JVM

Oracle8i JVM supports Enterprise JavaBeans. When deploying Java applications on Oracle8i JVM, you should consider the following:

- Conversational State

- Benefit of Fast SQL Access

- Security, Reliability, and Availability Requirements

##### Conversational State

Applications that hold on to substantial amounts of conversational state will scale better in Oracle8i JVM.

##### Benefit of Fast SQL Access

Oracle8i JVM runs in the same process space as the Oracle8i SQL engine. In the Oracle8i database, Oracle8i JVM benefits from fast data access when reading and writing to the database. In Oracle9i Application Server, Java applications running in Oracle8i JVM benefit from very fast access when reading cached data in Oracle Database Cache.

##### Security, Reliability, and Availability Requirements

Oracle8i JVM inherits many of the security, reliability, and availability features of the Oracle8i database, creating a very stable Java environment. For example, Oracle8i JVM isolates client sessions, so that failure in one session is not propagated to other concurrent user sessions. In many JVMs, one user session has the potential to bring down the entire JVM, affecting all concurrent JVM users. The session isolation in Oracle8i JVM protects sessions from one another. Even if one user's session goes down in Oracle8i JVM, other users' sessions are unaffected.

#### Deploying Enterprise JavaBeans in the Middle Tier

In Oracle9i Application Server, you can deploy Enterprise JavaBeans (EJBs) either in the middle tier or in the database. The deployment process is similar: You must direct the deployment tools (`deployejb` and `loadjava`) to the correct server.

##### Deploying EJBs in the Database

To deploy EJBs in the database, you direct the `deployejb` and `loadjava` commands to the origin, or back-end, database, and then pass the `host`, `port`, and `sid` of the database to the command-line tools.

##### Deploying EJBs in the Middle Tier

To deploy EJBs in the middle tier you must perform the following steps:

1. Before you can deploy EJBs to the middle tier, you must install Oracle8i JVM.

2. Direct the `deployejb` and `loadjava` commands to Oracle8i JVM.

3. Pass the `host`, `port`, and `sid` of the JVM to the command-line tools.

   Note: There are restrictions on using EJBs in the middle tier. These restrictions are documented in the Oracle9i Application Server Release Notes.

### Global Transactions Including Oracle Database Cache and the Origin Database

In a normal global transaction, you open connections to each database that you want included in the transaction. After the transaction completes, the transaction manager commits all changes to all databases involved in the transaction.

By using Oracle9i Application Server, Oracle Database Cache may incorrectly be treated by the transaction manager as one of the databases in the global transaction. A typical application is shown in Figure 3-8. The Enterprise JavaBean (EJB) that is active in the middle-tier retrieves a connection to both Oracle Database Cache and to the origin database. However, the EJB must only update the origin database. The transaction manager must not treat Oracle Database Cache as another database involved in the transaction or it will perform a two-phase commit when the transaction ends. The two-phase commit process is expensive and unnecessary. Only the origin database should be enlisted in the global transaction so the transaction manager will perform a single-phase commit.

#### Figure 3-8 Global Transaction That Includes Oracle Database Cache and the Origin Database

All database resources are enlisted only if you perform one of the following:

- You retrieve the connection to a remote database through the `getConnection` method of the `DataSource` class. However, the `DataSource` object must be previously bound through `bindds` with the `-type` `jta` option.

- You retrieve the connection to the local database using one of the methods described in Table 3-1.

  ##### Table 3-1 Local Resource Enlistment

  Retrieval Method | Description
  --- | ---
  `defaultConnection` method of the `OracleDriver` class | Pre-JDBC 2.0 method for retrieving the local connection.
  `getConnection` method of the `DriverManager` class | Pre-JDBC 2.0 method for retrieving connections. For retrieving the local connection, the input parameter must be the string "`jdbc:oracle:kprb:`".
  `getConnection` method of the `DataSource` class | JDBC 2.0 method for retrieving connections. For retrieving the local connection, the input parameter must be the string "`jdbc:oracle:kprb:`".

To ensure that Oracle Database Cache is not treated as an enlisted database in the global transaction, perform the following steps:

1. Ensure that the <`default-enlist`> element in the Oracle-specific deployment descriptor is either not set (and it defaults to FALSE) or is set to FALSE.

2. Bind the `DataSource` for Oracle Database Cache with any non-Java Transaction API (JTA) type. Only a JTA `DataSource` object can be automatically enlisted in a global transaction.

   The behavior for the methods indicated in Table 3-1 are as follows:

   - With the pre-JDBC methods (the `OracleDriver defaultConnection` and `DriverManager getConnection` methods) Oracle9i Application Server understands that Oracle Database Cache is not a database, and the cache is not enlisted in the global transaction.

   - With the JDBC 2.0 method (the `DataSource getConnection` method) the `DataSource` object bound for the cache must be bound through the `bindds` command with any `-type` other than `jta`. If bound with `bindds -type jta`, then the cache will be considered part of the global transaction and the transaction manager will complete the global transaction with a two-phase commit.

     See Also: Oracle8i Enterprise JavaBeans Developer's Guide and Reference in the Oracle9i Application Server Documentation Library.

### Oracle Forms Services

Oracle Forms Services deploys Forms applications with database access to Java clients in a Web environment. Together with Oracle Forms Developer, Oracle Forms Services provides

- application infrastructure and the event model for scalability and performance over a network

- support for integrating technologies such as PL/SQL, Java Stored Procedures, Enterprise JavaBeans, XML, and CORBA

- extensible user interface through native Java with Pluggable Java Components

- services for building and optimizing Oracle8i transactional database applications

When combined with Oracle Forms Developer and Oracle Designer, you can design, develop, and deploy a complete application framework for Oracle Forms applications on the Internet. Oracle Forms Developer allows you to quickly build complex Java applications for accessing a database, without writing any Java code. The development environment provides a full set of tools, such as wizards and utilities, for building custom, extensible applications. Oracle Forms Developer is specifically designed and optimized to build Oracle8i transactional database applications, with built-in database connectivity, query, management, and transactional services. Oracle Forms Services and Oracle Forms Developer also integrate with the Oracle Designer modeling tool to provide services for full life cycle application development and deployment.

With the integration of Forms Developer and Oracle8i, your Internet applications can share resources and improve application performance and scalability. Oracle Forms Services supports this integration with

- transaction management

- advanced queuing

- record caching

- record locking

- exception handling

- load balancing

- security management features

#### Processing Forms Requests

Oracle Forms Services resides as a component in Oracle9i Application Server. The process of handling Forms applications is illustrated in Figure 3-9.

#### Figure 3-9 Control Flow for a Forms Request in Oracle9i Application Server

1. Oracle HTTP Server receives an HTTP request from the browser client and contacts Forms CGI.

2. Forms CGI dynamically creates an HTML page containing all information to start the Forms session.

3. Oracle HTTP Server downloads a generic Java applet to the client. The client caches the applet so the applet does not need to be downloaded again. The applet runs all future Forms applications for as long as it resides in the client's cache.

4. The client applet contacts the Forms Listener to start the session. The Forms Listener starts an instance of the Forms Runtime engine on the Forms Server. The Forms Runtime engine handles the user's context, executing the business logic and conducting necessary transactions with the Oracle8i database instance.

5. The client applet and Forms Runtime engine establish network communication using socket, HTTP, or S-HTTP protocols.

The Forms Java client has been optimized for high performance on many platforms allowing efficient display of widgets and minimizing the time and frequency for client page refreshes. Another key element of the optimized Java client is the use of Java Archive (JAR) file caching. Oracle Forms Services use Oracle JInitiator to preform persistent client-side caching of the applet after the initial download. Any subsequent access to the application pulls the JAR file directly from the persistent client-side cache, significantly minimizing startup time. JAR file caching is an essential performance feature for any application with remote users who dial in to access the application over a wide area network.

Oracle Forms Services also optimizes network traffic by using several methods for communicating to the Java client, including:

- reducing the amount of network traffic by using metadata messages as a collection of name/value pairs. These messages tell the Java client which object to act upon and how to act

- comparing messages as collections of name/value pairs and sending only the differences between the messages

- sending an initial string once and referencing the string in subsequent messages

- minimizing the transfer of data types by using the lowest number of bytes required for their value

- bundling events triggered between two objects for single packet processing

  See Also: Oracle Forms Services documentation in the Oracle9i Application Server Documentation Library.

| Copyright © 2000 Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index