Best practices for backward compatibility of web services

Client applications should be able to interact with more than the current version of an interface. To ensure backward compatibility, observe the following guidelines:

• Determine the version of a web services description language (WSDL) interface when found in the registry.
• Provide business logic in the client application to accommodate different WSDLs.
• Incorporate if-then or case logic in the client for the different interface versions.

For example, for one version of a web service interface, the following schema tag in the WDSL indicates the version by the date 2009/02/15:

<schema targetNamespace="http://bmc.com/2009/02/15/myService.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema">

The following example shows a subsequent version of the service in which the WSDL changed:

<schema targetNamespace="http://example.com/2010/10/23/myService.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema">

To interact with both versions, a client application must determine the version from the dates embedded in the schema tag and take appropriate action.

If the first WSDL targetNamespace corresponds to interface versions 1.* of the service and the second one corresponds to interface versions 2.*, the client can compare the interface versions of services returned by the WSRegistryAPI findServices() or findService() calls and act accordingly.