Partager via

[Web] Service Versioning Guidance

  • Article

Oh man, I have waited years to be able to post this blog entry. I am finally in a position to release real pragmatic guidance on how to version your services based on your particular scenario. Just last week we kicked off a project that is part of a much larger effort (no, I haven't blogged about the big project yet) that addresses versioning services. If you know me or have followed my blog, you'll know that I'm pretty passionate about this problem. No, I don't have all the answers just yet, but at least I have more time, resources and money (WooHoo!) to throw at the problem :)

The first thing we're doing is putting together a rough positioning paper on what we think the problem space looks like. It also defines all of the areas in a solution that can be impacted by a (good or bad) versioning strategy. Lastly, we're going to define some scenarios that break this space up. I've thought for quite some time that the only way to provide comprehensive versioning guidance is to break it up into scenarios and tackle each one ... divide and conquer!

The whole goal of a versioning strategy is to make life less difficult for certain people. These are some of the most prominant people involved:

  • The developer of the client
  • The operations (management) team
  • The deployment team
  • The developer of the service

Naturally, we would want it to make life easier for everyone, but the way I see it, if we have to add a little complexity for the service developers to make life easier for everyone else ... so be it. They're supposed to be smart people, right :) I do feel pretty strongly that the client should have to do as little as necessary to support the versioning of the service. Fortunately, life might already be okay for some of these people ... it depends on the scenarios.

The way I see these scenarios breaking down at the most fundamental level is based on the relationship between the service and its consumers. Known consumers mean the service knows about the consumers. These consumers can be broken down further into the ones under control by operations and those that aren't. In other words, if the IT department decides to version a service, are they in a position to push down new consumers (through SMS, ClickOnce or some other approach). The IT department knows about the not controlled group - they just don't have a way of deploying new versions of them. They might, however, have a means in place to contact them, or send them notifications. The unknown consumers are like the lost cause and while this may sound hopeless, in my experience and research, this is a very rare scenario outside of playground or testing Web services like xmethods.com. We're considering making this out of scope for the guidance. Let me know if you don't want me to do this - and why.

The vertical boxes may exist for known and unknown consumers. Validation means there is a requirement to perform XML Schema validation on the messages to and/or from the service, and extensibility means the message must support extensions. This different (but related) to versioning. I'm calling these things out because the guidance may change when these requirements exist.

Message format is referring to SOAP, binary, or some other format the message will take while on the wire. In all honesty, I'm not yet sure if this is going to impact the guidance or not ... so I'll include it until I can dismiss it. Because of course the guidance should be appropriate for all services ... not just Web services. And lastely, there is a good possibility the guidance will differ when versioning old services (that were deployed without a versioning strategy) versus new services that have planned for evolution.

Okay, that's enough for now. If you're interested in this stuff and have the time to review guidance, let me know and we'll see what we can do about involving you in this project. I'm really interested those of you have have real challenges you're trying to address - I'm doing this for you - so drop me a note. I'm posting this to get feedback, so if you have thoughts on this stuff, leave a comment.

Comments

  • Anonymous
    January 31, 2006
    I agree that it's reasonable to put more work on the service developer and less on the other participants. I'd be interested in reviewing guidance in this area, as it's something we're facing in several directions at the moment.
  • Anonymous
    January 31, 2006
    Hey Patrick. I'll definitely get you involved. I think I still have your card from when we saw each other last month.
  • Anonymous
    February 08, 2006
    This is something we where waiting for.

    I think that there must be something in about the topic "unknown consumers", something like how to send notifications is it advisable to put something like a notification tag in the header to arrange this or…  just brainstorming ;-)
    Is there a gotdotnet site of this topic where I can sign in just like the service security site? or is a post to your blog enough?
  • Anonymous
    February 22, 2006
    Don, Looks interesting. Im working on a Biztalk based integration project and within the enterprise we have providers and consumers. So we know the consumers. However when we publish the 'provider' services and they wire up orchestrations and other consumer clients, changes from our side will break their deployment and cause tons of errors unless they undeploy, change and re-deploy the consumers.The changes can be minimised but not entirely avoided and it would be good to know how to reduce the pain for both sides. In time, the business services will be offered to partners outside the firewall so we need to have a well thought out versioning story.

    Thanks
    benjy
  • Anonymous
    February 27, 2006
    Our organization has been versioning services (and related assets) based on a strategy , outlined a few years back, in a set of MSDN postings by Scott Seely {http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service08202002.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service10152002.asp}.
    Do you agree with the best practices that Scott has laid down? If so, do you intend to augment/complement the guidance espoused by him? Or are you looking to produce direction that is orthogonal to his thinking?

    Cheers,
    Tom
  • Anonymous
    May 07, 2006
    Hi Don. I came accross your blogcasts about the Service Factory the other day. Brilliant. We are tackling quite a large SOA project at the moment and service versioning is starting to loom large on the horizon, so I was particularly excited to find that it was on the list of things you guys were looking to tackle. Hence I would be really interested to see any you have so far as we're due to deliver later this year!

    P.S. We have one of your colleages, Marc Mercuri, coming in to talk to us this month to have a look at our architecture and the direction we're headed in. I understand he's a WCF man - does he have any involvement with you guys?
  • Anonymous
    May 12, 2006
    I would be interested in reviewing guidance in this area, as it's something we're facing in several directions at the moment
  • Anonymous
    May 12, 2006
    I would be interested to participate also in this area. Versioning is something we're facing at the moment
  • Anonymous
    June 03, 2006
    I see this post dates back to January so I don't know if you're still looking for people that would be willing to provide input but, if you are, I would be very interested in getting involved.  I work for a company that is 18 months into a service-oriented delivery strategy and versioning is an area where we need to mature a great deal.
  • Anonymous
    July 26, 2006
    I think one of the most important factor when determining the versioning scenario is to care about the nature of the change. Is the interface changing or not? Is the change backward compatible or not?
    Based on that, the next version and the service development & lifecycle process is different.
    I have been blogging also about this stuff , check it out http://blogs.ittoolbox.com/eai/applications/archives/soa-change-management-part-1-6451
    Robin
  • Anonymous
    September 29, 2006
    Is the positioning paper released yet? I haven't come across guidance around versioning in WSSF. We are doing a large web service development project and this is a key area for us. I will be interested in participating in the work.
  • Anonymous
    October 19, 2006
    Alright, that's it! For some reason, this post is a favorite with the trackback spammers. So I'm going to close comments on this entry now. I'm still very interested in your thoughts (unless they have to do with perscription drugs and online casinos). Feel free to send them to me at dons@microsoft.com. Thanks.