Release 2 (9.0.2)
Part Number A95926-02
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9i Application Server Concepts Release 2 (9.0.2) Part Number A95926-02 |
|
This chapter describes the Java 2 Platform, Enterprise Edition (J2EE) and Internet application development and deployment environment in Oracle9i Application Server (Oracle9iAS), explaining its features and concepts. The topics include:
Oracle9iAS provides an integrated, standards-based infrastructure that makes it easy to develop applications for deployment, and that reliably delivers those deployed applications to users across an enterprise. The following sections describe how this infrastructure aids application development and deployment.
Oracle9i Application Server allows Web application developers to program their site in a variety of languages and technologies:
Table 2-1 lists the different technologies and programming languages that you can use to build applications for deployment with Oracle9iAS.
The following sections explain how Oracle9iAS supports these technologies and programming languages.
Oracle9iAS Containers for J2EE (OC4J) are fast, lightweight, and scalable J2EE containers that are written in Java and run on a standard Java Virtual Machine (JVM). They have been designed for ease of use and to support the standard APIs in Table 2-2.
Figure 2-1 shows the architecture of OC4J within Oracle9i Application Server.
OC4J is supported by the Java 2 Platform, Standard Edition (J2SE) infrastructure as shown in Figure 2-1. This means that the OC4J Web container and OC4J EJB container use the J2SE virtual machine. J2EE applications are modularized for reuse of application components, such as
The J2EE containers also perform services for applications, such as providing access to the APIs and lifecycle management.
The following sections provide introductory definitions and summaries of application programming technologies that are supported by Oracle9iAS. For detailed information on the technologies introduced in this section, refer to the following information sources.
|
See Also:
|
J2EE applications are composed of components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and XML descriptor files that communicate with other components. J2EE components are written in the Java programming language and are compiled in the same way as any program written in Java.
The J2EE platform provided in Oracle9i Application Server uses a multitiered distributed application model. A multitiered distributed application model divides application logic into components according to function, and the various application components that make up J2EE applications can be installed on different machines depending on which tier in the multitiered J2EE environment the application component belongs. Figure 2-2 shows two multitiered J2EE applications divided into the client, Web, business logic, and enterprise data tiers.
You can distribute J2EE applications across the four tiers shown in this figure, but generally they are considered to be three-tier applications because they are usually distributed over the following machine locations:
Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing an application server between the client and the back-end storage.
J2EE applications support the following clients:
You can use the following components in J2EE applications:
Containers are the interface between a component and the low-level platform-specific functionality that supports the component. Before a Web or enterprise bean component can run, it must be assembled into a J2EE application and deployed into a J2EE container. The assembly process involves specifying container settings for each component, which customize the underlying support provided by the J2EE server. These settings can be standard J2EE settings or container-specific settings depending on your application requirements. Some of the container settings that you can specify include security services, transaction model, naming and directory lookup, or remote connectivity model.
The J2EE containers are:
J2EE components are packaged separately and bundled into a J2EE application. Each component, with its related files such as GIF and HTML files or server-side utility classes, are packaged together with a deployment descriptor (DD), and are assembled into a module that is added to the J2EE application. Typically, a J2EE application is composed of one or more enterprise beans and Web or application client component modules.
A servlet is a Java program that runs on a J2EE server, such as OC4J. Think of a servlet as the server-side counterpart to a Java applet. A servlet is one of the application component types of a J2EE application. It must execute under the control of a servlet container, which is part of the OC4J Web container. The servlet container calls the servlet's methods and provides services that the servlet needs when running.
The servlet container provides the servlet with access to properties of the HTTP request, such as headers and parameters. Also, the container provides the servlet with access to other Java APIs, such as JDBC to access a database, Remote Method Invocation (RMI) to call remote objects, or JMS to perform asynchronous messaging.
When a request is mapped to a servlet, the servlet container performs the following steps:
The servlet extracts information from the client request, accesses external resources, and then populates the response based on that information.
JavaServer Pages provide a convenient way to generate dynamic content in Web pages. JSP technology, which is closely coupled with Java servlet technology, allows you to include Java code fragments and call, in the form of tags and directives, external Java components from within your Web pages. Typically the markup code used to compose your Web pages is HTML or XML. JSPs work well as a front-end for business logic and dynamic functionality in JavaBeans or Enterprise JavaBeans (EJBs).
A JSP is translated into a Java servlet before being run, and it processes HTTP requests and generates responses like any servlet. However, JSP technology provides a more convenient way to code a servlet. Translation occurs the first time the application is run. A JSP translator is triggered by the .jsp file name extension in a URL.
JSPs are fully interoperable with servlets. You can include output from a servlet or forward the output to a servlet, and a servlet can include output from a JSP or forward output to a JSP.
The JSP translator has a translator and a compiler. The JSP translator translates a JSP into a Java source file. The container compiles the source file into a Java bytecode (.class) file, which executes as a servlet in the servlet container using the JSP runtime library. The servlet container provides access to Java APIs and other services.
When a user requests a URL that maps to a JSP file, such as http://host/Hello.jsp, the following steps occur:
Hello.jsp and produces the file Hello.java.
Hello.class servlet.
Hello.class runs, using the JSP runtime library, which contains the supporting files to interpret the tags and directives from the JSP.
Hello class requires information from a database, then the servlet container provides JDBC access to the class so it can retrieve the information and return its output to the client browser.
The OC4J EJB container manages the execution of enterprise beans for J2EE applications. Like the OC4J Web container, the EJB container uses the J2SE virtual machine. The following sections describe what services the EJB container provides to J2EE applications and how it works.
Enterprise beans are the J2EE components that implement Enterprise JavaBeans technology. Enterprise beans run in the EJB container. An enterprise bean is a portable server-side component that encapsulates the business logic of an application. There are three types of EJBs: session beans, entity beans, and message-driven beans.
The OC4J EJB container provides system-level services to EJBs similar to the services that the Web container provides to servlets and JSPs. The container has configurable settings that customize the underlying support provided by OC4J, the J2EE server. The configurable settings include security, transaction management, Java Naming and Directory Interface (JNDI) lookups, and remote connectivity. In addition to the configurable settings, the container also manages EJB life cycles, database connection resource pooling, data persistence, and access to the J2EE APIs.
How the EJB container works depends on what type of enterprise bean you are using. The container manages the execution of the enterprise bean for one J2EE application.
For session beans, the EJB container provides all of the services that the Web container provides to Web components, such as access to APIs and the virtual machine, transaction services like Container Managed Transactions (CMTs), and secure and authorized EJB method invocation.
For entity beans, which represent business objects in a persistent storage mechanism, you can choose to have the bean manage its own persistence, or you can choose to have the container manage it. Persistence means that the entity bean's state exists beyond the lifetime of the application or the server process, like the data in a database, which is also persistent.
Depending on what entity manages a beans persistence, you can have either bean-managed persistence (BMP) beans or container-managed persistence (CMP) beans. With bean-managed persistence, the entity bean code contains the calls that access the database and the EJB container triggers callback methods on your code. Entity beans with bean-managed persistence execute in the EJB container with the typical container support and services. However, if you are using container-managed persistence, then the EJB container automatically generates the necessary database access calls. The EJB methods do not require any JDBC code to manage EJB data persistence.
J2SE provides core services for writing J2EE components. The J2EE containers manage access to these services for the application components. The services are:
Oracle9i Application Server includes the Oracle JDBC driver and DataDirect Connect Type 4 JDBC drivers. These drivers provide highly scalable and reliable connectivity to both Oracle and non-Oracle data sources.
OC4J provides additional support for two-phase commits for applications that require commit coordination across machines and containers. The two-phase commit engine is responsible for ensuring that when a distributed transaction ends, changes to all participating databases are all either committed or rolled back.
Oracle9i Application Server provides an implementation of Java Authentication and Authorization Service (JAAS) that integrates with the Oracle9iAS J2EE security infrastructure to enforce security constraints for Web (servlets and JSPs) and EJB components. The Oracle JAAS implementation:
The Sun Microsystems, Inc. published specifications for these services, and The J2EE Tutorial for instructions on how to use them in J2EE applications, at:
See Also:
http://java.sun.com
In addition to the standard J2EE Services, Oracle also provides the following services to Java developers:
Oracle9iAS MVC Framework for J2EE is available from the Oracle Technology Network at
Note:
http://otn.oracle.com/products/ias
The move to transform businesses to e-businesses has driven organizations around the world to begin to use the Internet to manage corporate business processes. Despite this transformation, business on the Internet still functions as a set of local hosts, or Web sites, with point-to-point communications between them. As more business moves online, the Internet should no longer be used in such a static manner, but rather should be used as a universal business network through which services can flow freely, and over which applications can interact and negotiate amongst themselves.
To enable this transformation, the Internet needs to support a standards-based infrastructure that enables companies and their enterprise applications to communicate with other companies and their applications more efficiently. These standards should allow discrete business processes to expose and describe themselves on the Internet, allow other services to locate and invoke them, and provide a predictable response.
Web services drive this transformation by promising a fundamental change in the way businesses function and enterprise applications are developed and deployed. A Web service is a discrete business process that:
Web services provide a standards based infrastructure through which any business can do the following:
Oracle9iAS Web Services run as servlets in the OC4J servlet container. This gives Web services the same scalability, availability, and load balancing facilities that all J2EE applications have in Oracle9iAS.
The following Internet standards provide the Web services framework:
XML makes data portable and interoperable across heterogeneous systems. XML is a metamarkup language that supports markup tags that have been defined by the user to encapsulate and describe data in a Web page. Because it is a self-defined language, it is extremely flexible.
To provide basic XML infrastructure components to manipulate and transform XML documents, Oracle9iAS includes the Oracle XML Developer Kit (XDK) to support development of any applications that use XML. The XDK contains component libraries and utilities that are based on W3C specifications. You can use these components to generate, manipulate, render, and store XML-formatted data in an Oracle database or to share data between applications written in diverse programming languages. The following sections describe the tools that make the Oracle XML Developer Kit.
The XML parser APIs are defined by the W3C specifications so that standard programming interfaces can be used by application developers. However, if some functionality is not specified, then Oracle Corporation may implement its own enhancements to the specifications.
The Oracle XML and XSLT parsers provide international character set and multithreaded support, allow optional validation, and cache Document Type Definitions (DTDs) and stylesheets for performance.
Oracle XML Developer Kit provides the following APIs:
Oracle XML schema processors comply with the Structures and Datatypes sections of the W3C XML Schema Working Drafts, except for certain features such as unique, key, keyref constraints when the SAX parser is used. XML schemas are a superset of DTDs, except for the support of primitive and complex datatypes in XML schemas. This allows you to validate XML documents, with embedded datatype information, against XML schemas.
The XML class generators create a set of Java or C++ classes that create XML documents corresponding to a DTD or XML schema definitions. This is useful when an application wants to send an XML message to another application based on an agreed-upon DTD or as the back end of a Web form to construct XML documents. You can use the generated classes to programmatically construct XML documents that comply with the DTD or schema definition.
XSQL Servlet is a tool that processes SQL queries and outputs the result set as an XML document. This processor uses an XML file with embedded SQL queries as its input. You can use XSQL Servlet to perform the following tasks:
XML transviewer beans are a set of XML components that constitute XML for Java Beans. These are used by Java applications or applets to view and transform XML documents.
These beans are visual and non-visual Java components that are integrated into Oracle9i JDeveloper to enable the fast creation and deployment of XML-based database applications.
Web applications written in PL/SQL are sets of stored procedures that interact with Web browsers through the HTTP protocol:
This kind of dynamic content is different from dynamic HTML (DHTML). With DHTML, the code is downloaded as JavaScript or some other scripting language, and processed by the browser along with the HTML. A PL/SQL Web application can print JavaScript or other script code in its output, to produce complex DHTML that would be tedious to produce manually.
Oracle9i Application Server PL/SQL developers can create applications using either Oracle PL/SQL Server Pages or Oracle PL/SQL Web Toolkit.
To include dynamic content, including the results of SQL queries, inside Web pages, you can use server-side scripting through PL/SQL Server Pages (PSP). You can author the Web pages in a script-friendly HTML authoring tool, and drop the pieces of PL/SQL code into place. You may find this technique more convenient than using the HTP and HTF packages to write out HTML content line by line.
Because the processing is done on the database server rather than the Web server, the browser receives a plain HTML page with no special script tags, and you can support all browsers and browser levels equally. It also makes network traffic efficient by minimizing the number of server roundtrips.
Embedding the PL/SQL code in the HTML page that you create lets you write content quickly and follow a rapid, iterative development process. You maintain central control of the software, with only a Web browser required on the client machine.
The PL/SQL toolkit contains PL/SQL packages that allow you to create applications that generate dynamic HTML. Using the toolkit, you can access data and insert it into Web pages. The packages remove the need for you to know the specifics of HTML syntax and allows you to focus on writing applications.
Oracle Forms applications combine interactive, graphical interfaces with strong support for data validation. Forms developers can quickly create applications with powerful data manipulation features.
An Oracle Forms application gives you the power of a desktop application deployed in a browser. It provides a very rich and productive user interface by allowing:
An Oracle Forms application is analogous to a traditional HTML form application. In the traditional application, the user enters data into a form on a Web page and submits the data. The Web server then processes the data from the form in a CGI application. The application then performs any necessary transactions and then returns feedback to the user's browser. JavaScript and the database perform data validation tasks to ensure that the data from the form is correct and complete.
Oracle9iAS Forms Services deploys Forms applications to Java clients in a Web environment. Oracle9iAS Forms Services automatically optimizes class downloads, network traffic, and interactions with the Oracle database. Applications are automatically load-balanced across multiple servers and, therefore, can easily scale to service any number of requests.
Oracle9iAS Forms Services consists of three components:
When a client requests an Oracle9iAS Forms application, the request has the following flow:
Figure 2-3 illustrates this flow in terms of the Oracle9iAS Forms Services architecture.
Oracle HTTP Server is the underlying deployment platform for all programming languages and technologies Oracle9iAS supports. It provides a Web listener for OC4J and the framework for hosting static and dynamic pages and applications over the Web. Based on the proven technology of the Apache HTTP Server, Oracle HTTP Server includes significant enhancements that facilitate load balancing, administration, and configuration. It also includes a number of enhanced modules, or mods, which are extensions to the HTTP server that extend its functionality for other enterprise applications and services.
Oracle HTTP Server allows developers to program their site in a variety of languages and technologies such as Java, Perl, C, C++, and PL/SQL. Additionally, it can serve as either a forward or reverse proxy server. The following sections describe how Oracle HTTP Server provides a robust deployment platform for dynamic Web sites and applications.
Oracle HTTP Server consists of several components that run within the same process. These components provide the extensive list of features that Oracle HTTP Server offers when handling client requests. Major components include:
Table 2-3 Prominent Oracle HTTP Server Modules
Figure 2-4 shows the path of various requests through Oracle HTTP Server components.
In addition to the standard Web server functionality of serving client requests to other Oracle9iAS components, Oracle HTTP Server also provides enterprise support with the following features:
At startup, the Web server parent process loads the entire configuration, the associated mods, and spawns a preconfigured number of child processes.
Figure 2-5 shows the process architecture of Oracle HTTP Server in a UNIX environment.
The parent process does not listen to HTTP requests. Its sole job is to ensure that the child processes are running or that new ones are started when the load requires it.
On UNIX platforms, each child process handles a single HTTP request. The child processes determine who should take the next request based on a mutex mechanism that you can configure.
The architecture of Oracle HTTP Server is modular. The core HTTP listener is very small with all capabilities implemented as modules that plug in and are invoked at the appropriate place during the HTTP request lifecycle. Figure 2-6 shows the lifecycle of an HTTP request in Oracle HTTP Server.
A child process guides the request through this entire lifecycle. The modules register their APIs, which are then either invoked automatically when the request reaches a certain stage in its lifecycle, or can be configured to be invoked only in certain situations.
Requests that are sent to a Common Gateway Interface (CGI) program may invoke two new processes--the child process that handles the HTTP request and the CGI program itself. It is possible to avoid this overhead by configuring Oracle HTTP Server to pre-start child processes and keep them running, leveraging the Perl module to run the CGI programs in memory, or using the FastCGI mechanism.
The following Oracle HTTP Server features support CGI:
A cluster is a set of application server instances configured to act in concert to deliver greater scalability and availability than a single instance can provide. While a single application server instance can only leverage the operating resources of a single host, a cluster can span multiple hosts, distributing application execution over a greater number of CPUs. While a single application server instance is vulnerable to the failure of its host and operating system, a cluster continues to function despite the loss of an operating system or host, hiding any such failure from clients.
Clusters leverage the combined power and reliability of multiple application server instances while maintaining the simplicity of a single application server instance. For example, browser clients of applications running in a cluster interact with the application as if it were running on a single server. The client has no knowledge of whether the application is running on a single application server or in an application server cluster. From the management perspective, an application server administrator can perform operations on a cluster as if the administrator was interacting with a single server. An administrator can deploy an application to an individual server; the application is propagated automatically to all application server instances in the cluster.
The following sections discuss how application server clustering increases scalability, availability, and manageability, and explain the server clustering architecture.
Table 2-4 lists the terms that Oracle9i Application Server documentation and administration tools use when referring to clustering.
Oracle9iAS clustering enables you to scale your system beyond the limitations of a single application server instance on a single host. Figure 2-7 shows how a cluster unifies multiple application server instances spread over multiple hosts to collectively serve a single group of applications. In this way, clustering makes it possible to serve increasing numbers of concurrent users after the capacity of a single piece of hardware is exhausted.
Clients interact with the cluster as if they are interacting with a single application server. An administrator can add an application server instance to the cluster while the cluster is operating, increasing system capacity without incurring downtime.
Clients access the cluster through a load balancer, which hides the application server configuration. The load balancer can send requests to any application server instance in the cluster, as any instance can service any request. An administrator can raise the capacity of the system by introducing additional application server instances to the cluster, each of which derives its configuration from a shared Oracle9iAS Metadata Repository.
Oracle9iAS clustering enables you to achieve a higher level of system availability than is possible with only a single application server instance. An application running on a single instance of an application server is dependent on the health of the operating system and host on which the server is running. In this case, the host poses as a single point of failure because if the host goes down, the application becomes unavailable.
An application server cluster eliminates the single point of failure by introducing redundancy and failover into the system. Any application server instance in the cluster can service any client request, and the failure of any single instance or host does not bring down the system. Client session state is replicated throughout the cluster, thereby protecting against the loss of session state in case of process failure. The administrator can configure the extent of session state replication.
Figure 2-8 illustrates how application server clusters enable higher availability by providing redundancy and backup and eliminating a single point of failure. Clients access the cluster through a load balancer which can send requests to any application server instance in the cluster. In the case that an application server instance becomes unavailable, the load balancer can continue forwarding requests to the remaining application server instances, as any instance can service any request.
Figure 2-9 demonstrates how managed clustering uses Oracle Enterprise Manager. While any clustered system requires all instances to be similarly configured in order to function properly, Oracle9iAS managed clustered instances synchronize their configurations automatically, relieving the administrator of the responsibility to manually update each individual instance. Using Oracle Enterprise Manager, the administrator can make configuration changes as if on a single application server instance. Applicable changes are propagated automatically to all instances in the cluster.
Oracle9iAS cluster management simplifies the tasks of creating and administering clusters and reduces the chance of human error corrupting the system. An administrator creates a cluster in a single management operation. Then, the administrator adds the initial application server instance to the cluster to define the base configuration for the cluster. Any additional instances automatically inherit this base configuration.
A cluster coordinates several application server instances and its components. The roles of the components included in the cluster are described in the following sections:
Figure 2-10 shows the architecture of a farm and a cluster. There are three application server instances, where each instance shares the same Oracle9iAS Metadata Repository within an infrastructure. Thus, all three application server instances are part of the same farm.
Application server instances 1 and 2 are involved in a cluster together. In front of the cluster is a front-end load balancer. Included within each application server instance are its manageability features--Oracle Process Management and Notification (OPMN) and Dynamic Configuration Management (DCM)--and its installed components--Oracle HTTP Server and Oracle9iAS Containers for J2EE (OC4J).
After you have created a cluster, you can add a load balancer in front of all application server instances in the cluster, which provides availability and scalability for the application server instances.
We recommend that you purchase and install a hardware load balancer for the best performance. Alternatively, you could use Web Cache as a load balancer, which could be a single point of failure.
|
See Also:
Oracle9iAS Web Cache Administration and Deployment Guide for instructions on how to set up Oracle9iAS Web Cache as your load balancer for your cluster |
When you install Oracle9iAS, you have the option of installing the Oracle9iAS Infrastructure. An Oracle9iAS Infrastructure provides Oracle Internet Directory, Oracle9iAS Single Sign-On, and the Oracle9iAS Metadata Repository. The metadata repository is an Oracle9i database that is used to store the application server instance information and configuration. The application server instance tables are created in the metadata repository. Multiple application server instances can share the metadata repository of the infrastructure.
Application server instances associate with an infrastructure either during installation or through the Oracle Enterprise Manager after installation.
A farm is a group of multiple application server instances that associate with the same metadata repository. The application server instances that belong to a farm can be installed anywhere on the network.
A cluster is a logical group of application server instances that belong to the same farm. Each application server instance may be part of only one cluster. If an instance is part of a cluster, then all of its configured components are implicitly part of that cluster. Each application server instance can only be configured with Oracle HTTP Server and OC4J components to be contained in a cluster. A cluster can include zero or more application server instances.
All application server instances involved in the cluster have the same "cluster-wide" configuration. If you modify the configuration on one application server instance, then the modification is automatically propagated across all instances in the cluster.
|
Note: "Instance-specific" configuration parameter modifications are not propagated. For a description of these parameters, see the Oracle9i Application Server Administrator's Guide. |
An application server instance consists of a single Oracle HTTP Server and one or more OC4J instances. It is a single installation in one Oracle home. If you have multiple application servers on a single host, each is installed into its own Oracle home and uses separate port numbers.
To manage clusters from Oracle Enterprise Manager, the application server uses a metadata repository for storing its tables and configuration. Each application server instance in the cluster has the same base configuration. The base configuration contains the cluster-wide parameters and excludes instance-specific configuration. If you modify any part of the cluster-wide configuration, the modifications are propagated to all other application server instances in the cluster. If you modify an instance-specific parameter, it is not propagated, as it is only applicable to the specified application server instance. See the Oracle9i Application Server Administrator's Guide for a listing of the instance-specific parameters. The cluster-wide parameters are all other parameters.
In order for each application server instance to be a part of a cluster, the following must be true:
Oracle9iAS Web Cache provides its own clustering functionality separate from application server clustering. See Oracle9iAS Web Cache Administration and Deployment Guide for more information.
Note:
Once grouped in the same cluster, these application server instances have the following properties:
Each application server instance contains management features that manage and monitor the application server instance, its components, and how it performs in a cluster. The management features do the following:
All of these activities are provided by the following management features:
Distributed Configuration Management (DCM) manages configuration by propagating the cluster-wide configuration for the application server instances and its components. When you add application server instances to the cluster, it is the DCM component that automatically replicates the base configuration to all instances in the cluster. When you modify the cluster-wide configuration, DCM propagates the changes to all application server instances in the cluster.
DCM is a management feature in each application server instance. However, it is not a process that exists at all times. DCM is invoked either by Oracle Enterprise Manager or manually by a user through dcmctl to do the following:
You can also manually execute the DCM command-line tool--dcmctl--to perform these duties. However, there are restrictions on how to use dcmctl, which are as follows:
Oracle9i Application Server Administrator's Guide. for directions on how to do the previous functions with the
See Also:
dcmctl tool
Oracle Process Management and Notification (OPMN) manages Oracle HTTP Server and OC4J processes within an application server instance. It channels all events from different components to all components interested in receiving them.
OPMN consists of the following two components:
The availability of a system or any component in that system is defined by the percentage of time that it works normally. A system works normally when it meets its correctness and performance specifications. For example, a system that works normally for twelve hours per day is 50% available. A system that has 99% availability is down 3.65 days per year on average. System administrators can expect critical systems to have 99.99% or even 99.999% availability. This means that the systems experience as little as four to five minutes of downtime per year.
Availability may not be constant over time. For example, availability may be higher during the daytime when most transactions occur, and lower during the night and on weekends. However, because the Internet provides a global set of users, it is a common requirement that systems are always available.
Redundant components can improve availability, but only if a spare component takes over immediately for a failed component. If it takes ten minutes to detect a component failure and twenty additional minutes to start the spare component, then the system experiences a 50% reduction in availability for that hour of service.
Oracle9iAS is designed to provide maximum system availability during many types of hardware and software failures.
Oracle9i Application Server keeps your system available by providing the following benefits:
At the mod_oc4j-OC4J level, after the failure of a stateless service, the application server routes requests to alternate instances of the service in a similar fashion to connection rerouting. After a failure of a stateful service, the application server reroutes the request to an alternate instance to which the state has been replicated.
At application server instance level, you can use a hardware load balancer, Oracle9iAS Web Cache, or a DNS round robin strategy to load balance requests across redundant application server instances. This allows your Web site to continue functioning even if one of the application server instances goes down.
|
See Also:
For instructions on configuring Oracle9iAS Web Cache as a load balancer to route requests, refer to Oracle9iAS Web Cache Administration and Deployment Guide. |
Figure 2-11 shows an example of high availability architecture where an Oracle9iAS instance can contain one Oracle HTTP Server instance and zero or more OC4J processes. Here, Oracle9iAS Web Cache is used as a load balancer to route requests. OPMN within the Oracle9iAS instance environment monitors the Oracle HTTP Server and OC4J processes. If either Oracle HTTP Server or OC4J fail, the OPMN restarts the failed process. This enables a maximum level of availability of the components within an Oracle9iAS instance.
The mod_oc4j module routes requests from the Oracle HTTP Server to Oracle Containers for J2EE (OC4J). It works in conjunction with OPMN to keep its routing table updated so that it load balances across only live OC4J processes in an OC4J instance. When a request comes in, mod_oc4j selects a process from its shared memory table. If a session is created with this request, related requests are routed to the same process. Otherwise, a new process is selected based on the load balancing algorithm. To allow fault tolerance, this module supports OC4J instances and islands. To handle failover with stateless requests, it tries to select an alternative OC4J process within the same island and routes the request to that process. If all the OC4J processes in the instance have been tried and none of them are successful, mod_oc4j returns request failure. For session enabled requests, the module tries to failover to another OC4J process within the same island as the original process that serviced the request. Again, if all the OC4J processes in the island are unable to service the request, mod_oc4j returns request failure.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|