Release 9.0.2
Part Number A95110-01
 Home |
 Contents |
 Index |
| Oracle9iAS Migrating From WebSphere Release 9.0.2 Part Number A95110-01 |
|
WebSphere and Oracle9iAS are created from entirely different architectures. Websphere is based on the IBM SanFrancisco Java application framework and its Component Broker, both of which predate J2EE standards. Oracle9iAS has a new lightweight, robust J2EE container that supports the latest J2EE 1.2 standard.
This chapter identifies major differences between Websphere and Oracle9iAS in terms of overall product offering, architecture, clustering and load balancing, J2EE support, and development and deployment tools.
This section describes WebSphere and Oracle9iAS application server products.
IBM sells a several technologies under the WebSphere marketing umbrella. The WebSphere Application Server is the core of the WebSphere extended family of products, of which there are three versions, described below.
Websphere Standard Edition is a Servlet/JSP container layer that runs on top of an HTTP server. It works with a number of popular HTTP servers, including IBM HTTP Server, Microsoft IIS, and Netscape iPlanet server. WebSphere Standard Edition supports static HTML pages, servlets, JavaServer Pages, and XML .
WebSphere Advanced Edition contains all the features of Standard Edition, and also includes:
WebSphere Advanced Edition is IBM's core J2EE server.
WebSphere Enterprise Edition includes all of the features in Advanced Edition, and also includes:
In WebSphere Enterprise Edition, the Component Broker serves both EJBs and CORBA objects. TXSeries provides a a pure transactional environment, for applications that don't require an EJB/component-based/object-oriented programming model. Depending on your requirements, you could use either or both.
Like WebSphere, 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 WebSphere and Oracle9iAS.
The WebSphere Advanced Edition 3.5.3 consists of the following components:
IBM's HTTP Server is the Apache HTTP Server (with official product support) with SSL capability implemented by IBM, and IBM tools for managing keys, certificates, and such. The public key technology that SSL uses is patented and requires tracking for licensing purposes. The SSL support is part of IBM's value-add on top of the Apache HTTP Server open source distribution. Neither Apache nor the IBM HTTP Server provide servlet support out-of-the-box.
The Web Server Plug-in is a module that runs within the web server, using its native APIs, and forwards requests to the WebSphere Application Server. When you install Websphere, the installation program installs a hook into the web server that intercepts HTTP requests that target a servlet (it examines the incoming URL to determine whether it is a servlet request), and redirects those requests to the servlet engine for processing. Static content is still handled solely by the HTTP Server.
The Adminsitrative Server must be running on every node that is running a WebSphere Application Server component. It performs the following functions:
The WebSphere Application Server version 3.5.x requires an Administrative Server Repository. The Administrative Server Repository is a relational database containing configuration information. This database is used to store setup, configuration, and state information about the WebSphere Application Server.
Before starting the Administrative Server, WebSphere Application Server checks for the existence of an Administrative Server Repository, which contains descriptive information about the resources that are configured to run on each node in the domain, for example, the names of application servers, the node each server is running on, the enterprise beans installed in each server, and the current state of each server.
The Administrative Server Repository enables the system administrator to manage the domain from any machine, because all configuration information is stored in a central location. Each Administrative Server has a central view of resource configuration information about in the domain. When the administrator modifies a resource configuration, the changes are seen by all administrative servers.
In WebSphere, an Application Server is the process that runs servlet and/or EJB-based applications, providing both the servlet run-time components (Servlet Engine, Web applications) and EJB run-time (EJB container). Like the Administrative Server, each WebSphere Application Server runs in its own Java Virtual Machine (JVM).
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 WebSphere 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.
WebSphere provides clustering and load balancing support through its Administrative Console, with cloning and workload management services.
Clustering is implemented in WebSphere with a mechanism called cloning, available in the Administration system. Cloning enables you to create multiple copies of an application server, based on a server that you have already configured.
The clone has the same structure and attributes as the application server on which it is based, but it is not associated with any node, and does not correspond to any real server process running on any node.
WebSphere Application Server supports cloning for servlet engines, Web applications, and servlets for workload management, load balancing, and failover. The servlets, EJBs, and Web resources are shared by the clones, but each clone uses its own JVM to run the application code. This provides identical, yet independent processes for the application to run in.
The workload management service improves the scalability of the application server environment by grouping multiple application servers into application server groups. Clients then access these application server groups as if they were a single server, and the workload management service distributes the workload among the application servers in the application server groups. An application server can belong to only one application server group. Websphere workload management supports load balancing for stateless servlets and stateless session beans, and provides a failover mechanism for stateful servlets and stateful session beans.
Servlet load balancing is performed by a servlet redirector. The servlet redirector runs on the Web server in front of the application servers. The redirector balances workload across the servlet engines running in multiple application servers behind the Web server. When a web server HTTP session asks to invoke a servlet, the redirector transfers the request to a servlet engine.
The EJB component workload manager balances the load between Java objects (servlets to EJB components, EJB components to EJB components and stand-alone Java clients to EJB components). For example, when a servlet needs data or begins a transaction through an EJB component, the EJB component workload manager transfers the request to an EJB container (an instance of WebSphere Application Server) or a remote EJB handler.
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 WebSphere and Oracle9iAS.
WebSphere 3.5.3 is a J2EE server, but is not fully J2EE 1.2 compliant. It supports the following J2EE API specifications:
WebSphere is not fully J2EE compliant, since it provides custom extensions to J2EE standards and includes non-standard packages for supporting J2EE features, such as servlet filtering and chaining, security, connection pooling and data access beans, and deployment dersciptors. An application using these extensions and packages requires code-level changes in order to migrate to Oracle9iAS or any other J2EE-compliant application server.
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.
Table 2-1 lists the J2EE technologies and the level of support provided by Oracle9iAS and WebSphere:
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 WebSphere and Oracle9iAS.
The WebSphere development environment, tools, and system administration console are described below.
VisualAge for Java is is IBM's integrated development environment (IDE) for building J2EE applications. VisualAge for Java offers remote debugging support for JSP pages and other server-side Java logic. A new Servlet SmartGuide generates servlets, JSP components, and HTML prototypes, so that developers can quickly test their code inside the IDE before deploying to a production server. Integration with IBM WebSphere Studio allows for quick addition of content to prototypes, increasing productivity for programmers and web developers. VisualAge also comes with Persistence Builder, a standalone object-relational mapper tool .
The WebSphere Studio provides a tool set for creating, managing and debugging multiplatform Web applications. It includes the following functionality:
The WebSphere Administrative Console provides a GUI for managing the WebSphere domain. A WebSphere domain consists of one or more WebSphere instances (where each instance runs one or more applications). The Administrative Console connects to one of the Administrative servers running in the domain and can be used change to the configuration or run-time state on any machine in a domain. The Administrative Console is used to manage the administrative repository, deploy applications and configure applications.
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 Internet 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 file, and deployment descriptors.
You can build applications with Oracle JDeveloper and deploy them manually, using Oracle Enterprise Manager. 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. |
|