Skip Headers

Oracle9i Application Server Concepts
Release 2 (9.0.2)

Part Number A95926-02
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

2
J2EE and Internet Application Development and Deployment

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:

Application Development and Deployment in Oracle9iAS

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.

What Types of Applications Can Be Developed for Deployment in Oracle9iAS?

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.

Table 2-1 Supported Technologies and Programming Languages
Java and J2EE XML PL/SQL
  • JavaServer Pages (JSP)

  • Servlets

  • Enterprise JavaBeans (EJB)

  • Java Database Connectivity (JDBC)

  • Java Transaction API (JTA)

  • Java Naming and Directory Interface (JNDI)

  • Java Message Service (JMS)

  • Java Authentication and Authorization Service (JAAS)

  • Web Services

  • Document Object Model (DOM)

  • Extensible Stylesheet Language Transformations (XSLT)

  • XML Schemas

  • Simple API for XML (SAX)

  • XSQL

  • Internet Data Access Presentation (IDAP)

  • XML Path Language (XPath)

  • Simple Object Access Protocol (SOAP)

  • Web Services Description Language (WSDL)

  • Universal Description, Discovery, and Integration (UDDI)

  • PL/SQL Server Pages

  • PL/SQL Web Toolkit

  • Oracle Forms

The following sections explain how Oracle9iAS supports these technologies and programming languages.

Oracle9iAS Containers for J2EE

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.

Table 2-2 Oracle9iAS Containers for J2EE Supported APIs
API Version

JavaServer Pages (JSP)

1.2

Java Servlet

2.3

Enterprise JavaBeans (EJB)

2.0

Java Database Connectivity (JDBC)

2.0

Java Transaction API (JTA)

1.0

Java Message Service (JMS)

1.0

JavaMail

1.2

JavaBeans Activation Framework

1.0

Java API for XML (JAXP)

1.1

J2EE Connector API

1.0

Java Authentication and Authorization Service (JAAS)

1.0

Figure 2-1 shows the architecture of OC4J within Oracle9i Application Server.

Figure 2-1 Oracle9iAS Containers for J2EE Architecture

Text description of ascon006.gif follows

Text description of the illustration ascon006.gif

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.

J2EE Application Development Concepts

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:

  • The J2EE Tutorial at http://java.sun.com

  • The Oracle9i Application Server Documentation Library

What Is a J2EE Application?

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.

J2EE Distributed Multitiered Application Model

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.

Figure 2-2 J2EE Distributed Multitiered Application Architecture

Text description of ascon005.gif follows

Text description of the illustration ascon005.gif

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.

Types of J2EE Clients

J2EE applications support the following clients:

Types of J2EE Application Components

You can use the following components in J2EE applications:

Types of J2EE Containers

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 Application Packaging Concepts

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.

How OC4J Runs and Manages Servlets

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.

See Also:

"Types of J2EE Application Components"

About the Servlet Container

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.

How the Servlet Container Works

When a request is mapped to a servlet, the servlet container performs the following steps:

  1. If an instance of the servlet does not exist, the container:

    1. Loads the servlet class.

    2. Instantiates an instance of the servlet class.

    3. Initializes the servlet instance.

  2. The container then invokes the servlet, passing request and response objects. The request object contains information about the client, request parameters, and HTTP headers. The response object returns the servlet's output to the client.

The servlet extracts information from the client request, accesses external resources, and then populates the response based on that information.

How OC4J Runs and Manages JavaServer Pages

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.

About the JSP Translator

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.

How the JSP Translator Works

When a user requests a URL that maps to a JSP file, such as http://host/Hello.jsp, the following steps occur:

  1. The Web server invokes the JSP translator, which translates Hello.jsp and produces the file Hello.java.

  2. The Java compiler is invoked, creating a Hello.class servlet.

  3. Hello.class runs, using the JSP runtime library, which contains the supporting files to interpret the tags and directives from the JSP.

  4. If the 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.

How OC4J Runs and Manages EJBs

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.

About the OC4J EJB Container

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

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.

J2EE Services

J2SE provides core services for writing J2EE components. The J2EE containers manage access to these services for the application components. The services are:

Oracle J2EE Services

In addition to the standard J2EE Services, Oracle also provides the following services to Java developers:

Oracle9iAS Web Services

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 Architecture

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.

See Also:

"How OC4J Runs and Manages Servlets"

Web Services Framework

The following Internet standards provide the Web services framework:

Oracle XML Developer Kit

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.

XML and XSLT Parsers

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:

XML Schema Processors

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.

XML Class Generators

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

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

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.

Oracle9iAS PL/SQL Platform

Web applications written in PL/SQL are sets of stored procedures that interact with Web browsers through the HTTP protocol:

Oracle9iAS PL/SQL

Oracle9i Application Server PL/SQL developers can create applications using either Oracle PL/SQL Server Pages or Oracle PL/SQL Web Toolkit.

Oracle PL/SQL Server Pages

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.

Oracle PL/SQL Web Toolkit

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.

