Adding methods to the webservice: do old clients need to update web references?

Question

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?

Polyamide

Answer 1

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.

Sanorasans

Answer 2

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.

Nacre

@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. – Positivism

@John: Fair enough. I included a disclaimer. – Nacre

Answer 3

Normally I would say no. However, we have one out of 50+ clients that has problems with this using JAX-WS. They get an error like this:

javax.xml.ws.WebServiceException: 

The Endpoint validation failed to validate due to the following errors: 

:: Invalid Endpoint Interface :: :: The operation names in the WSDL portType
do not match the method names in the SEI or Web service implementation class. 
wsdl operations = [...] 

I believe it is related to this:

http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftwbs_devjaxws_exposewebmethod.html

Which says: "Best practice: Be sure to regenerate your client side artifacts any time you receive an updated WSDL file."

However, the server-side WSDL is checked at run-time in our clients instance so it fails as soon as we add a new method. I don't know the specifics or scope of the issue, but it appears you can write a SOAP client implementation that will break with new methods in the WSDL served up by the service.

Roentgenogram

Answer 4

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.

Positivism

People test machine-generated code? I'm not denying it, but I am... surprised. – Nacre

@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. – Positivism

Answer 5

I did not want to chime in on an aging thread, and many key points have been made already, but I wanted to add a note about migrating frameworks. I have had unusual behaviors at times, after migrating from .Net 2.0 up, all the way through 4.6. I would elaborate more on the specific errors, but they were some time ago.

I want to also add that, despite most of these comments, I have had numerous issues from clients that did NOT upgrade web references even after the minimal changes described here in. And I might add that this could be the result of the newer framework. I have read in numerous places in MSDN over the years that the WSDL should always be regenerated.

I've actually been looking for a technique to do this automatically. So as to prevent client side crashes when the web services do get updated. I tripped across this thread in that search.

Not really an answer but too long for a comment here.

Eugeneeugenia