Release 2 (9.0.2)
Part Number A95109-01
 Home |
 Contents |
 Index |
| Oracle9i Application Server Migrating From WebLogic Release 2 (9.0.2) Part Number A95109-01 |
|
Although WebLogic Server 6.0 and Oracle9iAS are both J2EE servers that support J2EE 1.2 and some J2EE 1.3 features, both application servers have intrinsic differences ranging from product packaging to runtime architecture. This chapter seeks to discuss these differences and is organized as follows:
WebLogic Server 6.0 is sold in several configurations. This section outlines these configurations and Oracle9iAS Release 2.
WebLogic Server 6.0 is available in three configurations: WebLogic Server, WebLogic Enterprise, and WebLogic Express.
WebLogic Server provides the core services and infrastructure for J2EE applications. It supports J2EE 1.2 with additional support for some J2EE 1.3 features. These J2EE 1.3 features include JSP 1.2, Servlets 2.3, EJB 2.0, and JCA 1.0. However, these are implemented from non-final J2EE 1.3 specifications. Hence, compatibility problems will surface if a J2EE 1.3 compliant application is deployed on WebLogic Server 6.0.
WebLogic Server allows Java applications and components to be deployed as web services through SOAP, UDDI, and WSDL. It does not, however, support CORBA applications. CORBA support is available in WebLogic Enterprise (see next section).
Each WebLogic Server can be configured as a web server utilizing its own HTTP listener, which supports HTTP 1.1. Alternatively, Apache, Microsoft IIS, and Netscape web servers can also be used. This web server configuration allows WebLogic Server to service requests for static HTML content in addition to dynamic content generated by servlets or JSPs.
A WebLogic Server node can be deployed as an administration server. This node provides administrative services to other WebLogic Servers, called managed servers, in the WebLogic domain. A WebLogic domain is a set of WebLogic Servers and clusters of WebLogic Servers managed by an administration server, inclusive of the latter. The administration server provides a web-based GUI for management of the entire domain. In each domain, WebLogic Servers can be clusted together or are standalone. Refer to "Oracle9iAS Support for Clustering and Load Balancing" for more clustering information.
|
Note: For a list of J2EE 1.2 APIs supported by WebLogic Server, refer to "J2EE Support Comparison" in this chapter. |
WebLogic Enterprise consists of WebLogic Server and BEA Tuxedo. Tuxedo is a distributed transaction management platform that enables distributed transactions across multiple databases. Tuxedo integrates with WebLogic Server through the latter's connector architecture.
WebLogic Enterprise supports multiple application environments including Java, C++, C, and COBOL. WebLogic Enterprise also supports CORBA applications and allows single sign-on to disparate application environments. Additionally, through Tuxedo, WebLogic Enterprise supports industry standard SNMP MIBS allowing WebLogic Server to be monitored by third-party tools.
WebLogic Express is a "lightweight"version of WebLogic Server. It is not J2EE compliant as it does not have support for EJBs and JMS. It does support JSPs, servlets, JDBC, and RMI, and it also includes a web server. Hence, WebLogic Express can be used to build rudimentary web applications with simple database access using JDBC (no support for two-phase transactions).
Like WebLogic Server, Oracle9iAS is a platform-independent J2EE application server that can host multi-tier, web-enabled enterprise applications for the Internet and intranets, and which is accessible from browser and standalone clients. It includes Oracle9iAS Containers for J2EE (OC4J) a lightweight, scalable J2EE container written in Java, and is J2EE 1.2 certified. In addition, OC4J provides support for J2EE 1.3 features such as:
Oracle9iAS is designed specifically for running large-scale, distributed Java enterprise applications, including Internet commerce sites, enterprise portals and high volume transactional applications. It adds considerable value beyond the J2EE standards in areas critical to the implementation of real world applications, providing an entire suite of integrated solutions that encompass:
To enable these solutions to be implemented in a reliable and scalable infrastructure, Oracle9iAS can be deployed in a redundant architecture using clustering mechanisms. The sections "Architecture Comparison" and "Oracle9iAS Support for Clustering and Load Balancing" in this chapter details the components in and characteristics of Oracle9iAS.
This section describes and compares the overall architectures of WebLogic Server and Oracle9iAS.
WebLogic Server has several components and concepts peculiar to it. Each WebLogic Server can be configured and deployed either as a Managed Server or an Administration Server. A Managed Server hosts and executes the application logic deployed in it when requests are received from clients. An Administration Server configures and monitors Managed Servers. Figure 2-1 depicts the components in WebLogic Server and their interactions.
In any node, more than one Managed Server can exist. Each Managed Server is a Java process (JVM) executing J2EE containers (Web and EJB). An Administration Server, which is also a Java process, is required to propagate configuration information to Managed Servers when they start-up. The configuration information is stored in the filesystem on the Administration Server node.
The Administration Server is also used to monitor and log information about individual Managed Servers and the entire WebLogic domain. A WebLogic domain can consist of standalone Managed Servers, clusters of Managed Servers, and one Administration Server. If the Administration Server goes offline, client requests can still be serviced by the Managed Servers. However, configuration information is not available for new Managed Servers to start-up, and monitoring services are not available for server clusters. The Administration Server does not have automatic failover or replication. Configuration data for the WebLogic domain has to be manually backed. The Administration Server functions can be accessed through a console GUI (remotely over HTTP) or a command line utility.
In order for the Administration Server to start Managed Servers remotely, a Node Manager must be running on each node where there are Managed Servers. This Node Manager is a Java program executing in the background as a Unix daemon or Windows NT service. With the Node Manager, the Administration Server can also kill a Managed Server if the latter hangs or does not respond to commands from the former.
WebLogic Server 6.0 can also be set up to run as a web server. In this mode, it supports HTTP 1.1 and resolves client requests to Managed Servers based on the settings in the XML configuration files. Instead of WebLogic Server 6.0, third-party proxy plug-ins can also be used. Supported plug-ins are Apache, Netscape, and Microsoft IIS.
This section describes components and several concepts peculiar to Oracle9iAS. The discussion here provides an overview scope. For more detailed information, refer to the Oracle9i Application Server Concepts Guide, Oracle9i Application Server Administrator's Guide, and Oracle9iAS Containers for J2EE User's Guide.
An Oracle9iAS instance is a runtime occurrence of an installation of Oracle9iAS. An Oracle9iAS installation corresponds to an "Oracle home" where the Oracle9iAS files are installed. Each Oracle9iAS installation can provide only one Oracle9iAS instance at runtime. A physical node can have multiple "Oracle homes", and hence, more than one Oracle9iAS installation and Oracle9iAS instance.
Each Oracle9iAS instance consists of several interoperating components that enable Oracle9iAS to service user requests in a reliable and scalable manner. These components are Oracle HTTP Server, OC4J instances, Oracle Process Management Notification (OPMN) service, and Distributed Configuration Manager (DCM).
Oracle9iAS contains two listeners: The Oracle HTTP Server (based on the Apache open source product) and the listener that is part of OC4J, which runs in a separate thread of execution. Each Oracle9iAS instance has one Oracle HTTP Server.
The OC4J listener listens to requests coming from the mod_oc4j module of the Oracle HTTP Server and forwards them to the appropriate OC4J instance. From a functional viewpoint, the Oracle HTTP Server acts as a proxy server to OC4J, wherein all servlet or JSP requests are redirected to OC4J instances.
mod_oc4j communicates with the OC4J listener using the Apache JServ Protocol version 1.3 (AJP 1.3). This protocol load balances JSP and servlet requests between OC4J instances. mod_oc4j works with the Oracle HTTP Server as an Apache module. The OC4J listener can also accept HTTP and RMI requests, in addition to AJP 1.3 requests.
The following diagram depicts the Oracle HTTP Server and other Oracle9iAS runtime components in a single instance of Oracle9iAS.
An OC4J instance is a logical instantiation of the OC4J implementation in Oracle9iAS. This implementation is Java 2 Enterprise Edition (J2EE) complete and written entirely in Java. It executes on the standard Java Development Kit (JDK) 1.3.1 Java Virtual Machine. It has a lower disk and memory footprint than the previous Oracle9iAS Java environment and competitive Java application servers. Note that each OC4J instance can consist of more than one JVM process where each process can be executing multiple J2EE containers. The number of JVM processes can be specified for each OC4J instance using the Oracle Enterprise Manager GUI.
Oracle9iAS allows several OC4J instances to be clustered together for scalability and high-availibility purposes. When OC4J instances are clustered together, they have the same configuration and applications deployed amongst them. A more in-depth discussion on clustering is found in the section "Oracle9iAS Support for Clustering and Load Balancing" below.
Each Oracle9iAS instance has an OPMN service which performs monitoring and process management functions within that instance. This service communicates messages between the components in an Oracle9iAS instance to enable startup, death-detection and recovery of components. This communication extends to other OPMN services in other Oracle9iAS instances belonging to the same cluster as well, thereby allowing other instances in a cluster to be aware of active OC4J and Oracle HTTP server processes in other Oracle9iAS instances (in the same cluster).
The OPMN service also communicates and interfaces with Oracle Enterprise Manager to provide a consolidated interface for monitoring, configurating, and managing Oracle9iAS. Oracle9iAS components, Oracle HTTP Server, OC4J instances, and Distributed Configuration Manager (described below), use a subscribe-publish messaging mechanism to communicate with the OPMN service. For failover and availibility, the process that implements the OPMN service has a shadow process that restarts the OPMN process if it fails.
In order to manage and track configuration changes in the various components in each Oracle9iAS instance, a DCM process exists in each Oracle9iAS instance to perform those tasks. Each configuration change made to any of the components in a Oracle9iAS instance is communicated to the DCM. DCM in turn takes note of the change and records it in the Oracle9iAS metadata repository in the infrastructure database. This repository contains the configuration information for all the Oracle9iAS instances connected to it through their respective DCMs. All Oracle9iAS instances connecting to the same infrastructure repository in this way belong to the same Oracle9iAS farm. If any of the Oracle9iAS instances fail, the configuration information can be retrieved from the repository for purposes of restarting the instance.
Each DCM also communicates with the OPMN in their respective instances to send notification events on changes in repository data. This allows OPMN to make the corresponding adjustments to the Oracle9iAS components.
The Oracle9iAS infrastructure repository maintains metadata about the Oracle9iAS clusters and standalone Oracle9iAS instances connected to it. A common and shared infrastructure repository ensures a more robust way of maintaining configuration information and consistency between the clusters and instances. Whenever a new instance is added to a cluster, common configuration information such as the applications deployed is retrieved from the infrastructure repository and propagated to the new instance so that it will behave uniformly with the other instances of the cluster. The infrastructure repository is discussed further in the section "Oracle9iAS Clusters" below.
Oracle9iAS provides a caching solution with the unique capability to cache both static and dynamically generated web content. The Oracle9iAS Web Cache significantly improves the performance and scalability of heavily loaded Oracle9iAS web sites by reducing the number of round trips to the web server. In addition, it provides a number of features to ensure consistent and predictable responses. These features include page fragment caching, dynamic content assembly, web server load balancing, Web Cache clustering, and failover. Oracle9iAS Web Cache can be used as a load balancer for Oracle9iAS instances in a cluster. Web Cache can itself be deployed in its own cluster. Refer to the Oracle9iAS Database Cache Concepts and Administration Guide.
This section defines and describes clustering and load balancing and their importance to application server operation. It compares the methods for clustering and load balancing used in WebLogic Server 6.0 and Oracle9iAS.
An application server cluster is a group of independent application server instances managed as a single system for higher availability and increased scalability. The main goal of clustering is to minimize response time to user requests and to provide scalability (the ability to add nodes to an existing system with minimal system disruption). Clustering improves manageability, since the system administrator can remotely manage the cluster from a central location. The cluster appears to the administrator as a single system.
Within a cluster of multiple application server instances, a failed application server instance can rely on another instance to take over its workload. Two important characteristics of failover are quick failure detection, and failover without loss of data. The level of failover support varies among application servers. Oracle9iAS provides support for both.
Load balancing is the proportional distribution of client requests (the application server workload) among the servers in the cluster, enabling the maximum number of concurrent requests. The primary goals of load balancing are to optimize usage of available server capacity and provide the most rapid possible response time to clients.
One or more WebLogic Servers can be grouped together as a cluster. Applications can be deployed commonly in all servers in a cluster, through cluster-wide deployment, to allow client requests to be load balanced across the cluster and the applications to have failover capabilities. In a WebLogic cluster, the entities that benefit from clustering are HTTP session states, and EJB and RMI objects. Several load balancing algorithms are used by WebLogic. These are round-robin, weight-based, and parameter-based.
Clients making requests to a WebLogic cluster can have their requests load balanced across the servers in the cluster. For this to work, a web server installed with the WebLogic proxy plug-in or a hardware load balancer must be used. The WebLogic proxy plug-in uses a round-robin load balancing mechanism to distribute the request load. If a hardware load balancer is used, the cluster can be load balanced using the hardware's mechanism.
WebLogic Server achieves failover for servlets and JSPs by replicating the HTTP session states of clients. When a WebLogic Server receives the very first request for a servlet or JSP, it replicates the servlet's session state to another server. The replicated session state is always kept up-to-date with the original. The WebLogic proxy plug-in returns the names of the two servers to the client through a cookie or by rewriting the URL. If the server hosting the original session state fails, the WebLogic proxy plug-in uses the information in the cookie or URL to redirect the client to the server with the replicated session state. At any one time, the cluster maintains an original and replica of each active session state. In this scenario, the session state is replicated in memory. WebLogic Server also supports replication to the file system or a database through JDBC, however, the failover is not automatic for these replication methods.
WebLogic Server provides load balancing and failover for EJB and RMI objects by using a JNDI service and client stubs which are both cluster-aware.
Each WebLogic Server in a cluster maintains a local JNDI tree. This tree contains information on objects deployed on the local server and around the cluster (for objects that are clusterable). If a clusterable object is deployed on more than one server, each JNDI tree reflects the existence of that object on those servers. When a clusterable object is deployed on a server, that server, through multicast, notifies the other servers in the cluster of the new deployment. The other servers' update their JNDI trees accordingly. Note that the server with the deployed object also sends the object's stub to the other servers.
When a client looks up a clusterable object in the JNDI service, the server servicing the request returns a stub of the object to the client. This stub contains information about which server(s) the object is actually deployed in. The stub also has load balancing logic to balance method calls to the object. The load balancing algorithms available are round-robin, weight-based, random, and parameter-based. From the client's point-of-view, the cluster is transparent. The JNDI look ups and load balancing are done without the client knowing that it is working with a clustered object at the server end.
In the case where a clustered object is stateful, for example, a stateful session EJB, the object's state is replicated to a second server. The replication is achieved in a similar manner as for HTTP session state. The server that is chosen to service a client's very first request replicates the object's state to another server. The client stub is updated to reflect this. If the first server fails, the stub receives an exception when it tries to invoke a method. The stub then redirects the invocation to the server with the replicated object state. This server instantiates the object with the replicated state and executes the method invocation. The server also selects another server to replicate the state to since the original server is down. Failover of stateful objects is achieved this way.
Failover of stateless objects is more straightforward to achieve as state need not be replicated. Upon receiving an exception indicating that a server has failed, the client stub simply selects another server which is hosting another instance of the called object and redirects the method invocation there.
Oracle9iAS is designed with sophisticated clustering mechanisms. These mechanisms ensure that failover and scalibility are achieved at the infrastructure and application levels. This section describes the clustering and load balancing concepts and capabilities of Oracle9iAS and OC4J.
An Oracle9iAS cluster is made up of one or more Oracle9iAS instances (see Figure 2-3). All Oracle9iAS instances in the cluster have the same configuration. The first Oracle9iAS instance to join a cluster has its configuration replicated to the second and later instances when they join. In addition to the configuration, deployed OC4J applications are also replicated to the newer instances. Information for the replicated configuration and applications is retrieved from the Oracle9iAS infrastructure repository used by the cluster.
Within each cluster, there is no mechanism to load balance or failover the Oracle9iAS instances. That is, there is no internal mechanism in the cluster to load balance or failover requests to the Oracle HTTP Server component in the instances. A separate load balancer such as Oracle9iAS Web Cache or hardware load balancing product can be used to load balance the Oracle9iAS cluster and failover the Oracle HTTP Server instances in the cluster.
Several Oracle9iAS clusters and standalone Oracle9iAS instances can be further grouped into an Oracle9iAS farm. The clusters and instances in this farm share the same Oracle9iAS infrastructure repository. For further information on Oracle9iAS farms, refer to the Oracle9i Application Server Administrator's Guide.
An important function of clustering technology in Oracle9iAS is that of reducing multicast traffic. With every server sharing its session state with every other server in the cluster, a lot of CPU cycles is consumed as overhead to replicate the session state across all nodes in the cluster. Oracle9iAS solves this problem by introducing the concept of OC4J islands, where OC4J processes (JVMs) in an Oracle9iAS cluster can be sub-grouped into islands. Session state of applications is replicated only to OC4J processes belonging to the same island rather than all OC4J processes in the Oracle9iAS cluster. Hence, state is replicated to a smaller number of processes. OC4J islands are typically configured to span across physical nodes, thereby allowing failover of application state if a node goes down.
Consider an Oracle9iAS cluster with four OC4J processes running in two nodes, two processes per node (see Figure 2-4). When the state of an application changes, which could occur at every request from the same client, multicast messages are sent between all four processes to update the state of that application in each process. If these four processes were to be divided into two islands of two processes across two nodes, state replication of the application would only have to occur between processess within the same island. Multicast messages would be required only between the two processes in the island instead of four, reducing replication overhead by half. As a result, network traffic and CPU cycles are reduced.
When configuring OC4J islands (using OEM), you can specify the number of OC4J processes for each node that belong to each island. By doing so, you can increase or decrease the number of processes based on the capabilities of the hardware and operating system of each node. For instructions on how to configure Oracle9iAS clusters and OC4J islands, refer to Oracle9i Application Server Administrator's Guide.
This section outlines the differences in the level of support of J2EE specifications between WebLogic Server 6.0 and Oracle9iAS.
Oracle9iAS OC4J is fully certified with J2EE 1.2.1, having passed Sun Microsystems' Certification Test Suite (CTS). The CTS includes over 5,000 tests designed to assess application portability and the overall quality of a J2EE implementation.
WebLogic Server 6.0 supports J2EE 1.2. It also has some early J2EE 1.3 features which were implemented before the J2EE 1.3 specifications were finalized.
Table 2-1 lists the J2EE technologies and the level of support provided by Oracle9iAS and WebLogic Server 6.0:
In addition to supporting these standards, Oracle9iAS provides a well-thought-out, integrated architecture for building real world J2EE applications, including implementation of standard deployment archives: JAR files for EJBs, Web Archives (WARs) for servlets and JSPs, and Enterprise Archives (EARs) for applications. This ensures smooth server interoperability.
This section compares the Java tools included with WebLogic Server and Oracle9iAS.
The WebLogic Server development environment, tools, and Administration Console are described below.
WebLogic has partnered with WebGain to provide a suite of tools. WebLogic itself does not provide the tools as an integrated package with its WebLogic Server. The tools available from WebGain are:
The WebLogic Server administrative console provides a GUI for managing the WebLogic Server domain. A WebLogic Server domain consists of one or more WebLogic Server instances (where each instance runs one or more applications) or clusters of instances. The administrative console connects to the designated administrative server running in the domain and can be used to change the configuration or run-time state on any machine in a domain. The administrative console is used to define clusters, add servers, deploy applications, configure applications, and manage web servers, services, and resources in the domain.
This section describes development and deployment tools for creating J2EE applications. The tools are part of the Oracle9i Developer Suite.
Application developers can use the tools in Oracle JDeveloper to build J2EE- compliant applications for deployment on OC4J. JDeveloper is a component in Oracle Interent Developer Suite, a full-featured, integrated development environment for creating multi-tier Java applications. It enables you to develop, debug, and deploy Java client applications, dynamic HTML applications, web and application server components and database stored procedures based on industry-standard models. For creating multi-tier Java applications, JDeveloper has the following features:
.ear files, .war files, ejb-jar.xml file, and deployment descriptors.
You can build applications with Oracle JDeveloper and deploy them manually, using Oracle Enterprise Manager, or with the OC4J Administration Console. Also note that you are not restricted to using JDeveloper to build applications; you can deploy applications built with IBM VisualAge or Borland JBuilder on OC4J.
Oracle9iAS provides a number of assembly tools to configure and package J2EE Applications. The output from these tools is compliant with J2EE standards and is not specific to OC4J. These include:
Oracle9iAS also provides two different administration facilities to configure, monitor, and administer OC4J.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|