面向服務的架構pdf

『壹』 到底什麼才是面向服務的架構

面向服務架構（Service-Oriented Architecture，SOA） 面向服務架構又稱「面向服務的體系結構」， 是Gartner於2O世紀9O年代中期提出的面向服務架構的概 念。2002年的l2月，Gartner提出「面向服務的架構( SOA)」是「現代應用開發領域最重耍的課題」之後。 國內外計算機專家、學者掀起了對SOA的積極研究與探索。

『貳』 SOA（面向服務架構）的有關知識

SOA

面向服務的體系結構（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是一場革命。一個應用程序的業務邏輯（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？

不同種類的操作系統，應用軟體，系統軟體和應用基礎結構（application infrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程序被用來處理當前的業務流程（business processes），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個可以支持有機業務（organic business）的構架。SOA憑借其松耦合的特性，使得企業可以按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，並可以把企業現有的或已有的應用作為服務， 從而保護了現有的IT基礎建設投資。

如圖1的例子所示，一個使用SOA的企業，可以使用一組現有的應用來創建一個供應鏈復合應用（supply chain composite application），這些現有的應用通過標准介面來提供功能。

服務架構

為了實現SOA，企業需要一個服務架構，圖2顯示了一個例子：

在圖2中， 服務消費者（service consumer）可以通過發送消息來調用服務。這些消息由一個服務匯流排（service bus）轉換後發送給適當的服務實現。這種服務架構可以提供一個業務規則引擎（business rules engine），該引擎容許業務規則被合並在一個服務里或多個服務里。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似審核，列表（billing），日誌等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），並且可以在不影響其他服務的情況下更改某項服務。

SOA基礎結構

要運行，管理SOA應用程序，企業需要SOA基礎，這是SOA平台的一個部分。SOA基礎必須支持所有的相關標准，和需要的運行時容器。圖3所示的是一個典型的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 Procere 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），「重復消息過濾」（plicate 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以藉助現有的應用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程序和業務流程。

『叄』 如何認清面向服務架構SOA的真實面目

