Can an API in SOAP/WSDL be kept backwards compatible easily?

Question

When using an IPC library, it is important that it provides the possibility that both client and server can communicate even when their version of the API differs. As I'm considering using SOAP for our client/server application, I wonder whether a SOAP/WSDL solution can deal with API changes well.

For example:

• Adding parameters to existing functions
• Adding variables to existing structs that are used in existing functions
• Removing functions
• Removing parameters from existing functions
• Removing variables from existing structs that are used in existing functions
• Changing the type of a parameter used in an existing function
• Changing the order of parameters in an existing function
• Changing the order of composite parts in an existing struct
• Renaming existing functions
• Renaming parameters

Note: by "struct" I mean a composite type

Answer 1

It doesn't. You'll have to manage that manually somehow. Typically by creating a new interface as you introduce major/breaking changes.

More generally speaking, this is an architectural problem, rather than a technical one. Once an interface is published, you really need to think about how to handle changes.

Answer 2

AFAIK there is not such stuff as per the SOAP/WSDL standard. But tools exists to cope with such issues. For instance, in Glassfish you can specify XSL stylesheet to transform the request/response of a web service. Other solution such as Oracle SOA suite offer much more elaborated tools to manage versioning of web service and integration of component together. Message can be routed automatically to different version of a web service and/or transformed. You will need to check what your target infrastructure offers.

EDIT:

XML and XSD is more flexible regarding evolution of the schema than types and serialization in object-oriented languages. Some stuff can be made backward compatible by simply declaring them as optional, e.g.

• Adding parameters to existing functions - if a parameter is optional, you get a null value if the client doesn't send it
• Adding variables to existing structure that are used in existing functions - if the value is optional, you get null if the client doesn't provide it
• Removing functions - no magic here
• Removing parameters from existing functions - parameters sent by the client will be superfluous according to the new definition and will be omitted
• Removing variables from existing structure that are used in existing functions - I don't know in this case
• Changing the type of a parameter used in an existing function - that depends on the change. For a simple type the serialization/deserialization may still work, e.g. String to int.

Note that I'm not 100% sure of the list. But a few tests can show you what works and what doesn't. The point is that XML is sent over the wire, so it gives some flexibility.