Interoperating

WebSphere Application Server Version 6.0.x is interoperable with other WebSphere Application Server versions under certain conditions.

Before you begin

WebSphere Application Server Version 6.0.x 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, you should 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 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
    Table 2. Interim fixes to apply to Version 5.0.x
    Interim fix Version 5.0 Version 5.0.1 Version 5.0.2
    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.

    Interim fix PQ60074
    An Object Request Broker (ORB) fix that supports Version 6.0.x naming client access to the Version 4.0.x name server. A down-level client has no problem accessing a Version 6.0.x 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 despite the fix, re-export existing IORs.

    Interim fixes PQ88648 (Version 4), PQ89426 (Version 5.0.2), PQ84384 (Version 5.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.
  2. Follow the required guidelines for Version 4.0.x and Version 5.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 (Version 5.0.2 only) Apply
    2   Apply
    3   Apply
    4   Apply
    5   Apply (Version 4.0.1 only)
    6 Apply Apply
    7 Apply Apply
    8 Apply  
    Guideline 1:
    Set the following JVM properties:
    com.ibm.ejs.jts.jts.ControlSet.nativeOnly=false
    com.ibm.ejs.jts.jts.ControlSet.interoperabilityOnly=true

    Always apply this guideline to Version 4.0.x. For Version 5.0.2, apply this guideline in addition to applying interim fixes or moving to Version 5.0.2.8.

    Guideline 2:
    Make required naming changes to support Version 4.0.x client access to Version 6.0.x 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.0.x migration tools but have installed Version 4.0.x applications on Version 6.0.x. To allow Version 4.0.x client access to the applications, add additional information to the bind information in the Version 6.0.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 Version 6.0.x using the WASPreUpgrade and WASPostUpgrade migration tools already have this update.
    • Calling Version 6.0.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 Version 6.0.x enterprise beans.
    Guideline 3:
    Be aware of administrative console limitations.

    You cannot use the administrative interfaces for Version 6.0.x 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.0.x environment. If you use the administrative console on a remote machine to administer WebSphere Application Server Version 4.0.x domains, migrating any of the nodes or domains to Version 6.0.x renders the remote administration console ineffective for administering any Version 6.0.x 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 (Network Deployment product only):
    Be aware of limitations when calling workload management (WLM)-enabled enterprise beans. This guideline applies only to Version 4.0.1.

    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 Version 6.0, should not be deployed to a cluster including both Version 5.1 and Version 6.0.x servers.
    Guideline 7:
    If you run related cross-domain interoperating applications (one server is in rtp.raleigh.ibm.com and the other is in cn.ibm.com for example), you need to use fully-qualified host names (host9.rtp.raleigh.ibm.com instead of just host9 for example) when installing WebSphere Application Server Version 6.0.x.
    Guideline 8:
    If you want to interoperate Version 6.0.x with Version 5.0, you must be at or above the Version 5.0.2.7 level. If you want to interoperate Version 6.0.x with Version 5.1, you must be at or above the Version 5.1.1.1 level. Older levels of Version 5.0 and Version 5.1 do not support interoperability with Version 6.0.x.
  3. Upgrade the Software Development Kit (SDK) used to one supported by Version 6.0.x.

    See Recommended fixes for WebSphere Application Server.

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.

Task topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 5:25:00 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-base-dist&topic=tins_xver
File name: tins_xver.html