mat*_*att 11 versioning web-services
更新20100224我真的不需要某些供应商网站的一些蹩脚的定义.我正在寻找的是实际实施以及实际实施这些东西的人们在日常IT /业务周期中面临的挑战.
更多内容如下:
没有创建/采用退休策略:显然需要创建一个.我对您如何创建此策略并将其出售给管理层感兴趣.您看到的所有成本/收益是多少？您是否对客户重新编码要求与内部支持要求进行BE分析？您是否为古代API的内部支持成本分配了$ value？
生产IT支持的影响:您如何与生产IT团队合作以部署策略.他们喜欢什么,是什么让他们疯了？
软件:你们软件的人喜欢做什么,业务告诉他们做什么以及他们实际做了什么？什么最适合他们？
质量保证:质量保证如何处理测试.恩.如果您创建了一个处理多个版本的服务,QA会在每次对其中一个版本进行更改时对所有内容进行完全回归吗？
DBA:你的dba如何处理对于向xml响应添加字段的数据记录至关重要的常见过程？您是否有单一的proc或者您是否根据架构或其他方式进行分支和分段？
原始笔记
我正在收集有关不同Web服务版本控制策略的优缺点的信息.该业务尚未确定Web服务退役策略,由于产品变更,客户需求变更和合作伙伴集成变更,我的Web服务确实发生了重大变化.
我正在寻找维护独立独立或多个/集成版本的优缺点,以及这对业务的影响,包括开发人员支持/开发人员集成资源,生产IT支持,软件,QA和DBA.
任何见解,经验,资源或想法都表示赞赏.
我们的应用程序中的 Web 服务只是业务逻辑的前端。
由于业务逻辑的变化，出现了新版本的Web服务。当引入新版本的 Web 服务时，它将被放置在新的 url 下。例如：
版本1/websvc 版本2/websvc2
Web服务层和业务层之间有专门的代码。该层处理 Web 服务版本中的差异，并将调用传递给最新的业务层。
了解Web服务版本差异是特殊门面代码（Web服务和业务逻辑之间）的问题。