Web 服务版本控制策略的优缺点 [英] Pros and Cons of Web Services Versioning Strategies
问题描述
更新 20100224我真的不需要某些供应商网站上的一些蹩脚定义.我正在寻找的是实际实施这些东西的人在日常 IT/业务周期中面临的实际实施和挑战.
Update 20100224 I really don't need some lame definitions from some vendor website. What I am looking for is practical implementation and challenges faced in the daily IT/business cycle for people who actually implement this stuff.
更多内容如下:
尚未创建/采用退休策略:显然需要创建一个.我对您如何创建此策略并将其出售给管理层感兴趣.您看到的所有成本/收益是什么?您是否对客户重新编码要求与内部支持要求进行了 BE 分析?您是否为古代 API 的内部支持成本分配了 $ 价值?
No retirement strategy has been created/adopted: Obviously one needs to be created. I am interested in how you create this strategy and sell it to management. What are all of the costs/benefits you look at? Do you do a BE analysis on customer recoding requirements vs. Internal support requirements? Do you assign a $ value to internal support costs of ancient API's?
生产 IT 支持影响:您如何与生产 IT 团队合作部署您的战略.他们喜欢什么，又是什么让他们疯狂?
Production IT support implications: How have you worked with your production IT groups to deploy your strategy. What do they like and what makes them crazy?
软件:你们软件人喜欢做什么，企业告诉他们做什么，他们实际做什么?什么最适合他们?
Software: What do you software guys like to do, what does the business tell them to do and what do they actually do? What works best for them?
QA:QA 喜欢如何处理测试.前任.如果您创建了一个处理多个版本的单一服务，那么每次对其中一个版本进行更改时，QA 是否都会对所有内容进行全面回归?
QA: How do QA like to handle testing. ex. If you have created a single service that handles multiple versions does QA do full regression for everything every time a change is made to one of the versions?
DBA:您的 dba 如何处理对于将字段添加到 xml 响应的数据记录至关重要的常见过程?你有一个单一的 proc 还是你根据架构或其他做分支和分段?
DBA's: How do your dba's deal with the common procs that are critical to the data logging for adding a field to an xml response? Do you have a single proc or do you do branch things and segment based on schema or other?
原注
我正在收集有关不同网络服务版本控制策略的优缺点的信息.该企业尚未确定网络服务停用策略，而且我的网络服务确实会因产品变化、客户需求变化和我们的合作伙伴集成变化而发生重大变化.
I am collecting info on the pros and cons of different web services versioning strategies. The business has not yet determined a strategy for web service retirement, and my web services do change significantly due to product changes, customer requirement changes and our partner integration changes.
我正在寻找随着时间的推移维护独立的独立版本或多个/集成版本的利弊，以及这如何影响业务，包括开发人员支持/开发人员集成资源、生产 IT 支持、软件、QA &DBA 的.
I am looking for a pros/cons for maintaining independent stand alone or multiple/integrated versions over time and how this affects the business including developer support/developer integration resources, production IT support, Software, QA & DBA's.
感谢任何见解、经验、资源或想法.
Any insight, experiences, resources or ideas are appreciated.
推荐答案
我们应用程序中的 Web 服务只是业务逻辑的前端.
Web services in our application are just a front-end to the business logic.
由于业务逻辑更改，出现新版本的 Web 服务.当引入新版本的 web 服务时，它被放置在新的 url 下.例如:
New version of web service appears due to business logic change. When new version of web service is introduced it is placed under new url. For instance:
ver1 /websvc
ver2 /websvc2Web 服务层和业务层之间有特殊的代码.该层处理 Web 服务版本的差异，并将调用传递给最新的业务层.
There is special code between web service layer and business layer. This layer handles differences in the web services versions and passes a call to the latest business layer.
了解Web服务版本差异是特殊的门面代码(Web服务和业务逻辑之间)的问题.
It is the problem of the special facade code (between web service and business logic) to know web service version differences.
这篇关于Web 服务版本控制策略的优缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
