如何确保 Web 服务从一个版本到下一个版本都保持稳定？
我工作的公司是一家拥有一套应用程序的软件供应商。还有许多Web服务，当然即使应用程序发生变化，它们也必须保持稳定。我们并不总能成功做到这一点，有时客户会发现升级后服务的行为与以前不同。
我们现在想更好地处理这个问题。一般来说，Web 服务不应更改，如果必须更改，至少我们会了解并记录更改。
但我们如何确保这一点呢？一种想法是在每个版本中将 WSDL 文件与以前的版本进行比较。这将确保接口不会更改，但不会检测到行为更改，例如，如果某个通用库中引入了错误。
另一个想法是建立一套服务测试，例如使用soapUI。但我们永远不会知道我们是否涵盖了足够的案例。
对此有哪些最佳实践？
The company where I work is a software vendor with a suite of applications. There are also a number of web services, and of course they have to be kept stable even if the applications change. We haven't always succeeded with this, and sometimes a customer finds that a service is not behaving as before after upgrading.
We now want to handle this better. In general, web services shouldn't change, and if they have to, at least we will know about it and document the change.
But how do we ensure this? One idea is to compare the WSDL files with the previous versions at every release. That will make sure the interfaces don't change, but it won't detect that the behavior changes, for example if a bug is introduced in some common library.
Another idea is to build up a suite of service tests, for example using soapUI. But then we'll never know if we have covered enough cases.
What are some best practices regarding this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为，如果您不断使用服务中的最新更改来更新服务测试，您绝对可以对服务的稳定性充满信心，我认为这是人们在部署之前使用的最佳实践之一。
另外，一般来说，我认为重要的是编写服务所使用的组件（库）的开发人员的单元测试做得如何。这些单元测试是否随着服务所使用的组件的更改而更新。
I think, you can definitely be confident of the stability of the services If you keep updating your service tests with the latest changes in the service and I think this is one of the best practices people use before they deploy.
Also, In general, I think what would probably matter is how well the unit testing is being done by the developers who are writing the components(libraries) used by the services. Are those unit tests being updated with the changes in the components being used by the service.
Web 服务有两种更改：破坏性更改和非破坏性更改。重大更改就像更改 Web 方法的签名或更改数据契约架构。非破坏性更改就像添加新的 Web 方法或向数据合约添加可选成员。一般来说，您的客户应该继续进行不间断的更改。我不知道您使用的是哪种技术，但按照 W3C 建议。您甚至可以继续在不同端点托管不同版本。这样，如果您的客户端尝试使用您的服务的新版本而不从新版本的 WSDL 重新生成代理或继续使用旧版本，他们将会崩溃。
一些 WCF 特定链接是
http://msdn.microsoft.com/en-us/library/ms731060。 ASPX
http://msdn.microsoft.com/en-us/library/ms733832。 aspx
我不认为行为改变是 SOA 意义上的改变。这更像是修复缺陷。
There as two kinds of changes for a web service, breaking change and non-breaking change. Breaking change is like changing the signature of a web method or changing a datacontract schema. Non-breaking change is like adding a new web method or adding an optional member to a datcontract. In general your client should continue to work with a non-breaking change. I don't know which technology you are using but use versioing in service namespace and datacontract namespace following W3C recommendations. You can even continue to host different versions at different endpoints. This way your clients will break if they try to use a new version of your service without re-generating the proxy from the new version of WSDL or continue to use the old version.
Some WCF specific links are
http://msdn.microsoft.com/en-us/library/ms731060.aspx
http://msdn.microsoft.com/en-us/library/ms733832.aspx
I wouldn't consider behaviour change as a change in SOA sense. That is more like fixing defects.
IMO，除了监视 WSDL 的更改（实际上只有在您有任意实施（“推广到生产”）策略时才需要）之外，真正确保一切正常运行且稳定的唯一方法是使用测试套件执行连续、自动化、定期的功能测试，该测试套件提供 WSDL 和底层应用程序功能（包括边缘情况）的完整覆盖。测试用例应该像应用程序和 WSDL 一样进行版本控制，并且应该与应用程序的新版本并行开发（而不是事后作为反应）。
这一切都可以通过 SoapUI 实现自动化。理想情况下，将结果记录在可以累积并在某些仪表板上报告的地方，这样，如果某些东西发生故障，您就知道它何时发生故障，并希望将其与应用程序更新等事件或更良性的事件（例如服务包正在运行）相关联。推动、正在进行电气工作等
然而……照我说的做，而不是照我做的做。我在工作中推行这一策略并不成功。您的投票将告诉我是否应该更加努力或做其他事情！
IMO, aside from monitoring the WSDL for changes (which is really only necessary if you have a willy-nilly implementation ("promote-to-production") strategy), the only way to really ensure that everythign is operational and stable, is to perform continuous, automated, periodic, functional testing with a test suite that provides complete coverage of both the WSDL and the underlying application functionality, including edge cases. The test cases should be version controlled just like the app and WSDL, and should be developed in parallel to new versions of the app (not afterward, as a reaction).
This can all be automated with SoapUI. Ideally, logging results somewhere that can be accumulated and reported on some dashboard, so that if somethign breaks, you know when it broke, and hopefully correlate that to an event such as an application update, or something more benign such as a service pack being pushed, electrical work being performed, etc..
However... do as I say, not as I do. I have been unsuccessful in pushing this strategy at work. Your votes will tell me whether I should push harder or do something else!