WebSphere Application Server Version 6.0.x is interoperable with
other WebSphere Application Server versions under certain conditions.
Before you begin
WebSphere Application
Server Version 6.0.x is generally interoperable with WebSphere Application
Server Versions 4.0.x and 5.x. However, there are specific requirements to
address for each version. In general, you should apply the latest fix level
to support interoperability. If this is not possible, then the following interim
fixes can be used to support your environment.
Procedure
- Apply required
interim fixes.
Table 1. Interim fixes to apply to Version 4.0.x
Interim fix |
Version 4.0.1 |
Version 4.0.2 |
Version 4.0.3 |
Version 4.0.5 |
Version 4.0.6 |
Version 4.0.7 |
PQ60074 |
Apply |
Apply |
|
|
|
|
PQ60336 |
Apply |
Apply |
|
|
|
|
PQ63548 |
Apply |
Apply |
Apply |
|
|
|
PQ88648 (which requires PQ88653) |
|
|
|
Apply |
Apply |
Apply |
Table 2. Interim fixes to apply to
Version 5.0.x
Interim fix |
Version 5.0 |
Version 5.0.1 |
Version 5.0.2 |
PQ89426 (which requires PQ88653) |
|
|
Apply (or move to 5.0.2.8) |
Table 3. Interim fixes to apply to
Version 5.1.x
Interim fix |
Version 5.1.0 |
Version 5.1.1 |
PQ84384 |
Apply (or move to 5.1.0.4 or higher) |
|
All fixes are available on the Support site for WebSphere Application Server products.
- Interim fix PQ60074
- An Object Request Broker (ORB) fix that supports Version 6.0.x naming
client access to the Version 4.0.x name server. A down-level client has no
problem accessing a Version 6.0.x name server, even when using corbaloc.
- Interim fix PQ60336
- An ORB fix to reconcile java.math.BigDecimal and
other class differences in IBM Software Development Kits 130 and 131.
Note: This fix does not apply to IBM Software Development Kits on Solaris
platforms.
- Interim fix PQ63548
- A fix to correct problems that might occur when passing embedded valueTypes
between WebSphere Application Server releases.
The best solution is to upgrade
all your installations to the latest release and PTF levels, such as Version
4.0.4, which do not require this fix. If this solution is not possible, apply
the fix to your version.
Symptoms include org.omg.CORBA.MARSHAL exceptions
when passing embedded valueTypes across the versions. Sometimes, other symptoms
might mask org.omg.CORBA.MARSHAL exceptions, which makes
them difficult to identify.
If symptoms reoccur despite the fix, re-export
existing IORs.
- Interim fixes PQ88648 (Version 4), PQ89426 (Version 5.0.2), PQ84384 (Version
5.1.0):
- The transaction service is changed so that when a transaction is marked
for rollbackOnly in a subordinate server, the superior server will be informed.
This will allow applications running in the superior server to detect this
status change.
- Follow the required
guidelines for Version 4.0.x and Version 5.0.2.
Table 4. Guidelines to apply for Version 5.x and Version
4.0.x
Guideline |
Version 5.x |
Version 4.0.x |
1 |
Apply (Version 5.0.2 only) |
Apply |
2 |
|
Apply |
3 |
|
Apply |
4 |
|
Apply |
5 |
|
Apply (Version 4.0.1 only) |
6 |
Apply |
Apply |
7 |
Apply |
Apply |
8 |
Apply |
|
- Guideline 1:
- Set the following JVM properties:
com.ibm.ejs.jts.jts.ControlSet.nativeOnly=false
com.ibm.ejs.jts.jts.ControlSet.interoperabilityOnly=true
Always apply this guideline to Version 4.0.x. For Version
5.0.2, apply this guideline in addition to applying interim fixes or moving
to Version 5.0.2.8.
- Guideline 2:
- Make required naming changes to support Version 4.0.x client access to
Version 6.0.x enterprise beans. There are several ways to make it work, such
as:
- Updating the namebindings.xml file if you do not
use the Version 6.0.x migration tools but have installed Version 4.0.x applications
on Version 6.0.x. To allow Version 4.0.x client access to the applications,
add additional information to the bind information in the Version 6.0.x namespace
to make the old JNDI names work. Add the information to the namebindings.xml configuration
file at the cell level using the administrative console.
Note: Applications
that you migrate to Version 6.0.x using the WASPreUpgrade and WASPostUpgrade migration
tools already have this update.
After
federating an application server node into a deployment manager cell, you
cannot use the migration tools. To use these tools again, remove the node
from the cell, use the tools, and add the node to the cell again.
- Calling Version 6.0.x enterprise beans directly using the naming path
that includes the server on which the enterprise beans are running, such as cell/node/server1/some/ejb/name for
example.
- Using the Version 4.0.x client java:/comp location
to find Version 6.0.x enterprise beans.
- Guideline 3:
- Be aware of administrative console limitations.
You cannot use the administrative
interfaces for Version 6.0.x to administer a Version 4.0.x administrative
server. Likewise, you cannot use a Version 4.0.x administrative console to
administer a Version 6.0.x environment. If you use the administrative console
on a remote machine to administer WebSphere Application Server Version 4.0.x
domains, migrating any of the nodes or domains to Version 6.0.x renders the
remote administration console ineffective for administering any Version 6.0.x
environment.
- Guideline 4:
- Use Secure Sockets Layer Version 3 (SSL v3) for secure connections when
interoperating. You cannot use Common Secure Interoperability Version 2 (CSIv2)
for interoperability because Version 4.0.x does not support CSIv2.
- Guideline 5 (Network Deployment product only):
- Be aware of limitations when calling workload management (WLM)-enabled
enterprise beans. This guideline applies only to Version 4.0.1.
Some clients
cannot call WLM-enabled enterprise beans on remote clusters when there is
a local WLM-enabled enterprise bean of the same name. If there is a cluster
local to the client with the same enterprise bean as the remote cluster that
the client is trying to call, the client ends up talking to the local cluster.
- Guideline 6:
- Be aware of the level of WebSphere Application Server in which each function
you use is supported. Applications that you intend to be interoperable must
only use function that is supported by all levels of WebSphere Application
Server in the cluster. For example, applications that use the commonj.timer.TimerManager
resource, which is new for Version 6.0, should not be deployed to a cluster
including both Version 5.1 and Version 6.0.x servers.
- Guideline 7:
- If you run related cross-domain interoperating applications (one server
is in rtp.raleigh.ibm.com and the other is in cn.ibm.com for example), you
need to use fully-qualified host names (host9.rtp.raleigh.ibm.com instead
of just host9 for example) when installing WebSphere Application Server Version
6.0.x.
- Guideline 8:
- If you want to interoperate Version 6.0.x with Version 5.0, you must be
at or above the Version 5.0.2.7 level. If you want to interoperate Version
6.0.x with Version 5.1, you must be at or above the Version 5.1.1.1 level.
Older levels of Version 5.0 and Version 5.1 do not support interoperability
with Version 6.0.x.
- Upgrade the Software Development Kit (SDK) used to one supported
by Version 6.0.x.
See Recommended fixes for WebSphere Application Server.
What to do next
This information is dynamic and might be
augmented by information in technical articles that are available on the IBM DeveloperWorks
WebSphere site. Check the site for the latest information.