Web服务实现更改

Question

在不创建新服务版本的情况下，Web服务提供商应该在多大程度上限制实施更改？一种观点认为，只要合同得到维护，服务所有者就可以根据需要自由更新实施。模式并不总是紧张，可以预见服务实施中的变化会影响服务输出，同时仍然维持合同。

应该在多大程度上通知消费者实施变更？向消费者通知您自己的Web服务实现的更新是一回事。跟踪所有下游依赖项的实现更改有多可行？服务所有者是否应该在知道更改可能会影响消费者时创建新版本？并努力成为一个好公民并通知消费者所有其他变化？

很多问题，我怀疑有一个尺码适合所有答案。它可能只取决于具体情况。也许这就是SLA的用途。

Answer 1

好问题，我想你已经回答了。是的，这些细节将在SLA中，我认为如果合同/ WSDL与服务需要通知其“消费者”的原因相同？当然，除非服务影响响应时间和性能发生变化。也许该服务会在引入另一份合同时通知消费者（除原件外）。消费者会发现任何新功能，并可根据需要相应调整客户。

Answer 2

我所处的环境中内部客户端不存在SLA，因此缺少SLA，以下是一些常识指南

1. 尝试限制对服务的修改次数
2. 沟通服务实施版本，以便消费者可以规划测试周期
3. 向消费者提供直接下游依赖关系和位置列表，以查找其日程安排和发布说明
4. 如果实施更改在语义上影响消费者
，请考虑使用新版本

Answer 3

很大程度上取决于您的具体情况。一般来说，这里有一些重要的考虑因素。

服务合同和架构是服务和客户共享的全部内容。不改变合同或模式的服务实现更改（例如，修复实现逻辑中的错误）不应该通知客户端，也不应该被视为新版本。

OTOH，如果你有一个构造不良，过于宽松的合同，比如将所有数据作为一个大字符串传递，客户端必须进行广泛的解释才能使用该服务，现在你正在寻求利用如果合同过于松散可能会破坏客户，那么您应该向所有各方改变合同（并改进合同！）并将其作为新版本的服务发布。

由于服务通常用于实现服务之间的松散耦合，因此识别服务的所有客户端有时甚至不可行。在这些情况下生成新版本的服务通常需要在一段时间内维护服务的多个版本，通常是由某些治理机构指示。

提供有关服务实现，实现依赖性等的详细信息，鼓励通过披露客户可能依赖的非合同相关细节来创建紧密耦合。这可能会限制服务独立于客户端进行更改的能力。

这本书Web Service Contract Design and Versioning for SOA 作者Thomas Erl是该主题的一个很好的资源，并详细介绍了几种常见的场景。