我工作的公司是一家拥有一套应用程序的软件供应商。还有许多Web服务,当然即使应用程序发生变化,它们也必须保持稳定。我们并不总是成功,有时客户发现升级后服务的行为不像以前那样。
我们现在想要更好地处理这个问题。一般来说,Web服务不应该改变,如果必须,至少我们会知道它并记录变化。
但我们如何确保这一点?一个想法是在每个版本中将WSDL文件与先前版本进行比较。这将确保接口不会更改,但它不会检测到行为更改,例如,如果某个公共库中引入了错误。
另一个想法是建立一套服务测试,例如使用soapUI。但是,我们永远不会知道我们是否已经覆盖了足够的案例。
对此有哪些最佳做法?
答案 0 :(得分:2)
我认为,您绝对可以对服务的稳定性充满信心如果您继续使用服务的最新更改来更新服务测试,我认为这是人们在部署之前使用的最佳实践之一。
此外,一般来说,我认为可能重要的是编写服务使用的组件(库)的开发人员完成单元测试的程度。这些单元测试是否根据服务使用的组件的更改进行更新。
答案 1 :(得分:2)
Web服务有两种更改,即更改和不间断更改。突破性变化就像更改Web方法的签名或更改datacontract架构一样。不间断的更改类似于添加新的Web方法或向datcontract添加可选成员。一般而言,您的客户应继续使用不间断的更改。我不知道您使用的是哪种技术,但在W3C recommendations之后的服务命名空间和datacontract命名空间中使用了versioing。您甚至可以继续在不同的端点上托管不同的版本。这样,如果客户尝试使用新版本的服务而不从新版本的WSDL重新生成代理或继续使用旧版本,则客户端将会中断。
一些WCF特定的链接是
http://msdn.microsoft.com/en-us/library/ms731060.aspx
http://msdn.microsoft.com/en-us/library/ms733832.aspx
我不认为行为改变是SOA意义上的变化。这更像是修复缺陷。
答案 2 :(得分:1)
IMO,除了监控WSDL的变更之外(这实际上只有在你有一个无所畏惧的实施(“促进生产”)策略时才是必要的),真正确保每个标志都是可操作和稳定的唯一方法,是使用测试套件执行连续,自动,定期的功能测试,该测试套件提供WSDL和底层应用程序功能的完整覆盖,包括边缘情况。测试用例应该像应用程序和WSDL一样进行版本控制,并且应该与应用程序的新版本并行开发(之后不作为反应)。 这一切都可以通过SoapUI实现自动化。理想情况下,记录结果可以在某些仪表板上累积和报告,以便在某些信息中断时,您知道它何时中断,并希望将其与诸如应用程序更新之类的事件相关联,或者更为良性的事情,例如服务包推动,正在进行的电气工作等。 但是......就像我说的那样,不像我一样。我在推动这项战略工作方面没有成功。你的投票将告诉我是否应该更加努力或做其他事情!