面向服務的體系結構，是一個組件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平台、作業系統和程式語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行互動。
基本介紹
- 中文名：SOA架構
- 外文名：SOA framework
- 套用學科：通信
簡介,特徵,基本特點,元素,利用價值,SOA特性,6.1概述,6.2服務架構,6.3SOA基礎結構,6.4服務品質,6.5SOA不是Web服務,6.6SOA的優勢,
簡介
這種具有中立的接口定義（沒有強制綁定到特定的實現上）的特徵稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程式的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。而另一方面，緊耦合意味著應用程式的不同組件之間的接口與其功能和結構是緊密相連的，因而當需要對部分或整個應用程式進行某種形式的更改時，它們就顯得非常脆弱。
對松耦合的系統的需要來源於業務，應用程式需要根據業務的需要變得更加靈活，以適應不斷變化的環境，比如經常改變的政策、業務級別、業務重點、合作夥伴關係、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為按需（On demand）業務，在按需業務中，一旦需要，就可以對完成或執行任務的方式進行必要的更改。
雖然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向對象的模型的替代模型，面向對象的模型是緊耦合的，已經存在二十多年了。雖然基於 SOA 的系統並不排除使用面向對象的設計來構建單個服務，但是其整體設計卻是面向服務的。由於它考慮到了系統內的對象，所以雖然 SOA 是基於對象的，但是作為一個整體，它卻不是面向對象的。不同之處在於接口本身。SOA 系統原型的一個典型例子是通用對象請求代理體系結構（Common Object Request Broker Architecture，CORBA），它已經出現很長時間了，其定義的概念與 SOA 相似。
然而，現在的 SOA 已經有所不同了，因為它依賴於一些更新的進展，這些進展是以可擴展標記語言（標準通用標記語言的子集）為基礎的。通過使用基於 XML 的語言（稱為Web 服務描述語言（Web Services Description Language，WSDL））來描述接口，服務已經轉到更動態且更靈活的接口系統中，非以前 CORBA 中的接口描述語言（Interface Description Language，IDL）可比了。
SOA開發運行平台的Web 服務並不是實現 SOA 的惟一方式。前面剛講的 CORBA 是另一種方式，這樣就有了面向訊息的中間件（Message-Oriented Middleware）系統，比如 IBM 的 MQseries。但是為了建立體系結構模型，您所需要的並不只是服務描述。您需要定義整個應用程式如何在服務之間執行其工作流。您尤其需要找到業務的操作和業務中所使用的軟體的操作之間的轉換點。因此，SOA 應該能夠將業務的商業流程與它們的技術流程聯繫起來，並且映射這兩者之間的關係。例如，給供應商付款的操作是商業流程，而更新您的零件資料庫，以包括進新供應的貨物卻是技術流程。因而，工作流還可以在 SOA 的設計中扮演重要的角色。
此外，動態業務的工作流不僅可以包括部門之間的操作，甚至還可以包括與不為您控制的外部合作夥伴進行的操作。因此，為了提高效率，您需要定義應該如何得知服務之間的關係的策略，這種策略常常採用服務級協定和操作策略的形式。
最後，所有這些都必須處於一個信任和可靠的環境之中，以同預期的一樣根據約定的條款來執行流程。因此，安全、信任和可靠的訊息傳遞應該在任何 SOA 中都起著重要的作用。
特徵
SOA的服務級別抽象圖，如下圖1所示：
SOA的服務級別抽象圖圖1SOA的服務級別抽象圖
基於以上圖示．SOA具有以下五個特徵：
1、可重用
一個服務創建後能用於多個套用和業務流程。
2、松耦合
服務請求者到服務提供者的綁定與服務之間應該是松耦合的。因此，服務請求者不需要知道服務提供者實現的技術細節，例如程式語言、底層平台等等。
3、明確定義的接口
服務互動必須是明確定義的。Web服務描述語言（Web Services Description Language，WSDL）是用於描述服務請求者所要求的綁定到服務提供者的細節。WSDL不包括服務實現的任何技術細節。服務請求者不知道也不關心服務究竟是由哪種程式設計語言編寫的。
4、無狀態的服務設計
服務應該是獨立的、自包含的請求，在實現時它不需要獲取從一個請求到另一個請求的信息或狀態。服務不應該依賴於其他服務的上下文和狀態。當產生依賴時，它們可以定義成通用業務流程、函式和 數據模型。
5、基於開放標準
當前SOA的實現形式是Web服務，基於的是公開的W3C及其他公認標準．採用第一代Web服務定義的SOAP、WSDL和UDDI以及第二代Web服務定義的WS-*來實現SOA。
基本特點
SOA的目標在於讓IT系統變得更有彈性，以便更靈活、更快地回響不斷改變的企業業務需求，解決軟體領域一直以來存在的“如何重用軟體功能”問題。採用SOA來構建信息平台，無疑是未來的發展方向。
SOA的5大基本特徵為軟體功能重用提供了解決的辦法。
①服務之間通過簡單、精確定義的接口進行通信，不涉及底層編程接口和通信模型。
②粗粒度性：粗粒度服務提供一項特定的業務功能，採用粗粒度服務接口的優點在於使用者和服務層之間不必再進行多次的往復，一次往復就足夠了。
③松耦合性：松耦合性要求SOA架構中的不同服務之間應該保持一種松耦合的關係，也就是應該保持一種相對獨立無依賴的關係。這樣的好處有兩點，首先是具有靈活性，其次當組成整個應用程式的服務內部結構和實現逐步地發生變化時，系統可以繼續地獨立存在。而緊耦合意味著應用程式的不同組件之間的接口與其功能和結構是緊密相連的，因而當需要對部分或整個應用程式進行某種形式的更改時這種結構就顯得非常脆弱。
④位置透明性：位置透明性要求SOA系統中的所有服務對於其調用者來說都是位置透明的，也就是說，每個服務的調用者只需要知道想要調用的是哪一個服務，但並不需要知道所調用服務的物理位置在哪。
⑤協定無關性：協定無關性要求每一個服務都可以通過不同的協定來調用。
另外，在許多傳統的IT系統的內在部分採用的是硬連線，這種結構很難讓企業快速回響市場的變化，而SOA能夠重複利用企業現有的資源，可以減輕企業運營成本，提升資源的使用效率，並且減輕企業維護人員的工作量，減少潛在的風險以及管理費用。在業務方面和IT方面帶來許多優勢：
①服務給精確的業務流程帶來靈活性；
②使用服務來改善客戶服務，而不必擔心底層複雜的IT基礎架構；
③可以迅速創建新的業務流程和複雜的應用程式，以適應市場變化；
④藉助安全、易管理的集成環境，成為回響能力更強的IT組織；
⑤通過使用預裝的、可重複使用的服務構建模組，縮短開發和部署周期；
⑥通過使用服務來降低複雜性和維護成本；
⑦是增強而不是替換現有的IT系統。
元素
面向服務的體系結構中的角色包括：如下圖所示：
1、服務請求者：服務請求者是一個應用程式、一個軟體模組或需要一個服務的另一個服務。它發起對註冊中心中的服務的查詢，通過傳輸綁定服務，並且執行服務功能。服務請求者根據接口契約來執行服務。
面向服務的體系結構中的角色
面向服務的體系結構中的角色2、服務提供者：服務提供者是一個可通過網路定址的實體，它接受和執行來自請求者的請求。它將自己的服務和接口契約發布到服務註冊中心，以便服務請求者可以發現和訪問該服務。
圖2面向服務的體系結構中的角色
3、服務註冊中心：服務註冊中心是服務發現的支持者。它包含一個可用服務的存儲庫，並允許感興趣的服務請求者查找服務提供者接口。
發布：為了使服務可訪問．需要發布服務描述以使服務請求者可以發現和調用它。
查詢：服務請求者定位服務．方法是查詢服務註冊中心來找到滿足其標準的服務。
綁定和調用：在檢索完服務描述之後，服務請求者繼續根據服務描述中的信息來調用服務。
（1）服務：可以通過已發布接口使用服務，並且允許服務使用者調用服務。
（2）服務描述：服務描述指定服務使用者與服務提供者互動的方式。它指定來自服務的請求和回響的格式。服務描述可以指定一組前提條件、後置條件和/或服務質量（Q0S）級別。
利用價值
對 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是一場革命。一個應用程式的業務邏輯（business logic）或某些單獨的功能被模組化並作為服務呈現給消費者或客戶端。這些服務的關鍵是他們的松耦合特性。例如，服務的接口和實現相獨立。套用開發人員或者系統集成者可以通過組合一個或多個服務來構建套用，而無須理解服務的底層實現。舉例來說，一個服務可以用.NET或J2EE來實現，而使用該服務的應用程式可以在不同的平台之上，使用的語言也可以不同。
SOA特性
6.1概述
SOA服務具有平台獨立的自我描述XML（標準通用標記語言的子集）文檔。Web服務描述語言（WSDL，WebServicesDescriptionLanguage）是用於描述服務的標準語言。
SOA服務用訊息進行通信，該訊息通常使用XMLSchema來定義（也叫做XSD，XMLSchemaDefinition）。消費者和提供者或消費者和服務之間的通信多見於不知道提供者的環境中。服務間的通訊也可以看作企業內部處理的關鍵商業文檔。
在一個企業內部，SOA服務通過一個扮演目錄列表（directorylisting）角色的登記處（Registry）來進行維護。應用程式在登記處（Registry）尋找並調用某項服務。統一描述，定義和集成（UDDI，UniversalDescription，Definition，andIntegration）是服務登記的標準。
每項SOA服務都有一個與之相關的服務品質（QoS，qualityofservice）。QoS的一些關鍵元素有安全需求（例如認證和授權），可靠通信（譯註：可靠訊息是指，確保訊息“僅且僅僅”傳送一次，從而過濾重複信息。），以及誰能調用服務的策略。
為什麼選擇SOA？
不同種類的作業系統，套用軟體，系統軟體和套用基礎結構（applicationinfrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程式被用來處理當前的業務流程（businessprocesses），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程式和套用基礎結構（applicationinfrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個可以支持有機業務（organicbusiness）的構架。SOA憑藉其松耦合的特性，使得企業可以按照模組化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，並可以把企業現有的或已有的套用作為服務，從而保護了現有的IT基礎建設投資。
如圖1的例子所示，一個使用SOA的企業，可以使用一組現有的套用來創建一個供應鏈複合套用（supplychaincompositeapplication），這些現有的套用通過標準接口來提供功能。
6.2服務架構
為了實現SOA，企業需要一個服務架構，服務消費者（serviceconsumer）可以通過傳送訊息來調用服務。這些訊息由一個服務匯流排（servicebus）轉換後傳送給適當的服務實現。這種服務架構可以提供一個業務規則引擎（businessrulesengine），該引擎容許業務規則被合併在一個服務里或多個服務里。這種架構也提供了一個服務管理基礎（servicemanagementinfrastructure），用來管理服務，類似審核，列表（billing），日誌等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatoryrequirement），例如SarbanesOxley（SOX），並且可以在不影響其他服務的情況下更改某項服務。
6.3SOA基礎結構
要運行，管理SOA應用程式，企業需要SOA基礎，這是SOA平台的一個部分。SOA基礎必須支持所有的相關標準，和需要的運行時容器。圖3所示的是一個典型的SOA基礎結構。
SOAP，WSDL，UDDI
WSDL，UDDI和SOAP是SOA基礎的基礎部件。WSDL用來描述服務；UDDI用來註冊和查找服務；而SOAP，作為傳輸層，用來在消費者和服務提供者之間傳送訊息。SOAP是Web服務的默認機制，其他的技術為可以服務實現其他類型的綁定。一個消費者可以在UDDI註冊表（registry）查找服務，取得服務的WSDL描述，然後通過SOAP來調用服務。
WS-IBasicProfile
WS-IBasicProfile，由Web服務互用性組織（WebServicesInteroperabilityOrganization）提供，是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用BasicProfile測試程式來測試服務在不同平台和技術上的互用性。
J2EE和.Net
儘管J2EE和.NET平台是開發SOA應用程式常用的平台，但SOA不僅限於此。像J2EE這類平台，不僅為開發者自然而然地參與到SOA中來提供了一個平台，還通過他們內在的特性，將可擴展性，可靠性，可用性以及性能引入了SOA世界。新的規範，例如JAXB（JavaAPIforXMLBinding），用於將XML文檔定位到Java類；JAXR（JavaAPIforXMLRegistry）用來規範對UDDI註冊表（registry）的操作；XML-RPC（JavaAPIforXML-basedRemoteProcedureCall）在J2EE1.4中用來調用遠程服務，這使得開發和部署可移植於標準J2EE容器的Web服務變得容易，與此同時，實現了跨平台（如.NET）的服務互用。
6.4服務品質
在企業中，關鍵任務系統（mission-criticalsystem，譯註：關鍵任務系統是指如果一個系統的可靠性對於一個組織是至關重要的，那么該系統就是該企業的關鍵任務系統。比如，電話系統對於一個電話促銷企業來說就是關鍵任務系統，而文字處理系統就不那么關鍵了。）用來解決高級需求，例如安全性，可靠性，事物。當一個企業開始採用服務架構作為工具來進行開發和部署套用的時候，基本的Web服務規範，像WSDL，SOAP，以及UDDI就不能滿足這些高級需求。正如前面所提到的，這些需求也稱作服務品質（QoS，qualityofservices）。與QoS相關的眾多規範已經由一些標準化組織（standardsbodies）提出，像W3C（WorldWideWebConsortium）和OASIS（theOrganizationfortheAdvancementofStructuredInformationStandards）。下面的部分將會討論一些QoS服務和相關標準。
安全
Web服務安全規範用來保證訊息的安全性。該規範主要包括認證交換，訊息完整性和訊息保密。該規範吸引人的地方在於它藉助現有的安全標準，例如，SAML（asSecurityAssertionMarkupLanguage）來實現web服務訊息的安全。OASIS正致力於Web服務安全規範的制定。
可靠
在典型的SOA環境中，服務消費者和服務提供者之間會有幾種不同的文檔在進行交換。具有諸如“僅且僅僅傳送一次”（once-and-only-oncedelivery），“最多傳送一次”（at-most-oncedelivery），“重複訊息過濾”（duplicatemessageelimination），“保證訊息傳送”（guaranteedmessagedelivery）等特性訊息的傳送和確認，在關鍵任務系統（mission-criticalsystems）中變得十分重要。WS-Reliability和WS-ReliableMessaging是兩個用來解決此類問題的標準。這些標準現在都由OASIS負責。
策略
服務提供者有時候會要求服務消費者與某種策略通信。比如，服務提供商可能會要求消費者提供Kerberos安全標示，才能取得某項服務。這些要求被定義為策略斷言（policyassertions）。一項策略可能會包含多個斷言。WS-Policy用來標準化服務消費者和服務提供者之間的策略通信。
控制
當企業著手於服務架構時，服務可以用來整合數據倉庫（silosofdata），應用程式，以及組件。整合套用意味著例如異步通信，並行處理，數據轉換，以及校正等進程請求必須被標準化。在SOA中，進程是使用一組離散的服務創建的。BPEL4WS或者WSBPEL（WebServiceBusinessProcessExecutionLanguage）是用來控制這些服務的語言。WSBPEL目前也由OASIS負責。
管理
隨著企業服務的增長，所使用的服務和業務進程的數量也隨之增加，一個用來讓系統管理員管理所有運行在多相環境下的服務的管理系統就顯得尤為重要。WSDM（WebServicesforDistributedManagement）規定了任何根據WSDM實現的服務都可以由一個WSDM適應（WSDM-compliant）的管理方案來管理。
其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination和WS-Transaction標準中描述，這些都是OASIS的工作。
6.5SOA不是Web服務
在理解SOA和Web服務的關係上，經常發生混淆。根據2003年4月的Gartner報導，YefimV.Natis就這個問題是這樣解釋的：“Web服務是技術規範，而SOA是設計原則。特別是Web服務中的WSDL，是一個SOA配套的接口定義標準：這是Web服務和SOA的根本聯繫。”從本質上來說，SOA是一種架構模式，而Web服務是利用一組標準實現的服務。Web服務是實現SOA的方式之一。用Web服務來實現SOA的好處是你可以實現一個中立平台，來獲得服務，而且隨著越來越多的軟體商支持越來越多的Web服務規範，你會取得更好的通用性。
6.6SOA的優勢
SOA的概念並非什麼新東西，SOA不同於現有的分散式技術之處在於大多數軟體商接受它並有可以實現SOA的平台或應用程式。SOA伴隨著無處不在的標準，為企業的現有資產或投資帶來了更好的重用性。SOA能夠在最新的和現有的套用之上創建套用；SOA能夠使客戶或服務消費者免予服務實現的改變所帶來的影響；SOA能夠升級單個服務或服務消費者而無需重寫整個套用，也無需保留已經不再適用於新需求的現有系統。總而言之，SOA以藉助現有的套用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程式和業務流程。
