4

我工作的公司是一家拥有一套应用程序的软件供应商。还有一些网络服务，当然，即使应用程序发生变化，它们也必须保持稳定。我们在这方面并不总是成功，有时客户会发现升级后服务的行为不像以前那样。

我们现在想更好地处理这个问题。一般来说，Web 服务不应该改变，如果它们必须改变，至少我们会知道并记录改变。

但是我们如何确保这一点？一个想法是在每个版本中将 WSDL 文件与以前的版本进行比较。这将确保接口不会改变，但它不会检测到行为发生变化，例如，如果某个公共库中引入了错误。

另一个想法是建立一套服务测试，例如使用soapUI。但是，我们永远不会知道我们是否已经涵盖了足够多的案例。

对此有哪些最佳实践？

4

3 回答 3

2

我认为，您绝对可以对服务的稳定性充满信心，如果您使用服务中的最新更改不断更新服务测试，我认为这是人们在部署之前使用的最佳实践之一。

另外，总的来说，我认为可能重要的是编写服务使用的组件（库）的开发人员进行单元测试的效果如何。这些单元测试是否随着服务使用的组件的更改而更新。

于 2010-03-21T09:47:35.913 回答
2

Web 服务有两种更改，中断更改和非中断更改。重大更改就像更改 Web 方法的签名或更改数据合同模式。非破坏性更改就像添加新的 Web 方法或向 datcontract 添加可选成员。一般来说，您的客户应该继续使用非破坏性更改。我不知道您使用的是哪种技术，但按照W3C 的建议在服务命名空间和数据合同命名空间中使用版本。您甚至可以继续在不同的端点托管不同的版本。这样，如果您的客户尝试使用新版本的服务而不从新版本的 WSDL 重新生成代理或继续使用旧版本，他们就会中断。
一些 WCF 特定链接是 http://msdn.microsoft.com/en-us/library/ms731060.aspx http://msdn.microsoft.com/en-us/library/ms733832.aspx

我不会将行为改变视为 SOA 意义上的改变。这更像是修复缺陷。

于 2010-03-21T11:58:11.887 回答
1

IMO，除了监控 WSDL 的变化（只有当你有一个随意的实施（“推广到生产”）策略时才真正需要），真正确保一切都可操作和稳定的唯一方法是使用提供 WSDL 和底层应用程序功能（包括边缘案例）的完整覆盖的测试套件执行连续、自动化、定期的功能测试。测试用例应该像应用程序和 WSDL 一样进行版本控制，并且应该与应用程序的新版本并行开发（而不是之后，作为反应）。这一切都可以通过 SoapUI 自动化。理想情况下，在某个地方记录结果，可以在某个仪表板上累积和报告，这样如果有什么东西坏了，你就知道它什么时候坏了，并希望将其与诸如应用程序更新之类的事件相关联，或者将其与诸如推送服务包、执行电气工作等更良性的事件相关联。但是……按照我说的做，而不是像我做的那样。我在工作中推动这一策略一直没有成功。您的投票将告诉我是应该更加努力还是做其他事情！

于 2010-03-27T18:18:27.557 回答