Practical AgileSOA - Versioning services

In the previous post, we saw how by simply doing, we can get those first services built. This activity will answer a lot of questions, but also will show us which questions to ask next.

One of these is how to deal with service versions.

Undoubtedly, your services will undergo revisions and change.
That in and of its own is not a problem. The trouble happens when you change the interface definition and the functionality.
If the service starts behaving differently because


With push services (asynchronous) it is a good idea to include a version number in the messages it sends.
That way, a subscriber can be made aware that things have changed.
One can think of a subscriber routing incoming messages through a validation component if the expected message version does not match the incoming message version.

With Web services, commercial registries can handle much of the versioning.
Consumers can subscribe to registry updates and be rigged to take action when a service changes.

As a rule, you should be wary of deleting information from service outputs.
Not that you should keep everything around forever; just be aware that consumers are notified in some form.

In general, new content should be added in such a way that a consumer can continue to use the incoming data without knowing how to handle the new stuff. For instance, if you use a byte-encoded message, add new content at the end.

With self-describing message and XML messages, this restriction does not really apply, since you can just pull out what you're looking for, regardless of the extra content.

(See, even with standardized services, you are still not entirely decoupled, just loosely coupled.)

Next post: The emerging infrastructure