Skip to ContentSun and Oracle Channel Sun How to Buy Log In

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

内に含ま

Java Enterprise System 5 Update 1

その他のドキュメント

サポートリソース

PDF 文書ファイルをダウンロードする (1108 KB)

Chapter 1 Planning for Upgrades

This chapter provides information used for planning the upgrade of Sun Java^TM 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


Product Component	Abbreviation	Version	Type
Access Manager	AM	7.1 [This is the same version delivered with Java ES 5 and has not been updated at the time of the release of Java ES 5 Update 1.]	System service component
Application Server	AS	8.2 EE Patch 2	System service component
Directory Proxy Server	DPS	6.2	Service quality: access component
Directory Server	DS	6.2	System service component
High Availability Session Store	HADB	4.4.3	Service quality: availability component
Java DB	JavaDB	10.2.2.1	System Service Component
Message Queue	MQ	3.7 UR2	System service component
Monitoring Console	MC	1.0 Update 1	Service quality: administrative component
Portal Server	PS	7.1	System service component
Portal Server Secure Remote Access	PSRA	7.1	Service quality: access component
Service Registry	SR	3.1 Update 1	System service component
Web Proxy Server	WPS	4.0.5	Service quality: access component
Web Server	WS	7.0 Update 1	System service component

Release 5U1 Shared Components

Release 5U1 shared components are listed in the following table:

Table 1–2 Release 5U1 Shared Components


Shared Component	Version	Abbreviation
Apache Common Logging	1.0.3 [This is the same version delivered with Java ES 5 and has not been updated at the time of the release of Java ES 5 Update 1.]	ACL
Jakarta ANT Java/XML-based build tool	1.6.5	ANT
Berkeley Database	4.2.52	BDB
Common Agent Container	1.1 and 2.1	CAC
FastInfoSet	1.0.2	FIS
International Components for Unicode	3.2 Patch 1	ICU
Instant Messenger SDK	6.2.9	IM-SDK
Java Platform, Standard Edition	5.0 Update 12	Java SE
JavaBeans™ Activation Framework	1.0.3	JAF
Java Studio Web Application Framework	2.1.5	JATO
JavaHelp™ runtime	2.0	JHELP
JavaMail ™ runtime	1.3.2	JMAIL
Java Architecture for XML Binding runtime	2.0.3	JAXB
Java API for XML Processing	1.3.1	JAXP
Java API for XML Registries runtime	1.0.8	JAXR
Java APIs for XML-based Remote Procedure Call runtime	1.1.3_01	JAX-RPC
Java API for Web Services runtime	2.0	JAXWS
Java Dynamic Management™ Kit runtime	5.1_03	JDMK
Java Security Services (Network Security Services for Java)	4.2.5 and 3.1.11	JSS and JSS3
JavaServerPages^TM Standard Tag Library	1.0.6	JSTL
KT Search Engine	1.3.4	KTSE
LDAP C SDK	6.0	LDAP C SDK
LDAP Java SDK	4.19	LDAP J SDK
Mobile Access Core	6.2	MA Core
Netscape Portable Runtime	4.6.7	NSPR
Network Security Services	3.11.7	NSS
SOAP Runtime with Attachments API for Java	1.3	SAAJ
Simple Authentication and Security Layer	2.19	SASL
Sun Java Monitoring Framework	2.0 Update 1	MFWK
Sun Java Web Console	3.0.3	SJWC
Web services Common Library	2.0	WSCL
XML Web Services Security	2.0	XWSS

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

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:

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:

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.

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
JavaHelp^TM	S	S						S	S					S
JavaMail^TM	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


Product Components	Dependency [ For each product component, dependencies are listed in the order that they would normally be upgraded.]	Java ES Release	Nature of Dependency	Characteristics
Access Manager	Directory Server	4–5 & 5U1	Mandatory: Stores configuration data and enable lookup of user data
	Java 2 Enterprise Edition (J2EE^TM) web container:		Mandatory: Provides web container runtime services	Local only Also supported: -Weblogic [BEA Weblogic Server] -WebSphere [IBM WebSphere Application Server]
	Web Server	4–5 & 5U1
	Application Server	4–5 & 5U1
Access Manager SDK	Access Manager	4–5	Mandatory: Provides Access Manager services
	J2EE web container:		Mandatory: Provides web container runtime services	Local only Also supported: –Weblogic -WebSphere
	Application Server	4–5 & 5U1
	Web Server	4–5 & 5U1
Access Manager Distributed Authentication	Access Manager	4–5	Mandatory: Provides Access Manager services
	J2EE web container:		Mandatory: Provides web container runtime services	Local only Also supported: -Weblogic -WebSphere
	Application Server	4–5 & 5U1
	Web Server	4–5 & 5U1
Access Manager Session Failover	Access Manager	5	Mandatory: Provides Access Manager services
	J2EE web container:		Mandatory: Provides web container runtime services	Local only Also supported: -Weblogic -WebSphere
	Application Server	4–5 & 5U1
	Web Server	4–5 & 5U1
	Message Queue	4–5 & 5U1	Mandatory:Provides reliable asynchronous messaging
Application Server	Message Queue	5 & 5U1	Mandatory: Provides reliable asynchronous messaging	Local only
	High Availability Session Store	5	Mandatory: Stores session state needed to support failover between instances	Local only
	Java DB	5 & 5U1	Mandatory: Stores session state needed to support failover between instances	Local only
	Web Server	4–5 & 5U1	Optional: Provides load balancing between instances	Yes
Directory Proxy Server	Directory Server	4–5 & 5U1	Co-dependency: Results in improved security and performance for directory requests. Supplies data to Directory Proxy Server
Directory Server	Directory Proxy Server	4–5 & 5U1	Co-dependency: Results in improved security and performance for directory requests. Distributes load and caches data to Directory Server
High Availability Session Store (HADB)	None
Java DB	None
Message Queue	Directory Server	4–5 & 5U1	Optional: Stores administered objects and user data
	J2EE web container:		Optional: Supports HTTP transport between client and Message Queue broker
	Application Server	4–5 & 5U1
	Web Server	4–5 & 5U1
	Java DB	5 & 5U1	Optional: Stores persistent messages.	Local only
Monitoring Console	None
Portal Server	Directory Server	4–5 & 5U1	Mandatory: Stores and enables lookup of user profiles
	J2EE Web Container:		Mandatory: Provides web container runtime services	Local only
	Application Server	4–5 & 5U1
	Web Server	4–5 & 5U1
	Access Manager or Access Manager SDK	4–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
	Server Registry Client	5 & 5U1	Mandatory: Provides libraries needed for compilation
	Java DB	5 & 5U1	Optional: Provides support for several portlet applications
Portal Server Secure Remote Access Gateway	Portal Server	5	Mandatory: Supports Gateway functionality
	Access Manager or Access Manager SDK	4–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 & 5U1	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 & 5U1	Mandatory: Provides container runtime services	Local only
	Java DB	5 & 5U1	Mandatory: Provides default database for storing services and related meta data	Local only
	Service Registry Client	5U1	Mandatory: Provides required client libraries	Local only
Web Proxy Server	Directory Server	4–5 & 5U1	Optional: Provides LDAP-based authentication
Web Proxy Server	Web Server	4–5 & 5U1	Co-dependency: Results in improved security and performance for HTTP requests. Supplies data to Web Proxy Server	Also supported: -Weblogic –WebSphere
Web Server	Directory Server	4–5 & 5U1	Optional: Provides LDAP-based authentication
Web Server	Web Proxy Server	4–5 & 5U1	Co-dependency: Results in improved security and performance for HTTP requests. Distributes load and caches data from Web Server

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.