Pros and Cons of Web Services Versioning Strategies

Question

Update 20100224 I really don't need some lame definitions from some vendor website. What I am looking for is practical implementation and challenges faced in the daily IT/business cycle for people who actually implement this stuff.

More stuff follows:

No retirement strategy has been created/adopted: Obviously one needs to be created. I am interested in how you create this strategy and sell it to management. What are all of the costs/benefits you look at? Do you do a BE analysis on customer recoding requirements vs. Internal support requirements? Do you assign a $ value to internal support costs of ancient API's?

Production IT support implications: How have you worked with your production IT groups to deploy your strategy. What do they like and what makes them crazy?

Software: What do you software guys like to do, what does the business tell them to do and what do they actually do? What works best for them?

QA: How do QA like to handle testing. ex. If you have created a single service that handles multiple versions does QA do full regression for everything every time a change is made to one of the versions?

DBA's: How do your dba's deal with the common procs that are critical to the data logging for adding a field to an xml response? Do you have a single proc or do you do branch things and segment based on schema or other?

---

original note

I am collecting info on the pros and cons of different web services versioning strategies. The business has not yet determined a strategy for web service retirement, and my web services do change significantly due to product changes, customer requirement changes and our partner integration changes.

I am looking for a pros/cons for maintaining independent stand alone or multiple/integrated versions over time and how this affects the business including developer support/developer integration resources, production IT support, Software, QA & DBA's.

Any insight, experiences, resources or ideas are appreciated.

Answer 1

Web services in our application are just a front-end to the business logic.

New version of web service appears due to business logic change. When new version of web service is introduced it is placed under new url. For instance:

ver1 /websvc
ver2 /websvc2

There is special code between web service layer and business layer. This layer handles differences in the web services versions and passes a call to the latest business layer.

It is the problem of the special facade code (between web service and business logic) to know web service version differences.