訂閱發佈模式

場景概述：

 　　有時須要將多個應用程序集成到一個框架中，這些應用程序常見的基礎通訊方式包含總線模式、代理模式、

或者點對點模式。一些應用程序發送多種類型的消息，其餘應用程序可能更關注這些消息類型的組合。

　　例如，在一個金融系統存在多個應用程序管理同一客戶信息的狀況，存在一個客戶關係管理程序(CRM)掌握客戶信息。

一種典型的狀況：客戶信息存在於其餘系統中，且這些系統執行各自客戶信息管理函數來處理客戶信息。

當某個面向客戶的應用程序生成更新客戶信息的消息，例如客戶地址的修改時，CRM和其餘管理客戶信息的程序

都將到該消息，然而，這個消息類型對於那些無論理客戶信息的其餘程序是沒有意義的。

問題：

　　如何才能讓一個程序在集成環境中只發送消息到那些對該消息感興趣的應用程序中，而不須要知道消息接收方

的基本信息？

 

 約束：

　　爲確保集成的軟件可以只接收到各軟件感興趣的消息，這些軟件須要知足下列約束條件：

　　1. 集成框架中的應用程序關注不一樣的消息類型。例如，管理客戶信息的應用程序關注客戶信息的更新，貿易程序關注買賣事務，用於雙向提交事務消息的應用關注消息的提交。

　　2. 集成框架中的某個應用可能發送若干個消息類型。例如，應用程序可能發送用戶和操做的狀態信息。

一樣，集成框架中的某個應用一般關注的是其餘應用程序發佈的消息子集。例如，投資經理只關注那些影響其

所管理的股票的金融信息事務。

　　3. 應用程序添加不一樣信息到消息的狀況是多種多樣的，這種狀況下，固定長度的二進制消息一般是不靈活

的，相比而言，使用封裝元素來擴展SOAP(簡單對象訪問協議)消息更爲簡單。

　　4. 大多數集成框架集成全部的應用，這些應用一般假定在該集成環境中存在同其餘應用通訊的消息，甚至

對於一個靈活的消息格式，插入或處理應用未知的消息元素均可能遇到困難。

 

解決方案：

　　經過建立主題或動態檢測消息內容來擴展通訊基礎框架。通訊框架能確保應用程序可以收到訂閱的消息，

並可以建立一種機制來發送消息到全部關注該消息的接收端（訂閱方）。

　　這裏列舉了三類建立訂閱/發佈機制方式：

　　1. List-Based Publish/Subscribe（基於列表的訂閱發佈模式）

　　2. Broadcast-Based Publish/Subscribe （基於廣播的訂閱發佈模式）

　　3. Content-Based Publish/Subscribe （基於內容的訂閱發佈模式）

　　這三類模式都可以發送消息到全部關注該消息的訂閱方。

 

