SOA概覽3-SOA的基本特徵

  • 2020 年 1 月 13 日
  • 筆記

SOA的基本特徵

SOA的實施具有幾個鮮明的基本特徵。實施SOA的關鍵目標是實現企業IT資產的最大化重用。 1.可從企業外部訪問

通常被稱為業務夥伴的外部用戶也能像企業內部用戶一樣訪問相同的服務。業務夥伴採用先進的B2B協議(ebXML或RosettaNet)相互合作。當業務夥伴基於業務目的交換業務資訊時,他們就參與了一次會話。會話是業務夥伴間一系列的一條或多條業務資訊的交換。會話類型(會話複雜或簡單、長或短等)取決於業務目的。 除了B2B協議外,外部用戶還可以訪問以Web服務方式提供的企業服務。 2.隨時可用

當有服務使用者請求服務時,SOA要求必須有服務提供者能夠響應。大多數SOA都能夠為門戶應用之類的同步應用和B2B之類的非同步應用提供服務。同步應用對於其所使用的服務具有很強的依賴性。

許多同步應用通常部署在前台,其最終用戶很容易受到服務提供者短缺的影響。很多情況下,同步應用利用分散式服務提供者,這樣可以響應更多的用戶請求。但是,隨著提供特定服務功能的伺服器數量的增長,出現短缺的可能性也呈指數級上升。 相比之下,非同步應用要更為穩健,因為其採用隊列請求設計,因此可以容許出現服務提供者短缺或遲滯的情況。非同步應用大多數情況下部署在後台,用戶通常不會覺察到短暫的短缺。大部分情況下非同步應用能夠穩健應對短時間短缺,但是長時間短缺則會引發嚴重問題。在服務短缺解決、隊列引擎將罕見的大量工作推到共享的應用資源中時,可能會出現隊列溢出甚至服務死鎖。

服務使用者要求提供同步服務時,通常是基於其自身理解或使用習慣。在多數情況下,採用非同步模型可以達到同樣的效果,但更能夠體現SOA的最佳特性。

當然,並不是所有情況下都應當採用非同步設計模式。但大多數情況下,非同步消息可以確保系統在不同負荷下的伸縮性,在介面響應時間不是很短時尤其如此。 3.粗粒度服務介面

粗粒度服務提供一項特定的業務功能,而細粒度服務代表了技術組件方法。舉個例說明最為清楚:向計費系統中添加一個客戶是典型的粗粒度服務,而你可以使用幾個細粒度服務實現同一功能,如:將客戶名加入到計費系統中,添加詳細的客戶聯繫方式、添加計費資訊等等。

採用粗粒度服務介面的優點在於使用者和服務層之間不必再進行多次的往複,一次往複就足夠。Internet環境中有保障的TCP/IP會話已不再佔據主導、建立連接的成本也過高,因此在該環境中進行應用開發時粗粒度服務介面的優點更為明顯。

除去基本的往複效率,事務穩定性問題也很重要。在一個單獨事務中包含的多段細粒度請求可能使事務處理時間過長、導致後台服務超時,從而中止。與此相反,從事務的角度來看,向後台服務請求大塊數據可能是獲取回饋的唯一途徑。 4.分級

一個關於粗粒度服務的爭論是此類服務比細粒度服務的重用性差,因為粗粒度服務傾向於解決專門的業務問題,因此通用性差、重用性設計困難。解決該爭論的方法之一就是允許採用不同的粗粒度等級來創建服務。這種服務分級包含了粒度較細、重用性較高的服務,也包含粒度較粗、重用性較差的服務。

