Scaling over Time
A nice article on the lack of support for versioning in current programming languages. I certainly know the problem — in fact, I believe it has come up twice in customer discussions this week.
Within the SOA space, though, I think the answer lies in never having to change your interfaces in the first place.
Never changing a service interface is not an option. http://blogs.ittoolbox.com/eai/applications/archives/005634.asp
Of course, there must be a good reason to change a service interface. It should not be for the fun of changing it. A good reason is for example when EU moved from local country currencies to Euro. That was a good reason for changing service interfaces!
I mean refactoring within the service should not impact the interface as long as the data stays the same.
Because services are reused, it might be that new service consumers want additional attributes or want to provide extra information in their requests. In this case, what should we do? Create a new service or adapt the existing service and reuse it? I think that it is necessary to make a distinction between backward compatible changes and non backward compatible changes to deal with those cases efficiently. Immutable service interfaces are definitely not an option when we are talking about adding new optional attributes to a type used within a service interface.
I was actually trying to make a point that it does not make much sense to voluntarily introduce version dependencies into a layer where they are not needed — the concept of having breaking and non-breaking changes is much easier supported the more generic your interface.