Running WebSphere Application Server across versions

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

  1. Apply required interim fixes.

    Interim fixes to apply to Version 3.5.x

    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 fixes to apply to Version 4.0.x

    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 fixes to apply to Version 5.0.x client

    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.

    Interim fix PQ51387
    A naming client fix that supports Version 3.5.x naming client access to the V5.0.x or V5.1.x name server.
    Interim fix PQ60074
    An Object Request Broker (ORB) fix that supports V5.0.x or V5.1.x naming client access to the Version 3.5.x or 4.0.x name server. A down-level client has no problem accessing a V5.0.x or V5.1.x name server, even when using corbaloc.
    Interim fix PQ60335
    An ORB fix to reconcile java.math.BigDecimal and other class differences in IBM Software Development Kits 122 and 131.

    This fix does not apply to IBM Software Development Kits on the Solaris Operating Environment.

    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 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.

    Interim fix PQ81989
    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 5.1 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 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.

  2. Follow the required guidelines.

    Guidelines to apply for Version 3.5.x and Version 4.0.x

    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



    Guideline 1
    Use the context of the lowest common denominator when interoperating at the naming level. For example, always use the 3.5.x context com.ibm.ejs.ns.jndi.CNInitialContextFactory when a client or server is at 3.5.x. For later versions, use the current com.ibm.websphere.naming.WsnInitialContextFactory context.
    Guideline 2
    Make required naming changes to support V3.5.x or V4.0.x client access to V5.0.x or V5.1.x enterprise beans. This issue is new, introduced by V5. There are several ways to make it work, such as:
    • Updating the namebindings.xml file if you do not use the V5.0.x or V5.1.x migration tools, but have installed V3.5.x or V4.0.x applications on V5.0.x or V5.1.x. To allow V3.5.x or V4.0.x client access to the applications, add additional information to the bind information in the V5.0.x or V5.1.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 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.

    • Calling V5.0.x or V5.1.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 V5.0.x or V5.1.x enterprise beans. (You cannot use the command from a V3.5.x client.)
    Guideline 3
    Ensure that programs performing a JNDI lookup of the UserTransaction interface, use an InitialContext that resolves to a local implementation of the interface. Also ensure that such programs use a JNDI location appropriate for the enterprise bean version.

    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.

    Guideline 4
    Be aware of limitations when calling WorkLoad Management (WLM)-enabled enterprise beans.

    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



    Guideline 5
    Be aware of administrative console limitations.

    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.

    Guideline 6
    Use Secure Sockets Layer Version 3 (SSL v3) when interoperating with Version 3.5.x for secure connections. You cannot use Common Secure Interoperability Version 2 (CSIv2) for interoperability, because Versions 3.5.x and 4.0.x do not support CSIv2.
    Guideline 7
    The evolution of a number of core classes causes interoperability errors between a V3.5.x or V4.0.x WebSphere Application Server client and a Version 5.1 Application Server.

    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.


Related tasks
Configuring and viewing name space bindings
Related reference
Container interoperability
EJB binding settings
JNDI interoperability considerations
Installation: Resources for learning



Searchable topic ID:   tins_xver
Last updated: Jun 21, 2007 4:55:42 PM CDT    WebSphere Application Server Network Deployment, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tins_xver.html

Library | Support | Terms of Use | Feedback