SOA_and_ESB(WMB)3

其次,ESB明確強調消息(Message)處理在集成過程中的作用,這裡的消息指的是應用環境中被集成對象之間的溝通。以往傳統的EAI實施中碰到的最大的問題就是被集成者都有自己的方言,即各自的消息格式。作為基礎架構的EAI系統,必須能夠對系統範疇內的任何一種消息進行解析。傳統的EAI系統中的消息處理大多是被動的,消息的處理需要各自中間件的私有方式支持,例如API的方式。因此儘管消息處理本身很重要,但消息的直接處理不會是傳統EAI系統的核心。ESB系統由於集成對象統一到服務,消息在應用服務之間傳遞時格式是標準的,直接面向消息的處理方式成為可能。如果ESB能夠在底層支持現有的各種通訊協議,那麼對消息的處理就完全不考慮底層的傳輸細節,而直接通過消息的標準格式定義來進行。這樣,在ESB中,對消息的處理就會成為ESB的核心,因為通過消息處理來集成服務是最簡單可行的方式。這也是ESB中總線(Bus)功能的體現。其實,總線的概念並不新鮮,傳統的EAI系統中,也曾經提出過信息總線的概念,通過某種中間件平台,如CORBA來連接企業信息孤島,但是,ESB的概念不僅僅是提供消息交互的通道,更重要的是提供服務的智能化集成基礎架構。

最後,事件驅動成為ESB的重要特徵。通常服務之間傳遞的消息有兩種形式,一種是調用(Call), 即請求/回應方式,這是常見的同步模式。還有一種我們稱之為單路消息(One-way),它的目的往往是觸發異步的事件, 發送者不需要馬上得到回復。考慮到有些應用服務是長時間運行的,因此,這種異步服務之間的消息交互也是ESB必須支持的。除此之外,ESB的很多功能都可以利用這種機制來實現,例如,SOA中服務的性能監控等基礎架構功能,需要通過ESB來提供數據,當服務的請求通過ESB中轉的時候,ESB很容易通過事件驅動機制向SOA的基礎架構服務傳遞信息。

2.4.2    ESB的要素

ESB連接和企業的IT基礎結構,可以跨越不同的地域,支持不同的傳輸協議,它可以自動路由消息並且提供系統級的功能(例如,消息的格式自動轉換),ESB的實現必須是基於標準的規範, 並且這些實現必須是安全的、可靠的,並且在非常高的流量壓力情況下可管理。


遵循SOA架構的ESB 模式中,服務交互的參與方並不直接交互,而是通過一個總線交互,該總線提供虛擬化和管理功能來實現和擴展 SOA 的核心定義。
因此 ESB 模式使請求者不用了解服務提供者的物理實現——從應用程序開發人員和部署人員的角度來看均是如此。總線負責將請求交付給提供所需功能和 QoS 的服務提供者。提供者接收他們要響應的請求,而不知道消息的來源。ESB 本身對使用它的服務請求者和提供者均不可見。應用程序邏輯可以使用各種編程模型和技術調用或交付服務,而無需考慮是直接連接還是通過 ESB 傳遞的。連接到 ESB 是部署決策;應用程序源代碼不會受到影響。

 

2.4.3    ESB的功能

ESB 支持許多交互類型,包括單向、請求/響應、異步、同步和發布/訂閱。它還支持複雜事件處理(在複雜事件處理中,可能會觀測到一系列事件),以產生一個事件作為該系列中的關係的結果。

下圖對基本 ESB 模式進行了簡單描述。


消息流過將各個通信參與方相互連接在一起的總線,某些參與方會調用其他參與方提供的服務;而其他參與方則會向感興趣的使用者發布信息。端點與 ESB 交互的位置稱為服務交互點 (SIP)。例如,SIP 可以是 Web 服務端點、消息隊列或 RMI 遠程對象的代理。服務註冊表將捕獲描述以下內容的元數據:SIP 的要求和功能(例如,提供或需要的接口)、它們希望與其他 SIP 的交互方式(例如,同步或異步,通過 HTTP JMS)、它們的 QoS 要求(例如,首選的安全、可靠交互)以及支持與其他 SIP 交互的其他信息(例如,語義注釋)。

將總線插入參與方之間,提供了將它們的交互通過稱為”中介”的構造進行協調的機會。中介對請求者和提供者之間動態傳遞的消息進行操作。對於複雜的交互,可以按順序將中介連在一起。中介模式部分討論了實現這些虛擬化、QoS 和管理概念的常用中介模式。

