目前，主要企業都依賴多種分佈式技術和新的功能，如SOA等。虛擬化能夠提高這些系統的質量和上市的時間。但是，團隊如何實施虛擬化以便提高不在一個集中的團隊控制下的SOA功能和加快上市時間呢?這個擴展的機構必須要通過把共享的服務行爲虛擬化才能把這兩個戰略聯繫起來，從而成倍增加SOA的價值。
三種類型的SOA虛擬化
企業在SOA中應用虛擬化的概念有三種獨特的方法：
1、硬件虛擬化包括在一個硬件設備中，以虛擬機的方式運行多個版本的操作系統。這將爲在數據中心運行的內部應用程序提供更低的成本、更大的靈活性和風險管理的好處，並且爲SOA系統提供一個複製測試平臺的有用的途徑。
2、虛擬端點能夠在你與這個實際的端點隔離開來的時候允許SOA定義服務的虛擬位置。這對於SOA應用程序中固有的動態流程是很理想的，因爲一個服務的物理地址也許需要根據它什麼時候和如何用作一個指定的工作流的一部分而進行改變。
3、虛擬服務不僅僅是對SOA測試有用。虛擬服務通過優化整個實踐的開發和應用來提高價值。
對於SOA應用生命週期的其它方面來說，我們創建虛擬測試平臺的努力只能達到這個程度。企業通常爲了驗證和開發SOA而依靠實時的實施。然而，這些複雜的相互連接的環境能夠通過硬件虛擬化技術複製。我們需要把虛擬化擴展到實際的分佈式軟件組件中和在這些環境中運行的服務中。
如果SOA不能虛擬化，它就沒有靈活性
在硬件和數據中心的級別上實施虛擬化可以產生立竿見影的節省運營成本的回報，可直接節省數百萬美元IT成本。
然而，當我們把組件或者服務開發任務分配給多個團隊的時候，我們經常忘記這些團隊仍需要實時訪問這個應用程序的其它部分以完成自己的開發和測試目標。所有這些團隊之間仍需要高水平的依賴性和相互溝通以提供一個完整的工作流。對於大規模企業系統來說，這給SOA的投資回報提出了嚴格的限制。
有一種方法可以是使用SOV(面向服務的虛擬化)把這兩種技術聯繫起來：模擬應用軟件資產行爲的策略以及合成製作企業SOA應用程序的組件。不利用SOV的優勢，在整個企業範圍內最大限度地實現SOA價值是很困難的，如果不是不可能的話。
挑戰：SOA的障礙
企業採用SOA的最佳做法實現商業靈活性和成本的好處。遺憾的是，當SOA應用程序試圖通過升級來滿足大型企業的現實需求的時候，最佳的SOA架構和治理戰略仍很缺乏，即使擁有虛擬的服務器也是如此。出現這種事情有若干原因。
共享的系統資源的衝突
SOA就是通過把企業系統當作共享的服務提供來發揮企業系統的優勢。然而，訪問共享的資源問題危害每一個單獨的SOA計劃。一個主要的ERP系統管理員或者大型計算機管理員可能會對他們在生產中的應用程序採取保護措施，限制開發和測試團隊直接訪問這個應用程序以避免出現不可預料的問題。
此外，即使允許訪問，實時的服務經常會受到一個SOA環境中的多個機構需求的限制。當各個團隊被迫排隊等候訪問一個現實的環境以便進行測試和開發的時候，靈活性就受到了影響。在大型企業應用程序中，通過硬件虛擬化本身創建另一個環境的實例成本太高，是不允許的。
不連貫的開發和整合生命週期
開發人員需要把服務接口做成一個佔位符模型以便確定他們的服務如何與其它服務互操作。例如，一個開發團隊正在擴建用戶數據，而第二個開發團隊正在創建賬戶數據。由於這些應用程序是並行開發的，這兩個團對需要相互依賴對方的服務。每一個團隊都需要依靠訪問接近完成或者已經實施的服務來證明他們自己的服務能夠正確地互操作。
SOA通過把鬆散耦合的組件當作服務來實現靈活性。因此，更小的和更分散的團隊能夠並行開發和集成這些服務。當仍然存在依賴性的時候，我們如何才能達到這種並行開發的水平呢?看一下這個典型的項目計劃或者甘特進度表。在下一個開發團隊繼續開發下一個組件的之前，肯行會遇到一個項目中可用組件的下一個“依賴性”。這正是我們希望用SOA打破的一個模式。
增加的複雜性和異質性
雖然許多做SOA的計劃都是以Web服務(WSDL/SOAP)爲中心的，但是，在最佳的企業實施的SOA計劃中只有大約50%是基於Web服務的。有多種技術可以用來創建SOA中間件軟件。這些SOA中間件軟件也許是非常合法的，對於一個指定的機構來說也許比一個Web服務棧更好，例如使用一個幾乎不依賴Web服務的企業服務總線。要保證SOA的質量，各個團隊需要驗證實施狀況和對各種不同技術產生的副作用，而不僅僅測試自己選擇的Web服務或者中間件軟件層。
SOA測試環境維護和技術支持的高成本
要向一個SOA應用程序提供服務，許多機構試圖複製和維護自己的測試環境。然而，複製他們需要在自己的過渡環境中進行交流的全部組件是一個成本非常高的過程。它需要高水平的配置、許可證成本和維護，以保證那個測試構件保持最新狀態，即使它是在虛擬的硬件中運行也是如此(虛擬的硬件也有一些增量的許可證成本)。SOA利用的許多企業系統都太大了，有太多的開銷，不能實施虛擬化。
不要試圖通過複製數十個變化的服務來創建一個巨大的測試基礎設施，SOA需要一個策略解除這些團隊對這些實施的依賴。這將提供一種根據部署中存在的現實狀況進行測試和開發的方法。
數據和系統記錄的龐大規模
達到企業級SOA應用水平的最後(也許是最困難的)障礙是需要管理的系統和數據的龐大規模。要測試一個SOA應用程序的實際效果，機構需要輸入一套逼真的數據，然後離開正在測試中的環境。
雖然他們能夠在架構和設計過程中根據制定的元數據描繪出與其它服務之間的互動，但是，一旦他們通過連接這些端點的理想的模型，他們還必須要應付一個CRM大型計算機或者企業系統以及這些系統的管理者。嵌入在這些層的數據和商業邏輯在過去的若干年裏已經增加並且客戶化了。把這個系統和數據製作成完整的鏡像副本並且根據另一個企業許可證和實施團隊的要求進行測試成本太高了。
引進面向服務的驗證
SOV(面向服務的虛擬化)是一種IT策略，它要模擬組成一個SOA應用程序的軟件資產的實際行爲，進而使開發和測試團隊擺脫對應用的服務及其基本實施層的依賴。
SOV包括建模和模擬設計之中和應用的服務以及虛擬的服務。這些虛擬的服務將提供給擴展的SOA團隊進行測試並且開發自己的服務和工作流，不用依靠這些服務的實例。當各個團隊擺脫了對應用的服務和實施層的依賴的時候，提高的靈活性、更快的上市時間和減少的交付成本等擴展的SOA的好處就全部實現了。要做個比喻的話，SOV是針對SOA的，就像硬件虛擬化是針對數據中心的一樣。
在SOA生命週期中的SOV的例子
SOV不僅影響完成的應用程序的質量，它在加快SOA生命週期的開發和治理過程中發揮着巨大作用。目前在企業中還沒有出現更多的採用SOV的做法。
SOV應用實例1：靈活開發SOA新功能
企業正在脫離昨天單一的發展緩慢的“宇宙大爆炸”式的實施方法。那個時候，整個應用程序的開發、測試和發佈都是一個連續進行的過程，通常是在一個權威機構的領導下。
今天，應用程序是鬆散耦合式的一些服務的集合，是在運行時間作爲靈活的工作流的情況下靈活消費的，由靈活的開發人員和合作伙伴組成的分佈式的團隊進行管理的。一個靈活的SOA應用程序基礎設施能夠非常靈活地滿足不斷變化的商業需求。
爲了提供能夠滿足商業要求的服務，開發人員和QA團隊必須要針對當前正在開發中的虛擬服務進行測試。如果企業要得到SOA的靈活性的好處，所有的團隊必須在自己的生命週期並行開發和發佈自己的服務，不要等待其他人。
SOA方法
不要等待其它團隊提供訪問已經完成的服務進行測試，這個團隊要製作他們作爲虛擬服務所依靠的那些服務行爲的模型。一個團隊需要一個服務的副本進行對照測試和開發。這個團隊要把一個服務的行爲、它對刺激的控制和反應以及它的基礎的實施和數據作爲一個整體進行分析並且製作一個虛擬服務的模型。一個服務開發人員在開發的時候還能夠以虛擬服務的方式發佈一個自己服務的完整版本或者“未來的”版本。其它開發和QA(品質保證)團隊將利用這個虛擬的服務測試自己的服務。這將節省開發/QA成本和減少編寫客戶化測試客戶端軟件或“模擬服務”的時間。這些模擬服務不是附屬服務的真正行爲的實際模型。它允許在整個機構中進行高度並行的、靈活的開發和測試協作，以便用新的功能保證更快和更有預見性的上市時間。
例子：提供訪問以重新獲得靈活性
一家主要金融服務公司把它集中的開發功能按照SOA式的模型分爲不同的商務流程，讓專業服務開發團隊實現更短的服務交付週期。雖然最初的結果顯示了更快的交付過程，但是，隨着支持SOA應用程序的更多新服務開始應用，出現了客戶技術支持需求量大幅度增長的問題。
爲了解決這個問題，這家公司恢復了對發佈的集中控制，要求在11月之前提交所有的“最終服務，以便爲計劃在1月份完成的兩個月的測試周期創建一個完整的SOA的總體環境。如果在一年的測試周期中出現任何錯誤，這個系統管理員會把這些候選的服務退回到以前的版本。這就意味着一個開發週期是一年，如果一切正確才能發佈。這種做法按照任何定義都是不靈活的。
通過使用一個SOV模型，這家公司現在能夠把這個一年的週期分爲若干部分。開發團隊現在能夠根據目標環境創建一個模型，並且根據需要針對這個環境進行虛擬服務和產品測試。他們還能夠向其它附屬團隊提供一個託管的虛擬服務，這樣，他們就能獲得進行測試的早期的資產。因此，這家公司解散了它的控制委員會，採用每個季度發佈一次的週期(這個發佈週期是連續不斷的和靈活的)，並且建立和測試對用戶的需求反應更明顯的活動。
SOV應用實例2：複製一個完整的SOA環境
在一個內部應用程序開發過程中，在虛擬機上運行的虛擬化硬件和虛擬測試平臺是複製服務器環境的一種有效方法。它爲對照現有的軟件開發新的軟件組件提供一個良好的開發和測試的基準線。這種做法可節省硬件和設置成本。然而，SOA應用程序通常需要與那些不在任何集中的團隊控制之下的第三方系統進行互動。此外，它們需要連接到商業的“基礎的”系統(大型計算機、ERP系統等)。每一個系統都是數十億美元的設備，裏面有大量的重要數據。在開發期間向這些系統發送測試數據是被禁止的，因爲測試負擔會引起關鍵系統發生故障或者出現不可預料的後果。而且，從系統開銷和配置成本方面來說，通過硬件虛擬化複製這樣龐大的系統都是不可能的。
通過面向服務的虛擬化(SOV)設置和維護一些互相依賴的組件的一個完整的測試環境爲一個完整的SOA應用程序實例複製SOA應用程序的行爲在維護和技術支持的成本方面不允許的，即使採用虛擬機複製某些功能也是如此。
這種SOV的做法虛擬化了正在測試之中的整個系統的模擬版本的行爲。爲了每一個團對訪問相關的測試和開發過程，捕捉和模擬系統需要的大多數行爲的能力將取代複製的需求。
SOV方法 ·通過把連接的服務模擬爲虛擬的服務在服務環境中取代實時受限制的應用程序，無論這些服務是來自WSDL還是根據基礎實施和整合層模擬的。在這些組件能夠用於這些活動的理想時候，要重新捕捉和重新模擬新的服務組件，提供比複製的SOA實例更新的目標服務的模型。這需要幾個星期或者幾個月的時間才能組裝完成。在SOA應用程序中演練所有的系統以創建一個真實數據的豐富的測試平臺。這些真實的數據將用來驅動這個虛擬服務的動態行爲。在脫離應用的服務的隔離環境中進行開發和測試(在測試和開發中採用SOV方法，並且修改時間不取代在應用期間實時安裝的服務的集成測試)。
通過按照這個模型操作，企業能夠節省數百萬美元的硬件、軟件和維護成本，在不影響當前運營的情況下加快產品的上市時間。
例子：解決電子商務背後完整的數據圖片
一家全球的高科技廠商正在實施一個新的電子商務解決方案。這個電子商務解決方案需要連接到一個主要的CRM平臺、一個ERP系統以及其它存貨和物流系統。雖然使用選擇的標準很容易測試這些基本的Web層的可升級性和兼容性，但是，沒有它們背後的數據相互交流情況來進行測試，因爲這些系統已經在使用並且在管理重要的訂單。
這家公司沒有複製這些昂貴的系統，而是採用SOV流程捕捉數千個與它們交流的這些大型機和服務層之間進行的實時處理和相互作用(有正結果和負結果)。然後，這個豐富的數據集可驅動一些大型計算機的相關的虛擬服務，讓這個團隊及時地並且以低於預算的成本提供一個非常可靠的新系統。
下一步：從SOV向SOA集成過渡
一旦SOV的所有的協作開發和測試工作全部完成，這個虛擬服務便進入了實際集成過程的後臺。SOV不取代真正的集成測試、性能測試和實時SOA應用程序的功能驗證等實際需求。如何這個企業不能恰當地讓定義這個服務相互作用的元數據滿足商業目標的需求，它就很難產生積極的結果。
一個有效的SOV戰略提供兩方面的價值：
1、靈活性：最大限度地在整個分佈式SOA開發和測試團隊中協作，讓這些團隊進行並行的開發並且採取把新產品和新功能更快推向市場的發佈週期。
2、降低成本：通過軟件許可證、配置、維護、數據管理、開發和測試效率等方式在每個SOA環境中節省數百萬IT成本。越多地採取協作的開發方式，目標SOA應用程序就越有相互依賴性，虛擬服務能夠提供的潛在的好處就越大。
確實，對於擁有分佈式團隊和資源的任何大型企業應用來說，不採取SOV的做法SOA就不能完全取得成功。