專利名稱：一種事件通訊裝置及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)系統(tǒng)的事件服務(wù)技術(shù)，特別是涉及一種事件通訊裝置及方法。
背景技術(shù)：
隨著信息技術(shù)的發(fā)展，越來越多的信息通過網(wǎng)絡(luò)實現(xiàn)傳輸。例如在基于通用對象請求代理架構(gòu)(CORBA，Common Object Request Broker Architecture)的網(wǎng)絡(luò)的網(wǎng)管系統(tǒng)中，后臺各個模塊之間及前后臺之間有大量消息傳輸，通常由基于CORBA通知(Notification)服務(wù)的事件服務(wù)器來完成消息的轉(zhuǎn)發(fā)。
將發(fā)送消息的一方稱為事件發(fā)送者，接收消息的一方稱為事件接收者?，F(xiàn)有技術(shù)中，基于CORBA Notification服務(wù)的事件服務(wù)系統(tǒng)的事件通訊方法的發(fā)送及接收消息的過程如下1)創(chuàng)建事件通道獲取Notification服務(wù)的對象引用，調(diào)用Notification服務(wù)的接口以獲取Notification服務(wù)的事件通道管理器的對象引用，然后調(diào)用所述事件通道管理器的接口創(chuàng)建事件通道。所創(chuàng)建的事件通道的個數(shù)根據(jù)具體情況而定。
2)發(fā)送此事件通道的對象引用事件通道管理器所創(chuàng)建的事件通道的信息(如通道的對象引用)存放在通道索引表內(nèi)，并將所述事件通道的對象引用通過命名服務(wù)或者其他途徑提供給需要使用所述事件通道的事件發(fā)送者和事件接收者。
3)事件發(fā)送者發(fā)送事件事件發(fā)送者發(fā)送事件之前需要知道系統(tǒng)的事件通道劃分策略，也就是需要知道自己所發(fā)送的事件類型應(yīng)該發(fā)送到哪個事件通道上，并且要知道如何獲取此事件通道的對象引用。
得到事件通道后，事件發(fā)送者將所要發(fā)送的消息結(jié)構(gòu)映射到通用事件結(jié)構(gòu)中，選擇發(fā)送模式(push模式或pull模式，以及單事件發(fā)送模式或多事件發(fā)送模式)，并根據(jù)該發(fā)送模式創(chuàng)建一個Notification服務(wù)的事件發(fā)送器(ProxySupplier)對象，調(diào)用事件通道的對象引用，將所述ProxySupplier對象連接到事件通道，最終調(diào)用ProxySupplier接口將所要發(fā)送的消息發(fā)送出去。
4)事件接收者接收事件事件接收者接收事件時同樣需要知道系統(tǒng)的事件通道劃分策略，也就是需要知道自己需要接收的事件類型是發(fā)送到哪個事件通道上的，并且要知道如何獲取此事件通道的對象引用。
得到事件通道后，事件接收者還要選擇接收模式(push模式或pull模式，以及單事件接收模式或多事件接收模式)，并根據(jù)該接收模式創(chuàng)建Notification服務(wù)的事件接收器(ProxyConsumer)對象，調(diào)用事件通道的接口將ProxyConsumer對象連接到事件通道上，通過此事件通道接收消息。
事件接收者在接收到消息后，從通用事件結(jié)構(gòu)中取出信息并填充到自己的消息結(jié)構(gòu)中。
至此基于Notification服務(wù)的消息的發(fā)送及接收過程完成。
如圖1所示，是COBRA Notification服務(wù)提供的可擴(kuò)展的通用事件結(jié)構(gòu)(StructuredEvent)的示意圖。
所述StructuredEvent包括以下字段定長消息頭(Fixed Header)用于表明事件的類型、名稱和發(fā)起事件的區(qū)域或者領(lǐng)域，所述Fixed Header進(jìn)一步包括域名(Domain_name)，用于標(biāo)識事件發(fā)起的區(qū)域或領(lǐng)域，事件類型名稱(Type_name)，用于標(biāo)識事件的類型，事件名稱(Event_name)，用于標(biāo)識事件的名稱；可變消息頭(Variable Header)用于存放額外的事件說明信息，該字段為擴(kuò)展字段，所述Variable Header進(jìn)一步包括可變消息頭字段名稱(VH_name)，可變消息頭字段內(nèi)容(VH_value)；可變長度消息體(Filterable Body)用于存放消息的詳細(xì)信息，是消息的主體，所述Filterable Body進(jìn)一步包括消息體字段名(Name)，消息體字段內(nèi)容(Value)；事件體的擴(kuò)展部分(Remaining Body)由使用根據(jù)需要自行填寫。
對于一個消息事件，所述可變消息頭字段名稱與可變消息頭字段內(nèi)容對可有多個；同樣對于消息體字段名與消息體字段內(nèi)容對也可以有多個。
同時，Notification服務(wù)允許用戶根據(jù)需要創(chuàng)建多個事件通道，將不同類型的事件在不同通道上發(fā)送，用戶程序調(diào)用Notification服務(wù)的接口創(chuàng)建一個事件通道，然后將此事件通道的對象引用通過某種方式如CORBA命名服務(wù)發(fā)布給需要使用此通道的程序包括事件發(fā)送者和事件訂閱者，事件訂閱者可以根據(jù)需要連接到特定的通道上。
該現(xiàn)有技術(shù)的缺陷在于由于CORBA Notification服務(wù)使用通用事件結(jié)構(gòu)StructuredEvent，因此事件發(fā)送者需要將其消息結(jié)構(gòu)映射到StructuredEvent結(jié)構(gòu)的事件體中；事件接收者需要從StructuredEvent結(jié)構(gòu)中取出信息填充到自己的消息結(jié)構(gòu)中，使用起來較為不方便。
當(dāng)使用多通道發(fā)送事件時，事件接收者無法根據(jù)需要接收的事件查找到對應(yīng)的事件通道，事件發(fā)送者也無法直接根據(jù)所要發(fā)送的消息的事件類型來連接到對應(yīng)的事件通道，只能根據(jù)預(yù)先約定的方式從命名服務(wù)或其他途徑獲取事件通道的引用，并且連接過程比較復(fù)雜。
綜上所述，事件發(fā)送者和事件接收者直接使用Notification的過程復(fù)雜且繁瑣，且綁定比較緊密，如果需要修改事件通道分配策略則需要修改應(yīng)用程序代碼。

