服務虛擬化成為一類新興的SOA組件建模工具的基礎。利用一種新的仿真方式，在軟件服務實現之前很久，開發團隊就可以與其協同工作了。

　　這涉及到在創建高質量的復合應用時遇到的某些最大的瓶頸，并幫助敏捷開發工作，努力跟上快節奏的Web應用的步伐。

　　“在應用開發生命周期中植入虛擬化的想法是我們目前所見到的最令人興奮的技術，”Theresa Lanowitz說：“這會使得包括開發、測試及運營團隊在內的IT組織管理可以管理典型的成本、質量及進度的三角關系。”Theresa是Voke Media的創始人兼分析師。

　　這些工具使得軟件開發團隊可以在已有或計劃服務的上下文中，使用預期要交互的新代碼測試新服務的性能及行為。這降低了在開發中測試代碼的門檻，使得在開發過程可以更早更容易地發現缺陷，并打開了SOA應用敏捷開發之門。

　　2003年，Parasoft聲稱其一款產品SOATest體現了服務虛擬化概念。這一術語是在2007年由iTKO在LISA平臺發布時發明出來的。近年來，包括IBM、CA及惠普在內的主流企業軟件供應商已經開發或收購了一些服務虛擬化工具，服務虛擬化已蓄勢待發，準備成為主流的工具類型。IBM最近收購了Greenhat,CA則收購了iTKO,HP也開發了自己的內部工具。

　　Lanowitz說：“市場已經準備好聆聽服務虛擬化在幫助管理成本方面能做些什么。這已經在金融服務、零售、電信及其他組織內部署了高度復合的應用。在測試組織無法接觸大型主機的時候這很有用。”

　　Stub、mock及服務虛擬化

　　傳統上開發者已經建立了stub和mock來表示新代碼需要交互的服務。這一方案把開發者的注意力從寫代碼上轉移，從而減少了其有用的輸出。Peter Cole,Green Hat的前CEO,現在是IBM Rational軟件部質量管理主管說：“開發者針對mock進行測試的時候，他們將服務預期表現出來的行為進行編碼，而不是根據實際情況進行。我們發現最令人生厭的集成問題就是由于不好的假設導致的。”

　　中間件集成是一種不斷復雜化的嘗試。一旦新代碼最終準備就緒，可以拿到實體平臺上進行測試，開發者或測試者就得管理與這一代碼交互的其他服務。在許多情況下這些服務都是運行在開發者不熟悉的平臺上的。“有些開發者把30-50%的時間花在準備測試上面，”Cole說。而另一方面，他繼續說：“虛擬化服務更容易實現和管理。不到15分鐘開發者就能建立幾個虛擬化服務了。”

　　服務虛擬化對代碼有可能需要交互的服務的行為建模。這跟對所有的底層代碼邏輯都進行建模相比要容易得多，ITKO 創始人、現在是CA技術的著名工程師John Michelsen說：“你必須開發軟件的一部分以便與軟件的另一部分行為相匹配，這樣就不會有人知道仿真與實體的區別了。它必須提供相同的界面，但不需要支持所有的底層邏輯。”

　　“客戶也許有10億行自己無法理解的COBOL,”他說。通過仿真或虛擬化服務，他們不再需要理解這10億行代碼，他繼續道，他們只需知道如何與別的應用交互即可。

　　服務虛擬化工具可以移除若干開發過程中對測試硬件可用性、服務及隱私方面的約束，Parasoft 負責戰略企業發展的副總裁Wayne Ariola說。Parasoft最近的一項調查發現組織與平均8到10個受測應用存在依賴關系。而開發者在任何時間點上只能接觸到這些依賴關系的30%.

　　通過服務虛擬化，開發團隊還可以針對新服務的特定行為進行測試，而不是等待代碼開發完畢再開始。這強化了朝著更敏捷、高度迭代開發技術趨勢的演進。服務虛擬化還可以允許組織對敏感數據建模和屏蔽，使得這些數據可以在HIPAA、SOX等隱私約束下進行服務測試。

　　向云計算的演進可能會進一步加快服務虛擬化的應用，惠普應用產品營銷主管Kelly Emo說：“比如說，當作為復合應用的一部分的新業務需求向云遷移時，信貸服務或存貨服務就會倍感壓力，”她說：“從開發團隊的角度看，已有的共享服務會出現非常快速的變化。”

　　更糟糕的場景正等著。實際上，開發團隊往往會陷入等待狀態，Emo說。“他們需要進行端到端的測試，可是服務可能卻還沒有就緒，”她說。這些延誤導致團隊錯過日程安排，或者測試不夠優化。惠普的服務虛擬化產品試圖解決這一瓶頸。

　　美洲銀行是服務虛擬化的早期采用者之一，該公司已經習慣了用這一技術來增加測試的覆蓋面以及改進代碼質量。美洲銀行的前任性能與彈性測試經理Burt Klein說，為了采用傳統測試方法對兩項應用進行測試，該組織一直在考慮使用一款高成本的測試平臺。現在他們可以采用iTKO的一款新的服務虛擬化測試基礎設施來節省投入，現在該產品已經壯大到支撐更多的并發版本。

　　Klein說這個平臺能夠為性能、運營測試提供更好的測試覆蓋面。它們能夠模擬新代碼需要交互的單個服務的性能，從而幫助識別出不同的斷點以及相關行為。在失敗發生時這一知識可以幫助運營團隊識別底層的瓶頸。

　　這一基礎設施工具還極大地改善并加快了尋找、解決缺陷問題的能力，Klein說。在這個案例中，有一個缺陷被認為是完全的失敗或者無法滿足應用的服務水平協議。在第一次部署服務虛擬化之后，錯誤率從每百萬次有18000次失效的幾率下降到了250次。進一步的調優之后錯誤率最終降低為0.0001/百萬。

　　Klein對服務虛擬化的印象異常深刻，以至于他離開了該銀行，自己組建了一個服務虛擬化社區，幫助樹立對該技術的意識，并作為共享最佳實踐的論壇。他解釋說：“我將其視為我的軟件開發生涯中的游戲改變者。”