Oracle9iAS Forms Services

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:

Oracle9iAS Forms Services Architecture

When a client requests an Oracle9iAS Forms application, the request has the following flow:

  1. The client browser requests a forms application over HTTP or HTTPS.

  2. Oracle HTTP Server receives this request.

  3. Oracle HTTP Server forwards the request to the Forms Listener Servlet running in OC4J.

  4. The servlet returns a page to the client that contains information the client needs to start the Forms Client Applet. The applet launches in the client browser.

  5. The client applet starts a Forms session with the Forms Listener Servlet.

  6. The servlet starts a new Forms Runtime Process for the client.

  7. The runtime process opens a database connection and handles all interactions between the client and database.

  8. The runtime process sends metadata to the client describing the interface. The Forms applet renders the interface in the client browser.

Figure 2-3 illustrates this flow in terms of the Oracle9iAS Forms Services architecture.

Figure 2-3 Oracle9iAS Forms Services Request Flow

Text description of formsarc.gif follows.

Text description of the illustration formsarc.gif

Oracle HTTP Server

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 Components

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:

Figure 2-4 shows the path of various requests through Oracle HTTP Server components.

Figure 2-4 Oracle HTTP Server Request Flow

Text description of ascon016.gif follows

Text description of the illustration ascon016.gif

Oracle HTTP Server Features

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:

Oracle HTTP Server Architecture

At startup, the Web server parent process loads the entire configuration, the associated mods, and spawns a preconfigured number of child processes.


Note:

On Windows systems, the Web server main process is a child process that spawns multiple threads.


Figure 2-5 shows the process architecture of Oracle HTTP Server in a UNIX environment.

Figure 2-5 Oracle HTTP Server Process Architecture

Text description of ascon009.gif follows

Text description of the illustration ascon009.gif

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.


Note:

On Windows platforms, threads handle HTTP requests instead of child processes.


Modular Architecture

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.

Figure 2-6 Oracle HTTP Server HTTP Request-Response Cycle

Text description of ascon017.gif follows

Text description of the illustration ascon017.gif

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.

Common Gateway Interface (CGI) Support

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:

Oracle9iAS Clustering

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.

Clustering Terminology

Table 2-4 lists the terms that Oracle9i Application Server documentation and administration tools use when referring to clustering.

Table 2-4 Oracle9i Application Server Clustering Terminology  
Term Definition

Oracle9iAS Metadata Repository

The Oracle9iAS Metadata Repository maintains information about the available instances in a cluster. This simplifies the process of creating clusters and synchronizing applications and state information across a cluster because all Oracle9iAS instances share the same repository. Changing the configuration or deploying an application to one instance in a cluster triggers the infrastructure to update the other instances in the cluster with the new information.

Component Instance

Component instances include a single Oracle HTTP Server process or multiple Oracle9iAS Containers for J2EE (OC4J) instances.

Oracle9iAS Instance

An Oracle9iAS Instance (also called an application server instance) is the set of processes required to run the configured components within an application server installation. There can be only one application server instance per application server installation. The terms installation and instance are sometimes used interchangeably, however, it is important to remember that an installation is the set of files installed into an Oracle home and an instance is a set of processes associated with those files.

Oracle9iAS Cluster

A cluster is a collection of application server instances with identical configuration and application deployment. Clusters enforce homogeneity between member instances so that a cluster of application server instances can appear and function as a single instance. With appropriate front-end load balancing, any instance in an application server cluster can serve client requests. This simplifies configuration and deployment across multiple instances and enables fault tolerance among clustered instances.

Oracle9iAS Farm

A collection of clusters and instances that share the same Oracle9iAS Infrastructure.

Scalability

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.

Figure 2-7 Oracle9iAS Cluster

Text description of 9iasclus.gif follows.

Text description of the illustration 9iasclus.gif

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.

Availability

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 Application Server Instance Failure in a Cluster

Text description of clu_fail.gif follows.

Text description of the illustration clu_fail.gif

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.

Manageability

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.

Figure 2-9 Oracle Enterprise Manager Manages a Cluster

Text description of clu_oem.gif follows.

Text description of the illustration clu_oem.gif

Architecture

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).

Figure 2-10 Oracle9iAS Cluster Architecture

Text description of dcma.gif follows.

Text description of the illustration dcma.gif

Front-End Load Balancer

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

Metadata Repository in the Infrastructure

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.

Farm

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.

Cluster

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.


Application Server Instance

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:

Once grouped in the same cluster, these application server instances have the following properties:

Management Features

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)

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:

Oracle Process Management and Notification (OPMN)

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:

High Availability

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.

Benefits of High Availability

Oracle9i Application Server keeps your system available by providing the following benefits:

Architecture

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.

Figure 2-11 High Availability Architecture

Text description of opmn.gif follows.

Text description of the illustration opmn.gif

The mod_oc4j Module

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.

See Also:

Oracle HTTP Server Administration Guide
Oracle9i Application Server Administrator's Guide


Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index