Oracle Internet Application Server 8i Overview Guide Release 1.0.1 A83707-02 |
|
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.
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.
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:
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 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 (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 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.
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 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.
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.
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 (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.
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:
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.
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.
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.
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.
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:
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.
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.
The process of handling a PL/SQL Server Page is illustrated in Figure 3-3.
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.
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:
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.
When deploying reports in a Web environment, you should consider the following:
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.
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.
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.
The Oracle Internet Application Server provides support for running applications with advanced functionality such as business logic, scalability, and performance.
Java code can be deployed for execution on either of two Java runtime environments in Oracle Internet Application Server:
Apache JServ supports running Servlets and JSPs. When deploying Java applications on the JDK JVM, you should consider the following:
Applications that are stateless or hold on to minimal conversational state will benefit from the responsiveness of the JDK JVM.
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.
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.
Oracle8i JVM support running Enterprise JavaBeans. When deploying Java applications on Oracle8i JVM, you should consider the following:
Applications that hold on to substantial amounts of conversational state will scale better in Oracle8i JVM.
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.
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 deploy Forms applications with database access to Java clients in a Web environment. Together with Oracle Forms Developer, Oracle Forms Services provide:
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:
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.
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:
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.
|
Copyright © 2000 Oracle Corporation. All Rights Reserved. |
|