SOA（面向服務的架構）

面向服務的架構（SOA）是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）經過這些服務之間定義良好的接口和契約聯繫起來。
接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操做系統和編程語言。
這使得構建在各類各樣的系統中的服務能夠以一種統一和通用的方式進行交互。
Service-Oriented Architecture           面向服務的體系結構        SOA          組件模型

定義介紹
面向服務架構，它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。
服務層是SOA的基礎，能夠直接被應用調用，從而有效控制系統中與軟件代理交互的人爲依賴性。
SOA是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。
SOA能夠看做是B/S模型、XML（標準通用標記語言的子集）/Web Service技術以後的天然延伸。
SOA將可以幫助軟件工程師們站在一個新的高度理解企業級架構中的各類組件的開發、部署形式，
它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。
較之以往，以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 模型大的改變。
這種分工，就是讓開發人員集中精力於建立做爲服務定義的功能單元，
而讓架構師和建模人員集中精力於如何將這些單元適當地組織在一塊兒，它已經有十多年的歷史了，
一般用統一建模語言（Unified Modeling Language，UML），而且描述成模型驅動的體系結構（Model-Driven Architecture，MDA）。
對於面向同步和異步應用的，基於請求/響應模式的分佈式計算來講，SOA是一場革命。
一個應用程序的業務邏輯（business logic）或某些單獨的功能被模塊化並做爲服務呈現給消費者或客戶端。
這些服務的關鍵是他們的鬆耦合特性。例如，服務的接口和實現相獨立。
應用開發人員或者系統集成者能夠經過組合一個或多個服務來構建應用，而無須理解服務的底層實現。舉例來講，一個服務能夠用.NET或J2EE來實現，而使用該服務的應用程序能夠在不一樣的平臺之上，使用的語言也能夠不一樣。

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的一些關鍵元素有安全需求（例如認證和受權），可靠通訊（譯註：可靠消息是指，確保消息「僅且僅僅」發送一次，從而過濾重複信息。），以及誰能調用服務的策略。
不一樣種類的操做系統，應用軟件，系統軟件和應用基礎結構（application infrastructure）相互交織，這即是IT企業的現狀。
一些現存的應用程序被用來處理當前的業務流程（business processes），
所以從頭創建一個新的基礎環境是不可能的。
企業應該能對業務的變化作出快速的反應，
利用對現有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業務需求，
爲客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個能夠支持有機業務（organic business）的構架。
SOA憑藉其鬆耦合的特性，使得企業能夠按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務須要，提供選擇從而能夠經過不一樣的渠道提供服務，並能夠把企業現有的或已有的應用做爲服務， 從而保護了現有的IT基礎建設投資。

SOAP， WSDL， UDDI
WSDL，UDDI和SOAP是SOA基礎的基礎部件。
WSDL用來描述服務；UDDI用來註冊和查找服務；而SOAP，做爲傳輸層，用來在消費者和服務提供者之間傳送消息。
SOAP是Web服務的默認機制，其餘的技術爲能夠服務實現其餘類型的綁定。
一個消費者能夠在UDDI註冊表（registry）查找服務，取得服務的WSDL描述，而後經過SOAP來調用服務。

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

優勢
服務導向架構並非一種全新的解決方案；相反，SOA是技術與架構的天然進化。系統架構一直在不斷進步，與商業保持高度一致。
系統設計師與商家很早就認識到將技術與商業流程相協調的重要性，包括充分應用併合理化技術資源，以及爲商業提供更好的支持。
SOA也在必定程度上源於早已有之的企業架構理論。
企業架構對技術進行評估，可是更重要的是，它關注整個企業和所有的商業流程並提供了作出技術決策的背景信息。
SOA工具則融合了互聯網技術，如HTTP和XML，以及綜合技術，如消息總線、轉譯技術和鏈接技術。
虛擬桌面基礎設施、資源平衡和應用程序級高可用性多是其它的將來應用實例。這些解決方案有一些技術的和經濟的障礙。
這些障礙必需要在虛擬化普遍應用前克服。可是，考慮到虛擬化的重點，這些障礙已經在開始克服。
虛擬化還將成爲SOA(面向服務的架構)技術應用的推進因素。 面向服務的體系結構基於這些實際活動或業務服務進行組織，而不是造成公司所維護的不一樣的信息豎井 (Silo)。

優點
一，SOA可經過互聯網服務器發佈，從而突破企業內網的限制，實現與供應鏈上下游夥伴業務的緊密結合。
    經過SOA架構，企業能夠與其業務夥伴直接創建新渠道，創建新夥伴的成本得以下降。
二，SOA與平臺無關，減小了業務應用實現的限制。要將企業的業務夥伴整合到企業的「大」業務系統中，
    對其業務夥伴具體採用什麼技術沒有限制。
三， SOA具備低耦合性特色，業務夥伴對整個業務系統的影響較低。在企業與各業務夥伴關係不斷髮生變化的狀況下，節省的費用會愈來愈多。
四， SOA具備可按模塊分階段進行實施的優點。能夠成功一步再作下一步，將實施對企業的衝擊減小到最小。
五， SOA的實施可能並不具備成本顯著性。這要分三種狀況加以討論：
    (1)當企業從零開始構建業務系統時，採用SOA架構與不採用SOA架構成本可看作是相同的。
    (2)當企業業務發展或發生企業重組等變化而原有系統不能知足須要，而須要重構業務系統時，
       採用SOA架構與不採用SOA架構成本可看作是相同的。
    (3)當企業業務發生緩慢變化並可預見到未來須要重構業務系統時，因爲能夠按模塊分階段逐步實施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)

服務品質
在企業中，關鍵任務系統（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）。
安全質量
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服務規範，你會取得更好的通用性。

CRM(客戶關係管理)
ERP(企業資源計劃)

 

備註：隨筆中內容來源於網上資料整理,僅供參考。