Why and when to perform this task
WebSphere Application Server Version 5.1 is generally interoperable with WebSphere Application Server Versions 3.5.x, 4.0.x, and 5.0.x. However, there are specific requirements to address for each version. Make the following changes to support interoperability between versions.Steps for this task
Interim fix | Version 3.5.3 | Version 3.5.4 | Version 3.5.5 | Version 3.5.6 |
---|---|---|---|---|
PQ51387 | Apply | Apply | ||
PQ60074 | Apply | Apply | Apply | Apply |
PQ60335 | Apply | |||
PQ63548 | Apply | Apply | Apply | Apply |
Interim fix | Version 4.0.1 | Version 4.0.2 | Version 4.0.3 |
---|---|---|---|
PQ60074 | Apply | Apply | |
PQ60336 | Apply | Apply | |
PQ63548 | Apply | Apply | Apply |
Interim fix | Version 5.0.0 | Version 5.0.1 | Version 5.0.2 |
---|---|---|---|
PQ81989 | Apply | Apply | Apply |
All fixes are available on the Support site for WebSphere Application Server products at the http://www.ibm.com/software/webservers/appserv/was/support/ IBM Web address. A link to the Support site for WebSphere Application Server products is at the bottom of each information center topic. Scroll to the bottom a page to see the link.
This fix does not apply to IBM Software Development Kits on the Solaris Operating Environment.
Note: This fix does not apply to IBM Software Development Kits on Solaris platforms.
The best solution is to upgrade all your installations to the latest release and PTF levels, such as Versions 3.5.7 or 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 in spite of the fix, re-export existing IORs.
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 5.1 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 Software Development Kit (SDK) 1.3.x and SDK 1.4.x. You can experience problems interoperating with WebSphere Application Server, Version 5.1, which is the first WebSphere Application Server release to use SDK 1.4.x.
The recommended response is to upgrade the 5.0.x SDK 1.3.1 to a newer Service Release (SR). The SDK Service Release update is available at the whttp://www.ibm.com/support/docview.wss?uid=swg24006169 IBM Web address.
Guideline | Version 3.5.x | Version 4.0.x |
---|---|---|
1 | Apply | |
2 | Apply | Apply |
3 | Apply | |
4 | Apply | |
5 | Apply | Apply |
6 | Apply | Apply |
7 | Apply | Apply |
Note: Applications that you migrate to V5.0.x or V5.1.x during installation, or that you migrate 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.
Prior to the EJB 1.1 Specification, the JNDI location of the UserTransaction interface was not specified. Earlier versions up to and including Version 3.5.x do not use the EJB 1.1 Specification. They bind the UserTransaction interface to a JNDI location of jta/usertransaction.
Version 4, and later releases, bind the UserTransaction interface at the location defined by the EJB 1.1 Specification, which is java:comp/UserTransaction.
Version 5.0.x and Version 5.1.x no longer provide the earlier jta/usertransaction binding within Web and EJB containers to applications at a J2EE specification level of 1.3 or later, to enforce use of the newer UserTransaction interface. For example, EJB 2.0 applications can use only the java:comp/UserTransaction location.
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. The following table lists supported combinations of clients calling WLM-enabled enterprise beans on remote application servers.
All clients at Version: | Server at Version: | Supported interoperability |
---|---|---|
3.5.6 | 5.0.x, 5.1.x | Yes |
4.02, 4.03 | 5.0.x, 5.1.x | Yes |
5.0.x, 5.1.x | 5.0.x, 5.1.x | Yes |
5.0.x, 5.1.x | 3.5.x | No |
5.0.x, 5.1.x | 4.02, 4.03 | Yes |
You cannot use the administrative interfaces for V5.0.x or V5.1.x to administer a V3.5.x or V4.0.x administrative server. Likewise, you cannot use a Version 3.5.x or Version 4.0.x administrative console to administer a V5.0.x or V5.1.x environment. If you use the administrative console on a remote machine to administer V3.5.x or V4.0.x WebSphere Application Server domains, migrating any of the nodes or domains to V5.0.x or V5.1.x renders the remote administration console ineffective for administering any V5.0.x or V5.1.x environment.
You might see an error message similar to the following example when running an interoperability scenario between a WebSphere Application Server V3.5.x or V4.0.x client and a Version 5.1 Application Server:
java.rmi.MarshalException: CORBA MARSHAL 0 No; nested exception is: org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Custom marshaling of RMI:java.lang.Throwable: F8678B4F4D2EB705:D5C635273977B8CB not compatible with local class (local class not custom marshal capable) minor code : 0 completed: No
The exception is provoked by the evolution of the class you are trying to marshal. For example, the readObject() and writeObject() methods are inconsistent at the sender and the receiver.
The problem is provoked by an enterprise bean CreateException exception, as a result of its inheritance from the Throwable object, which evolves between Software Development Kit (SDK) 1.3.1 and SDK 1.4.0.
A number of core classes evolve between SDK 1.3.x and SDK 1.4.x. Therefore, you see the problems when you interoperate with WebSphere Application Server, Version 5.1, which is the first release to use SDK 1.4.x.
Migrate WebSphere Application Server, Version 3.5.x to Version 4.0.0 and upgrade to WebSphere Application Server, Version 4.0.7 to solve the problem.
Or upgrade WebSphere Application Server, Version 4.0.x to Version 4.0.7 or later to solve the problem.
What to do next
See Federating multiple Version 5 installation instances for information about mixed version cells, where a Version 5.1 deployment manager cell can include Version 5.0.x base nodes.
This information is dynamic and might be augmented by information in technical articles that are available on the IBM DeveloperWorks Web site at the http://www7b.software.ibm.com/wsdd/ IBM Web address. Check the site for the latest information.
Return to Planning to install an e-business network.