Oracle9i Application Server Overview Guide
Release 1.0.2

Part Number A87353-01

Go to previous page Go to next page

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

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

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 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 (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 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

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

    • 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:

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

    • 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:

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:


Adobe Portable Document Format provides high quality output that users can view on the Web and easily print. 


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 (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


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:

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

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

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

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

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.


    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:

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.

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

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

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: