Service Versioning in OSB

             I was looking at different ways in which we can version the OSB services for my customer. It is a dilemma for all when you get requests for OSB changes due to system standardization like change in the proxy URLS to meet new standards/new functionalities where signatures will change of the exposed services. This issue can arise in any enterprise because when you start of initially without properly architecting the SOA services, not laying down proper standards and guidelines and. Going forward, there will be huge increase in services and how to manage all these services and consumers of these services will be always painstaking. In this article I will put down some points on the service versioning that can be done in OSB.

Backward Compatible changes

The types of changes that are backwards compatible are:

1.       Adding  new XML schema types to WSDL document that doesn’t affect existing schema types

2.       Adding new operations to an existing/new port type in WSDL document. These are basically new functionalities so will not affect existing consumers.

Not Backward Compatible changes

1.       Altering/Removing an operation that is currently consumed.

2.       Modifying the structure/parameters of existing data types

Versioning

All the artifacts need to be versioned at

1.       Namespaces - Unique namespaces to define the new version, usually implemented by mentioning version number.

2.       Folder structure - Separate folders for storing artifacts and folder name mentioning version.

On a high level I am listing the available options

         

Option1 :

If the consumer need not be affected and the new service is backward compatible, then we can deprecate the version1.0 and move on to the new version by changing the proxy service

Option2 :

If the consumer need not be affected and if the new service is not backward compatible, then its always better to maintain different versions of proxy service and have new consumers consume the new Version. When the old consumer is ready to upgrade and move to new version we can deprecate the v1.0 and shutdown the proxy service.

Option3:

This is scenario where there are signature changes and new functionalities required by consumer can be provided only  by modifying the signature then the only option is to work together with consumers and get the new version out which will include changes at consumer as well as provider. Its always better to number the releases so that you can track the service versions and easily identify references to deprecated older versions

I prefer the Option 2 it’s more easy and clean and doesn’t affect existing consumers. Option1 and Option3 are quite similar except that in Option3 the consumer is affected due to the endpoint change and consumer is aware about the version of the Service it’s consuming.

References :-

http://www.infoq.com/articles/contract-versioning-comp2

http://www.ibm.com/developerworks/webservices/library/ws-version/

http://rogervdkimmenade.blogspot.com/2009/09/osb-10gr3-service-versioning.html