Sun Java Enterprise System Upgrade Guide for Microsoft Windows |
Chapter 1
Planning for UpgradesThis chapter provides information used for planning the upgrade of Sun Java™ Enterprise System (Java ES) software to Java ES 2005Q4 (Release 4). It contains the following sections:
Java ES 2005Q3 (Release 4) ComponentsAs an introduction to planning the upgrade of Java ES software, this section reviews the components included in Java ES Release 4. Depending on your upgrade scenario, you might need to upgrade one or more of these components to their Release 4 version.
Java ES components are grouped into different types, as described in the Java Enterprise System Technical Overview (http://docs.sun.com/doc/819-0061). Accordingly, system service components provide the main Java ES infrastructure services, while service quality components enhance those system services. These two types of Java ES components are together referred to here as product components, components that are selectable within the Java ES installer.
Each product component depends on one or more locally shared libraries known as Java ES shared components. Shared components are installed automatically by the Java ES installer during product component installation, depending on the product components that are being installed.
Release 4 Product Components
The Java ES Release 4 product components are shown in the following table, listed alphabetically. For the service quality components among them, the table includes the type of service enhancement they provide.
Release 4 Shared Components
Java ES shared components, upon which the product components installed on a single computer depend, cannot be selected or deselected within the Java ES installer. When installing Java ES product components, the Java ES installer automatically installs the shared components needed by the installed product components.
The Java ES Release 4 shared components are listed in the following table.
Patches for Upgrading Components
The following table lists the patches for the product components and shared components of this release.
About Java ES UpgradesThe upgrade of Java ES software to Release 4, with a few exceptions, is not performed using the Java ES installer or any other system utility. It is performed component-by-component, computer-by-computer, using component-specific upgrade procedures.
The upgrade of a component can range from a major upgrade, which might not be compatible with the previous version of the component, to a fully-compatible upgrade that simply provides bug fixes. Because of dependencies between Java ES components, the nature of the upgrade can impact whether other components need to be upgraded as well.
Product Component Upgrades
Java ES product component upgrades involve two basic operations that mirror the initial installation and configuration of Java ES product components:
- Installing upgraded software. The new software can be an enhancement or fixing of existing software, or a replacement of existing software. In general, the new software is achieved through the application of patches to existing software packages or a full re-installation of a component using the Java ES installer.
- Re-configuration. Re-configuration encompasses any change in configuration data, user data, or dynamic application data needed to support the upgraded software. A change in data can mean additional data, a change in data format (whether in property files or database schema), or a change in data location. Sometimes re-configuration requires that you perform an explicit procedure and sometimes it takes place automatically without your involvement.
These two aspects of component upgrades are described in this Upgrade Guide for each of the Java ES product components.
The Upgrade Guide also covers other important aspects of product component upgrades, including:
Shared Component Upgrades
Java ES shared component upgrades are often a necessary part of upgrading the product components that depend on them.
The upgrading of shared components is typically more straightforward than the upgrading of product components. In general, the upgrade is achieved through the application of patches to existing packages. As compared to upgrading product components, there is normally no re-configuration required, nor pre or post upgrade procedures to be performed.
While shared components can be upgraded one by one, Java ES Release 4 allows you to collectively upgrade a number of shared components in one operation. For more information, see Chapter 2, "Upgrading Java ES Shared Components."
Upgrade Technologies
The upgrade of both the product components and shared components, as described in this Upgrade Guide, involves application of packages to existing software packages. The patching is achieved through Windows installer patching or MSP files. Patches are distributed through the SunSolve web site.
Upgrade PlanningThe approach you take to upgrading a deployed Java ES software system to Java ES Release 4 can depend on many factors:
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 possible to achieve that end with minimal downtime.
These two examples represent upgrade scenarios of very different complexities, requiring substantially different upgrade plans. No one plan works for all deployed Java ES software systems.
In general, the greater the number of Java ES components and the greater the number of computers in your deployment architecture, the more complex will be your upgrade plan.
What is an Upgrade Plan?
An upgrade plan specifies how to approach each stage of the upgrade process. This process involves, at a minimum, the phases shown in the following table.
Upgrade Dependencies
One of the main issues in planning the upgrade of any given Java ES component is to understand that component’s dependencies on other Java ES components, and whether such other components also need to be upgraded to support the upgrade of the dependent component.
In this respect, there are two types of upgrade dependencies:
- Hard upgrade dependency. A hard upgrade dependency is where an upgraded version of a component requires an upgraded version of some component upon which it has a dependency. You cannot successfully upgrade the component without first upgrading the component upon which it depends. In other words, the Release 4 version of the component is not compatible with the Release 3 version of the component upon which it has a dependency.
- Soft upgrade dependency. A soft upgrade dependency is where an upgraded version of a component does not require an upgraded version of some component upon which it has a dependency. You can successfully upgrade the component without upgrading the component upon which it depends. In other words, the Release 4 version of the component is compatible with the Release 3 version of the component upon which it has a dependency.
Upgrading a Java ES component requires you to upgrade all the components upon which it has hard upgrade dependencies, but allows you to not upgrade components upon which it has soft upgrade dependencies.
This general rule does not necessarily apply, however, when multiple interdependent components are involved in an upgrade. In such cases, you have to upgrade a component if only one of several other Java ES components has a hard upgrade dependency on that particular component.
Upgrade All
You can upgrade all deployed Java ES components to Release 4. The complexity of this approach also depends on your deployment architecture. In some cases, it simply is not feasible for business reasons to upgrade an entire system at one time.
Java ES Component DependenciesAs mentioned in the previous section, an upgrade plan specifies the Java ES components you need to upgrade and the sequence by which you need to upgrade those components. One of the important considerations in an upgrade plan is the dependencies between the various Java ES components in your deployed system.
The sequence by 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. The following dependency factors impact your upgrade plan.
Each of these factors is discussed briefly in the following sections.
Dependencies On Shared Components
When upgrading Java ES product components, you have to take into account dependencies these Java ES components have on Java ES shared components. When a product component has a hard upgrade dependency on a shared component, the shared component also must be upgraded.
Shared Component Dependency Matrix
Table 1-6 shows the dependencies of Java ES 2005Q4 (Release 4) product components on Java ES shared components. The abbreviations for product components that head the columns of Table 1-6 are taken from Table 1-1. The abbreviations for shared components are spelled out in Table 1-2.
Four product components are not included in Table 1-6: Directory Proxy Server (DPS), High Availability Session Store (HADB), and Directory Preparation Tool (DPT) have been omitted because they have no dependencies on shared components. Service Registry (SR) and Web Proxy Server are omitted because they are new product components for which there is no previous version from which to upgrade.
Within the matrix of Table 1-6 hard upgrade dependencies for Release 3 to Release 4 upgrades are marked “H,” while soft upgrade dependencies are marked “S.”
The dependencies shown in Table 1-6 for any product component represent both direct and indirect shared component dependencies. In other words, a product component might depend on a specific shared component that, in turn, depends on one or more other shared components. The shared component dependencies shown in Table 1-6 include all such indirect dependencies. The following figure illustrates inter-dependencies among shared components.
Figure 1-1 Shared Component Inter-dependencies
Shared Component Upgrade Guidelines
Table 1-6 lets you determine the shared components to upgrade when upgrading one or more product components on a given computer:
If you are upgrading all product components from Release 3 to Release 4, all the shared components indicated in Table 1-6 for the respective product components should be upgraded.
Even if you are selectively upgrading product components, however, it is the recommended practice to upgrade the shared components needed by all product components on the computer; Release 4 shared components are certified to support Release 3 product components.
If no hard upgrade dependencies are involved, you might not upgrade shared components at all. However, as a general rule, it is a good practice to upgrade your underlying Java ES shared component base to the most current versions.
Note
The sequence of upgrading shared components can depend upon the shared component inter-dependencies shown in Figure 1-1.
Also, if you plan to upgrade J2SE to J2SE 5.0, you should upgrade this shared component first. J2SE is the base component for many Java ES components.
For information on how to upgrade shared components, consult Chapter 2, "Upgrading Java ES Shared Components."
Dependencies On Product Components
Dependencies of one product component on another are an important determinant of the Java ES components you need to upgrade and the sequence by which you need to upgrade them. 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 components are discussed in the Java Enterprise System Technical Overview. In upgrading any Java ES product component, you must take into account such dependencies. If an upgraded version of one component has a hard upgrade dependency on another component, that dependency implies that the dependent component should only be upgraded after the component upon which it depends is upgraded.
- Configuration Dependencies. In many cases a Java ES component must be installed, configured, and running for another component to be configured. For example, a Directory Server configuration directory must be running for you to configure Messaging Server components, or a Directory Server user/group directory must be running for an Access Manager service to be registered. Component upgrade procedures often involve re-configuration of upgraded components or migration of configuration data. In fact, some product components’ main function is to provide configuration or administrative support to other components. As a result, configuration dependencies can have a strong impact on the sequence of upgrade procedures.
Table 1-7 shows the dependencies between the Java ES product components listed in Table 1-1. Using Table 1-7, you can diagram the chain of dependencies in your upgrade set. The left column lists each product component, the middle column shows its dependencies on other product components, the third characterizes each dependency, and the last column indicates whether or not the respective components must be local.
General Sequencing GuidelinesThe factors discussed in the previous sections can all impact which Java ES components you plan to upgrade as well as the order in which you upgrade them. These factors also influence your approach to upgrading Java ES components that are deployed across multiple computers. The specific impact of all these factors depends on your deployment architecture.
Nevertheless a few general sequencing guidelines apply, though not in every case. The following list provides the order in which Java ES components can be successfully upgraded on a single computer or in a deployed system. When performing an upgrade, simply omit those components that are not part of your deployment architecture.
Note
The chapters in this Upgrade Guide are arranged according to the order you would normally upgrade Java ES components, as indicated by these sequencing guidelines.
- Shared Components (See Chapter 2, "Upgrading Java ES Shared Components".)
Shared components should generally be upgraded before the components which depend on them.
- Directory Server and Administration Server (See Chapter 3, "Directory Server and Administration 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 4, "Directory Proxy Server".)
Directory Proxy Server has a hard upgrade dependency on Directory Server and Administration Server and is therefore upgraded after Directory Server and Administration Server. Other components might access Directory Server through Directory Proxy Server.
- Web Server (See Chapter 5, "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, but if your architecture contains both, upgrade Web Server first.
- Message Queue (See Chapter 6, "Message Queue".)
Message Queue, if upgraded, is best upgraded before Application Server, which requires Message Queue to be Java 2 Enterprise Edition (J2EE) compliant.
- High Availability Session Store (See Chapter 7, "High Availability Session Store".)
High Availability Session Store, if upgraded, is best upgraded before Application Server, which requires High Availability Session Store for high availability.
- Application Server (See Chapter 8, "Application Server".)
Application Server depends on Web Server for its load balancing plug in, so if you are using that capability, Application Server should be upgraded after Web Server.
- Access Manager (See Chapter 9, "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. In addition, Access Manager requires specific Directory Server schema (Schema 2), which affects how other components use Directory Server.
- Directory Preparation Tool (See Chapter 10, "Directory Preparation Tool".)
Directory Preparation Tool depends on the Directory Server schema and should therefore be run against Directory Server. If upgrading Directory Preparation Tool, it should be upgraded before you upgrade the communications components that depend on Directory Preparation Tool to make changes in the directory: Messaging Server and Calendar Server.
- Messaging Server (See Chapter 11, "Messaging Server".)
Messaging Server, if upgraded, should be upgraded only after the preceding upgrades.
- Calendar Server (See Chapter 12, "Calendar Server".)
Calendar Server, if upgraded, should be upgraded after Messaging Server since some of its functions require Messaging Server support.
- Communications Express (See Chapter 13, "Communications Express".)
Communications Express, if upgraded, depends on many of the preceding components (Calendar Server, Messaging Server, Directory Preparation Tool, Access Manager, Web Server, and Directory Server) and, if upgraded, should be upgraded after them.
- Instant Messaging (See Chapter 14, "Instant Messaging".)
Instant Messaging, if upgraded, can be upgraded at almost any point after Access Manager has been upgraded.
- Portal Server (See Chapter 15, "Portal Server".)
Portal Server, like Communications Express, depends on many of the preceding components, but in particular, it depends on Communications Express to provide messaging and calendar channels, and, if upgraded, should therefore be upgraded after Communications Express
- Portal Server Secure Remote Access (See Chapter 16, "Portal Server Secure Remote Access".)
Portal Server Secure Remote Access, if upgraded, can be upgraded anytime after Portal Server has been upgraded.
- Delegated Administrator (See Chapter 17, "Delegated Administrator".)
Delegated Administrator, if upgraded, can be upgraded and used to provision users any time after Directory Preparation Tool has been upgraded and run against Directory Server. By convention, users are provisioned after other services have been upgraded and started, however, Delegated Administrator can be upgraded before upgrading the communications components that depend on Delegated Administrator for provisioning users.