This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Scaling over Time

Stefan Tilkov,

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.

On January 26, 2006 11:16 AM, Robin Mulkers said:

Never changing a service interface is not an option.

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.

On January 27, 2006 10:11 PM, Stefan Tilkov said:

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.