在服務分級方面,須注意服務層的公開服務通常由後台系統(BES's)或SOA平台中現有的本地服務組成。因此允許在服務層創建私有服務是非常重要的。正確的文檔、配置管理和私有服務的重用對於IT部門在SOA服務層快速開發新的公開服務的能力具有重要影響。 5.鬆散耦合

SOA具有「鬆散耦合」組件服務,這一點區別於大多數其他的組件架構。該方法旨在將服務使用者和服務提供者在服務實現和客戶如何使用服務方面隔離開來。

服務提供者和服務使用者間鬆散耦合背後的關鍵點是服務介面作為與服務實現分離的實體而存在。這是服務實現能夠在完全不影響服務使用者的情況下進行修改。

大多數鬆散耦合方法都依靠基於服務介面的消息。基於消息的介面能夠兼容多種傳輸方式(如HTTP、JMS、TCP/IP、MOM等)。基於消息的介面可以採用同步和非同步協議實現,Web服務對於SOA服務介面來講是一個重要的標準。

當使用者調用一個Web服務時,被調用的對象可以是CICS事務、DCOM或CORBA對象、J2EE EJB或TUXEDO服務等,但這與服務使用者無關。底層實現並不重要。

消息類Web服務通常是鬆散耦合和文檔驅動的,這要優於與服務特定介面的連接。當客戶調用消息類Web服務時,客戶通常會發送的是一個完整的文檔(如採購訂單),而非一組離散的參數。Web服務接收整個文檔、進行處理、而後可能或者不會返回結果資訊。由於客戶和Web服務間不存在緊密耦合請求響應,消息類Web服務在客戶和伺服器間提供了更為鬆散的耦合。 6.可重用的服務及服務介面設計管理

如果完全按照可重用的原則設計服務,SOA將可以使應用變得更為靈活。可重用服務採用通用格式提供重要的業務功能,為開發人員節約了大量時間。設計可重用服務是與資料庫設計或通用數據建模類似的最有價值的工作。由於服務設計是成功的關鍵因此,因此SOA實施者應當尋找一種適當的方法進行服務設計過程管理。

服務設計管理根本上講是服務設計問題,服務設計需要在兩點間折衷??走捷徑的項目戰術與企業構建可重用通用服務的長期目標。

超越項目短期目標進行服務介面的開發和評估是邁向精確定義服務介面的重要一步,同時還需要為介面文檔、服務實現文檔及所有重要的非功能性特徵設立標準。

在大型組織中實現重用的一個先決條件是建立通用(設計階段)服務庫和開發流程,以保證重用的正確性和通用性。此外,對記述服務設計和開發的服務文檔進行評估也是成功利用服務庫的關鍵。

簡而言之,不按規則編寫服務將無法保證可提供重用性的SOA的成功實施。在執行規則的過程中會產生財務費用,需要在制定SOA實施計劃時加以考慮。 7.標準化的介面

近年來出現的兩個重要標準XML和Web服務增加了全新的重要功能,將SOA推向更高的層面,並大大提升了SOA的價值。儘管以往的SOA產品都是專有的、並且要求IT部門在其特定環境中開發所有應用,但XML和Web服務標準化的開放性使企業能夠在所部署的所有技術和應用中採用SOA。這具有巨大的意義!

Web服務使應用功能得以通過標準化介面(WSDL)提供,並可基於標準化傳輸方式(HTTP和JMS)、採用標準化協議(SOAP)進行調用。例如,開發人員可以採用最適於門戶開發的工具輕鬆創建一個新的門戶應用,並可以重用ERP系統和訂製化J2EE應用中的現有服務,而完全無須了解這些應用的內部工作原理。採用XML,門戶開發人員無須了解特定的數據表示格式,便能夠在這些應用間輕鬆地交換數據。

你也可以不採用Web服務或XML來創建SOA應用,但是這兩種標準的重要性日益增加、應用日趨普遍。儘管目前只有幾種服務使用者支援該標準,但未來大多數的服務使用者都會將其作為企業的服務訪問方法。 8.支援各種消息模式

SOA中可能存在以下消息模式。在一個SOA實現中,常會出現混合採用不同消息模式的服務。

無狀態的消息。使用者向提供者發送的每條消息都必須包含提供者處理該消息所需的全部資訊。這一限定使服務提供者無須存儲使用者的狀態資訊,從而更易擴展。

有狀態的消息。使用者與提供者共享使用者的特定環境資訊,此資訊包含在提供者和使用者交換的消息中。這一限定使提供者與使用者間的通訊更加靈活,但由於服務提供者必須存儲每個使用者的共享環境資訊,因此其整體可擴展性明顯減弱。該限定增強了服務提供者和使用者的耦合關係,提高了交換服務提供者的服務難度。

等冪消息。向軟體代理髮送多次重複消息的效果和發送單條消息相同。這一限定使提供者和消費者能夠在出現故障時簡單的複製消息,從而改進服務可靠性。 9.精確定義的服務介面

服務是由提供者和使用者間的契約定義的。契約規定了服務使用方法及使用者期望的最終結果。此外,還可以在其中規定服務品質。此處需要注意的關鍵點是,服務契約必須進行精確定義。

META將SOA定義為:「一種以通用為目的、可擴展、具有聯合協作性的架構,所有流程都被定義為服務,服務通過基於類封裝的服務介面委託給服務提供者,服務介面根據可擴展標識符、格式和協議單獨描述。」該定義的最後部分表明在服務介面和其實現之間有明確的分界。 (作者:崔曉波)