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.
Steps for this task
- 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 |
PQ88973 |
|
|
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 |
PQ88973 |
Apply |
Apply |
Apply |
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.
- Interim fix PQ88973
- An interim fix to upgrade the Software Development Kit (SDK) used by the
Version 5.0.x client. The evolution of a number of core classes causes interoperability
errors between a WebSphere Application Server Version 5.0.x client and a Version
6.0.x server.
You might see the following message when running an interoperability
scenario between a WebSphere Application Server Version 5.0.x client and a
WebSphere Application Server Version 6.0.x server:
java.rmi.MarshalException:
CORBA MARSHAL 0x4942f89a No;
nested exception is: org.omg.CORBA.MARSHAL:
Unable to read value from underlying bridge :
Invalid start_value valuetag: c
minor code: 4942F89A
completed: No
A number of core classes evolved between SDK 1.3.x
and SDK 1.4.x. You can experience problems interoperating with WebSphere Application
Server Version 6.0.x, which uses SDK 1.4.x.
You should upgrade SDK 1.3.1
to a newer service release (SR). The SDK Service Release updates are available
at the following IBM support sites: V5.0.2 Cumulative Fix for SDKs.
- 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:
- 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.
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.