論題
在企業SOA進程中，需要認真考慮服務版本控制。讓我們以在具有共享服務的組織中發佈一個新版本的服務爲例，在這種情況下，可能要求一種Web服務的多個版本同時可用。部分消費者可能會延用舊版本的服務，直至所有消費者代碼都爲新功能和/或新界面而遷移。
在本篇博客文章中，我會試着提出一些對組織內廣泛應用的服務進行版本控制需要處理的方面。首先我會嘗試定義可能發生的改變的類型，然後介紹幾種可以考慮的不同模式，最後將這些模式映射到實際解決方案。應用這些模式時，我還會考慮到這些服務所屬的SOA層，以及一些與不同版本的服務的部署相關的實踐考慮事項。
改變的類型
Web Services實現中的改變對此web services消費者的影響取決於以下幾個因素：
- web服務操作參數的變化，比如添加新的參數（這會影響到當前消費者）或者改變已有參數，例如對XML文件中已有web服務的消息參數進行更改（使用打包的document/literal時，這是我喜愛的binding style）：XML文件中的改變可以包含增加可選的元素或屬性（這可能會影響到當前的消費者），或強制更改元素或屬性（這必然會影響到當前的消費者）。
- 改變操作名稱（這必然會影響到當前的消費者）。
- 增加操作（這可能會影響到當前的消費者）。
- 刪除操作（這必然會影響到當前的消費者）。
因此，我們可以確定一種web 服務改變的分類法，根據改變對對當前消費者及其行爲的影響來提出分類法。一種常見的辦法是將其分爲不會影響當前消費者的minor release和會產生影響的major release。
Minor Release
minor release可分爲兩種。第一種類型是更正bug或改進web服務的性能，這不會影響web服務的WSDL。第二種類型包括給web服務增加method，它會改變WDSL但不會對已存在的消費者產生影響。標註版本號時，這兩種不同類型的發佈可以區別出來。例如您可以選擇改變小數點後第二位作爲第一種類型，改變小數點後第一位作爲第二種類型（1.0X或1.Y0）。
Major Release
會破壞向後兼容的改變叫做major release。消費者必須改變。在某些情況下，有些發佈隻影響web服務的功能但不影響WSDL。因爲當前消費者只有仔細考慮這些改進的web服務功能才能調用新的web服務，所以這也被認爲是一種major release。
既然我們已經確定了改變的種類以及它們對當前用戶的影響，讓我們關注一下不同模式的Web Services版本控制。
模式
消費者綁定模式
當一個新版本的web服務發佈後，無論是major還是minor，這些變化會通知到消費者，他們有責任通過改變代碼來訪問新版本的服務。例如在一個UDDI註冊庫中，新的WDSL發佈了，發給消費者一份通知，這樣他們就能發現新服務並和服務提供者建立綁定。使用UDDI註冊庫是一種慣例，它包含了將給定版本的端口類型關聯到特定的tModel，一個WDSL關聯到一個tModel ，對major版本來說tModel應該包含版本的引用，因爲兩個major版本意味着兩個不同的WSDL；如果兩個minor 版本需要同時被訪問，tModel可能需要包含對minor 版本的引用。該端口類型/版本的消費者可以進行UDDI綠頁搜索來查找通知兼容性的服務，把它們與相應版本的tModel相關聯。
這種方法可能會把改變強加在消費者身上，至少需要搜索註冊庫來並訪問一個版本（minor或major）的服務，對minor release也是這樣。如果您需要兩個minor version同時運行會怎麼樣呢？例如，您可能希望在試點網站上部署minor release，供部分消費者使用，同時使大部分已有消費者依然可以使用舊版本。即使WSDL沒有修改（因爲是minor版本），試點網站上部署的服務的消費者還是需要改變服務的端點。在這種特定情況下，消費者和提供者之間設一個間接層是比較實際的，這可以以一種良好的方式推進不同消費者的遷移。
注意：消費者綁定模式並不一定表示應用UDDI，它指的是綁定決策發生在消費者端這一現象。稍後能看您將看到，使用這種模式可能會非常有趣。
間接層模式
在新的minor 版本發佈後，消費者會透明地向服務的新minor release遷移：這由間接層通過路由機制提供，它確保基於內容的路由或基於用戶的路由（例如基於請求者的IP，或者在傳播安全角色時，基於請求者的主要角色）調用web服務的不同版本。
使用間接層時，兩個minor release可在不改變消費者代碼的情況下共存，並且能確保新的發佈版得到很好的遷移。
但是major release就要求消費者改變他們的代碼。如果出於某些組織上的原因，我們需要在不改變所有當前消費者的代碼的情況下來遷移到新的major release，並使用舊客戶端來調用新服務，那麼該怎麼辦？這種情況完全可能發生，例如：某些法規要求意味着，僅通過使用服務的新major release纔可使用一種更改，即使用戶仍使用舊的客戶端界面。這使我們能夠作出一些調整，使當前消費者能夠利用新的major release，直至所有消費者代碼修改完畢。
適配器模式
適配器模式包括使客戶端請求和響應相配合來消費服務的新major release。如果出於商業、法規或者組織方面的原因，服務的新major release是強制性的，使用這種模式將能夠提供一種更爲平滑的遷移。
應用這些模式的解決方案
可以通過不同的方法來應用這些不同的模式。它可以通過消費者代碼完成，也就是考慮客戶端代碼中的那些模式：這是罕見的情況，也意味着維護客戶端代碼將變得十分複雜。另一種辦法是使用中介，令消費者與提供者解耦，將服務總線用作中介，其中應用那些模式。使用AquaLogic Service Bus作爲中介層可以使間接層模式與適配器模式關聯，客戶端得以解脫。如下圖所示：
使用這種基於AquaLogic Service Bus的方法有以下優勢：
- minor release改變可在不影響消費者的情況下完成，並有可能通過基於內容的路由或基於用戶的路由定位試點網站。
- 向major release的遷移以一種比較主動的方式得到處理，它通過使用AquaLogic Service Bus來使客戶端請求和響應適應服務的新major版本。
這種情況下UDDI 註冊庫的使用不是強制性的。
AquaLogic Service Bus通過業務服務的代理服務器提供了一箇中介層。用版本的引用組織這些代理服務器的配置和業務服務可能是比較實用的。AquaLogic Service Bus中的代理服務器包括對major release的引用，業務服務包括路徑中的minor release，例如，對於major v1.XX：
functional_block/module/proxies/v1_XX/ functional_block/module/businessservices/v1_00/ functional_block/module/businessservices/v1_01/ functional_block/module/wslds/v1_XX
對於major V2.XX：
functional_block/module/proxies/v2_XX functional_block/module/businessservices/v2_00 functional_block/module/wslds/v2_XX
注意：代理服務器和WDSL對minor releases是相同的，包含它們的路徑不包含minor 版本引用。
但如何在Weblogic上使用相同的編碼環境部署兩個不同版本的服務？這些服務可能含有相同的J2EE web模塊上下文路徑，因爲它們有可能是用同一個Workshop項目開發的。所以，除非您提供一個在J2EE web 模塊中加入版本引用的構件（使用ant），纔可能想在不同的目標上部署同一服務的不同版本；目標是一個集羣或一個託管服務器。如下圖所示：
當消費屬於業務服務層、數據訪問服務層或編排服務層的服務時，表現服務和編排服務（業務流程服務）將受益於這種方法的透明度。但是表現服務的消費者，使用WSRP的複合門戶消費遠程portlet。此時也可使用這一方法，但我們要採用一種更簡單合適的方法，它基於WebLogic Portal權限：使用基於訪問者角色的規則和權限來展示覆合門戶中某些取決於用戶配置文件的部分。在某些情況下，使用權限對錶現服務層更加相關，因爲表現服務可能依賴於最終用戶的配置文件，並且權限規則相對來說綆關注複合門戶引擎，而非總線。
因此表現服務層版本控制更適合使用消費者綁定模式。在這種情況下，無法依賴UDDI選擇服務來應用此種模式，還需要複合門戶中WebLogic Portal提供的權限。與消費者綁定模式的這種用法有關的一個重要的方面是，版本的選擇通過配置完成，使用門戶管理工具進行，這樣就不會導致任何代碼修改。
下圖表明一個複合門戶怎樣在不同版本的相同應用程序中通過WSRP消費portlet。公開portlet的哪一個版本這一選擇是在基於權限的複合門戶中完成的。
這樣做使同時運行同一應用程序的兩個版本成爲可能，新的功能以基於最終用戶配置文件的約束爲依據，僅展示給試點部分的最終用戶。如果門戶應用程序的J2EE模塊使用相同的上下文路徑，那麼在這種情況下您可能需要給每個版本的門戶應用一個域名（最後包含一個集羣）。
結束語
服務版本控制能否通過不同方式完成取決於需求和約束。處理方式可能有所不同，具體取決於服務所屬的層和發生的業務約束。本篇博客文章提到這樣幾種可能：
- 同時處理多版本服務
- 根據請求者的內容將請求路由到恰當的服務端點
- 使請求與響應相配合，以保持向後兼容
- 用一種良好的方式來使服務更新換代
- 部署不同版本的服務
此外，還有其他一些事項應納入考慮，例如XML 模式版本控制，以及管理服務與其所使用的XML 模式之間的依賴性。在組織水平上管理依賴性，並對改變進行合理的全盤推進，所有這一切都要求具備合適的工具。