Web服務版本控制策略的優缺點

Question

更新20100224 我真的不需要某些供應商網站的一些蹩腳的定義。我正在尋找的是在實際實施這些東西的人們的日常IT /商業週期中所面臨的實際實施和挑戰。

更多的東西如下：

沒有退休的策略已創建/通過：顯然，人們需要創建。我對如何制定這一戰略並將其出售給管理層感興趣。你看到的所有成本/收益是什麼？您是否對客戶記錄要求與內部支持要求進行了BE分析？您是否將$ value分配給古代API的內部支持成本？

生產IT支持含義：您如何與生產IT團隊合作部署您的戰略。他們喜歡什麼，什麼讓他們發瘋？

軟件：你們喜歡做什麼軟件，企業告訴他們做什麼以及他們實際做了什麼？什麼最適合他們？

問：QA如何處理測試。恩。如果您創建了一個可處理多個版本的服務，那麼每次對其中一個版本進行更改時，QA都會對所有內容進行全面迴歸？

DBA's：您的dba如何處理對於向xml響應中添加字段的數據記錄至關重要的常見過程？你有一個單一的過程，或者你是否根據模式或其他來分支事物和細分？

---

原注

我收集的不同的Web服務版本策略的利弊信息。該業務尚未確定Web服務退役策略，而且由於產品變更，客戶需求變更以及我們的合作伙伴集成變化，我的Web服務確實發生了顯着變化。

我在尋找一個優點/缺點，用於維護獨立的單機版或多版本/集成版本，以及這會如何影響業務，包括開發人員支持/開發人員整合資源，生產IT支持，軟件，QA & DBA's。

任何洞察力，經驗，資源或想法表示讚賞。

Answer 1

我們應用程序中的Web服務只是業務邏輯的前端。

由於業務邏輯的變化，出現了新版本的Web服務。當新版本的Web服務被引入時，它被置於新的URL之下。例如：

ver1 /websvc 
ver2 /websvc2

Web服務層和業務層之間有特殊的代碼。該層處理Web服務版本中的差異並將呼叫傳遞到最新的業務層。

這是專門的門面代碼（在Web服務和業務邏輯之間）瞭解Web服務版本差異的問題。