GT Backwards Compatibility Approach 2

From Globus

This approach will enable partial backward compatbility (BCP2).

A mechanism for supporting both the old and new interfaces, such as a multiple-version service deployment strategy, should be employed to achieve service backwards compatibility with old clients. New clients will not be backwards compatible with old services. The idea here is to allow old installations to use the new services until they are ready to upgrade to the latest software.

This approach may require significant changes to the existing implementation, or a brand new implementation to accommodate the multiple versions of the services that are deployed. There may be considerable work that needs to be done on dependent components if the changes are due to compliance with new specifications or the use of updated inherited portTypes. This approach is not so much backwards compatibility, as it is continuing to deploy the old services in the same container as the new services.

Holding off on some functionality or specifying additions as extensions (such as in approach 1) should be considered, especially if major changes are coming in the future. If this is not acceptable, it should be debated whether backwards compatibility is truly worth it. It might be better to have sites simply deploy multiple versions of the service.

Assuming this approach is adopted, sites still needing to interact with old services should reconsider upgrading or continue to install the old clients in an alternate location. The documentation should make it clear that backwards compatibility between new clients and old services is non-existent.

Go to the GT backward compatibility page.