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?

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.

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.

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.