Sun Java Enterprise System 5 Update 1 Upgrade Guide for Microsoft Windows

Upgrade Plan Considerations

An upgrade plan is the essential starting point for performing an upgrade to Java ES 5 Update 1 (Release 5U1). In an upgrade plan you specify the Java ES components you will upgrade to Release 5U1 and the sequence by which you will upgrade those components on the different computers or operating system instances in your Java ES deployment.

Your upgrade plan depends on a number of factors, each of which should be given careful consideration in preparing for upgrade to Release 5U1:

Upgrade Objectives and Priorities

An upgrade plan reflects your upgrade objectives and priorities, which often depend on the scope and complexity of your existing 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.

The Java ES Release Model

A key consideration in planning an upgrade is whether the objective of the upgrade is to achieve major functional enhancements or to apply bug fixes (or minor functional updates) to existing software.

The Java ES release model is a categorization scheme for Java ES releases that clarifies the nature of the releases, their relationships to one another, and the risks and planning required to upgrade from one to another.

Component Release Levels

The Java ES release model is based on a set of release levels that define the characteristics of individual Java ES component releases:

Java ES System Release Types

A Java ES release is a consolidation of individual Java ES component releases that are synchronized and collected in a single distribution that can be used for initial installation and upgrade.

The Java ES release model specifies two general types of Java ES releases: feature releases, which can include all levels of component releases, including major and minor releases, and maintenance releases, which can include only update and point-fix releases.

The two types of Java ES releases have the characteristics described below:

Feature Release

The primary purpose of a feature release is to deliver new features and functional capabilities. While specific components within a Java ES feature release might be only update or point-fix releases, the purpose of the release is to deliver major or minor component releases. A Java ES feature release has the following general characteristics:

Maintenance Release

The primary purpose of a maintenance release is to fix bugs in the software, so that components work as originally documented. New features are limited in number and highly constrained. A Java ES maintenance release cannot include major or minor component releases, only update and point-fix releases. A Java ES maintenance release has the following general characteristics:

Java ES Release Families

A Java ES release family consists of a feature release and its associated maintenance release as illustrated in the following figure.

Figure 1–1 Java ES Release Family

This figure illustrates the releases that are part of
the Java ES release family.

A Java ES feature release initiates a release family, and a number of subsequent maintenance releases (called Java ES update releases) provide distributions that periodically consolidate intervening component update and point-fix releases. These individual component maintenance releases are independently collected in a Java ES accumulated patch cluster.

The maintenance aspect of the Java ES release model is represented by both the Java ES update release and the Java ES accumulated patch cluster, described as follows:

The significance of the Java ES release model, from an upgrade point of view, is that an upgrade from one Java ES release family to another (a feature upgrade) involves significant impact and risk, and requires a more complex upgrade plan, as compared to an upgrade within a release family (a maintenance upgrade).

Release Delivery Formats

The following table shows the delivery formats of the releases within the Java ES release model shown in Figure 1–1.

Table 1–3 Characteristics of Java ES Release Types

Release Type 

Delivery Format 

Suitable For 

Feature Release 

Available as a full distribution that contains new component packages that are generally installed using the Java ES installer. 

Installation by new Java ES users and feature upgrades from previous release families. 

Update Release 

Available as a full distribution and also as a corresponding accumulated patch cluster. (The accumulated patch cluster supports in-place maintenance upgrades within the current release family.) 

Installation by new Java ES users, feature upgrades from previous release families, and maintenance upgrades from within the current release family. 

Accumulated Patch Cluster 

Available as a set of individual component patches, each of which accumulates previous sustaining patches. Patches can be applied in-place without requiring reconfiguration or migration of component data. 

Maintenance upgrades from a feature release, update release, or previous individual component release within the current release family. 

Supported Upgrade Paths and Strategies

Your upgrade plan depends on the Java ES release you wish to upgrade to Release 5U1. The following table describes the different upgrade paths to Release 5U1, their characteristics, and the upgrade strategies to be used in performing the upgrade.

Table 1–4 Upgrade Paths and Strategies

Release 

Java ES Release 

System Characteristics 

Upgrade Strategies 

Java ES 5 

Release 5 

Java ES 5 Update 1 (Release 5U1) supports a mixture of Release 5 and Release 5U1 product components on a single computer. Interoperability between Release 5 and Release 5U1 components is guaranteed. 

The coexistence of Release 5 and Release 5U1 product components provides for the possibility of selectively upgrading Release 5 product components to Release 5U1 on a single computer within a deployment architecture consisting of multiple computers. 

If any Release 5U1 product component requires support of a Release 5U1 shared component, all shared components on the computer are best synchronized to Release 5U1. 

2005Q4 

Release 4 

 

Direct upgrade from Release 4 to Release 5U1 is not supported. This upgrade path is supported by first upgrading Release 4 to Release 5 and then upgrading Release 5 to Release 5U1. The information about upgrading Release 4 to Release 5 is documented in Sun Java ES 5 Upgrade Guide for Microsoft Windows.

 

Upgrade Dependencies

One of the main issues in planning the upgrade of any given Java ES component is that component’s dependencies on other Java ES components. You should evaluate whether such other components also need to be upgraded to support the upgrade of the dependent component.

The two types of upgrade dependencies are:

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.

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.

Table 1–5 Upgrade All

Upgrade Approach 

Advantages 

Disadvantages 

Selective upgrade 

Minimizes number of components to upgrade 

Results in inconsistent versions for all components in your deployed system 

Upgrade All 

Maintains a consistent version for all components in your deployed system 

Maximizes the number of components to upgrade 

The choice between Selective Upgrade and Upgrade All is not rigid. For example, you might choose to selectively upgrade the product components on a particular computer, but wish to upgrade all shared components needed to support the selected product components.