3.6.2 Flexible Versioning Strategy

The selected versioning strategy is known in the literature as Flexible. Any incompatble change results in a new version of the service contract and the contract is designed to support backwards compatibility. Any change that breaks the existing contract results in a new version.

For XML Schema's and WSDLs versions are identified using a major and minor version in notation "major.minor". Conventions according to the compatibility guarantee:

• A minor version is expected to be backward compatible with other minor versions that are associated with a major version.
• A major version breaks backward compatibility.

The versioning strategy for SOAP services used by OHI Components applications can be characterized as follows:

• A compatible change leads to a minor change of the version number. The namespace(s) remain unchanged, hence supporting backward compatibility.
• An incompatible change leads to a major change of the version number.
• Major versions will be identified in XML namespaces of top-most XML schemas (and later WSDLs). As a result, a major change will require applications that use the schema or web service to be upgraded.

Version identification example:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:dt="http://healthinsurance.oracle.com/datatypes" xmlns="http://healthinsurance.oracle.com/fileimport/v1"
targetNamespace="http://healthinsurance.oracle.com/fileimport/v1" 
elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">

For a compatible change, only the version number will be affected whereas the namespace declarations remain unchanged:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:dt="http://healthinsurance.oracle.com/datatypes" xmlns="http://healthinsurance.oracle.com/fileimport/v1"
targetNamespace="http://healthinsurance.oracle.com/fileimport/v1" 
elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.1">

An incompatible change results in changes to both the version number as well as the version identifier in the namespaces:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:dt="http://healthinsurance.oracle.com/datatypes" xmlns="http://healthinsurance.oracle.com/fileimport/v2"
targetNamespace="http://healthinsurance.oracle.com/fileimport/v2" 
elementFormDefault="qualified" attributeFormDefault="unqualified" version="2.0">

Note that the DataTypes schema that holds re-usable simple and complex types, does not have a version identifier. The types in there are re-used often and existing types are expected to be stable. Given the amount of re-use in all OHI SOAP Services, it is not likely for types declared in DataTypes.xsd to be removed.