總的來說,ESB的主要功能是:

    ESB提供了服務位置和標識的基礎功能:參與方不需要知道其他參與方的位置或標識。例如,請求者不需要知道請求是否可以由某個提供者提供服務。您可以隨意添加或刪除服務提供者,而不會帶來任何干擾。這是IT系統實現靈活的服務框架的基礎。

    交互協議的功能:參與方不需要採用相同的通信協議或交互方式。表達為 SOAP/HTTP 的請求可能由包括 Java 遠程方法調用 (RMI)EJB等的提供者提供服務。

    獨立的接口處理:請求者和提供者不需要就公共接口達成協議。ESB 可以通過將請求消息轉換為提供者所期望的格式來處理此類差異。

    交互的服務質量 (QoS):參與方聲明其 QoS 要求,包括性能和可靠性、請求的授權、消息內容的加密/解密、服務交互的自動審核以及如何對請求進行路由(如根據工作負載分布標準將請求路由到可用的實現)。描述請求者和提供者的 QoS 要求和功能的策略可以由服務自己實現或者由進行不匹配補償的 ESB 實現。因此 ESB 模式使請求者不用了解服務提供者的物理實現——從應用程序開發人員和部署人員的角度來看均是如此。總線負責將請求交付給提供所需功能和 QoS 的服務提供者。提供者接收他們要響應的請求,而不知道消息的來源。

    保證不同應用系統之間的高度內聚,同時又保持各個應用系統的相對獨立性,使得各個系統之間存在着鬆散的藕合關係。

    保證在一個異構的環境中實現信息穩定、可靠的傳輸,屏蔽掉用戶實際中的硬件層、操作系統層、網絡層等相對複雜、煩瑣的接口,最大限度地提高用戶應用的可移植性、可擴充性和可靠性。

    可以將複雜的網狀結構變為星型結構,大大簡化系統配置;它為各種應用提供一個統一接口,從而大大減少系統間接口的個數;同時,它可以作為一個數據中心,提供各種數據處理服務

    提供了消息處理、格式轉換和消息路由等功能,用於實現系統擴展性和高可靠性。

 

2.4.4    ESB的實現模式

ESB 的角度來看,所有的服務交互端點都是類似的,因為它們都發送或處理請求/事件;它們都要求特定的 QoS;它們可能都需要交互協助。ESB 模式允許集成開發人員以與處理新業務邏輯、流程編排組件或外部 Web 服務同樣(面向服務)的方式對待與用戶交互的請求者或提供者。

用於構建基於 ESB 的解決方案的模式大致分為以下幾類:

    交互模式:允許服務交互點將消息發送到總線或從總線接收消息。

    中介模式:允許對消息交換進行操作。

    組合模式:綜合交互模式和中介模式進行更複雜處理。

    部署模式:支持將解決方案部署到聯合基礎設施中。

 

2.5    應用系統整合的國內外現狀

IDC的調查報告指出:”應用整合市場全球營業收入已經從2000年的50億美元上升到2006年的240億美元,這意味着綜合年增長率超過了30%。與此相對應,整個IT服務產業的同期綜合年增長率預計只有11%。”IDC還報道,北美和西歐等國家產生90%的應用整合服務需求,而日本和拉美將驅動剩下的需求。因此,他們認為:應用整合仍是是最近幾年內IT行業中增長最快的部分。其實,IT系統的整合是一個全球性問題,另據有關機構統計,大型企業每年IT預算的40%投給了整合和集成平台,整合和集成還被全球33%CIO評為最重要的問題,超過90%CIO認為它是非常重要的問題。

應用整合的前提是企業已經擁有了較為完善但又相互獨立的應用信息系統。經過十幾年的努力,我國企業信息化已經得到了很大的發展。隨着技術的進步以及Internet和電子商務應用的不斷深入,企業對信息化應用的要求也在不斷提高。同時,為了適應發展變化的形勢,企業應用系統也面臨著升級的壓力。因此,企業面臨著兩種選擇:第一,完全放棄已有的封閉系統,採用全新的開放技術或產品來開發企業的全部應用;第二,維持已有系統的正常運轉,採用整合技術將不同的系統集成起來。如果是稍大型的企業應用,完全更換是不現實的。因此絕大多數人傾向於應用整合。


中國應用整合應用行業分布

企業應用整合不僅包括企業內部應用系統的集成,還包括企業與企業間的集成。從集成層面上來講包括點對點集成、平台集成、數據集成、流程集成以及界面的集成。在電信行業里,去年某省移動成功實施了EAI項目,網通也較早實施了EAI;在金融領域中,某大型商業銀行的某省分行應用EAI框架,在金融領域率先完成了EAI項目,將之應用在國際結算業務的單證影像系統中;其他大型商業銀行也逐步或者已經用EAI技術構建自身IT架構的信息總線。EAI,如今似乎已成為金融、保險、電信、煙草、保險、石油、電力、航空、汽車等領域愈來愈

以下文章點擊率最高

Loading…

     

如果這文章對你有幫助,請掃左上角微信支付-支付寶,給於打賞,以助博客運營

發表評論

您的電子郵箱地址不會被公開。 必填項已用*標註