Here's an expanded list (not a complete list) of use cases that I'd like to test for.
- Adding a service operation - Removing a service operation - Renaming a service operation - Addition of an optional service request parameter - Renaming of a service request parameter - Removal of a service request parameter - Any changes to the response object - Changing the MEP This is a majority of the use cases that I'd look at. In addition, compatibility depends on your versioning strategy. For instance, a strict policy as defined in [1] every change listed above would be non-backwards compatible. However, in a flexible versioning scheme use cases such as adding a service operation are considered a backwards compatible change. In addition, I suppose I should add the capability to test for forward compatibility, especially if modifications to the response objects is desired. The goal with a tool like this is to test compatibility with clients that exist in the wild. So for example, supposed you released a 1.0 version of your service and your SLA says minor versions are compatible. Older v1.0 clients should be able to interact with 1.1, 1.2, etc. versions of your service. At least that is the idea/concept. -Derek References [1] - http://www.infoq.com/resource/articles/Web-Service-Contracts/en/resources/ERL_WSContractVersioning_013613517X_20-22.pdf Web Service Contract Design and Versioning for SOA (Chapters 20-22) -- View this message in context: http://cxf.547215.n5.nabble.com/Are-tools-available-to-test-backwards-compatibility-of-WSDL-s-tp4727313p4736325.html Sent from the cxf-user mailing list archive at Nabble.com.
