Interoperating

 

Overview

WebSphere Application Server V6 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, IBM recommends that you 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

  1. Apply required interim fixes.

    Table 1. Interim fixes to apply to V4.0.x
    Interim fix V4.0.1 V4.0.2 V4.0.3 V4.0.5 V4.0.6 V4.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 V5.0.x
    Interim fix V5.0.0 V5.0.1 V5.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 V5.1.x
    Interim fix V5.1.0 V5.1.1
    PQ84384 Apply (or move to 5.1.0.4 or higher)  

    All fixes are available on the Support site for WAS products. There is a link to the Support site for WAS products at the bottom of each information center topic. Scroll all the way to the bottom of each page to see the link.

    Interim fix PQ60074

    An Object Request Broker (ORB) fix that supports V6 naming client access to the V4.0.x name server. A down-level client has no problem accessing a V6 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 WAS 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 in spite of the fix, re-export existing IORs.

    Interim fixes PQ88648 (V4), PQ89426 (V5.0.2), PQ84384(V5.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 V5.0.x client. The evolution of a number of core classes causes interoperability errors between a WebSphere Application Server, V5.0.x client and a V6 server.

    You might see the following message when running an interoperability scenario between a WebSphere Application Server, V5.0.x client and a WebSphere Application Server, V6 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. We can experience problems interoperating with WebSphere Application Server, V6, which uses SDK 1.4.x.

    The recommended response is to upgrade SDK 1.3.1 to a newer Service Release (SR). The SDK Service Release updates are available at the following IBM support sites:

  2. Follow the required guidelines for V4.0.x and V5.0.2.

    Table 1. Guidelines to apply for V5.x and Version 4.0.x
    Guideline V5.x V4.0.x
    1 Apply (V5.0.2 only) Apply
    2   Apply
    3   Apply
    4   Apply
    5   Apply
    6 Apply Apply

    Guideline 1:

    Set the following JVM properties (for more information, see Interoperating transactionally between application servers) 

    com.ibm.ejs.jts.jts.ControlSet.nativeOnly=false


    com.ibm.ejs.jts.jts.ControlSet.interoperabilityOnly=true

    Always apply this guideline to V4.0.x. For V5.0.2, apply this guideline in addition to applying interim fixes (or moving to V5.0.2.8).

    Guideline 2:

    Make required naming changes to support V4.0.x client access to V6 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 migration tools, but have installed V4.0.x applications on Version 6. To allow V4.0.x client access to the applications, add additional information to the bind information in the V6 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 V6 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 V6 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 V4.0.x client java:/comp location to find Version 6 enterprise beans.

    Guideline 3:

    Be aware of administrative console limitations.

    We cannot use the administrative interfaces for V6 to administer a V4.0.x administrative server. Likewise, one cannot use a V4.0.x administrative console to administer a V6 environment. If you use the administrative console on a remote machine to administer V4.0.x WAS domains, migrating any of the nodes or domains to V6 renders the remote administration console ineffective for administering any V6 environment.

    Guideline 4:

    Use Secure Sockets Layer V3 (SSL v3) for secure connections when interoperating . We cannot use CSIv2 (CSIv2) for interoperability, because V4.0.x does not support CSIv2.

    Guideline 5:

    (This guideline applies only to V4.0.1.) 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.

    Guideline 6:

    Be aware of the level of WAS 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 V6, should not be deployed to a cluster including both V5.1 and V6 servers.

 

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.

 

Related Tasks


Configuring and viewing name space bindings

 

See Also


Container interoperability
EJB binding settings
JNDI interoperability considerations