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