面向服務的體系結構（service-oriented architecture，SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。
這種具有中立的接口定義（沒有強制綁定到特定的實現上）的特征稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程序的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。而另一方面，緊耦合意味著應用程序的不同組件之間的接口與其功能和結構是緊密相連的，因而當需要對部分或整個應用程序進行某種形式的更改時，它們就顯得非常脆弱。
對松耦合的系統的需要來源于業務應用程序需要根據業務的需要變得更加靈活，以適應不斷變化的環境，比如經常改變的政策、業務級別、業務重點、合作伙伴關系、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為按需（On demand）業務，在按需業務中，一旦需要，就可以對完成或執行任務的方式進行必要的更改。
雖然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向對象的模型的替代模型，面向對象的模型是緊耦合的，已經存在二十多年了。雖然基于 SOA 的系統并不排除使用面向對象的設計來構建單個服務，但是其整體設計卻是面向服務的。由于它考慮到了系統內的對象，所以雖然 SOA 是基于對象的，但是作為一個整體，它卻不是面向對象的。不同之處在于接口本身。SOA 系統原型的一個典型例子是通用對象請求代理體系結構（Common Object Request Broker Architecture，CORBA），它已經出現很長時間了，其定義的概念與 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 模型大的改變。這種分工，就是讓開發人員集中精力于創建作為服務定義的功能單元，而讓架構師和建模人員集中精力于如何將這些單元適當地組織在一起，它已經有十多年的歷史了，通常用統一建模語言（Universal Modeling Language，UML），并且描述成模型驅動的體系結構（Model-Driven Architecture，MDA）。
SOA（service-oriented architecture，也叫面向服務的體系結構或面向服務架構）是指為了解決在Internet環境下業務集成的需要，通過連接能完成特定任務的獨立功能實體實現的一種軟件系統架構。SOA是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。
傳統的Web（HTML/HTTP）技術有效的解決了人與信息系統的交互和溝通問題，極大的促進了B2C模式的發展。WEB服務(XML/SOAP/WSDL）技術則是要有效的解決信息系統之間的交互和溝通問題，促進B2B/EAI/CB2C的發展。SOA（面向服務的體系)則是采用面向服務的商業建模技術和WEB服務技術，實現系統之間的松耦合，實現系統之間的整合與協同。WEB服務和SOA的本質思路在于使得信息系統個體在能夠溝通的基礎上形成協同工作。
對于面向同步和異步應用的，基于請求/響應模式的分布式計算來說，SOA是一場革命。一個應用程序的業務邏輯（business logic）或某些單獨的功能被模塊化并作為服務呈現給消費者或客戶端。這些服務的關鍵是他們的松耦合特性。例如，服務的接口和實現相獨立。應用開發人員或者系統集成者可以通過組合一個或多個服務來構建應用，而無須理解服務的底層實現。舉例來說，一個服務可以用。NET或J2EE來實現，而使用該服務的應用程序可以在不同的平臺之上，使用的語言也可以不同。
一、SOA具有的特性
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三大基本特征
1 獨立的功能實體
在Internet這樣松散的使用環境中，任何訪問請求都有可能出錯，因此任何企圖通過Internet進行控制的結構都會面臨嚴重的穩定性問題。SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的組件技術，如.NET Remoting，EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體；當這些宿主運行結束時這些組件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現問題的時候，在該宿主上運行的其它應用服務就會受到影響。
SOA架構中非常強調實體自我管理和恢復能力。常見的用來進行自我恢復的技術，比如事務處理(Transaction)，消息隊列(Message Queue)，冗余部署(Redundant Deployment)和集群系統(Cluster)在SOA中都起到至關重要的作用。
2 大數據量低頻率訪問
對于.NET Remoting，EJB或者XML-RPC這些傳統的分布式計算模型而言，他們的服務提供都是通過函數調用的方式進行的，一個功能的完成往往需要通過客戶端和服務器來回很多次函數調用才能完成。在Intranet的環境下，這些調用給系統的響應速度和穩定性帶來的影響都可以忽略不計，但是在Internet環境下這些因素往往是決定整個系統是否能正常工作的一個關鍵決定因素。因此SOA系統推薦采用大數據量的方式一次性進行信息交換。
3 基于文本的消息傳遞
由于Internet中大量異構系統的存在決定了SOA系統必須采用基于文本而非二進制的消息傳遞方式。在COM、CORBA這些傳統的組件模型中，從服務器端傳往客戶端的是一個二進制編碼的對象，在客戶端通過調用這個對象的方法來完成某些功能；但是在Internet環境下，不同語言，不同平臺對數據、甚至是一些基本數據類型定義不同，給不同的服務之間傳遞對象帶來的很大困難。由于基于文本的消息本身是不包含任何處理邏輯和數據類型的，因此服務間只傳遞文本，對數據的處理依賴于接收端的方式可以幫忙繞過兼容性這個的大泥坑。
此外，對于一個服務來說，Internet與局域網最大的一個區別就是在Internet上的版本管理極其困難，傳統軟件采用的升級方式在這種松散的分布式環境中幾乎無法進行。采用基于文本的消息傳遞方式，數據處理端可以只選擇性的處理自己理解的那部分數據，而忽略其它的數據，從而得到的非常理想的兼容性。
三、面向服務架構（SOA）的原則
SOA的強大和靈活性將給企業帶來巨大的好處。如果某組織將其IT架構抽象出來，將其功能以粗粒度的服務形式表示出來，每種服務都清晰地表示其業務價值，那么，這些服務的顧客（可能在公司內部，也可能是公司的某個業務伙伴）就可以得到這些服務，而不必考慮其后臺實現的具體技術。更進一步，如果顧客能夠發現并綁定可用的服務，那么在這些服務背后的IT系統能夠提供更大的靈活性。
但是，要得到種強大和靈活性，需要有一種實現架構的新方法，這是一項艱巨的任務。企業架構設計師必須要變成“面向服務的架構設計師”，不僅要理解SOA，還要理解SOA的實踐。在架構實踐和最后得到的架構結果之間的區別非常微妙，也非常關鍵。本文將討論SOA的實踐，即：面向架構的設計師在構建SOA時必須要做的事情。
SOA的原則
SOA是一種企業架構，因此，它是從企業的需求開始的。但是，SOA和其它企業架構方法的不同之處在于SOA提供的業務敏捷性。業務敏捷性是指企業對變更快速和有效地進行響應、并且利用變更來得到競爭優勢的能力。對架構設計師來說，創建一個業務敏捷的架構意味著創建這樣一個IT架構，它可以滿足當前還未知的業務需求。
要滿足這種業務敏捷性，SOA的實踐必須遵循以下原則：
* 業務驅動服務，服務驅動技術
從本質上說，在抽象層次上，服務位于業務和技術中間。面向服務的架構設計師一方面必須理解在業務需求和可以提供的服務之間的動態關系，另一方面，同樣要理解服務與提供這些服務的底層技術之間的關系。
* 業務敏捷是基本的業務需求
SOA考慮的是下一個抽象層次：提供響應變化需求的能力是新的“元需求”，而不是處理一些業務上的固定不變的需求。從硬件系統而上的整個架構都必須滿足業務敏捷的需求，因為，在SOA中任何的瓶頸都會影響到整個IT環境的靈活性。
* 一個成功的SOA總在變化之中
SOA工作的場景，更象是一個活的生物體，而不是象傳統所說的“蓋一棟房子”。IT環境唯一不變的就是變化，因此面向服務架構設計師的工作永遠不會結束。對于習慣于蓋房子的設計師來說，要轉向設計一個活的生物體要求嶄新的思維方式。如下文所寫的，SOA的基礎還是一些類似的架構準則。
SOA基礎
在IT行業有兩個越來越普遍的發展方向，一個是架構方面的，一個是方法學方面的，面向服務的架構設計師可以從中有所收獲。第一個就是MDA（模型驅動架構），由提出CORBA的OMG模型提出。MDA認為架構設計師首先要對待創建的系統有一個形式化的UML（也是由OMG提出）的模型。MDA首先給出一個平臺無關的模型來表示系統的功能需求和use cases，根據系統搭建的平臺，架構設計師可以由這個平臺無關的模型得到平臺相關的模型，這些平臺相關模型足夠詳細，以至于可以用來直接生成需要的代碼。
MDA的核心就在于在設計階段系統就已經完全描述，這樣，在創建系統的時候，幾乎就沒有錯誤解釋的可能，模型也就可以直接生成代碼。但MDA有一些局限性：首先，MDA假設在創建模型之前，業務需求已經全部描述，而這一點，在當前典型的動態業務環境中幾乎是不可能的。第二，MDA沒有一個反饋機制。如果開發人員對模型有需要改動的地方，并沒有提供給他們這么一個途徑。
SOA的另一個基礎是敏捷方法（AM），其中非常有名的方法是極限編程（XP）。象XP這樣的AM提供了在需求未知或者多變的環境中創建軟件系統的過程。XP要求在開發團隊中要有一個用戶代表，他幫助書寫測試來指導開發人員的日常工作。開發團隊中的所有成員都參與到設計之中，并且設計要盡量小并且非形式化。AM的目標是僅僅創建用戶想要的，而不是在一些形式化模型上耗費工作量。AM的核心思想就在于其敏捷性－處理需求變更的敏捷性。AM的主要弱點是其規模上的限制，例如，XP在一個小團隊和中型項目中效果不錯，但是當項目規模增大時，如果沒有一個一致的清晰的計劃，項目成員很難把握項目中的方方面面。
從表面看來，MDA和AM似乎是相對立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避開它們。但是，我們還是決定冒險把這些不同方法中的一些元素提取出來，放入到一個一致的架構實踐中。
在SOA中有三個抽象層次，按照SOA的第一條準則：業務驅動服務、服務驅動技術。AM將業務模型直接和實踐連接起來，表現在平臺相關的模型之中。MDA并沒有把業務模型和平臺無關模型分開來，而是把平臺無關模型做為起點。SOA必須連接這些模型，或者說抽象層次，得到單一的架構方法。我們將從五個視圖的架構實現方法來實現這個連接。
SOA的五視圖實現方法
企業架構設計師發現他們的職業非常有競爭力并且值得驕傲，因為他們要從很多方面來通盤考慮IT系統。Kruchten（RUP的開發負責人）將這些方面提取出來，在應用到SOA時，我們稱為五視圖實現方法（five-view approach）。
四個方框表示對一個架構的不同審視方法，分別代表不同的涉眾（stakeholder）。弟五個視圖，use-case視圖涵蓋了其它視圖，在架構中扮演的是一個特殊的角色。部署視圖將軟件映射到底層平臺和相關硬件上，是系統部署人員對架構的視圖；實現視圖描述了軟件代碼的組織，是從開發人員角度出發的視圖；業務分析人員則利用過程視圖進行工作，它描述的是軟件系統的運行時特性。最后，邏輯視圖表示的是用戶的功能需求。在SOA中，面向服務的架構必須能夠以use-case視圖中的用例將用戶連接到服務，將服務連接到底層的技術。
為了表示面向對象的架構是如何工作在這些視圖之上，讓我們將他們置于SOA元模型的上下文之中。SOA中兩個領域存在重疊：由業務模型和服務模型表示的業務領域和由服務模型及平臺相關模型表示的技術領域（兩個領域共享服務模型）。業務用戶通過邏輯視圖和過程視圖處理粗粒度的業務服務，根據變化的業務需求，按照需要將它們安排在過程之中。另一方面，技術專家的工作是創建并維護服務和地層技術之間的抽象層。表示這些服務的中間模型，起到的是軸心的作用，業務以它為中心進行。
SOA元模型從MDA中繼承平臺無關模型和平臺相關模型，但是添加了AM和用戶交互以及敏捷的反饋這兩部分，后者通過橢圓之間的雙向箭頭來表現。類似地，元模型通過引入由中心的服務模型提供的中間層抽象解決了AM在伸縮性方面的問題。這樣，服務模型中的任何需求的變化，都會反映到用戶每天的業務處理中。同樣，由于底層技術是模型驅動的，技術專家也可以根據這些變化的需求迅速而有效地作出應變。
SOA實踐和過去解決企業架構傳統方式的不同之處就在于其對敏捷性的支持。如前所說，SOA的第三條原則就在于它總在變化之中。這種恒在的變化性環境是SOA實踐的基石。如圖所示，涉眾（stakeholders，譯者注：RUP中也有這個詞，表示軟件開發中涉及到的各種角色如：用戶、設計人員、開發人員乃至測試人員等等。）在一個必需的基礎上影響到整個架構的變化。在當技術專家在每天的日常工作中不斷對變化的業務需求作出響應的這種情況下，設計階段和運行階段之間的界限變得模糊起來，很難清晰地分離這兩個階段。
剩下的部分
我們已經為面向服務的架構提供了一個高層次的框架，其中MDA和AM的元素幫助工具的使用者來創建和維護SOA。但是，SOA中還缺少一些內容－那就是軟件開發商和專業的服務組織必需提供的。理想情況下，開發商必需提供面向服務的業務流程、工作流以及服務的協調工具和服務；另外，能夠以一種敏捷的、平臺無關的方式充分反映業務服務的建模工具也是必須的；技術專家必須配備可以從模型中自動生成代碼，并在代碼變化時更新模型的工具，最后，開發商必須提供支持SOA的軟件，幫助面向服務的架構設計師以一種可信并且可伸縮的方式創建位于服務和底層技術之間的抽象層次。幸運的是，這方面的產品即將上市。
另外，最重要的就是貫穿本文的自頂而下的SOA實現方法了。今天關于Web services的大部分思考都是自底而上的：“這是如何創建Web services的方法，現在，我們來使用它們集成吧”，對Web services技術的這種方法是偉大的第一步，因為它可以驚人地降低集成的開銷，這是現在的技術管理人員最樂意見到的了。但當經濟進一步發展，IT走出低谷，企業會尋求IT的幫助來提高組織戰略意義上的核心價值。使用面向服務的架構，IT可以提供給企業實現業務敏捷性的這樣一個框架。
四、為什么選擇面向服務架構（SOA）？
不同種類的操作系統，應用軟件，系統軟件和應用基礎結構（application infrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程序被用來處理當前的業務流程（business processes），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業伙伴以及供應商提供新的互動渠道，并呈現一個可以支持有機業務（organic business）的構架。SOA憑借其松耦合的特性，使得企業可以按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，并可以把企業現有的或已有的應用作為服務， 從而保護了現有的IT基礎建設投資。
如圖1的例子所示，一個使用SOA的企業，可以使用一組現有的應用來創建一個供應鏈復合應用（supply chain composite application），這些現有的應用通過標準接口來提供功能。
Figure 1. Supply chain application. Click on thumbnail to view full-sized image.
服務架構
為了實現SOA，企業需要一個服務架構，圖2顯示了一個例子：
Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.
在圖2中， 服務消費者（service consumer）可以通過發送消息來調用服務。這些消息由一個服務總線（service bus）轉換后發送給適當的服務實現。這種服務架構可以提供一個業務規則引擎（business rules engine），該引擎容許業務規則被合并在一個服務里或多個服務里。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似審核，列表（billing），日志等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影響其他服務的情況下更改某項服務。
五、面向服務架構（SOA）基礎結構
要運行，管理SOA應用程序，企業需要SOA基礎，這是SOA平臺的一個部分。SOA基礎必須支持所有的相關標準，和需要的運行時容器。圖3所示的是一個典型的SOA基礎結構。接下來的章節將逐一討論該結構的每個部分。
Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.
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 的工作。
六、SOA 不是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以借助現有的應用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程序和業務流程。
八、采用服務驅動型方法的企業體驗著以下業務和 IT 好處
面向服務架構的業務好處
效率： 將業務流程從 " 煙囪 " 狀的、重復的流程向維護成本較低的高度利用、共享服務應用轉變。
響應： 迅速適應和傳送關鍵業務服務來滿足市場需求，為客戶、雇員和合作伙伴更高水準的服務。
適應性： 更高效地轉入轉出讓整個業務變得復雜性和難度更小，達到節約時間和資金的目的。
面向服務架構的 IT 好處
復雜性降低： 基于標準的兼容性，與點到點的集成相比降低了復雜性。
重用增加： 通過重用以前開發和部署的共享服務，實現了更有效的應用程序 / 項目開發和交付。
遺留集成： 用作可重用服務的遺留應用程序降低了維護和集成的成本。
如今的服務驅動型企業都在體驗著開發的高效率，服務的高可靠性和服務的高質量，以最大限度獲得業務機會所帶來的這些好處。
九、SOA在國際市場上反響強烈
自2004年初業界推出SOA后，Bea、IBM、Oracle、微軟等業界巨頭紛紛發布自己的SOA戰略，建議用戶在進行企業IT建設時考慮SOA。
ZapThink調研公司在最近發表的一份報告中預測，到2006年，基于SOA架構(面向服務的架構)的中間件產品將成為網絡化商業系統的主要設計思路，其中70％的商業企業公司將使用SOA架構。
按照Gartner的預測，到2008年，SOA將成為占有絕對優勢的軟件工程實踐方法，它將結束傳統的整體軟件體系架構長達40年的統治地位。屆時，將有60％的商業公司在進行商業IT建設時會轉向SOA。
IDC預測到 2007年，包括軟件、服務和硬件在內的SOA市場將達到210億美元，其中商業企業方面的市場將達到120億美元。
綜上所述SOA已經成為大勢所趨，有著廣闊的市場空間和巨大的發展潛力；而在商業企業中的應用，將成為SOA未來發展的一大亮點。
SOA已經引起國內商業企業的重視
國內基于SOA架構Web服務目前還是集中在一些企業內部，而國內一些有影響的行業用戶正在搭建其核心業務系統，比如商業領域的流通行業和銷售行業的大集中正在起步。因此當商業企業需要更好地服務客戶，需要更好地與上、下游合作伙伴協同工作，并且自己內部的核心業務之間也需要協同工作時，基于SOA架構中間件產品就會為這類新的業務應用提供理想的底座，這種新的應用被稱作面向服務的業務應用。
現在，很多商業企業都準備在2006年內開始規劃使用這些基于SOA架構的應用，可想而知，這些SOA架構的中間件產品將在兩年內迅速發展，并在五年內在整個IT行業內獲得廣泛應用。
商業企業信息化存在的問題
商業企業信息系統多數處于封閉運行的狀態，企業之間、企業與上游供應商、下游消費者之間信息不對稱。商業企業之間無法形成協同效應。信息系統即無法滿足消費者的綜合需求也無法達到企業間的商務協同自動化和智能化的需求。信息化的經濟效益難以有效發揮。同時信息化標準不健全，如電子交換接口標準、業務流程協同標準；流通中的票證、單據格式標準；電子數據交換所必須的結構化數據標準等。
采用傳統的系統架構技術和傳統的EAI和B2Bi技術則存在系統封閉、廠商依賴性強、耦合度高、重用性差，擴展性差、無法和上下游企業的系統建立統一的接口等問題。而采用SOA 技術則可以有效解決上述問題，由于SOA基于HTTP/SOAP/WSDL等開放式技術，對于特定廠商產品依賴性小；系統開放、互操作性強，可以建立統一的WEB服務用于和不同的上下游企業信息系統實現供應鏈協同。由于SOA的松耦合特性、比較符合集團和各下屬機構的商業關系，業務流程整合和項目協調的阻力會有效降低。
SOA以服務為基本單元，更加貼近于企業的商業活動，業務梳理和建模的復雜度會有效降低，重用性也會有效提高。另外采用SOA，企業IT系統所提供的服務會更容易擴展、組合和變更，符合該集團目前業務發展變化較快的特點，可以有效的降低該集團IT系統的長期擁有總體成本。我們將該集團公司作為一個試點，推進SOA技術的運用，來有效解決上述問題。
“協同商務”的新經濟時代即將到來
采用SOA技術最終將使得各個商業企業之間、各個關聯的經濟實體之間實現高效實時的聯接，使得整個產業鏈實現自動化的協同商務，將會有力的提高商業企業的應變能力，轉變現有的商業運作模式，轉變經濟增長的方式。SOA技術將促進信息系統在商業企業貿易活動中的全面滲入和發展，對于簡單的貿易活動，將會由信息系統自動化實現；對于復雜的貿易活動，信息系統將會為企業管理人員提供足夠的決策信息并可以高效的執行決策。SOA技術的應用將會全面提高商務的自動化、智能化和實時化水平。
采用SOA技術實現協同商務可以提高城市范圍內商流、物流、資金流和信息流的運行效率，擴大北京市商業企業整體規模效益，加強商業企業的整體對外競爭力，拉動經濟增長，降低企業運營成本，推動城市流通信息技術創新體系的建立，提高北京市流通現代化水平，促進城市管理現代化和城市社會經濟信息化的進程。
采用SOA技術可以將將物流企業、物業企業、商業企業、消費者整體整合在一起，對供應鏈關聯企業、物流企業以及網上支付體系、安全認證體系等環境建設具有明顯的帶動作用，有利于促進支撐環境協同發展。
促進商業企業信息化標準的制定，完善政府職能
采用SOA技術為信息系統的溝通提供了技術基礎，而隨著SOA在商業企業的應用，必將促進統一的商業領域電子商務行業標準的發展和制定，對促進國家商業企業信息標準體系的建立和完善具有重要支撐作用。
SOA技術為政府對商業經濟的運行狀況提供了實時監測和指導的技術可能性，將從根本上改變政府對社會經濟的管理方式。
基于SOA的協同商務帶來的最直接的好處就是由于貿易范圍的空前擴大而產生的全球貿易活動的大幅度增加，因而提高了貿易環節中大多數角色的交易量，因此，全球范圍的經濟形勢將向一個良好的增長趨勢發展。它還可以擴大地方商業企業整體規模效益，加強商業企業的業務整合和商業協同效應，提高商業企業的整體對外競爭力，通過協同商務有效降低企業運營成本，推動城市流通信息技術創新體系的建立，提高地方的流通現代化水平，促進城市管理現代化和城市社會經濟信息化的進程。
SOA在商業企業的應用可以將物流企業、物業企業、商業企業、消費者整體整合在一起，對供應鏈關聯企業、物流企業以及網上支付體系、安全認證體系等環境建設具有明顯的帶動作用，可推動信息化各環節的全面應用與發展，有利于促進產業鏈和支撐環境協同發展，從而也創造了更多的就業機會和社會財富。
信息產業是知識經濟的核心和主要的推動力，而企業信息化又是目前信息產業中最具前途的發展趨勢，因此說企業信息化的發展，必將直接或間接地推動知識經濟的浪潮。這種知識經濟有著大量的無形成本和高附加值，在東南亞金融危機的同時，高科技給美國帶來的是"高增長速度、高就業率、低通貨膨脹率"。這也是我國在宣傳知識經濟的熱潮中應注意的一個真正有價值的切入點。
SOA技術由于其前所未有的信息系統整合與自動協同能力，成為繼互聯網以來又一個革命性的技術，將會把目前基于WEB/互聯網的知識經濟推進到一個前所未有的新階段。
十、SOA 企業考慮事項
服務驅動型企業在對客戶、合作伙伴和雇員的高效化服務方面得到了優化 -- 并加速了業務服務響應時間。然而，成為服務驅動型企業，需要的不僅僅是產品的部署。對實現服務驅動型架構感興趣的企業將希望能與一個有經驗的 SOA 提供商合作，它提供的服務可以保護企業在業務和 IT 方面的投入，他們考慮到了以下幾個方面：
業務戰略： 組織需要明確驅動關鍵業務流程的業務戰略，它將用于成形 SOA 的框架。一旦識別出業務問題，就可以用一種一致的、可復用的方法對其進行定義，并實現解決方案。在這個關鍵的基礎階段，業務通常需要與一個擁有開發 SOA 業務戰略經驗、并能共享橫向和縱向市場最佳實踐的提供商進行合作。
體系結構： 為了解決方案快速和動態的交付，企業必須開發一種允許裝配組件和服務的體系結構框架。通過與有經驗的 SOA 提供商合作，企業可以獲得相應的參考案例，以快速搭建一個關注復用、避免 " 煙囪 " （ stovepipe ）式應用程序和 IT 資源 " 孤島 " 的體系結構。此外，有經驗的 SOA 提供商還可以幫助企業對項目的易管理性進行設計。
構建模塊： 不管是對體系結構還是對編程模型來說， SOA 都是是思考構建軟件模型的一種優秀方式。與 SOA 提供商進行合作能讓組織能夠識別可在 SOA 實現中使用或重用的構建模塊代碼、服務、應用程序和組件。與有經驗的 SOA 提供商進行合作還有一個好處，企業可以獲得對構造組件、企業域（ domains ）、服務和規范數據模型的參考經驗。
項目和應用程序： SOA 創造了一種在更強大、更靈活的編程模式中搭建應用程序的新方法。與 SOA 提供商合作的企業可以更好地識別將被合并到 SOA 結構體系中的現存的和正在使用的應用程序。有經驗的 SOA 提供商還將引導項目基礎架構的搭建，并對正在進行中的項目提供有效的管理。
成本和收益： 在一個 SOA 項目中，開發和維護成本將大大削減，。有經驗的 SOA 提供商可以幫助企業構造 SOA 基金模式，并構建 " 行動案例 " ，包括評估基礎構造成本和效益、實現項目的最佳投資回報（ ROI ）以及開發商務案例。
組織和統轄： 組織需要為新的面向服務的 IT 組織識別角色和職責，并優化經驗集便于以后使用。有經驗的 SOA 提供商可以幫助企業實現這些目標，同時組織一個有效的設計 " 復用工廠 " （ Reuse Factory ），幫助定義統轄模式，并最終保證客戶滿意。