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

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 🙂

Leave a Comment