views:

241

answers:

3

ProductA uses our only web service, which is a separate deployment from ProductA. We deploy both to production.

Later, we're writing ProductB. During that effort, we add a new method to our only web service. That new method wasn't in the WSDL when ProductA shipped. We make no changes to ProductA in development.

When we deploy ProductB to production, we also deploy (to production) the new version of our only web service (to the same endpoint URL where ProductA is expecting to find it). We don't re-deploy ProductA to production.

The WSDL for our only web service has changed in production, but the signatures of the methods being consumed by ProductA have not changed. They're still in the WSDL.

Will ProductA have any problems due to our upgrading our only web service in this way?

Do you have to upgrade a client of a webservice if the webservice changed in such a way that left the original client's methods unchanged?

+2  A: 

No. As long as you left the methods that Product A uses alone, you do not have to update Product A's copy of the WebReference.

benjy
A: 

Just to add a little more detail to the existing answer, the only changes to a web service that require corresponding changes to the client proxy are:

  • Removing methods;
  • Changing method signatures;
  • Changing the bindings/behaviour (i.e. to use encryption).

Adding a new method, or adding new fields/properties to a type, are almost always non-breaking changes (still, it doesn't hurt to test with the client).

Keep in mind, of course, that the client won't actually be able to use those new methods or properties until they rebuild. But it won't break existing functionality.

Aaronaught
@Aaronaught: I wouldn't say "always". As an extreme case, consider that it's possible to write a program that would break if a method was added. Such a program could use Reflection to enumerate the methods and properties of the service reference. It would then detect the change, and could decide to fail. That's the most extreme example I can think of, but it allows me to imagine that there might be less extreme cases where something might actually break. Also, it might depend on the programming language used on the client.
John Saunders
@John: Fair enough. I included a disclaimer.
Aaronaught
A: 

While I agree that there probably won't be any problem by not updating the service references of existing clients, you should also ask what problems there will be if you do update the service references of existing clients. Be sure to test that scenario as well.

Although we tend to think about adding method to the service as something that's only important on the server, keep in mind that when a service reference is updated, this is actually changing the code of the client.

Some organizations believe in testing client code when the client code changes.

John Saunders
People test machine-generated code? I'm not denying it, but I am... surprised.
Aaronaught
@Aaronaught: it's code. It's called. It can affect the client program, or it wouldn't be there. If it changes, it could change for the worse. If lives are at stake, you'll want to test it.
John Saunders