List-Based Publish/Subscribe (基於列表的訂閱發佈模式）

 　　基於列表的訂閱發佈模式須要管理由訂閱方組成的鏈表，這些訂閱方都關注於某一主題。當事件發生時，

訂閱方鏈表上的全部關注該主題的訂閱者都將被通知到，這很像常見的觀察者模式。當你使用觀察者模式時，

需先肯定兩個類：主題和觀察者。假定採用push模式來更新，對於主題（subject）類須要添加三個方法：Attach(), Detach()和Notify()，對於觀察者添加Update()方法。

　　使用觀察者模式時，全部觀察者以及其所關注的主題將被註冊（使用Attach()方法）。當該主題內容發生

改變時，每一個關注該主題的觀察者都將被通知到。

　　當你建立對象實例而且具體化全部觀察者和主題時，使用觀察者模式構建訂閱發佈比較合適， 觀察者和主題

的關係要一直保持。經過構建關係數據庫，在多對多的情境下，構建主題與觀察者的依賴關係。使用時，經過

檢索該關係數據庫表，便可獲取關注某一主題的全部訂閱者。

　　維護主題和訂閱者鏈表，而後在事件來臨時，通知每個訂閱者是基於鏈表訂閱發佈實現的基礎。

 

Broadcast-Based Publish/Subscribe(基於廣播的訂閱發佈模式)

 　　當使用基於廣播的訂閱發佈模式時，事件發佈方將建立消息並廣播到局域網中，每一個監聽節點都會檢查

消息主題，若是主題爲該節點所關注的就會接收並處理該消息。若是該主題不是監聽節點關注的，就會忽略該

消息。

　　一般主題能夠分層而且可能包含多個域，每一個域根據週期來分隔，若是須要監聽節點能夠採用通配符來訂閱

某一特殊主題。

　　基於廣播的訂閱發佈可以有效的將生產者和消費者解耦，在某些狀況，還能夠作到區分特殊主題訂閱者。

爲了區分主題訂閱者，協調程序發出消息，訂閱該消息的節點將被要求回覆，這些響應回覆會指明全部該主題

的訂閱者。

　　這種訂閱發佈體如今全部的消息都會發布到全部的監聽節點，每一個節點負責過濾不感興趣的消息。

 

Content-Based Publish/Subscribe（基於文本內容的訂閱發佈模式）

 　　基於廣播和列表的訂閱發佈基本上都根據主題來分類，都使用預約義主題的方式實現多對多通訊。

基於主題和基於內容通訊的不一樣點以下：

　　在基於主題的系統，進程交換信息經過一個預訂的主題集合，這些主題在多對多的情景下用來區分各

邏輯通道。基於內容的系統更爲靈活，由於訂閱方與特殊消息內容有關，信息組合的方式被視爲動態的

邏輯通道，這極大的擴展了潛在的邏輯通道數量，也改變了訂閱發佈系統實現的方式。

 

使用訂閱發佈

　　圖一顯示四個應用程序集成的一種方案。發送方使用基於主題的方式來發布消息給主題A和主題B。其中

三個接收方訂閱這些主題；其中一個訂閱了主題A，一個訂閱了主題B，一個訂閱了主題A和B。箭頭描述消息發送

路徑。

　　實現訂閱發佈過程，一般影響消息結構，應用集成和通訊基礎框架。　　

　　首先， 必須區分主題或應用程序感興趣的內容。這將轉化爲將消息類型分爲不一樣的子集。例如在貿易領域

消息類型，一些貿易應用須要追蹤買入事務，一些追蹤賣出事務，其餘應用追蹤買賣事務。經過建立買入和賣出

主題來分離消息，並將貿易消息劃分到不一樣子集。

　　下一步，必須給消息中添加信息，這些消息指明主題或識別特殊內容信息。有時能夠經過保存主題相關的

信息到消息結構的某個未使用的域內。還有一種方式，能夠爲主題添加一個新的域，例如在SOAP頭中添加一個

新的元素。若是既不能使用已存在的域又不能添加，只能找到某種方式將主題嵌入到消息中，或者使用基於

內容的訂閱發佈方式。

　　接下來必須擴展通訊基礎框架以便消息可以傳遞給每一個訂閱者。使用的方法依賴於集成解決方案的拓撲

結構，例如三類廣泛的拓撲結構。對於總線結構，能夠採用在總線接口上實現訂閱機制；對於代理結構，能夠

經過爲代理者建立訂閱者鏈表來實現；對於點對點結構，能夠在發佈方建立訂閱鏈表來實現。

　　最後，須要修改應用集成框架，發佈方必須將與主題相關的信息添加到每一個發佈的消息中。例如，若是主題

做爲頭元素編入，發佈方必須將主題相關信息插入到合適的位置，一樣地，訂閱方必須明確感興趣的主題。

　　訂閱方能夠是固定或動態的，當訂閱方是固定的，集成框架設置應用訂閱的主題，應用程序沒法控制訂閱。

一般，訂閱過程由每一個應用程序在被添加到集成環境時肯定。圖二顯示一個針對主題A的固定訂閱方式。

 

　　與之相比，動態訂閱能讓每一個應用程序經過一組控制消息來控制其自身訂閱過程。應用程序經過發送消息

到通訊基礎框架，使其將應用程序從訂閱鏈表中移除，來實現移除訂閱內容。大多數提供訂閱發佈功能的通訊

框架都提供該功能，然而，不是非得要動態訂閱才能實現這種功能。

　　

 

 　上圖描述了動態訂閱的功能，首先是初始訂閱主題A，而後應用發送消息了從訂閱鏈表中移除訂閱，接着應用

發送兩個消息來訂閱主題B和主題C。

相關決定：

　　在決定使用訂閱發佈模式後，須要肯定下述要素：

　　1. 初始訂閱。 必須肯定訂閱方首次添加到集成環境中如何經過通訊框架與訂閱內容通訊。

　　2. 通配符訂閱。必須肯定是否讓訂閱發佈模式支持通配符訂閱。通配符訂閱確保訂閱者經過一個訂閱過程來

訂閱多個主題。

　　3. 靜態或動態訂閱。必須肯定集成解決方案是動態訂閱仍是靜態訂閱。

　　4. 主題發現。 必須肯定訂閱者在解決方案中支持動態訂閱的狀況下可以發現能夠主題。

職責與協做：

　　下表爲訂閱發佈個組件的職責和功能。