在經典軟體工程理論中，不管是瀑布方法還是原型方法，都是從需求分析做起，一步一步構建起形形色色的軟體系統。但是，需求變更像一個揮之不去的陰影，時刻伴隨著系統左右。每一個實際應用系統的開發者都飽嘗了在系統進入開發階段、測試階段，甚至上線階段遭遇應接不暇的需求變更的極端痛苦。客戶將變更的需求視為bug(錯誤)是測試上線階段的主要問題。 如何解決這一問題?能否來一場軟體開發和架構的革命?SOA架構的提出，就是被人看成這樣的一場革命。其實質就是要將系統模型與系統實現分割開來。 1.定義 SOA並不是一個新概念，有人就將CORBA和DCOM等組件模型看成SOA架構的前身。早在1996年，Gartner Group就已經提出了SOA的預言，不過那個時候僅僅是一個「預言」，當時的軟體發展水平和信息化程度還不足以支撐這樣的概念走進實質性應用階段。到了近一兩年，SOA的技術實現手段漸漸成熟了。在BEA、IBM等軟體巨頭的極力推動下，才得以慢慢風行起來。Gartner為SOA描述的願景目標是實現實時企業(Real-Time Enterprise)。 關於SOA，目前尚未有一個統一的、業界廣泛接受的定義。一般認為：SOA，面向服務的架構是一個組件模型，它將應用程序的不同功能單元 ----服務(service)，通過服務間定義良好的介面和契約(contract)聯系起來。介面採用中立的方式定義，獨立於具體實現服務的硬體平台、操作系統和編程語言，使得構建在這樣的系統中的服務可以使用統一和標準的方式進行通信。這種具有中立的介面定義(沒有強制綁定到特定的實現上)的特徵稱為服務之間的松耦合。 從這個定義中，我們看到下面兩點： ·軟體系統架構： SOA不是一種語言，也不是一種具體的技術，更不是一種產品，而是一種軟體系統架構，它嘗試給出在特定環境下推薦採用的一種架構，從這個角度上來說，它其實更像一種架構模式(Pattern)，是一種理念架構，是人們面向應用服務的解決方案框架。 ·服務(service)是整個SOA實現的核心。SOA架構的基本元素是服務，SOA 指定一組實體(服務提供者、服務消費者、服務注冊表、服務條款、服務代理和服務契約)，這些實體詳細說明了如何提供和消費服務。遵循 SOA 觀點的系統必須要有服務，這些服務是可互操作的、獨立的、模塊化的、位置明確的、松耦合的並且可以通過網路查找其地址。 2.SOA三種角色的關系 服務是一個自包含的、無狀態(stateless)的實體，可以由多個組件組成。它通過事先定義的界面響應服務請求。它也可以執行諸如編輯和處理事務(transaction)等離散性任務。服務本身並不依賴於其他函數和過程的狀態。用什麼技術實現服務，並不在其定義中加以限制。 服務提供者(service provider)提供符合契約(contract)的服務，並將它們發布到服務代理。 服務請求者(service consumer)也叫服務使用者，它發現並調用其他的軟體服務來提供商業解決方案。從概念上來說，SOA 本質上是將網路、傳輸協議和安全細節留給特定的實現來處理。服務請求者通常稱為客戶端，但是，也可以是終端用戶應用程序或別的服務。 服務代理者(service broker)作為儲存庫、電話黃頁或票據交換所，產生由服務提供者發布的軟體介面。 這三種 SOA 參與者：服務提供者、服務代理者以及服務請求者通過 3 個基本操作：發布(publish)、查找(find)、綁定(bind)相互作用。服務提供者向服務代理者發布服務。服務請求者通過服務代理者查找所需的服務，並綁定到這些服務上。服務提供者和服務請求者之間可以交互。 所謂服務的無狀態，是指服務不依賴於任何事先設定的條件，是狀態無關的(state-free)。在SOA架構中，一個服務不會依賴於其他服務的狀態。 它們從客戶端接受服務請求。因為服務是無狀態的，它們可以被編排(orchestrated)和序列化(sequenced)成多個序列 (有時還採用流水線機制) ，以執行商業邏輯。編排指的是序列化服務並提供數據處理邏輯。但不包括數據的展現功能。 3.SOA特徵 基於上面討論，我們給出SOA的下面一些特徵： ·服務的封裝(encapsulation)。將服務封裝成用於業務流程的可重用組件的應用程序函數。它提供信息或簡化業務數據從一個有效的、一致的狀態向另一個狀態的轉變。封裝隱藏了復雜性。服務的API保持不變，使得用戶遠離具體實施上的變更。 ·服務的重用(reuse)。服務的可重用性設計顯著地降低了成本。為了實現可重用性，服務只工作在特定處理過程的上下文(context)中，獨立於底層實現和客戶需求的變更。 ·服務的互操作(interoperability)。互操作並不是一個新概念。在CORBA、DCOM、web service中就已經採用互操作技術了。在SOA中，通過服務之間既定的通信協議進行互操作。主要有同步和非同步兩種通信機制。SOA提供服務的互操作特性更利於其在多個場合被重用。 ·服務是自治的(Autonomous)功能實體。服務是由組件組成的組合模塊，是自包含和模塊化的。 SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的組件技術，如。NET Remoting， EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體;當這些宿主運行結束時這些組件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現問題的時候，在該宿主上運行的其它應用服務就會受到影響。 SOA架構中非常強調實體自我管理和恢復能力。常見的用來進行自我恢復的技術，比如事務處理(Transaction)，消息隊列 (Message Queue)，冗餘部署(Rendant Deployment)和集群系統(Cluster)在SOA中都起到至關重要的作用。 ·服務之間的松耦合度(Loosly Coupled)。服務請求者到服務提供者的綁定與服務之間應該是松耦合的。這就意味著，服務請求者不知道提供者實現的技術細節，比如程序設計語言、部署平台，等等。服務請求者往往通過消息調用操作，請求消息和響應，而不是通過使用 API 和文件格式。 這個松耦合使會話一端的軟體可以在不影響另一端的情況下發生改變，前提是消息模式保持不變。在一個極端的情況下，服務提供者可以將以前基於遺留代碼(例如，COBOL)的實現完全用基於 Java 語言的新代碼取代，同時又不對服務請求者造成任何影響。這種情況是真實的，只要新代碼支持相同的通信協議。 ·服務是位置透明的(location transparency)。服務是針對業務需求設計的。需要反應需求的變化，即所謂敏捷(agility)設計。要想真正實現業務與服務的分離。就必須使得服務的設計和部署對用戶來說是完全透明的。也就是說，用戶完全不必知道響應自己需求的服務的位置，甚至不必知道具體是哪個服務參與了響應。 4.三個抽象級 從概念上講，SOA 中有三個主要的抽象級別： ·操作：代表單個邏輯工作單元(LUW)的事務。執行操作通常會導致讀、寫或修改一個或多個持久性數據。SOA 操作可以直接與面向對象 (OO) 的方法相比。它們都有特定的結構化介面，並且返回結構化的響應。完全同方法一樣，特定操作的執行可能涉及調用附加的操作。 ·服務：代表操作的邏輯分組。服務可以分層，以降低耦合度和復雜性。一個服務的粒度(granularity)大小也與系統的性能息息相關。粒度太小，會增加服務間互操作通訊的開銷;粒度太大，又會影響服務面對需求變化的敏捷性。 ·業務流程：為實現特定業務目標而執行的一組長期運行的動作或活動。業務流程通常包括多個業務調用。 在SOA中，業務流程包括依據一組業務規則按照有序序列執行的一系列操作。操作的排序、選擇和執行稱為服務或流程編排。典型的情況是調用已編排服務來響應業務事件。從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特徵以及如何系統地構造它們。這些涉及服務建模、特徵抽取的問題已經成為現階段人們關注的焦點。

