View Source

h3. Motivation
When a service-consumer starts using a service, a dependency to that service's contract is created. The service's contract can't undergo any major changes without this having an impact on the service-consumer. This introduces the need for several versions of a service.

h3. Argumentation
Services evolve over time. Service consumers need to know how the services evolve to be able to evolve alongside the service-lifecycle. The versioning life-cycle need to be predictable for the service-consumers, so that they can plan ahead for new versions of a service. Therefore any service must have a documented versioning strategy, so that consumers can plan their update strategy in accordance.

The versioning strategy and policies should be a part of a service's Service Level Agreement. See: [KM:P32. A service shall document its Service Level Agreement SLA (response time=30ms, availability=99.995%)]

h3. Exceptions/special cases

In most real cases, this policy will be limiting to a small set of versioning strategies (multiple endpoints, evolving service adaptor, adaptors, forced big-bang (really the worst versioning strategy..) et all..).

h3. Definitions

h3. Status

|| Doc status || [H2A] || [A2A] || [ACS] || [CS] || Last [PAB] discussion ||
| (/) | (-) | (-) | (+) | (+) | 2007.06.08 |

h3. PAB discussions


h3. [Design-Time Governance - SOA Design Rules FAQ]

{include:Design-Time Governance - SOA Design Rules FAQ}