In using WSDL to describe the evolution of interfaces, we can think about how interfaces can remain compatible when evolved. But why do we care? And how would this information be used?
Imagine that a travel reservation service offers a "reserveration" interface to the world. It offers a couple of operations that are request/response, say "findFlights" and "bookFlight".
The reservation service decides to change it's reservation interface. The new interface can either be compatible with the earlier interface, or not. The typical kinds of incompatible changes are: adding required data in the input of an operation, adding a required operation to the interface, deleting an operation, changing the semantics. Roughly speaking, these break down into 2 main types of changes: operation changes and format changes. There are invarients on operation changes and format changes to enable compatible evolution.
Now if the reservation service makes compatible change to the "reservation" interface and describes the new interface, it probably wants existing clients to continue to work without the new description.
This leads to a decision tree for descriptions of interfaces:
1. Compatible interface, client gets new interface: Client can adjust to new interface when it chooses.
2. Compatible interface, client doesn't get new interface: Client doesn't adjust to new interface.
3. Incompatible interface, client gets new interface: Client needs to adjust to new interface before old interface is terminated.
4. Incompatible interface, client doesn't get new interface: Client will break when old interface is terminated. Probably will then fall back to step 3 after some kind of metadata exchange step.
The point of doing compatible evolution and describing the new interface is to enable scenario #1: To give the client the opportunity but not the requirement to use the "new and improved" features of the interface.
Now the harder question for scenario #1 is how to describe the new interface wrt to the old interface.
Leave a comment