Chapter 1 Planning for Upgrades
This chapter provides information used for planning the upgrade of Sun JavaTM Enterprise System (Java ES) software from Java ES 5 (Release 5) to Java ES 5 Update 1 (Release 5U1) in a Windows operating system. This chapter contains the following sections:
Java ES 5 Update 1 Components
As an introduction to planning the upgrade of Java ES software, this section reviews the components included in Java ES 5 Update 1. Depending on your upgrade scenario, you might need to upgrade one or more of these components to their Release 5U1 version.
Java ES components are grouped into different types, as described in the Java Enterprise System Technical Overview:
-
Product Components. Java ES product components consist of:
-
System service components, which provide the main Java ES infrastructure services
-
Service quality components, which enhance system services
Product components are upgraded from Release 5 to Release 5U1 by applying the required patches. See Java ES Upgrade Through Application of Patches.
-
-
Shared Components. Java ES shared components are locally shared libraries upon which Java ES product components depend. Shared components are also upgraded by the application of patches.
Release 5U1 Product Components
Release 5U1 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.
Table 1–1 Release 5U1 Product Components
Release 5U1 Shared Components
Release 5U1 shared components are listed in the following table:
Table 1–2 Release 5U1 Shared Components
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:
-
Major release. The purpose of a major release is to introduce or change significant software functionality and architectural features. As such, it can introduce incompatibilities with previous versions, and operating system support may be dropped. As a result, users may be required to take specific actions in order for their applications to integrate with a major release. As part of upgrading to a new major release, users might have to perform migrations, redeployments, and possibly redesign their solutions to utilize new features or respond to the removal of old features.
-
Minor release. The purpose of a minor release is to introduce new, non-interfering features without introducing incompatibilities. New prerequisites or dependencies can be established and previous features can be deprecated in a minor release. As compared to upgrading to a major release, users might have to perform migrations and redeployments, but a redesign of their existing solution should not be necessary.
-
Update release. The purpose of an update release is to provide fixes to an existing component implementation so that it more accurately implements a prior release's functional specification. The update release provides for the delivery of bug fixes and a constrained set of feature enhancements such that the release remains suitable for adoption by the majority of existing users. When compared to a major or minor release an update release contains fewer, smaller and/or lower risk features. Other than in rare exceptions, an update release is 100% backwardly compatible with the prior release. Upgrading to an update release from the prior release should require minimal planning and investment.
-
Point-fix release. The purpose of a point-fix release is to address critical customer issues quickly. Like an update release, it supports existing users, but is generally more limited or focused, typically containing only a few bug fixes. Feature enhancements or new feature additions are not allowed in a point-fix release. Upgrading to a point-fix release from the prior release should be simple an low risk.
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:
-
The release can introduce significant interface changes, new dependencies, and/or incompatibilities with respect to Java ES components
-
The release requires a longer planning cycle prior to adoption
-
Upgrade to the release generally requires reconfiguration and/or migration of component data
-
The release can involve significant impact or risk
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:
-
The release cannot introduce significant interface changes, new dependencies, or incompatibilities with respect to Java ES components
-
The release allows for quick adoption
-
Upgrade to the release requires no reconfiguration or migration of component data
-
The release involves minimal impact or risk
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
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:
-
Java ES Update release. 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:
As compared to a feature release, an update release contains fewer, smaller, and/or lower risk features. Other than in rare exceptions, an update release is 100% backwardly compatible with the release family with which it is associated.
Note –Java ES 5 Update 1 is a Java ES update release.
-
Accumulated patch cluster. The accumulated patch cluster contains the latest set of individual component point-fix and update releases for the components in a release family. It facilitates upgrade to the most recent versions of all Java ES components.
The accumulated patch cluster is established at the onset of a release family and has a life cycle corresponding to the support life of the release family. It is updated whenever a new component point fix or update release is made available. Other than in rare exceptions, the accumulated patch cluster is 100% backwardly compatible with earlier releases in its release family.
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:
-
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 the 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.
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. In this approach you start with the Java ES product components you wish to upgrade to Release 5U1. 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 5U1. In some cases, due to the complexity of a deployment, upgrading an entire system at one time is not feasible for business reasons.
The two approaches to performing upgrades are compared in the following table:
|
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.
Upgrade Process
The 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.
Table 1–6 Phases in the Upgrade Process|
Upgrade Phase |
Description |
|---|---|
|
Plan |
You develop an upgrade plan. In the development plan, you specify the Java ES components to be upgraded and the sequence by which you need to upgrade those components on the different computers or operating system instances in your deployment. |
|
Pre-upgrade preparation |
You back up configuration and application data, perform any patching of the operating system, upgrade any required dependencies, and perform other tasks in preparation for upgrading any individual component. |
|
Upgrade |
You obtain all the necessary packages, patches, and tools needed for the upgrade. You install upgraded software and reconfigure each component as prescribed, including the migration of data to the upgraded system. |
|
Verification |
You verify that the upgrade has been successful using prescribed verification tests, including starting the upgraded software components and testing various usage scenarios. |
|
Rollback and restoration |
Roll back the upgrade and verify that the rollback is successful. Testing the rollback of the upgrade is important in case you have to restore the production environment to its previous state for some reason. |
Java ES Upgrade Through Application of Patches
Maintenance upgrades of Java ES product components from Release 5 to Release 5U1 are performed component-by-component through the application of Java ES 5 Update 1 patches. Because of dependencies between Java ES components, the nature of a component upgrade can impact whether other components need to be upgraded as well.
The following sections provide information about upgrading Java ES through application of patches:
Accessing Java ES Patches
Java ES 5 Update 1 patches can be accessed either as individual patches or as a patch cluster. You can access these patches in either of these two ways from the SunSolve web site:
-
As a patch cluster named Java Enterprise System 5 Accumulated Patch Cluster Windows.
-
As discrete upgrade patches, using the java_es-5 keyword to search for Java ES release 5 family patches.
Note –
This document captures only the information related to the patches and the patch cluster available at the time of Java ES 5 Update 1 release. New revisions of these patches might be made available in the future.
Upgrade Prerequisite-Java ES Windows Installer Patch
Before applying Java ES 5 Update 1 patches, be sure that the following Java ES Windows Installer patch has been installed:
126910–02 [Revision number indicated for the Java ES Windows Installer patch is the minimum required for upgrade to Release 5U1. If newer revision becomes available, use the newer one.]
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. Shared component upgrades can be rolled back to their previous versions only after Java ES components depending on them are rolled back.
Identifying and Stopping Processes to Avoid System Restart
The Java ES 5 Update 1 Windows patching system requires a system restart if any of the delivered and updated shared component DLLs are in use by another application. There are various tools that can be used to find if any files related to Java ES are in use by other processes. You can stop those processes before applying the patch so that the patch installation can be completed without a system restart.
The following sections describe some of the tools.
ListDLLs and Process Explorer
ListDLLs is a command line tool . ListDLLs provides a list of DLLs that are in use and also their path. The list indicates which DLLs have a version different from their original version on the disk (such DLLs are flagged in the list). The path column in the list shows which DLLs are relocated.
ListDLLs can be downloaded from:http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ListDlls.mspx
Process Explorer is the GUI version of the ListDLLs program.
Process Explorer can be downloaded from: http://www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx
Checking the version of DLLs
To get the basic version information of DLLs, use the tool GetVers.exe .
You can download GetVers.exe from: http://support.microsoft.com/kb/167597
To get a more informative version information of DLLs, use the tool ShowVer.exe.
You can download ShowVer.exe from: http://www.codeproject.com/dll/showver.asp.
Identifying Installed Java ES Patches
You can execute the utility ListJavaESPatches.exe to identify the installed Java ES patches in the system. This utility is available as part of Java ES 5 installation and its default location is <JavaES5InstallDir>\utils\patch.
The utility ListJavaESPatches.exe is also made available through the newer versions of the Java ES 5 Update 1 patches.
Default Installation Paths
Java ES software is built for 32–bits Windows systems. However, it can be installed on both 32–bit and 64–bit Windows systems.
The installation with the Java ES 5 installer takes place on the following default location for 32–bit programs.
Table 1–7 Default Installation Paths|
Default location |
Short equivalent |
|
|---|---|---|
|
32–bit |
C:\Program Files\Sun\... |
c:\progra~1\sun |
|
64–bit |
C:\Program Files (x86)\Sun\... |
c:\progra~2\sun |
Short path formats are commonly used in logs.
In this guide, 32–bit long path format is used in definitions, examples and so on.
Java ES Component Dependencies
One 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.
Each of these factors is discussed briefly in the following sections.
Dependencies on Shared Components
Table 1–8 shows the dependencies of Release 5U1 product components on Java ES shared components. The abbreviations for product components in the table are taken from Table 1–1. The abbreviations for shared components are spelled out in Table 1–2. The hard upgrade dependencies for Release 5 to Release 5U1 upgrades are marked “H,” and soft upgrade dependencies are marked “S.”
Within the matrix of the following table
Table 1–8 Shared Component Dependencies of Release 5U1 Product Components|
Shared Component |
AM |
AS |
DPS |
DS |
DS Console |
HADB |
JAVADB |
MQ |
MC |
PS |
PSRA |
SR |
WPS |
WS |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
ANT |
S |
S |
H |
H |
H | |||||||||
|
ACL |
S |
H | ||||||||||||
|
BDB |
S | |||||||||||||
|
C AC |
H |
S |
H |
H |
H |
S | ||||||||
|
FIS | ||||||||||||||
|
ICU |
S |
H |
H |
S |
S |
S |
||||||||
|
IM-SDK |
S | |||||||||||||
|
Java SE |
S |
S |
H |
H |
H |
S |
H |
S |
S |
H |
S |
H |
S |
S |
|
JAF |
S |
S |
S |
S |
H | |||||||||
|
JATO |
S |
S |
S |
S | ||||||||||
|
JavaHelpTM |
S |
S |
S |
S |
S |
|||||||||
|
JavaMailTM |
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 |
|||||||
|
JSS |
S |
S |
S |
S |
S |
|||||||||
|
JSTL | ||||||||||||||
|
KTSE |
S |
S |
S |
|||||||||||
|
LDAP C SDK |
H |
H |
H |
S |
S |
|||||||||
|
LDAP J SDK |
S | |||||||||||||
|
MA Core |
S | |||||||||||||
|
MFWK |
H |
H |
H | |||||||||||
|
NSPR |
S |
S |
H |
H |
H |
S |
S |
S |
S |
H |
||||
|
NSS |
S |
S |
H |
H |
H |
S |
S |
S |
S |
H |
||||
|
SAAJ |
S |
S |
S |
S |
H | |||||||||
|
SASL |
H |
S |
S |
|||||||||||
|
SJWC |
S |
S |
H |
H | ||||||||||
|
WSCL |
S |
S |
H |
S |
||||||||||
|
XWSS |
H |
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 components are discussed in the Java Enterprise System 5 Technical Overview. If a Release 5U1 product component has a hard upgrade dependency on another product component, the dependent component can 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 in order for another component to be configured. For example, a Directory Server user 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 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 5U1 product components, the second column shows other Java ES components upon which a Release 5U1 component has a dependency relationship, the third column provides the Java ES release versions that support the Release 5U1 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 or whether other third-party products can support the dependency.
If a product component you are upgrading to Release 5U1 has a dependency on Release 5U1 of a supporting component, then the supporting component represents a hard upgrade dependency: the supporting component must also be upgraded to Release 5U1.
Table 1–9 Java ES Product Component Dependencies
Upgrade Sequencing Guidelines
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.
The chapters in this guide are arranged according to the order in which components appear in the following listing.
Note –
Before applying Java ES 5 Update 1 patches, be sure that the following Java ES Windows Installer patch has been installed:
126910–02 [Revision number indicated for the Java ES Windows Installer patch is the minimum required for upgrade to Release 5U1. If newer revision becomes available, use the newer one.]
-
Shared Components ( Chapter 2, Upgrading Java ES Shared Components)
Shared components should be upgraded before the components which depend on them.
-
Directory Server (Chapter 3, 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 (Chapter 4, 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 (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 or Application Server, but if your architecture contains both, upgrade Web Server first, before upgrading Application Server.
-
Java DB (Chapter 6, Java DB)
Java DB must be upgraded before Application Server, which requires Java DB as a default database.
-
High Availability Session Store (Chapter 7, High Availability Session Store)
Upgrade is not supported for High Availability Session Store to Java ES 5 U1 (Release 5U1) on Windows.
-
Message Queue (Chapter 8, Message Queue)
Message Queue must be upgraded before Application Server, which requires Message Queue to be Java 2 Enterprise Edition (J2EE) compliant.
-
Application Server (Chapter 9, 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.
-
Service Registry (Chapter 10, Service Registry)
Service Registry can be upgraded any time after Application Server is upgraded because it depends upon Application Server for runtime container services.
-
Web Proxy Server (Chapter 11, Web Proxy Server)
Web Proxy Server can be upgraded any time, 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 5U1 component that can be upgraded from its previous non-Java ES release.
-
Access Manager (Chapter 12, Access Manager)
Upgrade is not supported for Access Manager to Java ES 5 U1 (Release 5U1) on Windows.
-
Monitoring Console (Chapter 13, Monitoring Console)
Monitoring Console has dependencies on a number of Java ES shared components (see Table 1–8), two of which are hard upgrade dependencies and need to be upgraded when you perform a maintenance upgrade of MFWK and SJWC.
-
Portal Server (Chapter 14, Portal Server)
Upgrade is not supported for Sun Java System Portal Server 7.1 to Java ES 5 U1 (Release 5U1) on Windows.
- © 2010, Oracle Corporation and/or its affiliates