Web 服务实施变更
Web 服务提供商应在多大程度上限制实施更改而不创建新的服务版本？一种观点是，只要遵守合同，服务所有者就应该可以根据需要自由更新实现。模式并不总是严密的，可以预见的是，服务实现中的变化会影响服务输出，同时仍然维护合同。
应在多大程度上通知消费者实施变更？通知消费者您自己的 Web 服务实现的更新是一回事。跟踪所有下游依赖项的实现更改有多可行？当服务所有者知道更改可能会影响消费者时，他们是否应该创建新版本？并努力成为一个好公民并通知消费者所有其他变化？
有很多问题，我怀疑是否有一个适合所有人的答案。这可能只是取决于具体情况。也许这就是 SLA 的用途。
To what degree should web service providers limit implementation changes without creating a new service version? One view is that as long as the contract is upheld, the service owner should be free to update the implementation as needed. Schemas are not always air tight and it is foreseeable that changes within the service implementation affect the service output while still upholding the contract.
To what degree should consumers be notified of implementation changes? Its one thing to notify consumers of updates to your own web service implementation. How feasible is it to track implementation changes to all downstream dependencies? Should service owners create a new version when they know that a change may affect consumers? And try to be a good citizen and notify consumers of all other changes?
Lots of questions and I doubt there is one size fits all answer. It could just depend on the situation. Maybe this is what SLAs are for.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好问题，我想你已经回答了。是的，这些详细信息将包含在 SLA 中，我认为如果合同/WSDL 相同，那么为什么服务需要通知其消费者？当然，除非服务的更改影响响应时间和性能。也许该服务会在引入另一个合同（除了原始合同之外）时通知消费者。消费者会意识到任何新功能，并可以根据需要相应地调整他们的客户。
Good questions, and I think you've already answered it. Yes, these details would be in an SLA and I think that if the contract/WSDL is the same that why would the service need to notify its' consumers? Unless of course changes to the service impact response times and performance. Maybe the service would notify consumers when another contract is introduced (in addition to the original). Consumers become aware of any new capabilities and can adjust their clients accordingly if desired.
我所处的环境中，内部客户端不存在 SLA，因此在没有 SLA 的情况下，以下是一些常识性准则
I'm in an environment where SLAs don't exist for internal clients, so absent an SLA, the following are some common sense guidelines
很大程度上取决于您的具体情况。一般来说，以下是一些主要考虑因素。
服务契约和模式是服务和客户端共享的所有内容。不更改契约或模式的服务实现更改（例如，修复实现逻辑中的错误）不应需要通知客户端，也不应将其视为新版本。
OTOH，如果您有一个构造不良、过于宽松的合同，例如将所有数据作为一个大字符串传递，客户端必须进行广泛的解释才能使用服务，而现在您正在寻求利用这种过度-松散的合同可能会破坏客户，因此您应该对所有各方更改合同（并改进它！）并将其发布为服务的新版本。
由于服务通常用于实现服务之间的松散耦合，因此有时识别服务的所有客户端是不切实际的，甚至是不可能的。在这些情况下，生成服务的新版本通常需要在一段时间内维护服务的多个版本，通常是按照某些治理机构的指示。
提供有关服务实现、实现依赖项等的详细信息，鼓励通过公开客户端可能依赖的非契约相关详细信息来创建紧密耦合。这可能会限制服务独立于客户端进行更改的能力。
SOA 的 Web 服务契约设计和版本控制一书
Thomas Erl 的作者是关于该主题的一个很好的资源，并详细介绍了几种常见的场景。
A lot depends on your specific circumstances. Speaking generally, here are a few top considerations.
The service contract and schema are all that a service and client share in common. A service implementation change that does not change the contract or schema (e.g., fixing a bug in the implementation logic) should not necessitate notifying the clients, nor should it be considered a new version.
OTOH, if you have a poorly constructed, overly-loose contract, such as passing all of the data as one big string, where the client had to do extensive interpretation to consume the service, and now you're looking to exploit that overly-loose contract in a way that would likely break the client, you owe it to all parties to change the contract (and improve it!) and publish that as a new version of the service.
Since services are often used to enable loose coupling between services, it is sometimes not practical or even possible to identify all of the clients of a service. Producing a new version of a service in these situations often entails maintaining multiple versions of a service for some period of time, often as directed by some governance body.
Providing details about service implementations, implementation dependencies, etc., encourages creating tight coupling by disclosing non-contract related details that the client may then take a dependency on. That can limit the ability of the service to change independently of the client.
The book Web Service Contract Design and Versioning for SOA
by Thomas Erl is a good resource on the topic, and details several common scenarios.