Oracle® Application Server Upgrade and Compatibility Guide 10g Release 3 (10.1.3.1.0) B31015-01 |
|
![]() Previous |
![]() Next |
Use this appendix to learn about the key differences between Oracle Application Server 10g Release 3 (10.1.3.1.0) and the following Oracle Application Server 10g releases:
Oracle Application Server 10g (9.0.4)
Oracle Application Server 10g Release 2 (10.1.2)
Note: For information about the differences between 10g Release 3 (10.1.3.1.0) and 10g Release 3 (10.1.3.0.0), refer to:
|
This chapter contains the following sections:
Using the admin_client.jar Utility to Manage OC4J Instances, Groups, and Clusters
Summary of Equivalent Features in 10g Release 3 (10.1.3.1.0)
With previous releases of Oracle Application Server, you can configure a set of Oracle Application Server instances so they use a common OracleAS Metadata Repository. The instances that share the common OracleAS Metadata Repository are members of the same OracleAS Farm. From the Farm page in the 10g (9.0.4) or 10g Release 2 (10.1.2) Application Server Control Console, you can view all the application servers that are members of the OracleAS Farm. The Distributed Configuration Management (DCM) software provides the underlying technology for managing the farm.
Oracle Application Server 10g Release 3 (10.1.3.1.0) does not include an OracleAS Metadata Repository or the DCM software. As a result, there is no concept of an OracleAS Farm. Instead, in 10g Release 3 (10.1.3.1.0), you configure your application server instances so they can communicate via Oracle Process Manager and Notification Server (OPMN).
When you configure two or more 10g Release 3 (10.1.3.1.0) instances in this manner, the instances can be managed from the Cluster Topology page in the 10g Release 3 (10.1.3.1.0) Application Server Control Console.
Figure B-1 shows the 10g Release 3 (10.1.3.1.0) Cluster Topology page, which includes two Oracle Application Server instances that have been configured to communicate via the same multicast address and port.
See Also: "Configuring and Managing Clusters" in the Oracle Containers for J2EE Configuration and Administration Guide"Configuring the Cluster Topology" in the in the Application Server Control online help |
Figure B-1 Oracle Application Server 10g Release 3 (10.1.3.1.0) Cluster Topology Page
With previous releases of Oracle Application Server, you can create and manage OracleAS Clusters. OracleAS Clusters consist of identically configured J2EE and Web Cache installations that are part of the same OracleAS Farm. Distributed Configuration Management (DCM) is then used to keep the instances within the cluster in synch. Configuration changes made to one instance in the cluster are automatically applied to other instances in the cluster.
In 10g Release 3 (10.1.3.1.0), there is no OracleAS Farm and there is no DCM. However, you can still group multiple Oracle Containers for J2EE (OC4J) instances that are part of the same cluster topology. These groups of OC4J instances can be used in a similar manner to OracleAS Clusters.
Refer to the following sections for more information:
Like OracleAS Clusters, groups make it easy to deploy your applications to more than one OC4J instance at a time:
With OracleAS Clusters, changes made to one instance in a cluster are automatically propogated to other instances in the cluster. For example, if you deploy an application to one instance in the cluster, the application is automatically deployed to the other instances.
With groups, you deploy your J2EE applications to all the OC4J instances in the group using the Group page (Figure B-2). The Group page is available from the Cluster Topology page.
Figure B-2 Oracle Application Server 10g Release 3 (10.1.3.1.0) Group Page
Like OracleAS Clusters, groups allow you to make specific configuration changes to all the OC4J instances in the group. For example, you can use the Group Administration page (Figure B-3) to set server properties, configure JDBC data sources, configure the Enterprise Messaging Service, and to access the cluster MBean browser.
Figure B-3 Oracle Application Server 10g Release 3 (10.1.3.1.0) Group Administration Page
The following sections describe some key differences between 10g Release 3 (10.1.3.1.0) groups and OracleAS Clusters:
Unlike OracleAS Clusters, configuration changes made to an individual OC4J instance in a group (from the OC4J instance Home page or from the command line) are not automatically applied to other OC4J instances in the cluster.
Instead, if you want to make a configuration change to all the OC4J instances in a group, you must either make the change from the Group page, or you must use the Application Server Control Console or command line tools to make the change to each OC4J instance in the cluster.
Similarly, if you add a new OC4J instance to the group, configuration changes are not automatically applied to the new instance. Instead, you must use the OC4J home page for that instance, or the command-line tools, to apply any required configuration changes to the new instance.
See Also: "Replicating Changes Across a Cluster" in the Oracle Containers for J2EE Configuration and Administration Guide |
In some ways, groups provide more flexibility than OracleAS Clusters. For example, when you add an OC4J instance to an cluster in 10g (9.0.4) or 10g Release 2 (10.1.2), the instance can be used for cluster operations only. Any changes you make to the instance are automatically applied to the other instances in the cluster.
In 10g Release 3 (10.1.3.1.0), you have the flexibility to deploy an application to just one OC4J instance in the group, or to adjust the attributes of one instance without impacting the other instances in the group.
Note, however, that if you make changes to one member of the group and not to another, some operations performed on the group could succeed on one instance and fail on another.
Also, unlike OracleAS Clusters, actions you perform on a group do not affect OC4J instances within the group that are not up and running when the operation is performed.
In addition to clusters and groups, Oracle Application Server 10g Release 3 (10.1.3.1.0) introduces the concept of application clustering, which provides state replication and load balancing for applications within your cluster topology.
The following sections provide more information:
Application Clustering provides a simpler, more efficient method of replicating application state, which replaces the following concepts and features that are no longer supported in 10g Release 3 (10.1.3.0.0) and 10g Release 3 (10.1.3.1.0):
In previous releases, an island was essentially a group of OC4J instances within a cluster across which HTTP session data was replicated. Although islands reduced overhead by not replicating data across the entire cluster, they increased configuration and management overhead. In addition, islands were only applicable to Web applications; EJB applications could not utilize the island configuration.
In 10g Release 3 (10.1.3.1.0), you replicate HTTP session data using Application Clustering, which can be configured using the Application Server Control Console during or after the deployment of your application.
The loadbalancer.jar
file, which provided load balancing functionality in previous OC4J releases, was deprecated in the previous release of OC4J and has been removed from the current release.
Deprecated Clustering-Specific XML Elements
The following XML elements are deprecated in OC4J 10g (10.1.3) and should no longer be used to configure clustering. The new <cluster>
element is now used for all cluster management:
Within a 10g Release 3 (10.1.3.1.0) cluster, you can configure clustering for selected applications that are deployed across the cluster. Application clustering offers the following features:
You can configure clustering for specific applications, or globally by configuring clustering for the default
application in an OC4J instance.
Other applications deployed to the instance automatically inherit the clustering characteristics of the default
application.
You can configure clustering for an application at deployment time, or later, after you deploy the application.
You can select from the following replication methods:
Peer-to-peer replication
Multicast replication
Database replication
See Also: "Application Clustering in OC4J" in the Oracle Containers for J2EE Configuration and Administration Guide for more detailed information about the supported replication methods |
OC4J 10g Release 3 (10.1.3.1.0) also provides a command-line utility— admin_client.jar
—that can be used to perform operations on active OC4J instances.
For many functions, the admin_client.jar
utility replaces the admin.jar
utility, which is used exclusively for the standalone configuration of the 10g Release 3 (10.1.3.1.0) OC4J server.
Unlike the admin.jar
utility, you can use the admin_client.jar
utility to manage OC4J instances in a managed, Oracle Application Server environment, as well as OC4J instances in a standalone OC4J environment.
You can perform the following tasks with the admin_client.jar
utility:
Deploy applications to a specific OC4J instance or to all instances within a cluster
Undeploy an application
Incrementally update a deployed EJB module with modified classes
Create a new shared library for a specific OC4J instance or for all instances within a cluster
Create data sources and JMS queues and topics
Stop, start or restart a specific application, on a specific OC4J instance or cluster-wide
Manage the creation, deletion, and membership of OC4J groups
See Also: "Using the admin_client.jar Utility" in the Oracle Containers for J2EE Configuration and Administration Guide |
Table B-1 describes how some common Oracle Application Server management tasks were performed in Oracle Application Server 10g (9.0.4) and 10g Release 2 (10.1.2). It then shows how those same tasks are performed in 10g Release 3 (10.1.3.1.0).
See Also: Appendix D, "Differences Between 10g Release 3 (10.1.3.1.0) and 10g Release 3 (10.1.3.0.0)" |
Table B-1 Summary of Changed Features for 10g Release 3 (10.1.3.1.0)
Task or Feature | In Prior Releases... | In 10g Release 3 (10.1.3.1.0)... |
---|---|---|
Clustering Oracle Application Server instances |
Configure multiple Oracle Application Server instances so they use the same OracleAS Metadata Repository. This creates an OracleAS Farm, which can be viewed from the Application Server Control Console Farm page. |
Use the Topology Network Configuration page to configure the cluster, or perform the equivalent task during the installation. This causes the selected Oracle Application Server instances to appear on the Cluster Topology page of the Application Server Control Console. |
Performing management tasks simultaneously on multiple OC4J instances |
Add selected J2EE and Web Cache instances within an OracleAS Farm to an OracleAS Cluster. Perform this task from the Farm page in the Application Server Control Console. |
Create multiple OC4J instances and organzie them into a group. Use the Group page in the Application Server Control Console to manage the group and to perform administration tasks on all OC4J instances in the group. |
Replicating application state across a cluster |
OC4J processes and islands within OracleAS Clusters. |
Application clustering, which can be configured from the Application Server Control Console during deployment or post-deployment. |
Creating new OC4J instances |
Click Create Instance on the OC4J Home page in the Application Server Control Console. |
Click Create OC4J Instance on the Application Server page, or use the |
Using command-line tools to manage instances and clusters |
Use one of the following:
|
DCM is not available in 10g Release 3 (10.1.3.1.0), but new |
Using OracleAS Identity Management |
Configure OracleAS Identity Management using the Application Server Infrastructure page in the Application Server Control Console. |
Configure OracleAS Identity Management using the Identity Management task on the OC4J Administration page in the Application Server Control Console. |