What are considered non-breaking or backwards-compatible changes to a WSDL contract?

Question

This page lists the following examples:

• Addition of new WSDL operations to an existing WSDL document
• Addition of new XML schema types within a WSDL document that are not contained within previously existing types

But is there a definition or standard guideline for what changes are considered backwards-compatible. Or in other words, what changes can you make to your contract, and still expect not to break your clients.

Answer 1

I have spent some time on this particular subject, and found some guidelines in a book by Thomas Erl which I refer to at the bottom. Here is what they have to say;

Compatible Changes

• adding a new WSDL operation definition and associated message definitions
• adding a new WSDL port type definition and associated operation definitions
• adding new WSDL binding and service definitions
• adding a new optional XML Schema element or attribute declaration to a message definition
• reducing the constraint granularity of an XML Schema element or attribute of a message definition type
• adding a new XML Schema wildcard to a message definition type
• adding a new optional WS-Policy assertion
• adding a new WS-Policy alternative

Incompatible Changes

• renaming an existing WSDL operation definition
• removing an existing WSDL operation definition
• changing the MEP of an existing WSDL operation definition
• adding a fault message to an existing WSDL operation definition
• adding a new required XML Schema element or attribute declaration to a message definition
• increasing the constraint granularity of an XML Schema element or attribute declaration of a message definition
• renaming an optional or required XML Schema element or attribute in a message definition
• removing an optional or required XML Schema element or attribute or wildcard from a message definition
• adding a new required WS-Policy assertion or expression
• adding a new ignorable WS-Policy expression (most of the time)

There is a great book on this particular subject from Thomas Erl et al; The name is Web Service Contract Design & Versioning for SOA.

HTH.

Disclaimer: As I've mentioned, this is work done by the authors of the book and I'm merely sharing it. I'm also not affiliated in anyway; just liked the book :)

Answer 2

Additional optional request elements (minoccurs=0) could also be backward compatible - this depends on the implementation of the service on the host side. Also, changing a mandatory response element to optional could also be backward compatible - it depends on the implementation of your client.

This area is tricky.

If you are really worried about backward compatibility consider creating a new version of the service for new clients and keep the existing implementation for existing clients. Also, in general, avoid sending domain objects over your services - use DTOs.

Hope this helps.