microsoft.public.dotnet.framework.aspnet.webservices

Erik P. Vinther

9/8/2003 1:07:00 PM

Hi Adam,



On a "versioning strategic" level, I would say that once a web service has
been deployed, it is NEVER CHANGED. If the need for a changed signature
arises, in order to satisfy new requirements, you deploy the web service in
a new version. So, new clients can use the new version, and old client
continue on the old version. Naturally, one would implement the new version
by reusing as much of the old version as possible.



If you adopt this scheme of deploying the "same" web service in different
versions, you need to include s version id in the xml-namespace/URL. In the
article "Evolving an Interface"
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/...
html/service04032002.asp) , Scott Seely recommends that the version id
precedes the name of the web service:



<base URL>/<version id>/<web service name>



Seely prefers the date to a version number as a version id, due to the fact,
that it then is quite obvious when the web service was made available.
However, it does leave us with the problem that the namespace are determined
quite early in the process, and it does happen that releases are delayed for
various reasons, so we prefer the version number as version id.



No matter which version id you use, it does produces the problem, that if
you want the same you physical directory structure on the web server , you
end up with a directory named "1.0" that contain all your version 1 web
services. The way we have solved this is to actually reverse the name and
version id in the physical directory structure, and the create a web alias
to direct a web service call to the right physical build, i.e. "<base
URL>/1.0/MyService" to "<web home>\MyService\1.0" on the web server.



Thanks

Erik



"Adam Davidson" <Adam.Davidson@team.telstra.com> skrev i en meddelelse
news:9bf4db0.0308132334.1d72b061@posting.google.com...
> Hi,
>
> I have an existing web service A with one one method. It returns two
> parametrs A and B. This web service is deployed and used by Client X.
>
> Client Y now wants the same web service but they also want output
> parameter C. If the existing web service A is changed to include
> parameter C, does Client X need to rebuild against the new WSDL? I
> don't fully understand how the deserialisation works?
>
> I know it is not the correct solution as ideally you would version the
> web service through a different target namespace but I want to
> understand why you can't do this. If Client X never even looks for
> parameter C then it shouldn't cause any probelms, right?
>
> Thanks,
> Adam