web-services - Web 服务版本控制策略的优缺点

Question

更新 20100224
我真的不需要某些供应商网站上的一些蹩脚定义。我正在寻找的是实际实现这些东西的人在日常 IT/业务周期中面临的实际实现和挑战。

更多内容如下:

尚未创建/采用退休策略:显然需要创建一个。我对您如何创建此策略并将其出售给管理层感兴趣。您看到的所有成本/ yield 是什么？您是否对客户重新编码要求与内部支持要求进行了 BE 分析？您是否为古代 API 的内部支持成本分配了 $ 值(value)？

生产 IT 支持影响:您如何与生产 IT 团队合作部署您的战略。他们喜欢什么，又是什么让他们疯狂？

软件:你们软件人喜欢做什么，业务告诉他们做什么，他们实际做什么？什么对他们最有效？

QA:QA 喜欢如何处理测试。前任。如果您创建了一个处理多个版本的单一服务，那么每次对其中一个版本进行更改时，QA 是否会对所有内容进行全面回归？

DBA:您的 dba 如何处理对于将字段添加到 xml 响应的数据记录至关重要的常见过程？你有一个单一的 proc 还是你根据模式或其他做分支事情和分段？

原始笔记

我正在收集有关不同 Web 服务版本控制策略的优缺点的信息。该业务尚未确定 Web 服务停用策略，由于产品更改、客户需求更改和我们的合作伙伴集成更改，我的 Web 服务确实发生了重大变化。

我正在寻找随着时间的推移维护独立独立或多个/集成版本的利弊，以及这如何影响业务，包括开发人员支持/开发人员集成资源、生产 IT 支持、软件、QA 和 DBA。

任何见解、经验、资源或想法都值得赞赏。

Answer 1

我们应用程序中的 Web 服务只是业务逻辑的前端。

由于业务逻辑的变化，出现了新版本的 Web 服务。当引入新版本的 web 服务时，它被放置在新的 url 下。例如:

版本 1/websvc
版本 2/websvc2

Web 服务层和业务层之间有特殊的代码。该层处理 Web 服务版本的差异，并将调用传递到最新的业务层。

了解Web服务版本差异是特殊的外观代码(Web服务和业务逻辑之间)的问题。