Running WAS across versions

WAS, Version 5.1 is generally interoperable with WAS, 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.

  1. Apply required fixes.
    Fixes to apply for Version 3.5.x

    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


    Fixes to apply for Version 4.0.x

    Fix Version 4.0.1 Version 4.0.2 Version 4.0.3
    PQ60074 Apply Apply  
    PQ60336 Apply Apply  
    PQ63548 Apply Apply Apply

    All fixes are available on the IBM WAS Support page.

    Fix PQ51387... A naming client fix that supports Version 3.5.x naming client access to the Version 5.1 name server.

    Fix PQ60074... An Object Request Broker (ORB) fix that supports Version 5.1 naming client access to the Version 3.5.x or 4.0.x name server. A down-level client has no problem accessing a Version 5.1 name server, even using corbaloc.

    Fix PQ60335... An ORB fix to reconcile java.math.BigDecimal and other class differences in IBM Software Development Kits 122 and 131.

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

    Fix PQ60336... An ORB fix to reconcile java.math.BigDecimal and other class differences in IBM Software Development Kits 130 and 131.

    Note that This fix does not apply to IBM Software Development Kits on Solaris platforms.

    Fix PQ63548... A fix to correct problems that might occur when passing embedded valueTypes between WAS 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.

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

    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 Version 3.5.x or 4.0.x client access to Version 5.1 enterprise beans. This issue is new, introduced by Version 5.1. There are several ways to make it work, such as...

    • Updating the namebindings.xml file if you do not use the Version 5.1 migration tools, but have installed Version 3.5.x or 4.0.x applications on Version 5.1. To allow Version 3.5.x or 4.0.x client access to the applications, add additional information to the bind information in the Version 5.1 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 that Applications that you migrate to Version 5.1 during installation, or that you migrate using the WASPreUpgrade and WASPostUpgrade migration tools, already have this update.

    • Calling Version 5.1 enterprise beans directly using the naming path that includes the server on which the enterprise beans are running, such as cell/node/server/some/ejb/name, for example.

    • Using the Version 4.0.x client java:/comp location to find Version 5.1 enterprise beans. (You cannot use the command from a Version 3.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.1 no longer provides 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 appservers.

    All clients at Version: Server at Version: Supported interoperability
    3.5.6 5.1 Yes
    4.02, 4.03 5.1 Yes
    5.1 3.5.x No
    5.1 4.02, 4.03 Yes

    Guideline 5... Be aware of administrative console limitations.

    You cannot use the administrative interfaces for Version 5.1 to administer a Version 3.5.x or 4.0.x administrative server. Likewise, you cannot use a Version 3.5.x or Version 4.0.x administrative console to administer a Version 5.1 environment. If you use the administrative console on a remote machine to administer Version 3.5.x or 4.0.x WAS domains, migrating any of the nodes or domains to Version 5.1 renders the remote administration console ineffective for administering any Version 5.1 environment.

    Guideline 6... Use SSL 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.

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.

 

See Also

Configuring and viewing name space bindings
Container interoperability
EJB binding settings
Installation: Resources for learning