Skip to end of metadata
Go to start of metadata

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.

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: P32. A service shall document its Service Level Agreement SLA (response time=30ms, availability=99.995%)

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..).

Definitions

Status

Doc status H2A A2A ACS CS Last PAB discussion
2007.06.08

PAB discussions


Design-Time Governance - SOA Design Rules FAQ

  • [Question still to be asked..]
Labels:
policy_acs policy_acs Delete
policy_cs policy_cs Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.