Web Service Versioning

On my new project team here is a lot of discussion around supporting multiple versions of our applications (which are most likely going to be a collection of web services). This affects me as I'm responsible for deployment of these applications. This got me thinking, how does TFS do versioning for their web services? TFS 2008 supports Team Explorer 2005 and 2008 so they had to have the same discussion we're having now.

As it turns out, it looks like they support multiple versions within the TFS 2008 code base by simply organizing the versions in a folder hierarchy. It looks very well organized and something that would be easy to deploy! Let me explain what I see.

Underneath %Program Files%\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\Build I find both v1.0 and v2.0 folders. My assumption is that the TFS development team decided to put all new 2008 functionality in the v2.0 folder for each web service. In this example I just show "Build" but you can see similar things in "Services" as well. I'm guessing when the next release comes out, we'll see v3.0.

I'm the type of person who has really never created anything original. Well that's not 100% true as the book I'm writing is not simply copied from other fiction thriller writers. However, the fundamentals are based on the same story structure and writing format that most all novel writers use. I just simply follow the rules. Back to TFS though. I brought up the web services versioning I saw TFS use to our architects and from what it sounds like, they are going in a slightly different direction.

What we "plan" (plan is used loosely as they are constantly changing things) on doing is hosting each "version" under a separate IIS 7.0 site. Something like this I guess.

IIS
/AppPool1.0
    /WebServiceSite1.0
        /mycode
/AppPool2.0
    /WebServiceSite2.0
        /mycode

My understanding is, this will put each "version" in a separate worker process. The approach TFS took would not.

Personally I think the way TFS does web service versioning is better. That is, simply versioning the web services within a single deployment (i.e. site under IIS). But given we're selling/supporting different types of software (ours is hosted internally and we have full control over deploying it) I can see an argument for supporting multiple version as separate deployments under IIS.

Now this all comes with my standard caveat that I often misunderstand very technical details. I'm sure there is a number of white papers and studies done on web service versioning that trump any opinion I have. This is simply an observation of how I see TFS is doing some kind of versioning.