Tim has an interesting post
here about dealing with semantic changes in existing interfaces on Web
Services (continuing from his posts here,
I found this particularly interesting because we followed a very similar
approach on our last project.
In our case, we had a set of existing operations on a service with an
existing client using it, and needed to extend it with new operations. That was
no problem. However, during development we noticed that due to changes in a
backend LOB application our services connected with a new field was needed some
of the original operations. In particular, we needed the client to let us know
on what TimeZone (or rather what the time shift from UTC) to use when
registering the time some operations occurred. However, we required the original
client didn't change.
What we ended up doing was basically making the new TimeZone field optional,
and then introducing logic on the operations that checked if it was missing. If
it was, instead of simply assuming a global default value, we actually queried
our security configuration and extracted a default value for this field that was
specific to the client making the call. This was possible because the
services were using WS-Security for authenticating the caller. This way, we
could actually set especific default values for other clients if needed. It
worked very nicely overall and was remarkably easy to put in place.
Some of you might be wondering how we dealt with DST: We didn't. A explicit
decision from the business side was made not to support it because of some
complexity in the business side of things, and particularly because it would've
required clients in other countries to make changes to existing
infrastructure and the benefits just were not worth it. One thing we did learn
from that experience was that handling date and time fields in webservices where
consumers and service-providers are on different countries and time zones can be
easily get quite tricky, and that the way .NET handles
on WebServices does not make things any easier.