Web服务提供商应该在多大程度上限制实施变更而不创建新的服务版本？一种观点是，只要合同得到维护，服务所有者就可以根据需要随意更新实施。模式并不总是密不透风，可以预见，服务实施中的变化会影响服务产出，同时仍然维护合同。Web服务实施变更
应该在什么程度上通知消费者实施变更？将消息更新通知给您自己的Web服务实现是一回事。跟踪所有下游依赖项的实施变更有多可行？服务所有者是否应该在知道变更可能会影响消费者时创建新版本？并努力成为一个好公民并通知消费者所有其他变化？
很多问题，我怀疑有一个尺寸适合所有答案。这可能仅仅取决于情况。也许这是SLA的目的。
好问题，我想你已经回答了。是的，这些细节将出现在SLA中，我认为如果合同/ WSDL与服务需要通知其消费者的原因相同？除非改变服务影响响应时间和性能。也许服务会在另一个合同被引入时通知消费者（除了原件之外）。消费者会意识到任何新功能，并可根据需要调整其客户端。
我在服务水平协议没有为内部客户端存在，所以缺席SLA中的环境，以下是一些常识准则
很大程度上取决于您的具体情况。一般来说，这里有几个重要的考虑因素。
服务契约和模式都是服务和客户共享的。不改变合同或模式的服务实现更改（例如，修复实现逻辑中的错误）不应该要求通知客户端，也不应将其视为新版本。
OTOH，如果你的结构构造不良，过于松散的合同，比如将所有数据作为一个大字符串传递，客户端必须做大量解释才能使用该服务，现在你正在寻找以可能破坏客户的方式利用过度松散的合同，您应该向所有各方更改合同（并改进它！），并将其作为新版本的服务发布。
由于服务通常用于实现服务之间的松散耦合，因此识别服务的所有客户端有时不切实际甚至不可能。在这些情况下生成新版本的服务通常需要在一段时间内维护多个版本的服务，这通常是由某个管理机构指导的。
提供有关服务实现，实现依赖关系等的详细信息，鼓励通过披露客户可能依赖的非合同相关细节来创建紧密耦合。这可能会限制服务独立于客户端进行更改的能力。
Thomas Erl的书Web Service Contract Design and Versioning for SOA 是关于这个话题的一个很好的资源，并且详细介绍了几种常见的场景。