『肆』 面向服務架構的SOA特性

SOA服務具有平台獨立的自我描述XML（標准通用標記語言的子集）文檔。Web服務描述語言（WSDL，）是用於描述服務的標准語言。
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的企業，可以使用一組現有的應用來創建一個供應鏈復合應用（），這些現有的應用通過標准介面來提供功能。 要運行，管理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服務互用性組織（）提供，是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用BasicProfile測試程序來測試服務在不同平台和技術上的互用性。
J2EE和.Net
盡管J2EE和.NET平台是開發SOA應用程序常用的平台，但SOA不僅限於此。像J2EE這類平台，不僅為開發者自然而然地參與到SOA中來提供了一個平台，還通過他們內在的特性，將可擴展性，可靠性，可用性以及性能引入了SOA世界。新的規范，例如JAXB（JavaAPIforXMLBinding），用於將XML文檔定位到Java類；JAXR（JavaAPIforXMLRegistry）用來規范對UDDI注冊表（registry）的操作；XML-RPC（JavaAPIforXML-basedRemoteProcereCall）在J2EE1.4中用來調用遠程服務，這使得開發和部署可移植於標准J2EE容器的Web服務變得容易，與此同時，實現了跨平台（如.NET）的服務互用。 在企業中，關鍵任務系統（mission-criticalsystem，譯註：關鍵任務系統是指如果一個系統的可靠性對於一個組織是至關重要的，那麼該系統就是該企業的關鍵任務系統。比如，電話系統對於一個電話促銷企業來說就是關鍵任務系統，而文字處理系統就不那麼關鍵了。）用來解決高級需求，例如安全性，可靠性，事物。當一個企業開始採用服務架構作為工具來進行開發和部署應用的時候，基本的Web服務規范，像WSDL，SOAP，以及UDDI就不能滿足這些高級需求。正如前面所提到的，這些需求也稱作服務品質（QoS，qualityofservices）。與QoS相關的眾多規范已經由一些標准化組織（standardsbodies）提出，像W3C（WorldWideWebConsortium）和OASIS（）。下面的部分將會討論一些QoS服務和相關標准。
安全
Web服務安全規范用來保證消息的安全性。該規范主要包括認證交換，消息完整性和消息保密。該規范吸引人的地方在於它藉助現有的安全標准，例如，SAML（）來實現web服務消息的安全。OASIS正致力於Web服務安全規范的制定。
可靠
在典型的SOA環境中，服務消費者和服務提供者之間會有幾種不同的文檔在進行交換。具有諸如「僅且僅僅傳送一次」（once-and-only-oncedelivery），「最多傳送一次」（at-most-oncedelivery），「重復消息過濾」（plicatemessageelimination），「保證消息傳送」（guaranteedmessagedelivery）等特性消息的發送和確認，在關鍵任務系統（mission-criticalsystems）中變得十分重要。WS-Reliability和WS-ReliableMessaging是兩個用來解決此類問題的標准。這些標准現在都由OASIS負責。
策略
服務提供者有時候會要求服務消費者與某種策略通信。比如，服務提供商可能會要求消費者提供Kerberos安全標示，才能取得某項服務。這些要求被定義為策略斷言（policyassertions）。一項策略可能會包含多個斷言。WS-Policy用來標准化服務消費者和服務提供者之間的策略通信。
控制
當企業著手於服務架構時，服務可以用來整合數據倉庫（silosofdata），應用程序，以及組件。整合應用意味著例如非同步通信，並行處理，數據轉換，以及校正等進程請求必須被標准化。在SOA中，進程是使用一組離散的服務創建的。BPEL4WS或者WSBPEL（）是用來控制這些服務的語言。WSBPEL目前也由OASIS負責。
管理
隨著企業服務的增長，所使用的服務和業務進程的數量也隨之增加，一個用來讓系統管理員管理所有運行在多相環境下的服務的管理系統就顯得尤為重要。WSDM（）規定了任何根據WSDM實現的服務都可以由一個WSDM適應（WSDM-compliant）的管理方案來管理。
其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination和WS-Transaction標准中描述，這些都是OASIS的工作。 SOA的概念並非什麼新東西，SOA不同於現有的分布式技術之處在於大多數軟體商接受它並有可以實現SOA的平台或應用程序。SOA伴隨著無處不在的標准，為企業的現有資產或投資帶來了更好的重用性。SOA能夠在最新的和現有的應用之上創建應用；SOA能夠使客戶或服務消費者免予服務實現的改變所帶來的影響；SOA能夠升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經不再適用於新需求的現有系統。總而言之，SOA以藉助現有的應用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程序和業務流程。

