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 回答