3
Developing Applications for
Oracle Internet Application Server

Oracle Internet Application Server provides several options for developing and deploying applications using various programming languages and communication protocols. This chapter demonstrates how you can use Oracle Internet Application Server to build your applications.

Contents

• Content Publishing

• Business Logic

Content Publishing

Static Content

The simplest Web sites consist of static pages where the result of a client request returns one or more HTML pages with 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.

For detailed information about Oracle HTTP Server, refer to the Oracle HTTP Server documentation on your Documentation Library CD-ROM.

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. Oracle Internet 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 the 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 Oracle Internet 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.

Oracle Internet 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 via 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 demons 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, the cache purges the original script, then compiles and stores a fresh copy of the modified script.

For general information about Perl and the Perl module in the Oracle HTTP Server powered by Apache, refer to the documentation created by the Apache Software Foundation (available at http://www.apache.org/).

For information about running Perl in the Oracle Internet Application Server, refer to the Apache mod_perl Guide in the Oracle HTTP Server documentation on your Documentation Library CD-ROM.

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.

Oracle Internet 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 against 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.

For information about using XML in the Oracle Internet Application Server, refer to the Oracle XML Developer's Kit documentation on your Documentation Library CD-ROM.

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 Oracle Internet 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 Oracle Internet 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 Oracle Internet 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 now returns the response to the client. This process is illustrated in Figure 3-1.

Figure 3-1 Control Flow for a Servlet in the Oracle Internet 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, 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.

For general information about Java servlets, refer to the Java Servlet API Specification 2.0 (available from http://java.sun.com).

For information about running servlets in Oracle Internet Application Server, refer to Apache JServ Documentation in the Oracle HTTP Server documentation on your Documentation Library CD-ROM.

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-based file with 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 Sun's JSP specification can run on any Oracle Internet Application Server node without modification.

OracleJSP, Oracle's 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 Oracle Internet Application Server. Some integrated development environments, such as Oracle JDeveloper, provide built-in debugging environments for JSP.

Processing JSP Requests

In Oracle Internet 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.

For general information about JavaServer Pages, refer to the JavaServer Pages Specification 1.0 (available from http://java.sun.com).

For information about developing JavaServer Pages in Oracle Internet Application Server, refer to OracleJSP documentation on your Documentation Library CD-ROM.

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. Using this method, content developers can design the static portions of Web pages in HTML, then add scripts that generate the dynamic portions of the pages. In addition, PSP uses PL/SQL as the scripting language and 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:

• PSPs support 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, some other 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 can 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 basically 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 Oracle Internet Application Server provides 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 a hardcoded 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 Oracle Internet Application Server

1. The Oracle HTTP Server receives a PL/SQL Server Page request 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 PL/SQL. 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 to the client browser.

For information about deploying PL/SQL Server Pages in the Oracle Internet Application Server, refer to Using mod_plsql in the Oracle HTTP Server documentation on your Documentation Library CD-ROM.

Oracle Reports Services

The Oracle Reports Services enable you to deploy new and existing Oracle Reports within the Oracle Internet Application Server multi-tiered 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 support 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 provides higher fidelity output, but it requires an HTML 3.0 compliant browser that supports style sheets.
XML	You can use XML (eXtensible Markup Language) to store report definitions. By applying different XML report definitions at runtime, you can customize report formats for different users or purposes.

Processing Report Requests

The Reports Services use the Oracle Internet Application Server multi-tiered architecture to publish and run report requests on the Web. Figure 3-4 shows the Reports Services residing on the same machine as the Oracle HTTP Server. Alternatively, you may distribute the Report Services across multiple machines by running the Reports Server on a separate machine. If you choose to use this distributed architecture, 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 Oracle Internet Application Server

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

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

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

4. The Reports Server checks its output cache for an existing response to the request. If the cache has an acceptable output, the Reports Server immediately returns that output. If the cache does not have the acceptable output, 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 the Oracle HTTP Server.

8. The 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 the Reports Web CGI or Reports Servlet to handle the transmission of job requests and output between your Oracle HTTP Server and the Reports Services. Oracle Internet Application Server supports both CGI and Java based applications.

• Choose the location of the Reports Server

  You can deploy the Reports Services in Oracle Internet 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 the 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 your Oracle HTTP Server, spreading the resource requirements across multiple machines. However, if you choose to have the Reports Server and the 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

  The Reports Services handle 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 the Reports Services receive 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 or to free up system resources. After removal, the Reports Server replaces it with a new engine.

For information about developing and publishing Reports in the Oracle Internet Application Server, refer to Building Reports and Publishing Reports to the Web with Oracle Internet Application Server in the Forms and Reports Services documentation on your Documentation Library CD-ROM.

Business Logic

The Oracle Internet Application Server provides support for running applications with advanced functionality such as business logic, scalability, and performance.

• Java Servlets, Applications, and Enterprise JavaBeans

• Oracle Forms Services

Java Servlets, Applications, and Enterprise JavaBeans

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

• Apache JServ running on the JDK JVM

• Oracle8i JVM

  Note: Java applications running in either of these environments on the 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

• Stateless vs. stateful applications

• JNI access

Conversational State

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

Stateless vs. Stateful Applications

When weighing the benefits of the JDK JVM vs. Oracle8i JVM, we often talk in terms of stateless and stateful applications.

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, persist 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. 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.

The JDK JVM scales by giving quick performance to many clients. This works well for stateless Java applications because the JVM does not get weighted down by holding onto a lot of state.

Stateful applications force the 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.

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.

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.

Running Java on Oracle8i JVM

Oracle8i JVM support running 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 Oracle Internet Application Server, Java applications running in Oracle8i JVM benefit from very fast access when reading cached data in Oracle8i 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.

Oracle Forms Services

Oracle Forms Services deploy Forms applications with database access to Java clients in a Web environment. Together with Oracle Forms Developer, Oracle Forms Services provide:

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

• support for integrating technologies such as PL/SQL, Java Stored Procedures in the Oracle8i database, Enterprise Java Beans, 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 toolset of wizards, widgets, 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 lifecycle 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 supporting this integration include:

• transaction management

• advanced queuing

• record caching

• record locking

• exception handling

• load balancing

• security management features

Processing Forms Requests

The Forms Services reside as a component, in the Oracle Internet Application Server, executing forms applications. The process of handling Forms applications is illustrated in Figure 3-5.

Figure 3-5 Control Flow for a Forms Request in Oracle Internet Application Server

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

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

3. The 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 on the Forms Server. The Forms Runtime 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 establish network communication using socket, HTTP, or HTTPS 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 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.

The Forms Services also optimize network traffic by using several methods for communicating to the Java Client including:

• Meta-data messages that reduce the amount of network traffic by using a collection of name-value pairs. These messages tell the Java Client which object to act upon and how,

• Message diffing comparing 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.

Forms Services supports standard protocols to deploy applications including socket, HTTP, and HTTPS.

For information about developing and deploying Forms in the Oracle Internet Application Server, refer to Deploying Forms Applications to the Web with Oracle Internet Application Server in the Forms and Reports Server documentation of your Documentation Library CD-ROM.