Release 1 (9.0.1)
Part Number A90213-02
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle9i Servlet Engine Developer's Guide Release 1 (9.0.1) Part Number A90213-02 |
|
This chapter introduces Java servlets and the Oracle Servlet Engine (OSE). It describes the basics of the OSE design and operation, and shows how to combine the OSE with other products to get speed and scalability for your Web application. Later chapters of this guide describe in detail how to develop an application for the OSE and how to administer the OSE.
This chapter covers the following topics:
A Web server is simply a program that runs on a server platform, and sends files back to clients that request them. Client requests use the HTTP protocol, and the files are typically pages written using HTML. The client is usually a Web browser such as Netscape Communicator or Internet Explorer, but any client or even a server-side program can send HTTP requests to a Web server.
Apache is a well-known Web server. The Oracle HTTP Server is the Oracle extended version of the Apache Web server.
A Web server takes the URL sent by the client, and finds a file on a server that it can send back to the client, as an HTTP response. But some clients require information that has dynamic content, that can change over time, or that varies depending on information that the client sends to the server as part of the request.
To serve dynamic content, a Web server can include or call on a servlet engine, which is a program that takes a client request for a dynamic page and activates a Java class--the servlet--that provides the dynamic content. The content is typically derived from queries to the database, normally using a JDBC connection.
A servlet engine is almost always separate architecturally from the Web server. For example, the Apache Web server can use the JServ servlet engine, which supports the Servlet 2.0 specification, or the newer Tomcat servlet engine, which supports the Java Servlet specification version 2.2.
The Oracle Servlet Engine running in the Oracle Java Virtual Machine (OJVM) is a servlet engine that works in conjunction with the Oracle HTTP Server, using the mod_ose module.
Traditional Web applications have consisted of static pages written in HTML, combined with a few forms to provide for user input and to supply dynamic content. The dynamic content was usually enabled using Common Gateway Interface (CGI) scripts, often written in a scripting language such as Perl or TCL.
Although static HTML pages are a central part of most Web applications, using CGI scripts to supply dynamic content turned out to be very inefficient. For example, in the traditional model each request to a script requires spawning a separate process in the Web server, thus limiting the scalability of the Web application.
Servlets were designed to overcome these limitations, and to provide efficient access to data stored in a database server.
A servlet is a Java class that executes on a server. It is the server-side version of a Java applet. You write a servlet using standard, platform-independent Java, and compile it using a Java byte code compiler. Compile your servlets using a Sun JDK 1.2-compliant Java compiler. After compilation, the servlet is loaded into an Oracle9i server, either on the data tier or perhaps into a read-only database on the middle tier, and is published in the server. The servlet runs inside the servlet engine.
After a few configuration steps, the servlet is accessible to a Web browser or other client that uses the HTTP protocol. The client can query the servlet and receive the servlet response, for display or other processing.
As with Enterprise JavaBeans (EJBs), servlets are invoked indirectly. However, to call an EJB method directly from a client, you must activate an ORB and use the session IIOP or RMI/IIOP protocol to call methods on the bean. The client activates a servlet using an HTTP request, from a Web browser or other client application. Unlike EJBs, you do not call methods on a servlet, because a servlet has a single entry point. Instead, the client activates the servlet, which then processes the HTTP request, and sends a response back to the client.
Data can be passed to the servlet in the request URL. A common scenario is for the client to activate a Web page, written in HTML. The Web page collects some information from the user, then calls a servlet in the middle tier or in the data tier to obtain information from the database.
Servlets are close to the data. This is especially true for the Oracle9i platform. In that platform, servlets reside in the server JVM, and have very fast in-memory access to SQL data through a special internal JDBC driver.
A servlet can be either stateless or it can have state.
A stateless servlet simply processes requests, sending the response back to the client. It has no knowledge of other requests, or any data that they might contain. This follows the HTTP protocol, which is a stateless protocol. The only certain way that two stateless requests can share data is for the servlet to store the data of one request in the database, and retrieve it when needed for other requests. There is no common Java memory that stateless servlets can share.
However, for many applications it is very convenient to be able to handle separate but related HTTP requests in a way that preserves their relatedness. For example, when you connect to a Web site to purchase some items, the server maintains a shopping cart of your selections. But to keep the shopping cart available, the server has to know who the client is. The client might make many requests to place items in the cart, and for the server and the client to agree on which client goes with which cart requires that some state be maintained.
Servlet engines have a mechanism for handling related requests: the session. A session encompasses a series of related requests that come from the same client, within a specified time period. Session state mechanisms relate the separate requests from the same client. The most successful session state mechanism has been cookies, developed by Netscape.
The server sends a cookie to the client that identifies the session, and the client (a Web browser, for example) returns the cookie with each new request to the same domain. There are also other mechanisms to relate requests that are used, for browsers that do not support cookies, or in cases where the client has turned off cookies. Two of these mechanisms are URL rewriting and Hidden Form Fields. The OSE/OJVM supports URL rewriting whenever cookies are not available.
The J2EE Servlet 2.2 specification defines a session interface. This allows stateful servlets to persist information on the server, by using an HttpSession object. Thus any servlet that is written to the 2.2 specification can maintain and process session state in the same way.
A Java servlet offers the following advantages over scripts and other methods that provide database access for Web applications:
Servlets are an effective replacement for CGI scripts. They provide a way to generate dynamic content that is both easier to write and runs faster. In addition, servlets address the problem of doing server-side programming with platform-specific APIs: they are developed with the Java Servlet API, a standard Java extension.
So, use servlets to handle HTTP client requests. For example, have servlets process data POSTed over HTTPS using an HTML form, including purchase order or credit card data. A servlet such as this could be part of an order-entry and processing system, working with product and inventory databases, and perhaps an on-line payment system.
JavaServer Pages (JSPs) are also becoming widely used in Web applications to provide dynamic content for HTTP clients. JavaServer Pages is a technology that is specified by Sun Microsystems as a convenient way of generating dynamic content in HTML pages that are served up by a Web application.
JSPs are closely coupled with Java servlet technology. They allow you to include Java code snippets and calls to external Java components within the HTML code (or other markup code, such as XML) of your Web pages. JSPs work nicely as a front-end for business logic and dynamic functionality in JavaBeans and Enterprise JavaBeans (EJBs).
JSP code is distinct from other Web scripting code, such as JavaScript, in a Web page. Anything that you can include in a normal HTML page can be included in a JSP page as well. In a typical scenario for a database application, a JSP page will call a component such as a JavaBean or Enterprise JavaBean, and the bean will directly or indirectly access the database, generally through JDBC or perhaps SQLJ. The server translates a JSP page into a Java servlet before being executed (typically on demand, but sometimes in advance), and it processes HTTP requests and generates responses similarly to any other servlet.
JSPs provide a standard way to separate HTML code and Java code. Web developers who are familiar only with HTML can maintain JSPs independently of the dynamic content.
JSP pages are fully interoperable with servlets. JSP pages can include output from a servlet or can forward to a servlet, and servlets can include output from a JSP page or can forward to a JSP page.
See the JavaServer Pages Developer's Guide and Reference for complete information about the use of JSPs in the Oracle Servlet Engine.
The Oracle Servlet Engine is a complete, full-featured servlet container. The purpose of a servlet engine is to support Web applications. A Web application can consist of Java servlets, JSP pages, static HTML Web pages, and other Web resources. Other resources might include CGI scripts, image files, compressed archives, and various other data files.
The OSE fully supports the servlet 2.2 specification, which is part of the J2EE specification.
Although functionally identical to servlet activation in a non-server JVM, the servlet activation model for the OSE/OJVM depends upon the properties of the OJVM, and hence requires a different development model for optimum speed and scalability.
The Java process, and hence the Java servlet, are started up only when a request comes into the OSE service. This is the way the OJVM itself works, as described in the Oracle9i Java Tools Reference. For this reason, "heavy weight" servlets, that do a lot of initialization work when started up, often do not confer any performance advantage in the OSE/OJVM, and they always incur a performance penalty on session start-up.
The OSE/OJVM supports stateful servlets very well, due to the nature of the OJVM session model. However, if your application makes heavy use of stateless servlets, be aware that each request to a stateless servlet requires a new instantiation of the OJVM, which is costly.
Therefore, if your application uses stateless servlets you should always connect to the OSE by way of Apache and mod_ose, because mod_ose keeps a stateless connection to the OSE open for the duration of each Apache (httpd) process. If the application servlets do a lot of initialization (such as caching connection pools, precomputed data, or data obtained from the database), then it is likely that other client requests will get hits on the cached data when you use Apache and mod_ose. If you connect directly to the OSE/OJVM to run stateless servlets, each new HTTP request starts a new server session, and any caching that the servlet does is completely wasted.
The most important thing to keep in mind about the OSE is that it runs within an Oracle9i server. The OSE runs under the Java Virtual Machine, in a server session. Each new request to the OSE gets a separate session, each with its own JVM.
Because the servlet engine is running as part of an Oracle server session, it offers very fast access to data. A direct in-memory connection is available, using the Oracle server-side internal JDBC driver, thereby making access to SQL data from JDBC statements almost immediate. This fast-path access is also indirectly but conveniently available to SQLJ statements in a servlet, and to JSP statements.
The OSE can also serve static HTML pages to a browser, but that is not its primary role. For efficient serving of both dynamic content and static pages it is best to combine the OSE/OJVM in a server (running servlets for fast database access) with the Oracle's HTTP server. The Oracle HTTP Server uses a module (mod_ose) that is provided for access to the OSE/OJVM. Chapter 4, "An Apache Module for OSE" describes mod_ose.
A Web application that is implemented using servlets is by definition distributable. When you publish an application in the Oracle9i server, it is simultaneously accessible by many clients. Each client that connects to the instance in which the application runs gets its own virtual JVM. It is important to realize that these are not separate threads of execution, but are completely separate JVMs.
The following statement from the Oracle9i Java Developer's Guide (page 1-13) summarizes the special way that the OJVM operates:
"As a database server, Oracle9i efficiently schedules work for thousands of users. The Oracle9i Aurora JVM uses the facilities of the RDBMS server to concurrently schedule Java execution for thousands of users. Although Oracle9i supports Java language level threads required by the Java language specification (JLS) and Java Compatibility Kit (JCK), using threads within the scope of the database will not increase your scalability. Using the embedded scalability of the database eliminates the need for writing multi threaded Java servers. You should use the database's facilities for scheduling users by writing single-threaded Java applications. The database will take care of the scheduling between each application; thus, you achieve scalability without having to manage threads. You can still write multi threaded Java applications, but multiple Java threads will not increase your server's performance."
When the Oracle Servlet Engine is running in an Oracle server instance, it looks for pages, as well as other objects such as servlets, in its "filesystem". The OSE filesystem is a namespace that represents objects that are stored in the database, as entries in SQL tables. This namespace, which is configured and maintained using JNDI, looks to the OSE application developer just like a UNIX file system. A UNIX or Windows NT filesystem has a root directory. For example, '/' in UNIX is the root directory of a file system, and "C:\" in Windows NT is the root of a disk drive. In JNDI, a directory is called a context, and there is a root context, also named '/'. An object name in JNDI is called a reference, because it is a name bound to a specific object.
You usually access the OSE/OJVM namespace using command tools that were written using JNDI, and that execute in the Oracle9i server. The principal tool is the session shell, which is a utility that mimics a simple version of a UNIX command-line shell. The session shell provides built-in commands that let you explore the namespace, such as the directory lister ls and the cd utility, and tools that let you modify the namespace, such as mkdir (create a new context), rm (remove a context or a reference), chmod (change the access permissions on a context or reference), and many other UNIX-like commands. See Chapters 2 and 3 for more information about the session shell and the other tools. You can find the complete documentation for these tools in the Oracle9i Java Tools Reference.
Hosting a Web application on an Oracle server requires the following:
When using the Oracle Servlet Engine, you can configure your Web site to use virtual hosts. Virtual hosting allows you to host more than one Web domain with a single servlet engine, running in a single Oracle server session.
You can also configure the Oracle Servlet Engine to support multiple IP addresses. If your server system has multiple network interface cards (NICs), a domain for each card's address can be configured into the OSE. For example, you might do this if you have a single system that supports entry points for both intranet services inside your company's firewall and internet services external to the firewall.
Multiple IP address and name-based virtual hosting can be combined. You can configure a system that combines one or more network interfaces that host a single Web domain and other network interfaces that support multiple virtual hostnames.
To develop a servlet-based Web application for the OSE/OJVM, you follow these basic steps. Later parts of this guide describe these steps in detail.
loadjava tool. See the Oracle9i Java Tools Reference for information about loadjava.
For the OSE/OJVM, you perform steps 1 and 2 using the session shell tool. The session shell, and the session shell commands that you use, are described in Chapter 2, "Oracle Servlet Engine Concepts" and in Chapter 3, "OSE Configuration and Examples". Steps 4 and 5 are performed from the operating system command prompt. Steps 1, 2, 4, and 5 are best done indirectly using a makefile in UNIX, or a batch script in Windows NT. See the makefiles and batch scripts in the demo directories of your OSE/OJVM installation for examples.
You can perform the following steps using either commands in the session shell, or by using a Web Application Archive (WAR) deployment file. For maximum portability, Oracle recommends that you write and use a WAR file. See Chapter 8, "Oracle WAR Deployment" for complete information on deploying a Web application using a WAR file.
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|