WebSphere Application Server - Express, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Interoperating

Why and when to perform this task

WebSphere Application Server Version 6 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.

Steps for this task

  1. 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.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. There is a link to the Support site for WebSphere Application Server 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 Version 4.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 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 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 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 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 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 6, 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 4. Guidelines to apply for Version 5.x and Version 4.0.x
    Guideline Version 5.x Version 4.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 Version 4.0.x client access to Version 6 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 Version 4.0.x applications on Version 6. To allow Version 4.0.x client access to the applications, add additional information to the bind information in the Version 6 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 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 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 enterprise beans.
    Guideline 3:
    Be aware of administrative console limitations.

    You cannot use the administrative interfaces for Version 6 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 environment. If you use the administrative console on a remote machine to administer Version 4.0.x WebSphere Application Server domains, migrating any of the nodes or domains to Version 6 renders the remote administration console ineffective for administering any Version 6 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:
    (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 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 V6, should not be deployed to a cluster including both V5.1 and V6 servers.
    Guideline 7:
    If you run related cross-domain, interoperating applications (for example, one server is in rtp.raleigh.ibm.com, the other is in cn.ibm.com), when installing WebSphere Application Server V6.0, you need to use fully-qualified hostnames (for example, use example9.rtp.raleigh.ibm.com instead of just example9).

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

Related reference
EJB binding settings
JNDI interoperability considerations

Task topic    

Terms of Use | Feedback

Last updated: Jun 8, 2005 12:45:23 PM EDT
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tins_xver.html

© Copyright IBM Corporation 2002, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)