|
| |
| Sun Java Enterprise System 5 Upgrade Guide for UNIX | |
Chapter 1
Planning for UpgradesThis chapter provides information used for planning the upgrade of Sun Java™ Enterprise System (Java ES) software to Java ES 5 in a Sun Solaris™ Operating System or Red Hat Enterprise Linux (referred to simply as Linux) operating system environment.
It contains the following sections:
Java ES 5 ComponentsAs an introduction to planning the upgrade of Java ES software, this section reviews the components included in Java ES 5 (Release 5). Depending on your upgrade scenario, you might need to upgrade one or more of these components to their Release 5 version.
Java ES components are grouped into different types, as described in the Java Enterprise System 5 Technical Overview, http://docs.sun.com/doc/819-2330:
Release 5 Product Components
Release 5 product components are listed alphabetically in the following table, along with abbreviations used in subsequent tables. For the service quality components among them, the table includes the type of service enhancement they provide.
Release 5 Shared Components
Release 5 shared components are listed alphabetically in the following table, along with abbreviations used in subsequent tables.
Java ES Upgrade TechnologiesNo single system utility upgrades all Java ES components. In addition, product components and shared component upgrades have different characteristics and upgrade technologies, as described in the sections below.
Product Component Upgrades
The upgrade of Java ES product components to Release 5 is performed component-by-component, computer-by-computer, using component-specific upgrade procedures documented in this Upgrade Guide.
The upgrade of product components can range from major functional upgrades, which might not be compatible with the previous version of the component, to bug-fix upgrades, which are fully compatible with the previous version. Because of the dependencies between Java ES components, the nature of one upgrade can impact whether other components need to be upgraded as well.
Java ES product component upgrades involve two basic operations that mirror the initial installation and configuration of Java ES product components:
- Installation of software upgrades. Upgraded software enhances or fixes existing software or replaces existing software. Software installation can be achieved through the application of patches to existing software packages, the selective replacement of existing packages, the installation of new packages, or a full re-installation of component software.
- Reconfiguration. Reconfiguration encompasses any change in configuration data, user data, or dynamic application data needed to support the upgraded software. A change in data can be additional data, a change in data format (whether in property files or database schema), or a migration of data to a new location. Sometimes reconfiguration requires that you perform a procedure and sometimes it takes place automatically. In some cases, reconfiguration also requires redeployment of component software to a web container.
In addition, Java ES product component upgrades normally involve pre-upgrade tasks and, in some cases, post-upgrade procedures before the upgrade is operational.
Product Component Upgrade Approaches
The component-specific upgrade procedures used to install upgraded software and perform component reconfiguration include the following upgrade approaches:
Using the Upgrade Capability of the Java ES Installer
The Release 5 installer includes an upgrade capability that performs product component upgrade in a few special cases: Application Server, Message Queue, HADB, and Java DB. When the Java ES installer detects the previously installed release versions of these product components, it marks these components as “upgradable.”
Before upgrading any of these components, the installer checks for current and previous versions of shared components. If the installer detects that a shared component required by the selected component is of a previous version or is missing, the installer upgrades all shared components currently installed and installs any missing shared components required by the selected component. In some cases (notably Application Server), the installer will also upgrade product components upon which the component being upgraded depends.
The installer removes the previous version packages, installs the Release 5 product component packages, and reconfigures, as needed, the product component being upgraded. (In the case of Application Server bundled with Solaris 9 operating system, however, the installer does not remove packages; see Release 2 Application Server Upgrade).
If you are using the Solaris 10 operating system zones feature, special considerations apply. See Zone Support in the Java ES Installer.
Performing a Fresh Install of the Product Component
Some product components are upgraded by performing a fresh install of the components using the Java ES installer. First you remove the previous version’s packages and then install Release 5 in the same path, or install Release 5 in a parallel path and leave the previous version intact.
In both cases you reconfigure the product components by migrating the previous version’s configuration data to the new installation, by performing a new configuration, or by doing a combination of both. For some product components, a utility is provided for reconfiguring or migrating configuration data for that component.
Running a Component-Specific Upgrade Utility
Some product components provide an upgrade utility or script for automating the upgrade of the component to Release 5. The utility generally performs both the upgrade of software packages and any reconfiguration required as part of the upgrade. For those components deployed to a web container, the utility generally redeploys the upgraded component software to the web container.
Patching Existing Component Packages
For some product components, upgrade is performed by manually patching existing software packages. While Solaris and Linux platforms employ similar technologies for managing installed software packages and tracking changes to those packages through a package registry, the differences in patching technologies between platforms impact upgrade procedures.
- Solaris platform. Packages are installed and removed through the Solaris pkgadd and pkgrm commands. Package contents, once installed, can be modified using patches that are applied or removed through the patchadd and patchrm commands. Patches to Solaris packages are distributed through the SunSolve web site at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
Solaris patches can patch one or more packages. The patchadd command saves a backup of the package being patched to facilitate the removal of the patch using the patchrm command. Patches are identified by a patch ID, which consists of a patch number followed by a revision number that is incremented as the patch is modified over time.
- Linux platform. Red Hat Enterprise Linux packages (RPMs) can be installed or updated through the rpm command. Package contents, once installed, however, cannot be modified using patches. Rather, RPM packages are updated using the rpm -U command option, which replaces the current package with a newer package.
As a convenience, many RPM package upgrades are distributed not only on the Java ES Release 5 distribution, but also through the SunSolve web site at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
For distribution through SunSolve, RPM packages are encapsulated as patches and assigned a patch ID and revision number similar to Solaris patches. These Linux patches can include one or more RPM packages, each identified by a unique RPM name, RPM number, and a revision number that is incremented as the RPM package is modified over time.
Upgrade Approach Used for Each Product Component
The upgrade approach used to upgrade each product component to Release 5 is shown in the following table:
Shared Component Upgrades
Java ES shared component upgrades are a necessary part of upgrading the product components that depend on them.
The upgrading of shared components does not require reconfiguration of the components, nor pre- or post-upgrade procedures. In addition, shared component upgrades cannot be rolled back to their previous versions.
The large number (around 30) of Java ES shared components and the complex interactions between shared components and product components requires that all shared components within a single operating system instance be synchronized to the same Java ES release version. An operating system instance means a single computer running the Solaris 9, Solaris 10, or Red Hat Enterprise Linux operating system, or any of the virtual operating system environments (zones) on a computer running the Solaris 10 operating system.
Because of the synchronization requirement, you should not upgrade Java ES shared components one by one, but need to upgrade shared components to their Release 5 versions at the same time.
The synchronization of shared components to Release 5 is achieved using the Java ES installer. The installer synchronizes shared components when performing an upgrade of product components (see Using the Upgrade Capability of the Java ES Installer) or when performing a fresh install of product components. The installer also includes a synchronization function that upgrades any existing shared components and installs any missing shared components. For a fuller description of this function, see Synchronize All Shared Components.
The Upgrade ProcessThe Java ES upgrade process involves a number of phases, which are normally carried out first in a staging environment, before being executed in a production environment. The use of a staging environment allows you to test each phase as well as write scripts to be used by IT personnel for upgrading complex Java ES deployments.
When you have tested the upgrade process in a staging environment, and have confidence that the upgrade is working properly, you can reproduce the process in your production environment.
The process involves the phases shown in the following table and documented in this Upgrade Guide. The phases apply to individual component upgrades as well as to your Java ES deployment as a whole.
Upgrade Plan ConsiderationsIn an upgrade plan you specify the Java ES components you will upgrade to Release 5 and the sequence by which you will upgrade those components on the different computers or operating system instances in your Java ES deployment.
Your plan will depend on your upgrade objectives and priorities, as well as the scope and complexity of your deployment architecture.
For example, your Java ES deployment architecture might consist of a single Java ES component running on a single computer, and your upgrade objective is to fix some bug in the previous software release. On the other hand, your Java ES deployment architecture might consist of a number of interdependent Java ES components deployed across a number of different computers, and your upgrade objective is to achieve some new functionality by upgrading the minimum number of components required to achieve that end with minimal downtime.
In general, the greater the number of Java ES components and the greater the number of computers in your deployment architecture, the more complex your upgrade plan will be.
However, your upgrade plan will depend on a number of considerations other than the scope and complexity of your deployment architecture. These considerations include the following factors:
Upgrade Dependencies
One of the main issues in planning the upgrade of a Java ES product component is to understand that component’s dependencies on other Java ES components, and whether other components need to be upgraded to support the upgrade of the dependent component.
There are two types of upgrade dependencies:
- Hard upgrade dependency. An upgrade of a product component requires you to upgrade a component upon which it depends. This requirement can be due to new functionality, new interfaces, or bug fixes needed by the dependent component. With a hard upgrade dependency, you cannot successfully upgrade and use the dependent component without first upgrading the component upon which it depends.
- Soft upgrade dependency. An upgrade of a product component does not require you to upgrade a component upon which it depends. With a soft upgrade dependency, you can successfully upgrade and use the dependent component without upgrading the component upon which it depends.
Upgrading a Java ES product component requires you to upgrade all the components upon which it has hard upgrade dependencies, but, with some exceptions noted in this book, allows you to not upgrade components upon which it has soft upgrade dependencies. When multiple interdependent components are involved in an upgrade, you have to upgrade a component if only one of the Java ES components being upgraded has a hard upgrade dependency on that particular component.
In a few special cases, due to incompatibilities that are introduced, upgrade of a component requires you to also upgrade a component that it supports. These special cases are noted in this book.
Supported Upgrade Paths and Strategies
Your upgrade plan depends on the Java ES release you wish to upgrade to Release 5.
While it is possible to upgrade all previous releases of Java ES software to Java ES 5 (Release 5), the only supported upgrades are from Java ES 2005Q4 (Release 4), Java ES 2005Q1 (Release 3), and Java ES 2004Q2 (Release 2). While this Upgrade Guide provides strategies for upgrading from Java ES 2003Q4 (Release 1) and releases that pre-date Java ES, it does not provide procedures for performing such upgrades.
The following table describes the different upgrade paths to Release 5, their characteristics, and the upgrade strategies to be used in performing the upgrade.
Because of the differences between upgrade paths described in the table, and because product component upgrade procedures often depend on which release is being upgraded, the chapters in this Upgrade Guide that describe the upgrade of each product component are divided into sections: each representing a different upgrade path.
Table 1-5 Upgrade Paths to Java ES 5 (Release 5)
Product Version
Java ES Release
System Characteristics
Upgrade Strategies
2005Q4
Release 4
Java ES 5 (Release 5) supports a mixture of Release 4 and Release 5 product components on a single computer, but requires that shared components be synchronized to the same release. Interoperability between Release 4 and Release 5 product components has been tested, and known interface incompatibilities are noted in the Java Enterprise System 5 Release Notes for UNIX, http://docs.sun.com/doc/819-4893.
The coexistence of Release 4 and Release 5 product components provides for the possibility of selectively upgrading Release 4 product components to Release 5 on a single computer or within a deployment architecture consisting of multiple computers.
If any Release 5 product component requires support of a Release 5 shared component, all shared components on the computer must be synchronized to Release 5.
2005Q1
Release 3
Similar to the Release 4 upgrade path, above. Java ES 5 (Release 5) supports a mixture of Release 3 (also Release 4) and Release 5 product components on a single computer, but requires that shared components be synonymized to the same release. Interoperability between Release 3 and Release 5 components has been tested, and known interface incompatibilities are noted in the Java Enterprise System 5 Release Notes for UNIX, http://docs.sun.com/doc/819-4893.
Similar to the Release 4 upgrade path, above. The coexistence of Release 3 and Release 5 components provides for the possibility of selectively upgrading Release 3 components to Release 5 on a single computer or within a deployment architecture consisting of multiple computers.
If any Release 5 product component requires support of a Release 5 shared component, all shared components on the computer must be synchronized to Release 5.
2004Q2
Release 2
Contrasts with the Release 4 and Release 3 upgrade paths, above. Java ES 5 (Release 5) does not support a mixture of Release 2 and Release 5 components, neither product components nor shared components, on a single computer. Known interface incompatibilities exist between the release versions, and interoperability between Release 2 and Release 5 components is not certified (has not been tested).
When upgrading components from Release 2 to Release 5 on a single computer, all Release 2 components must be upgraded to Release 5. However, it is sometimes possible to mix Release 2 and Release 5 components residing on different computers within a deployment architecture.
2003Q4
and prior versionsRelease 1 and pre-dating Java ES
Similar to the Release 2 upgrade path, above. Java ES 5 (Release 5) does not support a mixture of Release 2 and Release 5 components, neither product components nor shared components, on a single computer. Known interface incompatibilities exist between the release versions, and interoperability between Release 1 or prior releases and Release 5 components is not certified (has not been tested).
Java ES does not certify the direct upgrade of Release 1 or prior releases to Release 5.
In some cases, however, you can perform an upgrade from Release 1 by upgrading first to Java ES Release 3, as documented in the Release 3 Java Enterprise System Upgrade and Migration Guide, http://docs.sun.com/doc/819-0062, and then upgrading from Release 3 to Release 5. In those cases, the upgrade roadmap for that component in this Upgrade Guide notes this possibility.
In other cases the upgrade from Release 1 to Release 5 can be performed in the same way as the upgrade from Release 2 or Release 3 to Release 5, and in those cases, the upgrade roadmap for that component in this Upgrade Guide notes this possibility.
Selective Upgrade or Upgrade All
The distinction between hard and soft upgrade dependencies allows for the possibility in your upgrade plan of selectively upgrading Java ES product components within a deployed system. Selective upgrade applies to upgrading from Release 3 and Release 4 to Release 5 on a single computer. Selective upgrade from Release 2 to Release 5 on a single computer is not supported.
In general, you have the choice of performing a selective upgrade or upgrading all Java ES product components on a computer:
- Selective Upgrade. In this approach you start with the Java ES product component you wish to upgrade to Release 5. You determine the hard upgrade dependencies for that component; those components also need to be upgraded. Repeat this process for each successive hard upgrade dependency until no further components need to be upgraded. This exercise specifies all Java ES product components that need to be upgraded.
- Upgrade All. In this approach you upgrade all deployed Java ES product components to Release 5. In some cases, due to the complexity of a deployment, it is not feasible for business reasons to upgrade an entire system at one time.
The two approaches to performing upgrades are compared in the following table.
Selective upgrade was also supported in Java ES Release 4. It is therefore possible to have both Release 3 product components and Release 4 product components coexisting on a computer, both of which can be selectively upgraded to Release 5.
Multi-Instance Upgrades
The sequence of upgrade procedures in an upgrade plan depends on how redundancy is being used in a deployment architecture. Multiple instances of a Java ES component can be used to achieve high availability, scalability, serviceability, or some combination of these service qualities. Three technologies make use of redundant components in Java ES deployment architectures: load balancing (Directory Proxy Server, Web Server, Web Proxy Server, Application Server, Access Manager, and Portal Server), high availability techniques (Sun Cluster and High Availability Session Store), and Directory Server replication.
In most cases where redundancy is involved, upgrades must be performed without incurring significant downtime. These rolling upgrades attempt to successively upgrade redundant instances of a component without compromising the service that they provide.
Redundant instances are usually deployed across multiple computers. For upgrade planning, you might need to isolate the upgrade of replicated components from other component upgrades in order to achieve minimal downtime. You perform all the pre-upgrade tasks for the replicated components on each computer before performing the rolling upgrade.
Each replication technology has configuration or reconfiguration procedures that might affect the overall sequence of Java ES component upgrades. For example, components that run in a Sun Cluster environment can require upgrading Sun Cluster before upgrading the components that are running in the Sun Cluster environment.
The chapters in this Upgrade Guide that describe the upgrade of each product component describe how to perform multi-instance upgrades for their respective components.
Operating System Considerations
A number of operating system considerations can impact your Java ES upgrade plan, as described below.
Required Operating System Patches
Successful upgrade of a Java ES product component can require you to first patch the operating system or otherwise update the operating system to the level required by the Java ES 5 product component. However, rather than applying the specific patches or fixes needed in each case, it is preferable to bring the operating system to the level required by Java ES 5 as a whole before performing upgrades of specific product components.
- Solaris platform. Operating system patches are available through the SunSolve web site as a patch cluster, a collection of operating system patches that can be collectively applied. The patch clusters required to support Java ES Release 5 for Solaris 9 and 10 are available at http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Linux platform. Update releases are available at https://www.redhat.com/apps/download/. However, it is not necessary to update the Linux operating system before performing Java ES upgrades.
Dual Upgrades: Java ES and Operating System Softwared
Operating system and Java ES software can become misaligned when you attempt to upgrade either Java ES software or operating system software to a non-supported version. The relevant support matrix is shown in the following table.
If an upgrade of Java ES software or operating system software would result in a non-supported configuration, then you have to perform a dual upgrade: one in which both Java ES and the operating system are upgraded. The following situations can require a dual upgrade:
For example, Java ES 2004Q2 (Release 2) is supported on Solaris 8 and 9 operating systems and on Red Hat Enterprise Linux (RHEL) 2.1. If you wish to upgrade your operating system platform to Solaris 10 or RHEL 3.0, which are not supported by Java ES Release 2, you also need to upgrade your Java ES Release 2 to a Java ES release version that supports the upgraded platform. In this case, it would be preferable to upgrade to Java ES 5 (Release 5).
For example, Java ES 2005Q1 (Release 3) and Java ES 2005Q4 (Release 4) are supported on Solaris 8 and RHEL 2.1. If you want to upgrade Java ES to Release 5, however, which is not supported on Solaris 8 or RHEL 2.1, you must upgrade your operating system to versions supported by Java ES 5 (Release 5). In this case, it would be preferable to upgrade to Solaris 10 or RHEL 4.0.
In general, there are two approaches you can take to performing a dual upgrade:
- Fresh operating system installation. Install the new operating system followed by a fresh installation of Java ES Release 5, including migration of earlier version product component data (such as configuration data, runtime data, customizations, and so forth). The operating system installation can be on a new system (or Solaris 10 zone) or it can wipe out the existing file system. In the latter case, component data must first be backed up and then restored after the operating system installation.
- In-place operating system upgrade. Perform an operating system upgrade, leaving the existing file system in place, followed by an upgrade of Java ES product components to Release 5. For this to work, the operating system upgrade must have no impact on upgrade of the installed Java ES product components, their data, and required shared components.
If dual upgrade is not supported for any Java ES product component, that is, if neither of these approaches work, then you have to re-install and freshly configure that component after performing an operating system install or upgrade.
The following table shows the dual upgrade approach supported by each of the Java ES product components.
Operating System Upgrades
In some cases, upgrading the Solaris operating system overwrites existing Java ES shared components with earlier versions. In those cases the correct Java ES versions can be restored by upgrading Message Queue, which is bundled with the Solaris operating system, to Release 5. Upgrading Message Queue will force the upgrade of all resident shared components as well.
Solaris 10 Multizone Environments
A number of issues are involved in installing and upgrading Java ES components in a multizone environment. For a description of the benefits and limitations of deploying Java ES in Solaris 10 zones, and recommended practices for upgrading Java ES components in a multizone environment, see Java ES 5 Upgrade and Solaris 10 Zones.
Java ES Component DependenciesOne of the most important considerations in an upgrade plan is the dependencies between the various Java ES components in your deployed system. The sequence in which you perform the component upgrades is affected by the nature of the dependencies between them.
This section provides information about Java ES component dependencies that impact your upgrade plan.
Dependencies on Shared Components
Table 1-9 shows the dependencies of Java ES 5 (Release 5) product components on Java ES shared components. The abbreviations for product components in the column headings of Table 1-9 are taken from Table 1-1. The abbreviations for shared components are listed in Table 1-2.
Within the matrix of Table 1-9 hard upgrade dependencies for Release 3 and Release 4 to Release 5 upgrades are marked “H,” and soft upgrade dependencies are marked “S.” For Release 2 to Release 5 upgrades, all shared component dependencies are, by definition, hard upgrade dependencies; all shared components must be upgraded from Release 2 to Release 5.
Table 1-9 Shared Component Dependencies of Java ES 5 (Release 5) Product Components
Shared Component
AM
AS
DPS
DS
DS Console
HADB
JavaDB
MQ
MC
PS
PSRA
SC
SCG
SR
WPS
WS
ANT
S
S
H
H
H
ACL
S
H
BDB
S
CAC
H
S
H
H
H
S
S
S1
S1
FIS
ICU
S
H
H
S
S
S
IM-SDK
S
Java SE
S
S
H
H
H
S
H
S
S
S
S
S
S
H
S
S
JAF
S
S
S
S
H
JATO
S
S
S
S
S
S
JavaHelp™
S
S
S
S
S
JavaMail ™
S
S
S
S
H
S
JAXB
S
S
S
JAXP
S
S
S
S
H
S
JAXR
S
S
H
S
JAX-RPC
S
S
H
S
JAXWS
S
JCAPI
JDMK
H
S
H
H
H
S
S
S
S
JSS
S
S
S
S
S
JSTL
KTSE
S
S
S
LDAP C SDK
H
H
S
S
LDAP J SDK
S
MA Core
S
H
H
MFWK
H
H
H
NSPR
S
S
H
H
H
S
S
S
S
S
S
H
NSS
S
S
H
H
S
S
S
S
S
S
H
SAAJ
S
S
S
S
H
SASL
H
S
S
SEDC
S
S
SJWC
S
S
H
H
S
S
WSCL
S
S
H
S
XWSS
H
1This dependency is specifically on Common Agent Container (CAC) version 1.1.
The dependencies shown in Table 1-9 for any product component represent both direct and indirect shared component dependencies: a product component might depend on a specific shared component (direct dependency) that, in turn, depends on one or more other shared components (indirect dependency). Figure 1-1 illustrates interdependencies among shared components.
Table 1-9 shows which shared components must be upgraded when you upgrade one or more product components on a given computer.
However, because shared components must be synchronized (see Shared Component Upgrades), you cannot upgrade Java ES shared components one by one, but must upgrade all shared components on a computer or in an operating system instance to their Release 5 versions at the same time.
If no hard upgrade dependencies are involved, you need not upgrade shared components. However, it is a good practice to upgrade your underlying Java ES shared component base to the most current version. In fact, when product components are installed or upgraded by the Java ES installer, all shared components residing on the host computer are automatically synchronized to Release 5.
For information on how to manually upgrade shared components, consult Chapter 2, "Upgrading Java ES Shared Components."
Figure 1-1 Shared Component Interdependencies
Dependencies on Product Components
Dependencies on product components fall into two general categories: runtime dependencies and configuration dependencies.
- Runtime dependencies. The functioning of a software system is based on the interactions between its deployed components. The infrastructure dependencies between Java ES product components are discussed in the Java Enterprise System 5 Technical Overview. If a Release 5 product component has a hard upgrade dependency on another product component, the dependent component con only be successfully upgraded and used as intended if the component upon which it depends is also upgraded.
- Configuration dependencies. In some cases a Java ES component must be installed, configured, and running for another component to be configured. For example, a Directory Server user/group directory must be running for an Access Manager service to be registered. Component upgrade procedures often involve reconfiguration of upgraded components or migration of configuration data. Configuration dependencies can impact the sequence of upgrade procedures.
For runtime dependencies, the relationship between product components can be of the following three types:
- Mandatory. The component cannot operate without the supporting component.
- Optional. The component can operate without the supporting component, but a subset of its functionality requires the supporting component.
- Co-Dependency. Both components can operate without the support of the other, but the components used together can provide certain enhanced functionality or performance.
The following table shows the dependencies and dependency relationships between the Java ES product components listed in Table 1-1. The information can be used to determine the hard upgrade dependencies that impact your upgrade plan.
The first column alphabetically lists Release 5 product components, the second column shows other Java ES components upon which a Release 5 component has a dependency relationship, the third column provides the Java ES release versions that support the Release 5 dependency, the fourth column characterizes the dependency relationship, and the last column indicates special characteristics of the dependency, such as whether the supporting component must be local (as opposed to remote) or whether other third-party products can support the dependency.
If a product component you are upgrading to Release 5 has a dependency on Release 5 of a supporting component (as opposed to an earlier release), then the supporting component represents a hard upgrade dependency: the supporting component must also be upgraded to Release 5.
Table 1-10 Java ES Product Component Dependencies
Release 5
Product ComponentDependency1
Java ES Release
Nature of Dependency
Characteristics
Access Manager
Directory Server
2-5
Mandatory: Stores configuration data and enables lookup of user data
J2EE web container:
- Application Server
- Web Server
4-5
4-5
Mandatory: Provides web container runtime services
Local only
Access Manager
SDKAccess Manager
3-5
Mandatory: Provides Access Manager services
Access Manager
Distr. AuthenticationAccess Manager
4-5
Mandatory: Provides Access Manager services
J2EE web container:
- Application Server
- Web Server
4-5
4-5
Mandatory: Provides web container runtime services
Local only
Also supported;
- Weblogic2
- WebSphere3Access Manager
Session FailoverAccess Manager
5
Mandatory: Provides Access Manager services
Message Queue
4-5
Mandatory: Provides reliable asynchronous messaging
Application Server
Message Queue
3-5
Mandatory: Provides reliable asynchronous messaging
Local only
High Availability Session Store (HADB)
5
Mandatory: Stores session state needed to support failover between instances
Local only
Java DB
5
Mandatory: Provides default developer database and other persistent storage.
Local only
Web Server
3-5
Optional: Provides load balancing between instances
Local only
Directory Proxy Server
Directory Server
1-5
Co-dependency: Results in improved security and performance for directory requests. Supplies data to Directory Proxy Server
Directory Server
Directory Proxy Server
1-5
Co-dependency: Results in improved security and performance for directory requests. Distributes load and caches data from Directory Server
High Availability Session Store (HADB)
None
Java DB
None
Message Queue
Directory Server
2-5
Optional: Stores administered objects and user data
J2EE web container:
- Application Server
- Web Server
2-5
2-5
Optional: Supports HTTP transport between client and Message Queue broker
Java DB
5
Optional: Stores persistent messages.
Local only
Sun Cluster
2-5
Optional: Supports high availability
Monitoring Cosole
None
Portal Server
Directory Server
4-5
Mandatory: Stores and enables lookup of user profiles
J2EE web container:
- Application Server
- Web Server
4-5
4-5
Mandatory: Provides web container runtime services
Local only
Access Manager or
Access Manager SDK4-5
Mandatory: Provides authentication and authorization services, single sign-on
Local only
(If Access Manager is remote, Access Manager SDK must be used locally)Portal Server Secure Remote Access
5
Optional: Provides secure remote access through the Gateway, Rewriter Proxy, and Netlet Proxy components
Service Registry Client
5
Mandatory: Provides libraries needed for compilation
Java DB
5
Mandatory: Provides support for several portlet applications
Portal Server Secure Remote Access
GatewayPortal Server
5
Mandatory: Supports Gateway functionality
Access Manager or
Access Manager SDK4-5
Mandatory: Provides authentication and authorization services, single sign-on
Local only
(If Access Manager is remote, Access Manager SDK must be used locally)Directory Server
4-5
Mandatory: Stores and enables lookup of user data
Rewriter Proxy
Portal Server
5
Mandatory: Supports Rewriter Proxy functionality
Netlet Proxy
Portal Server
5
Mandatory: Supports Netlet Proxy functionality
Service Registry
Deployment
Application Server
5
Mandatory: Provides container runtime services
Local only
Java DB
5
Mandatory: Provides default database for storing services and related meta data
Local only
Service Registry Client
5
Mandatory: Provides required client libraries
Local only
Client
None
Sun Cluster
None
Sun Cluster Agents
Sun Cluster
4-5
Mandatory: Provides access to Sun Cluster services
Local only
Sun Cluster Geographic Edition
Sun Cluster
4-5
Mandatory: Supports Sun Cluster Geographic Edition functionality.
Local only
Web Proxy Server
Directory Server
2-5
Optional: Provides LDAP-based authentication
Web Server
2-5
Co-dependency: Results in improved security and performance for HTTP requests. Supplies data to Web Proxy Server
Also supported;
- Weblogic2
- WebSphere3Web Server
Directory Server
1-5
Optional: Provides LDAP-based authentication
Web Proxy Server
1-5
Co-dependency: Results in improved security and performance for HTTP requests. Distributes load and caches data from Web Server
1For each product component, dependencies are listed in the order that they would normally be upgraded.
2BEA Weblogic Server
3IBM WebSphere Application Server
Upgrade Sequencing GuidelinesThe the choice between selective upgrade or upgrade all, the impact of hard upgrade dependencies, and other factors discussed in the previous sections can all affect which Java ES components you plan to upgrade as well as the order in which you need to upgrade them. Nevertheless, a few general sequencing guidelines apply, though not in every case.
The following listing provides the order in which Java ES components can be successfully upgraded on a single computer or in a deployed system. When you plan your upgrade, you can omit those components that are not part of your deployment architecture or, if you are performing a selective upgrade, you can omit those components that represent soft upgrade dependencies.
The chapters in this Upgrade Guide are arranged according to the order in which components appear in the following listing.
NoteS
Before upgrading Java ES components, be sure to apply any required update of your operating system (see Required Operating System Patches).
Also check Special Cases to see if any apply to your upgrade scenario.
- Shared Components (See Chapter 2, "Upgrading Java ES Shared Components")
Shared components should be upgraded before the components which depend on them. In most cases shared component upgrade is handled by the Java ES installer, however in the case of Web Proxy Server and Portal Server you have to explicitly upgrade shared components.
- Sun Cluster software (See Chapter 3, "Sun Cluster Software")
If any components run in a Sun Cluster environment, and the Sun Cluster software needs to be upgraded, it should be upgraded before the components that use Sun Cluster services. Sun Cluster agents, if upgraded, should be upgraded as part of the Sun Cluster upgrade.
- Sun Cluster Geographic Edition software (See Chapter 4, "Sun Cluster Geographic Edition")
Sun Cluster Geographic Edition should be upgraded after Sun Cluster software, upon which it depends. It should be upgraded before any components that use Sun Cluster services.
- Directory Server (See Chapter 5, "Directory Server")
Many components store user data or configuration data in Directory Server, so upgrades to Directory Server should generally be performed before upgrading the components that have runtime or configuration dependencies on Directory Server.
- Directory Proxy Server (See Chapter 6, "Directory Proxy Server")
Directory Proxy Server has a soft upgrade dependency on Directory Server and can be upgraded at any time. Some components might access Directory Server through Directory Proxy Server, however, so if Directory Proxy Server is upgraded, it should be upgraded right after Directory Server.
- Web Server (See Chapter 7, "Web Server")
A number of Java ES components require the support of a web container, which, if upgraded, should be upgraded before the components requiring web container services. Normally web container services are provided by Web Server or Application Server, but if your architecture contains both, upgrade Web Server first, before upgrading Application Server.
- Java DB (See Chapter 8, "Java DB")
Java DB must be upgraded before Application Server, which requires Java DB as a default database. However, Java DB is automatically upgraded by the Java ES installer when upgrading Application Server.
- High Availability Session Store (See Chapter 9, "High Availability Session Store")
High Availability Session Store (HADB) must be upgraded before Application Server, which requires High Availability Session Store for high availability. However, HADB is automatically upgraded by the Java ES installer when upgrading Application Server.
- Message Queue (See Chapter 10, "Message Queue")
Message Queue must be upgraded before Application Server, which requires Message Queue to be Java Enterprise Edition (Java EE) compliant. However, Message Queue is automatically upgraded by the Java ES installer when upgrading Application Server.
- Application Server (See Chapter 11, "Application Server")
Application Server depends on Message Queue and High Availability Session Store, and if upgraded, should be upgraded after these components. Application Server can also depend on Web Server for its load balancing plug in, so if you are using that capability, Application Server should be upgraded after Web Server.
- Service Registry (See Chapter 12, "Service Registry")
Service Registry can be upgraded anytime after Application Server is upgraded because Service Registry depends upon Application Server for runtime container services.
- Web Proxy Server (See Chapter 13, "Web Proxy Server")
Web Proxy Server can be upgraded anytime, though generally it would be upgraded after the Web Server or Application Server component for which it provides a proxy service. Web Proxy Server is a new Java ES Release 5 component that can be upgraded from its previous non-Java ES release.
- Access Manager (See Chapter 14, "Access Manager"
Access Manager plays a central role in authentication and authorization, including single sign-on, and, if upgraded, should be upgraded before the components that depend on it for those services.
- Portal Server (See Chapter 15, "Portal Server")
Portal Server depends on many of the preceding components (Directory Server, a web container, and Access Manager), and if upgraded, should be upgraded after these components.
- Portal Server Secure Remote Access (See Chapter 16, "Portal Server Secure Remote Access")
Portal Server Secure Remote Access, must be upgraded when Portal Server is upgraded.
Special CasesThere are a few special cases to be aware of when planning the upgrade of Java ES components to Release 5. These are described below.
Selective Upgrade: Application Server Not Upgraded
If you are performing a selective upgrade of any Java ES component to Java ES 5 on a computer that is running Release 3 or Release 4 Application Server (8.1), and you are not upgrading Application Server to Release 5, there are situations that must be addressed for Application Server to continue functioning properly:
- JSP compilation errors. Before performing the selective upgrade, you should first apply the Application Server patch shown in the following table.
Table 1-11 Patches1 Needed When Application Server Is Not Upgraded to Release 5
Description
Patch ID: Solaris 9 & 10
Patch ID: Linux
Fix for Release 3 and Release 4
Application Server119166-17 (SPARC)
119166-17 (x86)
119168-17
1Patch revision numbers are the minimum required. If newer revisions become available, use the newer ones instead of those shown in the table.
If you fail to apply the patch, Application Server will experience JSP compilation errors. (The patches in Table 1-11 can also be applied retroactively to fix the problem.)
Upgrade of Portal Server Interim Feature Release (IFR) 7.0 to Java ES 5
If you are upgrading Portal Server in a Web Server environment from the Interim Feature Release (IFR) 7.0 2005Q4 to Release 5, please consult Upgrading Portal Server from the Interim Feature Release 7.0 for exceptions to the guidelines in Upgrade Sequencing Guidelines.
Java ES 5 Upgrade and Solaris 10 ZonesThis section addresses issues involved in upgrading Java ES software in Solaris 10 zones and provides recommended in such an environment. The section supplements information regarding Java ES 5 and Solaris 10 zones in the Java Enterprise System 5 Installation Planning Guide, http://docs.sun.com/doc/819-5079.
It includes the following topics:
Zone Support in the Java ES Installer
The Java ES 5 installer provides qualified zones support for upgrade (as well as installation) of Java ES product components and for synchronization of shared components. Policies have been implemented in the installer to help prevent problematic upgrade scenarios.
Upgrade of Product Components
As described in Using the Upgrade Capability of the Java ES Installer, the Java ES installer can be used to upgrade a limited number of product components and their corresponding shared components. The upgrade capability applies to global zones and all non-global zones.
However, there are three zones-related exceptions to this behavior:
- In sparse root zones, some shared components cannot be installed or upgraded because they reside in read-only directories. In such cases, the upgrade of product components is halted until such time as such shared components have been installed or upgraded in the global zone. The installer provides the following message: “The following shared components, required by the components you have selected, cannot be installed or upgraded in a sparse root zone. Please install or upgrade these shared components in the global zone before proceeding. Use the All Shared Components option.”
- Both Application Server and Message Queue are bundled with the Solaris operating system. Neither of these versions can be directly upgraded in a sparse-root zone. For the details regarding these two bundled components, see Product Component Special Cases.
- In a global zone, if non-global zones are present, instead of upgrading all shared components currently installed and installing any missing shared components required by a selected component, the installer synchronizes all Java ES shared components to Release 5, whether or not they are needed by any specific product component. This allows all Release 5 shared components to be propagated to non-global zones, thus assuring that there is no intermixing of shared component versions in non-global zones.
Note
There are a number of special cases or exceptions that might interfere with the installation or upgrade of product components in non-global zones. These are described in Special Cases or Exceptions.
Synchronize All Shared Components
A shared component synchronization option is provided in Release 5 to meet situations in which all shared components must be synchronized to their Release 5 versions. When the All Shared Components option is selected, the installer will upgrade all shared components currently installed and install any missing shared components, whether or not they are needed by any specific product component. This option applies to global zones and whole root zones (but not to sparse root zones).
The All Shared Components option, described in more detail in Synchronize All Shared Components, is needed in the following two zone-based upgrade scenarios:
- Manually upgrading product components. The All Shared Components option is needed to perform the shared component installation and upgrade needed when upgrading product components that cannot be upgraded using the Java ES installer.
- Upgrades in a Sparse Root Zone. Some shared components cannot be installed or upgraded in default sparse root zones. Hence, when using the Java ES installer to upgrade product components in sparse root zones, you might first be required to synchronize shared components in the global zone, depending on the shared components involved. You use the All Shared Components option in the global zone to perform the shared component installation and upgrade required in this case.
For a summary of the Java ES installer’s zone behavior regarding shared components, see the information regarding Java ES 5 and Solaris 10 zones in the Java Enterprise System 5 Installation Planning Guide, http://docs.sun.com/doc/819-5079.
Recommended Upgrade Practices
In formulating an upgrade plan, you should survey any existing multizone deployments of Java ES software, keeping in mind the zones installation and administration strategies outlined in the Java Enterprise System 5 Installation Planning Guide, http://docs.sun.com/doc/819-5079. In some cases you might be required to uninstall components in one or more zones and re-install them in other zones to implement the following recommended practices:
- Avoid mixing strategies. In particular:
- Keep your Java ES zones deployment and administration strategy as simple as possible. Do not mix whole root and sparse root deployments of Java ES components on the same computer. (Procedures and practices needed to support sparse root zone deployments can interfere with whole root zone deployments.)
- Do not install the same Java ES product component in both the global zone and non-global zones, even if they are of different versions. (Procedures needed to upgrade a global zone installation can break the non-global zone installations.)
- When Release 4 (or earlier) Java ES components have been installed in a whole root zone, do not upgrade Java ES components to Release 5 in the global zone. Upgrade in the global zone could result in a mixing of Release 4 and Release 5 files in the whole root zone.
- Upgrade practices:
- If you want to upgrade all installed Release 4 product components to Release 5, synchronize all Java ES shared components in the global zone, then perform the upgrade of the desired product components in the zones where they have been installed. (Release 5 shared components are backwardly compatible.)
- If you have Release 4 or Release 5 product components installed in a non-zones environment, and you wish to add non-global zones to the environment and install product components in the new non-global zones, you might need to uninstall components in the global zone and reinstall them in non-global zones.
Special Cases or Exceptions
There are a number of special cases, some of which arise from the fact that some Java ES shared components and some Java ES product components are bundled with Solaris 10. By virtue of this bundling, these Java ES components automatically exist in the global zone, and therefore in any non-global zone that is created from the global zone.
Product Component Special Cases
- Message Queue. Message Queue is bundled with Solaris 10, and, as a result, is automatically propagated when non-global zones are created (unless you have first removed Message Queue from the global zone). Message Queue cannot be installed or upgraded in a sparse root zone. When installed or upgraded in a global zone by the Java ES installer, Message Queue, unlike other product components, is, by default, propagated to non-global zones,.
- Application Server. Application Server is bundled with Solaris 10, and, as a result, is automatically propagated when non-global zones are created (unless you have first removed Application Server from the global zone). When propagated in this way, the bundled Application Server, which is installed in /usr, cannot be upgraded by the Java ES installer in a sparse root zone (by default /usr is read-only). To address this problem, the bundled Application Server packages must be manually removed from the global zone before installing the Release 5 Application Server in a sparse root zone. See Solaris OS Only: Manually Remove the Application Server Packages Bundled with the Operating System.
- Sun Cluster. Sun Cluster software is not supported in non-global zones.
Shared Component Special Cases
- Sun Java Web Console (SJWC). SJWC packages that are bundled with Solaris 10 (Update 1 and Update 2) cannot be removed by the Java ES installer. These older SJWC packages have had the SUNW_PKG_ALLZONES attribute set to True, which means the package must be identical in all zones and can only be managed by the global administrator. As a result, these packages must be manually removed in the global zone and replaced by the correct packages.
If the Java ES installer is attempting to install a selected product component in a non-global zone and detects that SJWC needs to be upgraded, the installer will block. This will happen when installing on Solaris 10, Update 1 and 2.
As a workaround, a special script has been developed that will remove the old packages of SJWC from the global zone and replace them with Release 5 SJWC, which has the correct zones propagation attribute value. See the Java Enterprise System 5 Installation Guide for UNIX for details.
