Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 5 down vote favorite
1

We are working on an ASP.NET-based XML Web Service that we will be using for our own purposes as well as using it as part of a product offering for our integration partners.

Once it goes live we will be working on future phases of the project, and it occurs to me that the service's details may need to change over time (method signatures, object types, etc.) and since we are not the only ones using the web service, we will need to have some level of coordination with our partners.

What I'm not sure about is the best way to do this. When we update the web service in such a way that the WSDL would be changed, should we deploy it to a separate URL? Should we overload the existing methods? Have differently named methods? Ideally we would just have everything coordinated and cut over to the new methods but I don't see that happening.

Are there established good ways to handle this?

share|improve this question
You probably mean SOAP given that your talking about a WSDL file. Is that right? – Tom Squires Mar 9 '12 at 23:14
@TomSquires: Yes, although I usually see them referred to as "ASP.NET Web Services" so that's what I went with in the question. And I figure it's an issue to RESTful services as well? – Schnapple Mar 10 '12 at 0:30
Yeh, you can do REST, POX or OData using ASP.NET. – Tom Squires Mar 10 '12 at 9:51
What is your approach on supporting older, incompatible endpoints? If you need multiple versions available the problem is more complex than just rolling out new versions. – user1249 Mar 11 '12 at 9:45

1 Answer

up vote 2 down vote accepted 
When we update the web service in such a way that the WSDL would be changed, should we deploy it to a separate URL?

You could version the url (ie www.foobar.com/v2/service.svc) It would lead to a lot of sites though. What happens when you fix bugs? Would you still continue to support buggy versions? This is possible but not what I would advise.

Should we overload the existing methods? Have differently named methods?

No. In a few versions time you may end up with loads of redundant methods and your code will be a nightmare to maintain.

Are there established good ways to handle this?

I would recommend just having scheduled releases at set intervals (every quarter? ). That way your customers will have notice of the change, update their WSDL and run a few tests to check everything is still working. Its a matter of a few minutes every quarter so shouldn't be disruptive. The only changes that should break things is changing the signature of your contracts or methods. Adding new ones shouldn't disrupt old functionality or even need a wsdl update.

One other thing that may be worth looking into is using the IExtensibleDataObject interface to allow versioning in your datacontract (msdn here). Have a read through and see if its apropriate in your case.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.