『伍』 面向服務架構的基本特點

SOA的目標在於讓IT系統變得更有彈性，以便更靈活、更快地響應不斷改變的企業業務需求，解決軟體領域一直以來存在的「如何重用軟體功能」問題。採用SOA來構建信息平台，無疑是未來的發展方向。
SOA的5大基本特徵為軟體功能重用提供了解決的辦法。
①服務之間通過簡單、精確定義的介面進行通信，不涉及底層編程介面和通信模型。
②粗粒度性：粗粒度服務提供一項特定的業務功能，採用粗粒度服務介面的優點在於使用者和服務層之間不必再進行多次的往復，一次往復就足夠了。
③松耦合性：松耦合性要求SOA架構中的不同服務之間應該保持一種松耦合的關系，也就是應該保持一種相對獨立無依賴的關系。這樣的好處有兩點，首先是具有靈活性，其次當組成整個應用程序的服務內部結構和實現逐步地發生變化時，系統可以繼續地獨立存在。而緊耦合意味著應用程序的不同組件之間的介面與其功能和結構是緊密相連的，因而當需要對部分或整個應用程序進行某種形式的更改時這種結構就顯得非常脆弱。
④位置透明性：位置透明性要求SOA系統中的所有服務對於其調用者來說都是位置透明的，也就是說，每個服務的調用者只需要知道想要調用的是哪一個服務，但並不需要知道所調用服務的物理位置在哪。
⑤協議無關性：協議無關性要求每一個服務都可以通過不同的協議來調用。
另外，在許多傳統的IT系統的內在部分採用的是硬連接，這種結構很難讓企業快速響應市場的變化，而SOA能夠重復利用企業現有的資源，可以減輕企業運營成本，提升資源的使用效率，並且減輕企業維護人員的工作量，減少潛在的風險以及管理費用。在業務方面和IT方面帶來許多優勢：
①服務給精確的業務流程帶來靈活性；
②使用服務來改善客戶服務，而不必擔心底層復雜的IT基礎架構；
③可以迅速創建新的業務流程和復雜的應用程序，以適應市場變化；
④藉助安全、易管理的集成環境，成為響應能力更強的IT組織；
⑤通過使用預裝的、可重復使用的服務構建模塊，縮短開發和部署周期；
⑥通過使用服務來降低復雜性和維護成本；
⑦是增強而不是替換現有的IT系統。

『陸』 《微服務架構設計模式豆瓣》pdf下載在線閱讀全文，求百度網盤雲資源

《微服務架構設計模式豆瓣》網路網盤pdf最新全集下載:
鏈接: https://pan..com/s/13dZPagLLfEhXXesufeqUhQ

『柒』 SOA面向服務架構是什麼意思

就是在原有系統基礎上實現信息互聯互通。 這種具有中立的介面定義（沒有強制綁定到特定的實現上）的特徵稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程序的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。 很多平台都有這樣的功能！但是方正飛鴻的快速開發平台比較好！ 舉例： 某人就職，要經過一系列手續，使用實現SOA的話， 人事系統直接拿招聘系統的人員資料作為員工檔案的基礎 完成員工檔案後，安排職務崗位， 這個確定後，財務系統有了這個人的工資標准，ERP中多了這個資源信息，IT部門自動開EMAIL，該人入職完成。 看上去很普通的功能，但如果這些系統都不是一家廠家實現的，實現難度相當大。