面向服務的體系結構（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 ），幫助定義統轄模式，并最終保證客戶滿意。
![網絡攻防技術（2021期末考試）[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)