SOA面向服務架構詳解
一、定義介紹
SOA（Service-Oriented Architecture，面向服務的架構）是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。面向服務架構，它可以根據需求通過網路對鬆散耦合的粗粒度應用元件進行分散式部署、組合和使用。服務層是SOA的基礎，可以直接被應用呼叫，從而有效控制系統中與軟體代理互動的人為依賴性。
SOA是一種粗粒度、鬆耦合服務架構，服務之間通過簡單、精確定義介面進行通訊
SOA將能夠幫助軟體工程師們站在一個新的高度理解企業級架構中的各種元件的開發、部署形式，它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。較之以往，以SOA架構的系統能夠更加從容地面對業務的急劇變化。
二、體系結構
鬆耦合的系統
這種具有中立的介面定義（沒有強制繫結到特定的實現上）的特徵稱為服務之間的鬆耦合。鬆耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程式的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。與之相反，緊耦合意味著應用程式的不同元件之間的介面與其功能和結構是緊密相連的，因而當需要對部分或整個應用程式進行某種形式的更改時，它們就顯得非常脆弱。
對鬆耦合的系統的需要來源於業務應用程式需要根據業務的需要變得更加靈活，以適應不斷變化的環境，比如經常改變的政策、業務級別、業務重點、合作伙伴關係、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為按需（On demand）業務，在按需業務中，一旦需要，就可以對完成或執行任務的方式進行必要的更改。
雖然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向物件的模型的替代模型，面向物件的模型是緊耦合的，已經存在二十多年了。雖然基於 SOA 的系統並不排除使用面向物件的設計來構建單個服務，但是其整體設計卻是面向服務
然而， SOA 已經有所不同了，因為它依賴於一些更新的進展，這些進展是以可擴充套件標記語言（eXtensible Markup Language，XML）為基礎的。通過使用基於XML（標準通用標記語言的子集） 的語言（稱為 Web 服務描述語言（Web Services Definition Language，WSDL））來描述介面，服務已經轉到更動態且更靈活的介面系統中，非以前 CORBA 中的介面描述語言（Interface Definition Language，IDL）可比了。
Web 服務並不是實現 SOA 的惟一方式。前面剛講的 CORBA 是另一種方式，這樣就有了面向訊息的中介軟體（Message-Oriented Middleware）系統，比如 IBM 的 MQseries。但是為了建立體系結構模型，您所需要的並不只是服務描述。您需要定義整個應用程式如何在服務之間執行其工作流。您尤其需要找到業務的操作和業務中所使用的軟體的操作之間的轉換點。因此，SOA 應該能夠將業務的商業流程與它們的技術流程聯絡起來，並且對映這兩者之間的關係。例如，給供應商付款的操作是商業流程，而更新您的零件資料庫，以包括進新供應的貨物卻是技術流程。因而，工作流還可以在 SOA 的設計中扮演重要的角色。
此外，動態業務的工作流不僅可以包括部門之間的操作，甚至還可以包括與不為您控制的外部合作伙伴進行的操作。因此，為了提高效率，您需要定義應該如何得知服務之間的關係的策略，這種策略常常採用服務級協定和操作策略的形式。
最後，所有這些都必須處於一個信任和可靠的環境之中，以同預期的一樣根據約定的條款來執行流程。因此，安全、信任和可靠的訊息傳遞應該在任何 SOA 中都起著重要的作用。
三、體系結構作用
我可以用面向服務的體系結構做什麼？
對 SOA 的需要來源於需要使業務 IT 系統變得更加靈活，以適應業務中的改變。通過允許強定義的關係和依然靈活的特定實現，IT 系統既可以利用現有系統的功能，又可以準備在以後做一些改變來滿足它們之間互動的需要。
下面舉一個具體的例子。一個服裝零售組織擁有 500 家國際連鎖店，它們常常需要更改設計來趕上時尚的潮流。這可能意味著不僅需要更改樣式和顏色，甚至還可能需要更換布料、製造商和可交付的產品。如果零售商和製造商之間的系統不相容，那麼從一個供應商到另一個供應商的更換可能就是一個非常複雜的軟體流程。通過利用 WSDL 介面在操作方面的靈活性，每個公司都可以將它們的現有系統保持現狀，而僅僅匹配 WSDL 介面並制訂新的服務級協定，這樣就不必完全重構它們的軟體系統了。這是業務的水平改變，也就是說，它們改變的是合作伙伴，而所有的業務操作基本上都保持不變。這裡，業務介面可以作少許改變，而內部操作卻不需要改變，之所以這樣做，僅僅是為了能夠與外部合作伙伴一起工作。
另一種形式是內部改變，在這種改變中，零售組織決定它還將把連鎖零售商店內的一些地方出租給專賣流行衣服的小商店，這可以看作是採用店中店（store-in-store）的業務模型。這裡，雖然公司的大多數業務操作都保持不變，但是它們需要新的內部軟體來處理這樣的出租安排。儘管在內部軟體系統可以承受全面的檢修，但是它們需要在這樣做的同時不會對與現有的供應商系統的互動產生大的影響。在這種情況下，SOA 模型保持原封不動，而內部實現卻發生了變化。雖然可以將新的方面新增到 SOA 模型中來加入新的出租安排的職責，但是正常的零售管理系統繼續如往常一樣。
為了延續內部改變的觀念，IT 經理可能會發現，軟體的新配置還可以以另外的一種方式加以使用，比如出租貼上海報的地方以供廣告之用。這裡，新的業務提議是通過在新的設計中重用靈活的 SOA 模型得出的。這是來自 SOA 模型的新成果，並且還是一個新的機會，而這樣的新機會在以前可能是不會有的。
垂直改變也是可能的，在這種改變中，零售商從銷售他們自己的服裝完全轉變到專門通過店中店模型出租地方。如果垂直改變完全從最底層開始的話，就會帶來 SOA 模型結構的顯著改變，與之一起改變的還可能有新的系統、軟體、流程以及關係。在這種情況下，SOA 模型的好處是它從業務操作和流程的角度考慮問題而不是從應用程式和程式的角度考慮問題，這使得業務管理可以根據業務的操作清楚地確定什麼需要新增、修改或刪除。然後可以將軟體系統構造為適合業務處理的方式，而不是在許多現有的軟體平臺上常常看到的其他方式。
正如您可以看到的，在這裡，改變和 SOA 系統適應改變的能力是最重要的部分。對於開發人員來說，這樣的改變無論是在他們工作的範圍之內還是在他們工作的範圍之外都有可能發生，這取決於是否有改變需要知道介面是如何定義的以及它們相互之間如何進行互動。與開發人員不同的是，架構師的作用就是引起對 SOA 模型大的改變。這種分工，就是讓開發人員集中精力於建立作為服務定義的功能單元，而讓架構師和建模人員集中精力於如何將這些單元適當地組織在一起，它已經有十多年的歷史了，通常用統一建模語言（Unified Modeling Language，UML），並且描述成模型驅動的體系結構（Model-Driven Architecture，MDA）。
對於面向同步和非同步應用的，基於請求/響應模式的分散式計算來說，SOA是一場革命。一個應用程式的業務邏輯（business logic）或某些單獨的功能被模組化並作為服務呈現給消費者或客戶端。這些服務的關鍵是他們的鬆耦合特性。例如，服務的介面和實現相獨立。應用開發人員或者系統整合者可以通過組合一個或多個服務來構建應用，而無須理解服務的底層實現。舉例來說，一個服務可以用.NET或J2EE來實現，而使用該服務的應用程式可以在不同的平臺之上，使用的語言也可以不同。.
四、特性狀況
基本特徵
SOA的實施具有幾個鮮明的基本特徵。實施SOA的關鍵目標是實現企業IT資產的最大化作用。要實現這一目標，就要在實施SOA的過程中牢記以下特徵：
（1）可從企業外部訪問
（2）隨時可用
（3）粗粒度的服務介面分級
（4）鬆散耦合
（5）可重用的服務
（6）服務介面設計管理
（7）標準化的服務介面
（8）支援各種訊息模式
（9）精確定義的服務契約
SOA服務具有平臺獨立的自我描述XML文件。Web服務描述語言（WSDL， Web Services Description Language）是用於描述服務的標準語言。
SOA 服務用訊息進行通訊，該訊息通常使用XML Schema來定義（也叫做XSD， XML Schema Definition）。消費者和提供者或消費者和服務之間的通訊多見於不知道提供者的環境中。服務間的通訊也可以看作企業內部處理的關鍵商業文件。
在一個企業內部，SOA服務通過一個扮演目錄列表（directory listing）角色的登記處（Registry）來進行維護。應用程式在登記處（Registry）尋找並呼叫某項服務。統一描述，定義和整合（UDDI， Universal Description， Definition， and Integration）是服務登記的標準。
每項SOA服務都有一個與之相關的服務品質（QoS， quality of service）。QoS的一些關鍵元素有安全需求（例如認證和授權），可靠通訊（譯註：可靠訊息是指確保訊息“僅且僅僅”傳送一次，從而過濾重複資訊。），以及誰能呼叫服務的策略。
五、新興變革
隨著全球資訊化的浪潮，資訊化產業不斷髮展、延伸，已經深入了眾多的企業及個人，SOA系統架構的出現，將給資訊化帶來一場新的革命。
縱觀資訊化建設與應用的歷程，儘管出現過XML（標準通用標記語言的子集）、Unicode、UML等眾多資訊標準，但是許多異構系統之間的資料來源仍然使用各自獨立的資料格式、元資料以及元模型，這是資訊產品提供商一直以來形成的習慣。各個相對獨立的源資料整合一起，往往通過構建一定的資料獲取與計算程式來實現，這樣的做法需要花費大量工作。資訊孤島大量存在的事實，使資訊化建設的ROI（投資回報率）大大降低，ETL成為集中這些異構資料的有效工具。 ETL常用於從源系統中提取資料，將資料轉換為與目標系統相相容的格式，然後將其裝載到目標系統中。資料經過獲取、轉換、裝載後，要產生應用價值，還需另外的資料展現工具予以實現，如此複雜的資料應用過程，必定產生高昂的應用成本。
結構化的資料管理尚可通過以上方法，予以實現其整合應用。在非結構化的內容方面，這些具有挑戰性的問題令人生畏。內容管理的應用方案基於不同的資訊化應用系統，而且大部分是縱向的以組織部門為界限的。在內容管理市場中，經常使用來自不同廠商的產品來提供這些解決方案。即使是同一個廠商的產品，相互之間的功能也是經常重疊，並且無法整合。
隨著資訊化建設的深入，不同應用系統之間的功能界限已趨於模糊。同時企業資源計劃系統和協同商務系統，又需要商業智慧的分析展現資料提供使用者操作依據。
在激烈競爭且多變的市場環境下，企業的管理模式很難固化，應用傳統的資訊化軟體，當企業要做出一些改動時需要面對巨大的挑戰。
SOA系統架構的出現，資訊化變革
微軟大中華區服務部總經理辛兒倫介紹說，從上世紀60年代應用於主機的大型主機系統，到80年代應用於PC的CS 架構，一直到90年代網際網路的出現，系統越來越朝小型化和分散式發展。2000年WebService出現後，SOA被譽為下一代Web服務的基礎框架，已經成為計算機資訊領域的一個新的發展方向。
SOA的出現給傳統的資訊化產業帶來新的概念，不再是各自獨立的架構形式，能夠輕鬆的互相聯絡組合共享資訊。
可複用以往的資訊化軟體。基於SOA的協同軟體提供了應用整合功能，能夠將ERP、CRM、HR等異構系統的資料整合。
鬆散耦合方式，只要充分了解業務的程序，就可以不用編寫一行程式碼，通過流程圖實現一套我們自己的資訊系統。就像已經給你準備好了磚瓦和水泥，只需要想好蓋什麼樣的房子就可以輕鬆的蓋起。加快開發速度，並且減少了開發和維護的費用。軟體將所有的管理提煉成表單和流程，以記錄管理的內容，指定過程的流轉方向。
更簡便的資訊和資料整合。資訊整合功能可以將散落在廣域網和區域網上的文件、目錄、網頁輕鬆整合，加強了資訊的協同相關性。同時，複雜、成本高昂的資料整合，也變成了可以簡單且低成本實現的引數設定。建立了完全整合的資訊化應用新領域。
在具體的功能實現上，SOA協同軟體所實現的功能包括了知識管理、流程管理、人事管理、客戶管理、專案管理、應用整合等，從部門角度看涉及了行政、後勤、營銷、物流、生產等。從應用思想上看，SOA協同軟體中的資訊管理功能，全面兼顧了貫穿整個企業組織的資訊化軟硬體投入。儘管各種IT技術可以用於不同的用途，但是資訊管理並沒有任意地將資訊分為結構化或者非結構化的部分，因此ERP等結構化管理系統並不是資訊化建設的全部；同時，資訊管理也沒有將資訊化解決方案劃分為部門的檢視，因此僅僅以部分為界限去構建軟體應用功能的思想未必是不可撼動的。基於SOA的協同軟體與 ERP、CRM等傳統應用軟體相比，關鍵的不同在於它可以在合適的時間、合適的地點並且有正當理由向需要它提供服務的任何使用者提供服務。
六、為何選擇SOA
簡介介紹
不同種類的作業系統，應用軟體，系統軟體和應用基礎結構（application infrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程式被用來處理當前的業務流程（business processes），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程式和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個可以支援有機業務（organic business）的構架。SOA憑藉其鬆耦合的特性，使得企業可以按照模組化的方式來新增新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，並可以把企業現有的或已有的應用作為服務， 從而保護了現有的IT基礎建設投資。
一個使用SOA的企業，可以使用一組現有的應用來建立一個供應鏈複合應用（supply chain composite application），這些現有的應用通過標準介面來提供功能。
服務架構
為了實現SOA，企業需要一個服務架構，下圖顯示了一個例子：
在上圖中， 服務消費者（service consumer）可以通過傳送訊息來呼叫服務。這些訊息由一個服務匯流排（service bus）轉換後傳送給適當的服務實現。這種服務架構可以提供一個業務規則引（business rules engine），該引擎容許業務規則被合併在一個服務裡或多個服務裡。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似稽核，列表（billing），日誌等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），並且可以在不影響其他服務的情況下更改某項服務。
基礎結構
要執行，管理SOA應用程式，企業需要SOA基礎，這是SOA平臺的一個部分。SOA基礎必須支援所有的相關標準，和需要的執行時容器。下圖所示的是一個典型的SOA基礎結構。
SOAP， WSDL， UDDI
WSDL，UDDI和SOAP是SOA基礎的基礎部件。WSDL用來描述服務；UDDI用來註冊和查詢服務；而SOAP，作為傳輸層，用來在消費者和服務提供者之間傳送訊息。SOAP是Web服務的預設機制，其他的技術為可以服務實現其他型別的繫結。一個消費者可以在UDDI登錄檔（registry）查詢服務，取得服務的WSDL描述，然後通過SOAP來呼叫服務。
WS-I Basic Profile
WS-I Basic Profile，由Web服務互用性組織（Web Services Interoperability Organization）提供，是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用Basic Profile測試程式來測試服務在不同平臺和技術上的互用性。
J2EE 和 .Net
儘管J2EE和.NET平臺是開發SOA應用程式常用的平臺，但SOA不僅限於此。像J2EE這類平臺，不僅為開發者自然而然地參與到SOA中來提供了一個平臺，還通過他們內在的特性，將可擴充套件性，可靠性，可用性以及效能引入了SOA世界。新的規範，例如 JAXB（Java API for XML Binding），用於將XML文件定位到Java類；JAXR（Java API for XML Registry）用來規範對UDDI登錄檔（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用來呼叫遠端服務，這使得開發和部署可移植於標準J2EE容器的Web服務變得容易，與此同時，實現了跨平臺（如.NET）的服務互用。
服務品質
在企業中，關鍵任務系統（mission-critical system，譯註：關鍵任務系統是指如果一個系統的可靠性對於一個組織是至關重要的，那麼該系統就是該企業的關鍵任務系統。比如，電話系統對於一個電話促銷企業來說就是關鍵任務系統，而文書處理系統就不那麼關鍵了。）用來解決高階需求，例如安全性，可靠性，事物。當一個企業開始採用服務架構作為工具來進行開發和部署應用的時候，基本的Web服務規範，像WSDL，SOAP，以及UDDI就不能滿足這些高階需求。正如前面所提到的，這些需求也稱作服務品質（QoS，quality of services）。與QoS相關的眾多規範已經由一些標準化組織（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分將會討論一些QoS服務和相關標準。
安全質量
Web服務安全規範用來保證訊息的安全性。該規範主要包括認證交換， 訊息完整性和訊息保密。該規範吸引人的地方在於它藉助現有的安全標準，例如，SAML（as Security Assertion Markup Language）來實現web服務訊息的安全。OASIS正致力於Web服務安全規範的制定。
可靠信度
在典型的SOA 環境中，服務消費者和服務提供者之間會有幾種不同的文件在進行交換。具有諸如“僅且僅僅傳送一次”（ once-and-only-once delivery），“最多傳送一次”（ at-most-once delivery），“重複訊息過濾”（duplicate message elimination），“保證訊息傳送”（guaranteed message delivery）等特性訊息的傳送和確認，在關鍵任務系統（mission-critical systems）中變得十分重要。WS-Reliability 和 WS-ReliableMessaging是兩個用來解決此類問題的標準。這些標準都由OASIS負責。
策略計劃
服務提供者有時候會要求服務消費者與某種策略通訊。比如，服務提供商可能會要求消費者提供Kerberos安全標示，才能取得某項服務。這些要求被定義為策略斷言（policy assertions）。一項策略可能會包含多個斷言。WS-Policy用來標準化服務消費者和服務提供者之間的策略通訊。
控制能力
當企業著手於服務架構時，服務可以用來整合資料倉庫（silos of data），應用程式，以及元件。整合應用意味著例如非同步通訊，並行處理，資料轉換，以及校正等程序請求必須被標準化。在SOA中，程序是使用一組離散的服務建立的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用來控制這些服務的語言。WSBPEL也由OASIS負責。
管理能力
隨著企業服務的增長，所使用的服務和業務程序的數量也隨之增加，一個用來讓系統管理員管理所有執行在多相環境下的服務的管理系統就顯得尤為重要。WSDM（Web Services for Distributed Management）規定了任何根據WSDM實現的服務都可以由一個WSDM適應（WSDM-compliant）的管理方案來管理。
其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination 和 WS-Transaction 標準中描述， 這些都是OASIS 的工作。
Web服務
在理解SOA和Web服務的關係上，經常發生混淆。根據2003年4月的Gartner報道，Yefim V. Natis就這個問題是這樣解釋的：“Web服務是技術規範，而SOA是設計原則。特別是Web服務中的WSDL，是一個SOA配套的介面定義標準：這是Web服務和SOA的根本聯絡。”從本質上來說，SOA是一種架構模式，而Web服務是利用一組標準實現的服務。Web服務是實現SOA的方式之一。用Web服務來實現SOA的好處是你可以實現一箇中立平臺，來獲得服務，而且隨著越來越多的軟體商支援越來越多的Web服務規範，你會取得更好的通用性。
SOA優勢
SOA的概念並非什麼新東西，SOA不同於現有的分散式技術之處在於大多數軟體商接受它並有可以實現SOA的平臺或應用程式。SOA伴隨著無處不在的標準，為企業的現有資產或投資帶來了更好的重用性。SOA能夠在最新的和現有的應用之上建立應用；SOA能夠使客戶或服務消費者免予服務實現的改變所帶來的影響；SOA能夠升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經不再適用於新需求的現有系統。總而言之，SOA以藉助現有的應用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程式和業務流程。
發展效益
A. 平衡最初的舊系統投資(Leverage initial investment)：
組織過去所投資的系統、軟硬體，如果能再利用等於賦予其新的價值，這也替組織降低成本並增加競爭力。
B. 基礎建設的便利性(Infrastructure Commoditization)：
讓所有的應用程式能相互溝通(互通性)。
C. 快速的接近市場(Faster time-to-market)：
服務的重複使用(再利用)，來縮短過去的組織流程，更快速的提供服務來接近市場。
D. 減少支出(Reduce Cost)：
服務的重複使用，可降低開發成本。因為開發新系統的成本，大部份比更新舊有系統來的花費大。
E. 減低風險(Risk mitigation)：
開發新系統的風險遠大於更新舊系統。
F. 持續改善商業流程的迴圈(Continuous improvement cycle for business process)
G. 中心流程處理(Process-centric processing)
主要優勢
一，SOA可通過網際網路伺服器釋出，從而突破企業內網的限制，實現與供應鏈上下游夥伴業務的緊密結合。通過SOA架構，企業可以與其業務夥伴直接建立新渠道，建立新夥伴的成本得以降低。
二，SOA與平臺無關，減少了業務應用實現的限制。要將企業的業務夥伴整合到企業的“大”業務系統中，對其業務夥伴具體採用什麼技術沒有限制。
三， SOA具有低耦合性特點，業務夥伴對整個業務系統的影響較低。在企業與各業務夥伴關係不斷髮生變化的情況下，節省的費用會越來越多。
四， SOA具有可按模組分階段進行實施的優勢。可以成功一步再做下一步，將實施對企業的衝擊減少到最小。
五， SOA的實施可能並不具有成本顯著性。這要分三種情況加以討論：
(1) 當企業從零開始構建業務系統時，採用SOA架構與不採用SOA架構成本可看做是相同的。
(2) 當企業業務發展或發生企業重組等變化而原有系統不能滿足需要，而需要重構業務系統時，採用SOA架構與不採用SOA架構成本可看做是相同的。
(3) 當企業業務發生緩慢變化並可預見到將來需要重構業務系統時，由於可以按模組分階段逐步實施SOA以適應變化的需要，這樣企業不需一下投入一大筆經費進行系統改造，而是根據企業業務發展情況和資金情況逐步投入，緩解了資訊投入的壓力。
推動因素
IDC負責企業平臺研究的副總裁Michelle Bailey說，最近的IDC的研究表明，到2011年，18%以上的全部新伺服器都將採用虛擬化技術，對於伺服器硬體供應商來說，這是一個年收入達220億美元的市場機會。
對於企業來說，日益增長的挑戰是如何管理和保證虛擬環境的安全，因為隨著機構採用虛擬化技術，傳統的管理物理伺服器蔓延的挑戰正在轉向管理虛擬機器蔓延的挑戰。機構將需要可靠的、穩定的、安全的和可管理的虛擬化解決方案。
綠色IT一直被列為頭號的戰略技術和2008年大多數機構的趨勢。據IDC稱，虛擬化的綠色的好處不僅是減少伺服器佔地面積，而是還包括減少碳排放量和耗電量。這些好處正在成為重要的好處。
據IDC對亞太地區綠色IT的調查，75%的受訪者對於IT部門沒有綠色IT政策。然而，80%以上的受訪者認為他們的IT供應商的“綠色”在未來幾年將更加重要。
虛擬化在這方面將發揮重要作用，一些企業將採用更環保的方法經營業務以便贏得政府部門的合同。其它機構正在採用虛擬化技術以便得到節省電源的好處和減少碳排放量的獎勵。
同時，一些企業管理者和市場研究人士也對虛擬化的未來發展發表了看法：
Avnet公司營銷經理Michael Costigan：
儘管虛擬化有巨大的潛力，許多轉銷商不知道這種有潛力的新技術的實際狀況。機構能夠獲得顯著的能量和計算效率，同時提高技術的應用率和靈活性。
為了幫助你的客戶認識到這些好處並且為你的企業建立強大的市場佔有率，你需要了解這個強大的新技術的細節，瞭解需要採取什麼有效手段識別和利用虛擬化的真正機會。
虛擬化正在用來解決範圍日益廣泛的商業目標和挑戰，如伺服器整合/保留、業務持續性、測試/開發優化、軟體開發與釋出以及桌面管理和安全。
人們對於虛擬化的未來顯然非常感興趣。但是，還有許多言過其實的宣傳。第一波x86伺服器虛擬化的應用一直集中在伺服器整合方面，重點是減少資本開支 (也就是伺服器開支)以及電源和冷卻等運營開支。在未來的五年裡，機構將超越伺服器整合尋求如何利用虛擬化技術得到其它的好處，如重點減少運營成本(也就是物理管理成本)和讓基礎設施更有活力和更靈活，以便改善IT對於不斷變化的商業需求的反應能力。
分析師認為，虛擬化的下一個大事將是高可用性和災難恢復工具。災難恢復在歷史上一直是非常難管理的。虛擬化將提供一個節省成本的和容易管理的災難恢復解決方案。
虛擬桌面基礎設施、資源平衡和應用程式級高可用性可能是其它的未來應用例項。這些解決方案有一些技術的和經濟的障礙。這些障礙必須要在虛擬化廣泛應用前克服。但是，考慮到虛擬化的重點，這些障礙已經在開始克服。虛擬化還將成為SOA(面向服務的架構)技術應用的推動因素。 [4] 面向服務的體系結構基於這些實際活動或業務服務進行組織，而不是形成公司所維護的不同的資訊豎井 (Silo)。通過實現 SOA，可以帶來大量好處，包括以下各個方面： *更高的業務和 IT 一致性
*基於元件的系統
*鬆散耦合的元件和系統
*基於網路的基礎設施，允許分散於各地且採用不同技術的資源協同工作
*動態構建的按需應用程式
*更高的程式碼重用率
*更好地標準化整個企業內的流程
*更易於集中企業控制
七、優點
服務導向架構並不是一種全新的解決方案；相反，SOA是技術與架構的自然進化。系統架構一直在不斷進步，與商業保持高度一致。系統設計師與商家很早就認識到將技術與商業流程相協調的重要性，包括充分應用併合理化技術資源，以及為商業提供更好的支援。
SOA也在一定程度上源於早已有之的企業架構理論。企業架構對技術進行評估，但是更重要的是，它關注整個企業和全部的商業流程並提供了做出技術決策的背景資訊。SOA工具則融合了網際網路技術，如HTTP和XML，以及綜合技術，如訊息匯流排、轉譯技術和連線技術。