發(fā)明內(nèi)容
本發(fā)明解決的技術(shù)問題是提供一種事件通訊裝置及方法，可以簡化Notification服務(wù)使用的復(fù)雜度，提高系統(tǒng)的可移植性和兼容性。
為此，本發(fā)明解決技術(shù)問題的技術(shù)方案是提供一種事件通訊裝置，包括事件類型對象單元，用于生成事件類型對象和解析事件類型對象，所述事件類型對象包括消息載體和消息頭存取部分，其中消息載體用于以通用事件結(jié)構(gòu)存放待發(fā)送的消息，所述消息頭存取部分用于根據(jù)事件類型填充通用事件結(jié)構(gòu)的消息頭或者從消息頭中提取信息；事件服務(wù)器，用于根據(jù)通道分配信息創(chuàng)建事件通道并保存所有事件通道引用，所述通道分配信息包括事件通道和事件類型的對應(yīng)關(guān)系；事件發(fā)送單元，用于發(fā)送事件，包括從上層的事件發(fā)送者獲取事件類型對象，根據(jù)事件類型信息從該事件服務(wù)器獲得事件通道的引用，創(chuàng)建事件發(fā)送代理對象并連接到所述事件通道，將封裝的消息發(fā)送出去；事件接收單元，用于接收事件，包括根據(jù)傳入的事件類型信息從該事件服務(wù)器獲得事件通道的引用，創(chuàng)建事件接收代理對象并連接到事件通道上，實現(xiàn)消息的接收，根據(jù)其中的事件結(jié)構(gòu)體生成事件類型對象并傳送給上層的事件接收者。
優(yōu)選地，所述事件發(fā)送單元包括事件發(fā)送類型選擇單元，用于選擇發(fā)送類型是逐一發(fā)送還是批量發(fā)送；事件模式選擇單元，用于選擇模式是push模式還是pull模式；單事件發(fā)送器，用于實現(xiàn)單一事件的發(fā)送；批事件發(fā)送器，用于實現(xiàn)批量事件的發(fā)送。
優(yōu)選地，所述事件發(fā)送單元還包括事件通道類型選擇單元，用于選擇是CORBA Notification通道類型，還是自定義通道類型。
優(yōu)選地，所述單事件發(fā)送器包括事件類型對象接口，用于接收事件類型對象；事件通道獲取單元，用于根據(jù)事件類型信息從該事件服務(wù)器獲得事件通道的引用；事件發(fā)送代理創(chuàng)建單元，用于創(chuàng)建CORBA Notification事件發(fā)送代理對象。
優(yōu)選地，所述事件接收單元包括事件接收類型選擇單元，用于選擇接收類型是逐一接收還是批量接收；事件模式判斷單元，用于判斷模式是push模式還是puu模式；事件訂閱單元，用于從上層的事件接收者接收事件訂閱信息，并根據(jù)事件訂閱信息實現(xiàn)事件的接收；事件傳輸單元，用于根據(jù)接收的事件生成事件類型對象并提供給上層進(jìn)行處理。
優(yōu)選地，所述事件接收單元還包括事件通道類型判斷單元，用于確定是CORBA Notification通道類型，還是自定義通道類型。
優(yōu)選地，所述事件訂閱單元包括訂閱信息接收單元，用于接收事件訂閱信息，包括事件類型信息和事件過濾條件；事件通道獲取單元，用于根據(jù)事件類型信息從該事件服務(wù)器獲得事件通道的引用；事件接收代理創(chuàng)建單元，用于創(chuàng)建CORBA Notification事件接收代理對象。
本發(fā)明還提供一種事件通訊方法，包括步驟1)根據(jù)通道分配信息創(chuàng)建事件通道并保存所有事件通道引用，所述通道分配信息包括事件通道和事件類型的對應(yīng)關(guān)系；2)事件發(fā)送者生成事件類型對象；所述事件類型對象包括消息載體和消息頭存取部分，其中消息載體用于以通用事件結(jié)構(gòu)存放待發(fā)送的消息，所述消息頭存取部分，用于根據(jù)事件類型填充通用事件結(jié)構(gòu)的消息頭或者從消息頭中提取信息；3)封裝待發(fā)送消息為通用事件結(jié)構(gòu)；事件發(fā)送單元根據(jù)事件類型獲得事件通道的引用，創(chuàng)建事件發(fā)送代理對象并連接到事件通道，實現(xiàn)事件的發(fā)送；4)事件接收單元接收事件類型信息，根據(jù)事件類型信息獲得事件通道的引用；創(chuàng)建事件接收代理對象并連接到事件通道，實現(xiàn)事件的接收；根據(jù)接收到的事件生成事件類型對象；5)事件接收者從該事件類型對象獲取發(fā)送的消息內(nèi)容。
優(yōu)選地，所述步驟3)還包括當(dāng)通道類型是自定義通道時，根據(jù)事件類型獲取對端的地址；將待發(fā)送的消息按照事件接收者的格式打包；與對端建立連接；基于該連接實現(xiàn)事件的發(fā)送；所述步驟4)還包括當(dāng)通道是自定義通道時，根據(jù)接收到的數(shù)據(jù)包生成事件類型對象。
優(yōu)選地，所述步驟2)所述的通用事件結(jié)構(gòu)是指CORBA Notification服務(wù)使用的StructuredEvent結(jié)構(gòu)。
優(yōu)選地，所述事件類型對象還包括消息體存取部分，用于根據(jù)事件類型填充通用事件結(jié)構(gòu)的消息體或者從消息體中提取信息；所述步驟3)的封裝具體是通過消息頭存取部分和/或消息體存取部分實現(xiàn)的；所述步驟5)的獲取具體是通過消息頭存取部分和/或消息體存取部分實現(xiàn)的。
相對于現(xiàn)有技術(shù)，本發(fā)明的有益效果是首先，由于本發(fā)明中生成事件類型對象，可以實現(xiàn)通用事件結(jié)構(gòu)的消息頭的自動填充和提取，即實現(xiàn)對通用事件結(jié)構(gòu)的封裝，并且通過事件服務(wù)器創(chuàng)建事件通道，由事件發(fā)送單元和事件接收單元實現(xiàn)事件通道的獲取和連接等操作，即對上層封裝這些操作，從而降低了事件發(fā)送者和事件接收者的使用復(fù)雜度，同時可以提高系統(tǒng)的可移植性和兼容性，還可以在不改變上層程序的情況下修改事件發(fā)送模式。
此外，在本發(fā)明的優(yōu)選方案中，可以根據(jù)通道的類型來實現(xiàn)發(fā)送和接收的處理，因此，本發(fā)明不僅可應(yīng)用于COBRA的Notification模式，還可以應(yīng)用于非COBRA，構(gòu)造普通系統(tǒng)的事件通訊機(jī)制。


