Back to Main PageBack

Interoperability Between OpenFusion TAO releases

The following combinations of OpenFusion TAO & OpenFusion JacORB clients and servers have been explicitly tested for CORBA (GIOP) interoperability using PrismTech's ORB interoperability test framework.

A bug fix correction Bug ID - 00RE, implemented after OpenFusion TAO 1.3.1.3 release, raises interoperability issues with older versions of TAO. For more information, see the known issues.

OpenFusion TAO 1.5.1.1 Interoperability Tests

Client Server Configuration Interoperate Fully (Yes/No)
TAO 1.4.1.3 TAO 1.5.1.1 Solaris 8, Studio 8 (client) Studio 8 (server) Yes
TAO 1.5.1.1 TAO 1.4.1.3 Solaris 8, Studio 8 (client) Studio 8 (server) Yes
JacORB 2.1.3 TAO 1.5.1.1 Solaris 8, JDK 1.4 (client) Studio 8 (server) Yes
TAO 1.5.1.1 JacORB 2.1.3 Solaris 8, JDK 1.4 (client) Studio 8 (server) Yes
TAO 1.4.1.3 TAO 1.5.1.1 Windows NT, Visual C++ 6 Yes
TAO 1.5.1.1 TAO 1.4.1.3 Windows NT, Visual C++ 6 Yes
JacORB 2.1.3 TAO 1.5.1.1 Windows NT, JDK 1.4 (client), Visual C++ 6 (server) Yes
TAO 1.5.1.1 JacORB 2.1.3 Windows NT, JDK 1.4 (client) Visual C++ 6 (server) Yes

API Compatibility Between OpenFusion TAO Releases

PrismTech's policy is to ensure that there are no source code (API) incompatibilities between maintenance releases of OpenFusion TAO (e.g. TAO 1.5.1.0 to 1.5.1.1, these are releases where the last two digits of the release number may change).

The general Open Source community's policy which is also PrismTech's is to try and ensure source code backwards compatibility between major and minor ORB releases (e.g. TAO 1.4.x.y to TAO 1.5.x.y, these are releases where the first two digits of the release may change). At times this may not always be possible and where this is not the case PrismTech will provide a description of source code differences that may affect a user's application.

API Changes Between OpenFusion TAO 1.4 and OpenFusion TAO 1.5

The libraries libTAO_IORInterceptor, libTAO_ObjRefTemplate, libTAO_RTScheduler and libTAO_ValueType have been introduced to TAO 1.4. This has an impact on backward compatibility between TAO 1.3 and TAO 1.4.

Binary Compatibility Between OpenFusion TAO Releases

PrismTech's policy is to ensure that there are no binary incompatibilities between maintenance releases of OpenFusion TAO (e.g. TAO 1.5.1.0 to 1.5.1.1, these are releases where the last two digits of the release number may change) and that OpenFusion TAO shared libraries can be used interchangeably.

The test procedure involves buidling a test enviornment for a specific TAO release (e.g. TAO 1.5.1.0) and making sure that all of the regression tests for this release run successfully. Then for each subsequent TAO release (e.g TAO 1.5.1.1), relacing the older libraries in the test environment with the new libraries and re-running the tests without re-compilation of the test environment.

The general Open Source community's policy which is also PrismTech's is that it is not possible to ensure binary backwards compatibility between major and minor ORB releases (e.g. TAO 1.4.x.y to TAO 1.5.x.y; these are releases where the first two digits of the release may change). OpenFusion TAO libraries for major and minor release cannot be used interchangeably.

Binary Compatibility Between OpenFusion Standard, Inline and Debug TAO Releases

Arbitary switching between inline and debug or standard libraries is impossible. By definition, inlining will move functions and methods from a library into the code using the library. Therefore an application built non-inline will have dependencies on symbols that will not exist in a library built with inlining turned on. However, switching between standard and debug libraries can be undertaken successfully.


PrismTech TOP
Top