There has been a lot written and discussed about how to do Service versioning.
On LinkedIn there is a nice discussion about the WSDL versioning (read here). Also on InfoQ there is a nice article.
I like the strategy in which a minor and major version is used. A minor change is backwards compatible and only updates the documentation element within the WSDL. A major change, also changes the namespace (http://.../v2).
The following structure within the OSB can help to implement this strategy.
The advantages of this structure are:
* The different versions are nicely seperated and can be governed and maintained seperatly. Instead of having only one proxy for all versions and doing some content based routing.
* The two versionings can live together and in case the old version is deprecated the proxy can be deleted. This way "old" consumers do not have to migrate in case a major update is published, so they have the time to plan it.
On LinkedIn there is a nice discussion about the WSDL versioning (read here). Also on InfoQ there is a nice article.
I like the strategy in which a minor and major version is used. A minor change is backwards compatible and only updates the documentation element within the WSDL. A major change, also changes the namespace (http://.../v2).
The following structure within the OSB can help to implement this strategy.
The advantages of this structure are:
* The different versions are nicely seperated and can be governed and maintained seperatly. Instead of having only one proxy for all versions and doing some content based routing.
* The two versionings can live together and in case the old version is deprecated the proxy can be deleted. This way "old" consumers do not have to migrate in case a major update is published, so they have the time to plan it.
Reacties
Een reactie posten