圖1是COBRA Notification服務(wù)提供的可擴(kuò)展的通用事件結(jié)構(gòu)的示意圖；圖2是本發(fā)明的事件通訊裝置的框圖；圖3是圖2所示的事件發(fā)送單元的框圖；圖4是圖3所示的單事件發(fā)送器的框圖；圖5是圖2所示的事件接收單元的框圖；圖6是圖5所示的事件訂閱單元的框圖；圖7是本發(fā)明的實施例的事件通訊裝置的框圖；圖8是本發(fā)明的實施例中的消息頭存取部分和消息體存取部分與通用事件結(jié)構(gòu)的對應(yīng)關(guān)系的示意圖；圖9是本發(fā)明的實施例中的事件發(fā)送的流程圖；圖10是本發(fā)明的實施例中的事件訂閱的流程圖；圖11是本發(fā)明的實施例中的事件接收的流程圖；圖12是本發(fā)明的事件通訊方法的流程圖。
具體實施例方式
請參閱圖2，是本發(fā)明的事件通訊裝置的框圖。
該事件通訊裝置包括事件類型對象單元100、事件服務(wù)器200和事件發(fā)送單元300、事件接收單元400。
其中，該事件類型對象單元100可以位于上層的事件發(fā)送者800和事件接收者900內(nèi)，分別用于生成事件類型對象和解析事件類型對象。當(dāng)然，所述事件類型對象單元100也可以分別位于事件發(fā)送單元200和事件發(fā)送單元300內(nèi)；或者分別位于事件發(fā)送者800和事件發(fā)送單元200之間、事件接收者900和事件接收單元300之間。
所述事件類型對象單元100生成的事件類型對象包括消息載體，用于以通用事件結(jié)構(gòu)存放待發(fā)送的消息；消息頭存取部分，用于根據(jù)事件類型填充通用事件結(jié)構(gòu)的消息頭或者從消息頭中提取信息。
該事件服務(wù)器200用于根據(jù)通道分配信息創(chuàng)建事件通道并保存所有事件通道引用，所述通道分配信息包括事件通道和事件類型的對應(yīng)關(guān)系；事件發(fā)送單元300用于發(fā)送事件，包括從上層的事件發(fā)送者800獲取事件類型對象，根據(jù)事件類型信息從事件服務(wù)器200獲得事件通道的引用，創(chuàng)建標(biāo)準(zhǔn)的Notification事件發(fā)送代理對象并連接到所述事件通道，將封裝的消息發(fā)送出去。
事件接收單元400用于接收事件，包括根據(jù)傳入的事件類型信息從事件服務(wù)器200獲得事件通道的引用，創(chuàng)建標(biāo)準(zhǔn)的Notification事件接收代理對象并連接到事件通道上，實現(xiàn)消息的接收，根據(jù)其中的事件結(jié)構(gòu)體生成事件類型對象并傳送給上層的事件接收者900。
請一并參閱圖3，所述事件發(fā)送單元300包括事件發(fā)送類型選擇單元310，用于選擇發(fā)送類型是逐一發(fā)送還是批量發(fā)送；事件模式選擇單元320，用于選擇模式是push模式還是pull模式；單事件發(fā)送器330，用于實現(xiàn)單一事件的發(fā)送；批事件發(fā)送器340，用于實現(xiàn)批量事件的發(fā)送。
此外，所述事件發(fā)送單元300還包括事件通道類型選擇單元350，用于選擇是Notification通道類型，還是自定義通道類型(詳后述)。
請參閱圖4，該單事件發(fā)送器330包括事件類型對象接口331，用于接收事件類型對象；事件通道獲取單元332，用于根據(jù)事件類型信息從事件服務(wù)器200獲得事件通道的引用；事件發(fā)送代理創(chuàng)建單元333，用于創(chuàng)建標(biāo)準(zhǔn)的Notification事件發(fā)送代理對象。
請一并參閱圖5，所述事件接收單元400包括事件接收類型選擇單元410，用于選擇接收類型是逐一接收還是批量接收；
事件模式判斷單元420，用于判斷模式是push模式還是pull模式；事件訂閱單元430，用于從上層的事件接收者接收事件訂閱信息，并根據(jù)事件訂閱信息實現(xiàn)事件的接收；事件傳輸單元440，用于根據(jù)接收的事件生成事件類型對象并提供給上層進(jìn)行處理。
此外，所述事件接收單元400還包括事件通道類型判斷單元450，用于確定是Notification通道類型，還是自定義通道類型(詳后述)。
請參閱圖6，該事件訂閱單元430包括訂閱信息接收單元431，用于接收事件訂閱信息，包括事件類型信息和事件過濾條件；事件通道獲取單元432，用于根據(jù)事件類型信息從事件服務(wù)器200獲得事件通道的引用；事件接收代理創(chuàng)建單元433，用于創(chuàng)建標(biāo)準(zhǔn)的Notification事件接收代理對象。
為了便于對本發(fā)明的進(jìn)一步理解，下面以基于CORBA Notification服務(wù)實現(xiàn)的事件通訊為例來描述本發(fā)明。
請參考圖7，是本實施例的事件通訊裝置的框圖。
其中，事件發(fā)送單元300是一個事件發(fā)送代理類Supplier Proxy；事件接收單元400是一個事件接收代理類Consumer Proxy。
基于CORBA Notification服務(wù)采用的通用事件結(jié)構(gòu)StructuredEvent，本實施例中的事件類型對象單元100生成的事件類型對象采用一個事件基類(EventBase)來實現(xiàn)。其中，消息載體是EventBase的一個成員變量，所述成員變量的類型就是StructuredEvent。消息頭存取部分是EventBase中定義的若干存取函數(shù)。若干個存取函數(shù)用來存取EventBase中的成員變量所表示的消息的字段的內(nèi)容，起到接口的作用。
用戶定義的具體事件類型都從EventBase繼承，每增加一個消息字段，則在繼承類中添加對應(yīng)的存取函數(shù)，負(fù)責(zé)將指定字段的值填充到內(nèi)部StructuredEvent的事件體中或者從事件體中取出指定的字段值，這部分函數(shù)的聲明和實現(xiàn)都類似，可以使用預(yù)定義宏來實現(xiàn)，如可以聲明一個DECLARE_EVENT_ATTRIBUTE_SHORT宏用于聲明一個short類型的事件字段及其存取函數(shù)，并聲明一個和IMPLEMENT_EVENT_ATTRIBUTE_SHORT宏提供函數(shù)實現(xiàn)，這樣定義一個事件類型就不需要額外的編碼工作。
參考圖8，是所述繼承EventBase的某個用戶自定義事件類中若干存取函數(shù)和StructuredEvent結(jié)構(gòu)的對應(yīng)關(guān)系圖。其中，獲取域信息(getDomain)從事件中獲取事件的域信息；設(shè)置域信息(setDomain)設(shè)置事件中的域信息字段；獲取事件類型(getType)從事件中獲取事件類型信息；設(shè)置事件類型(setType)設(shè)置事件中的事件類型字段；獲取事件名稱(getEventName)從事件中獲取的事件名稱信息；設(shè)置事件名稱(setEventName)設(shè)置事件中的事件名稱字段；第一獲取函數(shù)(get_name_1)獲取事件體中的一個字段信息，此字段為用戶自定義字段；第一設(shè)置函數(shù)(set_name_1)設(shè)置事件體中的一個字段信息，此字段為用戶自定義字段；第二獲取函數(shù)(get_name_2)獲取事件體中的又一個字段信息，此字段為用戶自定義字段；第二設(shè)置函數(shù)(set_name_2)設(shè)置事件體中的又一個字段信息，此字段為用戶自定義字段。
本例中不使用StructuredEvent的可變消息頭部分和事件體的擴(kuò)展部分。
存取函數(shù)的個數(shù)要根據(jù)所發(fā)送消息的字段的個數(shù)來確定，一般來說對于消息的一個字段對應(yīng)兩個存取函數(shù)，其中一個用來獲取該字段的內(nèi)容，另一個用來設(shè)置該字段的內(nèi)容。
此外，所述消息載體的封裝也可以通過多個存取函數(shù)來實現(xiàn)，此不贅述。
本實施例的事件服務(wù)器200負(fù)責(zé)根據(jù)預(yù)配置的通道分配信息在Notification中創(chuàng)建事件通道，通道分配信息包括需要創(chuàng)建幾個事件通道以及每個通道分別用于發(fā)送哪些事件類型，通道創(chuàng)建后事件服務(wù)器200在其內(nèi)部保存所有的通道對象引用。
事件服務(wù)器200還提供根據(jù)事件類型獲取對應(yīng)事件通道對象引用的接口。事件類型是由使用者自行定義的，是一個字符串，在配置文件中已經(jīng)說明此類型的事件應(yīng)該從哪個通道上發(fā)送，因此事件服務(wù)器200可以查找到對應(yīng)的通道引用。事件類型可以存放在StructuredEvent的事件頭部分，也可以存放在事件體的特定位置，實現(xiàn)者可以根據(jù)實際情況決定。用戶可以配置多個事件類型使用同一個事件通道，也可以配置一種事件類型在多個事件通道上發(fā)送。
假定存在三個事件通道，一個是通用事件通道，一個是告警事件通道，一個是性能事件通道。事件服務(wù)器200可以設(shè)置通道一用作通用事件通道，傳送兩種事件類型，這兩種事件類型分別為告警模塊通用事件和性能模塊通用事件；通道二用作告警事件通道，傳送告警事件類型的事件；通道三用作性能事件通道，傳送性能事件類型的事件。則相應(yīng)的通道配置文件如下<Channel name="1">；通道一<Partition name="Common">；通用事件通道<param name="EventType">AlarmCommon</param>；告警類型<param name="EventName">AlarmCommon1</param>
</Partition>
<Partition name="Common">；通用事件通道<param name="EventType">PerformCommon</param>；性能類型<param name="EventName">PerformCommon1</param>
</Partition>
</Channel>
<Channel name="2">；通道二<Partition name="Alarm">；告警事件通道<param name="EventType">Alarm</param>；告警類型<param name="EventName">AlarmEvent</param>
</Partition>
</Channel>
<Channel name="3">；通道三<Partition name="Perform">；性能事件通道<param name="EventType">Perform</param>；性能類型<param name="EventName">PerformEvent</param>
</Partition>
</Channel>
所述配置文件是CORBA Notification服務(wù)的事件通道的配置文件，即使用CORBA Notification服務(wù)的事件通道發(fā)送及接收消息。本發(fā)明的事件通訊裝置還可以使用自定義的事件通道，那么自定義的事件通道的配置文件包含的信息可以是事件發(fā)送者和事件接收者所在系統(tǒng)的地址。
本實施例的事件發(fā)送單元300采用一個事件發(fā)送代理類Supplier Proxy來實現(xiàn)。以C++為例，所述Supplier Proxy的一個具體示例如下class Supplier Proxy{public:
SupplierProxy(EventClientType clientType，//事件發(fā)送類型1)SINGLE_EVENT逐一發(fā)送，2)LIST_OF_EVENT批量發(fā)送，EventClientMode clientMode，//事件模式1)push 2)pullConnectionMode mode//通道類型指示將使用的事件通道的類型，1)USING_NOTIFY使用CORBANotification服務(wù)的事件通道，2)PUSH_DIRECTLY使用自定義的事件通道；virtual～EventSupplierProxy();
int doPushEvent(EventBase& event)；//此函數(shù)用于發(fā)送一個單個的事件int addEvent(EventBase& event)；//用于添加一個事件到緩存中，intflush()；//用于將當(dāng)前緩存中的所有事件發(fā)送出去}事件發(fā)送代理類SupplierProxy對外提供一個doPushEvent接口，此接口用于發(fā)送事件，對外屏蔽了內(nèi)部與Notification服務(wù)的之間的交互，包括事件通道查找，連接及發(fā)送。使用者只需要生成一個SupplierProxy類實例，調(diào)用其doPushEvent接口，傳入待發(fā)送的事件即可。
SupplierProxy內(nèi)部包含一個標(biāo)準(zhǔn)Notification ProxySupplier，即事件發(fā)送器，此事件發(fā)送器用于連接Notification的事件通道并發(fā)送事件。
在SupplierProxy的doPushEvent接口內(nèi)部，根據(jù)傳入的事件類型從事件服務(wù)器中獲取對應(yīng)的事件通道對象引用，然后取出用戶自定義事件中的StructuredEvent發(fā)送到對應(yīng)通道上。
請參閱圖9，下面詳述doPushEvent的處理過程。
步驟401，從待發(fā)送事件中取出事件類型字段的值；步驟402，取出通道類型；
步驟403，判斷所述通道類型是否為PUSH_DIRECTLY；如果不是，即所述通道類型是USING_NOTIFY，則執(zhí)行以下步驟步驟404，從事件服務(wù)器200獲取對應(yīng)待發(fā)送事件類型的事件通道對象引用；步驟405，根據(jù)事件發(fā)送類型和事件模式創(chuàng)建對應(yīng)CORBA Notification服務(wù)的事件發(fā)送器(Notification ProxySupplier)的對象；步驟406，將Notification ProxySupplier對象連接到事件通道上，步驟407，通過Notification ProxySupplier對象將事件發(fā)送出去；如果是，即所述通道類型是PUSH_DIRECTLY，則執(zhí)行下述步驟步驟408，從事件服務(wù)器中獲取對應(yīng)待發(fā)送事件類型的目標(biāo)系統(tǒng)(事件接收者)的地址信息；步驟409，將待發(fā)送消息組裝成目標(biāo)系統(tǒng)(事件接收者)要求的格式；步驟410，同目標(biāo)系統(tǒng)(事件接收者)建立連接；步驟411，通過所建立的連接將消息發(fā)送出去。
本實施例的事件接收單元5采用一個事件接收代理類Consumer Proxy來實現(xiàn)。以C++為例，Consumer Proxy的一個具體示例如下class ConsumerProxy{public:
ConsumerProxy(EventClientType clientType,//事件接收類型1)SINGLE_EVENT單事件接收2)LIST_OF_EVENT批事件接收EventClientMode clientMode,//事件模式1)push 2)pullConnectionMode mode,//通道類型指示將使用的通道類型，1)USING_NOTIFY使用Corba Notification服務(wù)的事件通道，2)PUSH_DIRECTLY使用自定義的事件通道)；virtual ConsumerProxy();
int subscribe(const char*EventType, //EventType對應(yīng)于配置文件中的EventTypestd::list<string>& EventNameList,//EventNameList是一個字符串序列，可以包含多個EventName
const char*constraint,//constraint是符合標(biāo)準(zhǔn)Notification過濾條件語法的過濾條件)；//subscribe函數(shù)用于訂閱事件virtual void pushEvent(EventBase event)=0;
};//pushEvent需要由上層應(yīng)用實現(xiàn)，用于處理接收到的事件事件接收代理類ConsumerProxy提供一個subscribe接口及一個pushEvent虛函數(shù)，使用者需要重載pushEvent函數(shù)，在此函數(shù)內(nèi)處理接收到的事件。
subscribe函數(shù)用于訂閱事件，其輸入?yún)?shù)中包括事件類型信息和事件過濾條件，事件類型信息包含定長消息頭中的各個字段信息，包括域名，事件類型及事件名稱。事件過濾條件的語法按照標(biāo)準(zhǔn)的CORBA Notifcation服務(wù)定義。
ConsumerProxy內(nèi)部包含一個標(biāo)準(zhǔn)的Notification ProxyConsumer即事件接收器，此事件接收器用于連接Notification的事件通道，在接收到事件后調(diào)用ConsumerProxy的pushEvent函數(shù)。
在subscribe函數(shù)內(nèi)部，首先根據(jù)輸入的事件類型信息從事件服務(wù)器中獲取對應(yīng)的事件通道對象引用，然后將內(nèi)部的Notification ProxyConsumer連接到事件通道并調(diào)用相應(yīng)接口設(shè)置過濾條件。
如圖10所示，事件訂閱的處理流程如下步驟501，根據(jù)待接收的事件類型從事件服務(wù)器200取出事件通道的引用；步驟502，取出通道類型；步驟503，判斷所述通道類型是否為是PUSH_DIRECTLY；如果不是，即通道類型是USING_NOTIFY，則執(zhí)行下述步驟步驟504，根據(jù)事件接收類型和事件模式創(chuàng)建對應(yīng)的CORBA的事件接收器(Notification ProxyConsumer)的對象；步驟505，將Notification ProxyConsumer的對象連接到事件通道上；步驟506，將待接收的事件的過濾條件設(shè)置到已連接的事件通道；如果是，即所述通道類型是PUSH_DIRECTLY，則執(zhí)行以下步驟步驟507，從事件服務(wù)器200取出目標(biāo)系統(tǒng)的地址；步驟508，與目標(biāo)系統(tǒng)(事件發(fā)送者)建立連接；
步驟509，根據(jù)目標(biāo)系統(tǒng)(事件發(fā)送者)要求發(fā)送事件訂閱請求；步驟510，判斷目標(biāo)系統(tǒng)(事件發(fā)送者)是否支持過濾；如果判斷結(jié)果為支持，則執(zhí)行步驟512，將過濾條件發(fā)送到目標(biāo)系統(tǒng)(事件發(fā)送者)上；如果判斷結(jié)果為不支持，則執(zhí)行步驟511)，將過濾條件保存。
如圖11所示，事件接收的處理流程如下步驟610，判斷事件來源；根據(jù)事件來源進(jìn)行相應(yīng)的后續(xù)過程；如果是從Notification通道到達(dá)，則執(zhí)行下述步驟步驟620，使用接收到的Notification StructuredEvent構(gòu)造一個內(nèi)部自定義事件格式EventBase；步驟630，調(diào)用上層應(yīng)用實現(xiàn)的PushEvent函數(shù)將自定義事件傳入；步驟640，在PushEvent函數(shù)內(nèi)部，使用自定義事件的存取函數(shù)獲取事件信息；如果是從PUSH_DIRECT通道到達(dá)，則執(zhí)行下述步驟步驟650，如果對端系統(tǒng)未執(zhí)行事件過濾，則在本地執(zhí)行過濾操作；步驟660，使用接收到的數(shù)據(jù)包構(gòu)造一個內(nèi)部自定義事件格式EventBase；隨后進(jìn)入步驟630。
請參閱圖12，是本發(fā)明的事件通訊方法的流程圖。
步驟110，繼承和形成事件類型；步驟120，創(chuàng)建事件通道并保存事件通道的引用；步驟130，事件發(fā)送者生成事件類型對象；步驟140，封裝待發(fā)送消息為通用事件結(jié)構(gòu)；事件發(fā)送單元根據(jù)事件類型獲得事件通道的引用；實現(xiàn)事件的發(fā)送；其中，還包括判斷通道類型，如果是Notification，則創(chuàng)建事件發(fā)送代理對象并連接到事件通道；如果是自定義通道類型，則根據(jù)事件類型獲取對端的地址并建立連接；步驟150，事件接收單元接收事件類型信息，根據(jù)事件類型信息獲得事件通道的引用；步驟160，實現(xiàn)事件的接收；根據(jù)接收到的事件生成事件類型對象；其中，還包括判斷通道類型，如果是Notification，則創(chuàng)建事件接收代理對象并連接到事件通道；如果是自定義通道類型，則根據(jù)接收到的數(shù)據(jù)包生成事件類型對象；步驟170，事件接收者從該事件類型對象獲取發(fā)送的消息內(nèi)容。
本實施例中，采用本發(fā)明的方法后，上層的使用步驟如下從EventBase繼承并定義自己的事件類型；事件發(fā)送者生成一個SupplierProxy對象，待發(fā)送消息創(chuàng)建一個所述事件結(jié)構(gòu)的實例并使用若干存取單元來填充消息載體單元中的各字段，然后調(diào)用SupplierProxy的doPushEvent發(fā)送消息；事件接收者生成一個ConsumerProxy對象，調(diào)用subscribe訂閱所關(guān)心的事件類型，有消息到達(dá)時，調(diào)用ConsumerProxy的PushEvent來處理接收到的消息。
而本實施例的事件通訊裝置的內(nèi)部處理過程可以描述如下事件服務(wù)器啟動時讀取配置文件信息，根據(jù)需要創(chuàng)建指定數(shù)量的事件通道，然后將所有事件通道引用保存在內(nèi)部緩存；事件發(fā)送者發(fā)送事件時，生成一個自定義的事件類型對象，填充各個字段值后，生成一個SupplierProxy對象，然后調(diào)用此對象的doPushEvent函數(shù)發(fā)送事件。
在doPushEvent函數(shù)內(nèi)部，從傳入的事件類型對象中取出事件類型信息，調(diào)用事件服務(wù)器的接口獲取事件通道對象引用，創(chuàng)建相應(yīng)數(shù)量(根據(jù)具體配置，一種事件類型可能在多個通道上發(fā)送)的Notification ProxySupplier對象并連接到這些事件通道上，然后從傳入的事件類型對象中取出標(biāo)準(zhǔn)StructuredEvent結(jié)構(gòu)并通過ProxySupplier的接口發(fā)送事件；事件接收者則是生成一個ConsumerProxy對象，調(diào)用其subscribe接口訂閱事件，在subscribe函數(shù)內(nèi)部，根據(jù)傳入的事件類型列表，調(diào)用事件服務(wù)器的接口獲取和這些事件類型相關(guān)的所有事件通道對象引用，然后創(chuàng)建相應(yīng)數(shù)量的Notification ProxyConsumer對象并連接到這些事件通道上，同時設(shè)置過濾條件。當(dāng)某個事件通道上有事件到達(dá)時，ConsumerProxy內(nèi)部接收這些事件并構(gòu)造一個EventBase對象，將接收到的事件結(jié)構(gòu)體放入此對象中并調(diào)用用戶重載的pushEvent函數(shù)，在此函數(shù)內(nèi)部由用戶程序代碼對事件進(jìn)行處理。
此外，本發(fā)明適用于Notification服務(wù)的push和pull模式(pull模式下由事件通道主動調(diào)用事件發(fā)送者的接口以獲取需要發(fā)送的事件，事件接收者則是主動調(diào)用事件通道的接口獲取事件；push模式下，事件發(fā)送者主動調(diào)用事件通道的接口將需要發(fā)送的事件傳入，由事件通道主動調(diào)用事件接收者的接口將事件發(fā)送給事件接收者)，同時適用于Notification的單事件發(fā)送方式和批事件發(fā)送方式(單事件發(fā)送方式一次只發(fā)送一個事件，批事件發(fā)送方式一次發(fā)送一個事件序列，其中可能包含一個或多個事件)。
綜上所述，本發(fā)明對Notification使用的通用事件格式進(jìn)行封裝，同時對上層模塊封裝了Notification服務(wù)事件通道的創(chuàng)建、對象引用獲取、通道連接等操作，降低使用的復(fù)雜度，同時提高系統(tǒng)的可移植性和兼容性，提供靈活的系統(tǒng)集成功能。
本發(fā)明的一個實施例中，對Notification服務(wù)的封裝方式包括將通用的StructuredEvent封裝成具體編程語言的對象類，同時提供事件發(fā)送及接收的代理類，簡化了Notification服務(wù)使用的復(fù)雜度，提高了使用的靈活度。本文中的例子以C++為主，但本發(fā)明所提供的封裝模式同時適用于C++及Java。
本實施例是基于CORBA的Notification模式，但可以將此封裝模式應(yīng)用于非CORBA系統(tǒng)，用于構(gòu)造普通系統(tǒng)的事件通訊機(jī)制。
總之，通過本發(fā)明，對事件服務(wù)系統(tǒng)底層使用的Notification服務(wù)進(jìn)行了良好的封裝，不僅降低了上層模塊使用Notification服務(wù)的復(fù)雜度，而且可以降低系統(tǒng)在不同廠商的CORBA實現(xiàn)中移植的難度，更方便地實現(xiàn)跨CORBA實現(xiàn)的特性。
同時，由于對上層應(yīng)用屏蔽了底層的實現(xiàn)細(xì)節(jié)，因此事件服務(wù)系統(tǒng)可以在不影響上層應(yīng)用的情況下改變事件發(fā)送模式因為經(jīng)過封裝后，上層應(yīng)用程序?qū)嶋H上不了解事件是通過單事件模式發(fā)送還是通過批事件模式發(fā)送，使用Push模式還是Pull模式，使用單獨事件通道還是和其他事件共用一個事件通道。因此可以在事件服務(wù)系統(tǒng)底層進(jìn)行修改(使用配置文件的方式修改)以滿足不同的應(yīng)用場景，而上層應(yīng)用可以不作任何修改，如可以根據(jù)實際應(yīng)用的情況，將事件流量小的兩個通道合并，將原來在這兩個通道里面發(fā)送的所有事件類型合并在一個通道中發(fā)送，同樣，可以將事件流量大的通道劃分成兩個或多個，將原來在同一個通道里面發(fā)送的事件類型分布到不同的事件通道中去。
而且，在必要時可以不使用Notification服務(wù)進(jìn)行事件發(fā)送而改用其他的事件發(fā)送方式如直接使用TCP連接傳送。因為上層服務(wù)的事件接收和事件發(fā)送實際上都沒有直接涉及Notification服務(wù)的接口調(diào)用，使用的都是內(nèi)部事件服務(wù)所提供的接口，也就是說上層應(yīng)用并不清楚事件是通過什么方式發(fā)送接收的。這樣，假設(shè)用戶系統(tǒng)需要跟外部非CORBA系統(tǒng)進(jìn)行事件通訊，則可以在內(nèi)部事件服務(wù)底層進(jìn)行修改，在SupplierProxy的dopushEvent內(nèi)部，將用戶提交發(fā)送的事件內(nèi)容取出，組裝成對端系統(tǒng)要求的事件格式，同對端系統(tǒng)建立TCP連接，然后通過TCP連接將事件發(fā)給對方；同樣，也可以通過TCP連接接收外部系統(tǒng)發(fā)過來的事件，重新組裝成內(nèi)部事件格式，然后調(diào)用ConsumerProxy的pushEvent接口將事件傳給上層應(yīng)用。這樣可以提供靈活的系統(tǒng)集成功能而不需要上層應(yīng)該做太多改動。
以上所述僅是本發(fā)明的優(yōu)選實施方式，應(yīng)當(dāng)指出，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進(jìn)和潤飾，這些改進(jìn)和潤飾也應(yīng)視為本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種事件通訊裝置，其特征在于，包括事件類型對象單元，用于生成事件類型對象和解析事件類型對象，所述事件類型對象包括消息載體和消息頭存取部分，其中消息載體用于以通用事件結(jié)構(gòu)存放待發(fā)送的消息，所述消息頭存取部分用于根據(jù)事件類型填充通用事件結(jié)構(gòu)的消息頭或者從消息頭中提取信息；事件服務(wù)器，用于根據(jù)通道分配信息創(chuàng)建事件通道并保存所有事件通道引用，所述通道分配信息包括事件通道和事件類型的對應(yīng)關(guān)系；事件發(fā)送單元，用于發(fā)送事件，包括從上層的事件發(fā)送者獲取事件類型對象，根據(jù)事件類型信息從該事件服務(wù)器獲得事件通道的引用，創(chuàng)建事件發(fā)送代理對象并連接到所述事件通道，將封裝的消息發(fā)送出去；事件接收單元，用于接收事件，包括根據(jù)傳入的事件類型信息從該事件服務(wù)器獲得事件通道的引用，創(chuàng)建事件接收代理對象并連接到事件通道上，實現(xiàn)消息的接收，根據(jù)其中的事件結(jié)構(gòu)體生成事件類型對象并傳送給上層的事件接收者。
2.根據(jù)權(quán)利要求1所述的事件通訊裝置，其特征在于，所述事件發(fā)送單元包括事件發(fā)送類型選擇單元，用于選擇發(fā)送類型是逐一發(fā)送還是批量發(fā)送；事件模式選擇單元，用于選擇模式是push模式還是pull模式；單事件發(fā)送器，用于實現(xiàn)單一事件的發(fā)送；批事件發(fā)送器，用于實現(xiàn)批量事件的發(fā)送。
3.根據(jù)權(quán)利要求2所述的事件通訊裝置，其特征在于，所述事件發(fā)送單元還包括事件通道類型選擇單元，用于選擇是CORBA Notification通道類型，還是自定義通道類型。
4.根據(jù)權(quán)利要求2所述的事件通訊裝置，其特征在于，所述單事件發(fā)送器包括事件類型對象接口，用于接收事件類型對象；事件通道獲取單元，用于根據(jù)事件類型信息從該事件服務(wù)器獲得事件通道的引用；事件發(fā)送代理創(chuàng)建單元，用于創(chuàng)建CORBA Notification事件發(fā)送代理對象。
5.根據(jù)權(quán)利要求1所述的事件通訊裝置，其特征在于，所述事件接收單元包括事件接收類型選擇單元，用于選擇接收類型是逐一接收還是批量接收；事件模式判斷單元，用于判斷模式是push模式還是pull模式；事件訂閱單元，用于從上層的事件接收者接收事件訂閱信息，并根據(jù)事件訂閱信息實現(xiàn)事件的接收；事件傳輸單元，用于根據(jù)接收的事件生成事件類型對象并提供給上層進(jìn)行處理。
6.根據(jù)權(quán)利要求5所述的事件通訊裝置，其特征在于，所述事件接收單元還包括事件通道類型判斷單元，用于確定是CORBA Notification通道類型，還是自定義通道類型。
7.根據(jù)權(quán)利要求5所述的事件通訊裝置，其特征在于，所述事件訂閱單元包括訂閱信息接收單元，用于接收事件訂閱信息，包括事件類型信息和事件過濾條件；事件通道獲取單元，用于根據(jù)事件類型信息從該事件服務(wù)器獲得事件通道的引用；事件接收代理創(chuàng)建單元，用于創(chuàng)建CORBA Notification事件接收代理對象。
8.一種事件通訊方法，其特征在于，包括步驟1)根據(jù)通道分配信息創(chuàng)建事件通道并保存所有事件通道引用，所述通道分配信息包括事件通道和事件類型的對應(yīng)關(guān)系；2)事件發(fā)送者生成事件類型對象；所述事件類型對象包括消息載體和消息頭存取部分，其中消息載體用于以通用事件結(jié)構(gòu)存放待發(fā)送的消息，所述消息頭存取部分，用于根據(jù)事件類型填充通用事件結(jié)構(gòu)的消息頭或者從消息頭中提取信息；3)封裝待發(fā)送消息為通用事件結(jié)構(gòu)；事件發(fā)送單元根據(jù)事件類型獲得事件通道的引用，創(chuàng)建事件發(fā)送代理對象并連接到事件通道，實現(xiàn)事件的發(fā)送；4)事件接收單元接收事件類型信息，根據(jù)事件類型信息獲得事件通道的引用；創(chuàng)建事件接收代理對象并連接到事件通道，實現(xiàn)事件的接收；根據(jù)接收到的事件生成事件類型對象；5)事件接收者從該事件類型對象獲取發(fā)送的消息內(nèi)容。
9.根據(jù)權(quán)利要求8所述的事件通訊方法，其特征在于，所述步驟3)還包括當(dāng)通道類型是自定義通道時，根據(jù)事件類型獲取對端的地址；將待發(fā)送的消息按照事件接收者的格式打包；與對端建立連接；基于該連接實現(xiàn)事件的發(fā)送；所述步驟4)還包括當(dāng)通道是自定義通道時，根據(jù)接收到的數(shù)據(jù)包生成事件類型對象。
10.根據(jù)權(quán)利要求8或9所述的事件通訊方法，其特征在于，所述步驟2)所述的通用事件結(jié)構(gòu)是指CORBA Notification服務(wù)使用的StructuredEvent結(jié)構(gòu)。
11.根據(jù)權(quán)利要求8或9所述的事件通訊方法，其特征在于，所述事件類型對象還包括消息體存取部分，用于根據(jù)事件類型填充通用事件結(jié)構(gòu)的消息體或者從消息體中提取信息；所述步驟3)的封裝具體是通過消息頭存取部分和/或消息體存取部分實現(xiàn)的；所述步驟5)的獲取具體是通過消息頭存取部分和/或消息體存取部分實現(xiàn)的。
全文摘要
本發(fā)明公開一種事件通訊裝置，包括事件類型對象單元，用于生成事件類型對象和解析事件類型對象；事件服務(wù)器，用于根據(jù)通道分配信息創(chuàng)建事件通道并保存所有事件通道引用，所述通道分配信息包括事件通道和事件類型的對應(yīng)關(guān)系；事件發(fā)送單元，用于從上層的事件發(fā)送者獲取事件類型對象，根據(jù)事件類型信息從該事件服務(wù)器獲得事件通道的引用，創(chuàng)建事件發(fā)送代理對象并連接到所述事件通道，將封裝的消息發(fā)送出去；事件接收單元，用于根據(jù)傳入的事件類型信息從該事件服務(wù)器獲得事件通道的引用，創(chuàng)建事件接收代理對象并連接到事件通道上，實現(xiàn)消息的接收，根據(jù)其中的事件結(jié)構(gòu)體生成事件類型對象并傳送給上層的事件接收者。本發(fā)明還公開一種事件通訊方法。
文檔編號H04L12/24GK1870525SQ20051012592
公開日2006年11月29日 申請日期2005年11月25日 優(yōu)先權(quán)日2005年11月25日
發(fā)明者阮偉毅 申請人:華為技術(shù)有限公司