Release 1.0.2
Part Number A87353-01
 Library |
 Solution Area |
 Contents |
 Index |
| Oracle9i Application Server Overview Guide Release 1.0.2 Part Number A87353-01 |
|
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:
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.
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:
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 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.
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.
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 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.
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.
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.
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:
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.
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.
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.
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 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.
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.
The process of handling a PL/SQL Server Page is illustrated in Figure 3-3.
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:
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.
When deploying reports in a Web environment, you should consider the following:
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 code can be deployed for execution on either one of two Java runtime environments in Oracle9i 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.
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.
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.
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.
Oracle8i JVM supports 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 Oracle9i Application Server, Java applications running in Oracle8i JVM benefit from very fast access when reading cached data in Oracle Database 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.
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.
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.
To deploy EJBs in the middle tier you must perform the following steps:
deployejb and loadjava commands to Oracle8i JVM.
host, port, and sid of the JVM to the command-line tools.
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.
All database resources are enlisted only if you perform one of the following:
getConnection method of the DataSource class. However, the DataSource object must be previously bound through bindds with the -type jta option.
Table 3-1 Local Resource Enlistment
To ensure that Oracle Database Cache is not treated as an enlisted database in the global transaction, perform the following steps:
default-enlist> element in the Oracle-specific deployment descriptor is either not set (and it defaults to FALSE) or is set to FALSE.
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:
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.
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 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
Oracle Forms Services resides as a component in Oracle9i Application Server. The process of handling Forms applications is illustrated in Figure 3-9.
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:
|
 Copyright © 2000 Oracle Corporation. All Rights Reserved. |
|