摘要：CORBA的通知服務(wù)相對于傳統(tǒng)的事件服務(wù)，增加了一系列新的特性，對海量教育資源信息的訂閱發(fā)布提供了更大的靈活性和通用性。文章根據(jù)通知服務(wù)原理，構(gòu)建了一個資源訂閱系統(tǒng)模型，用戶可以訂閱感興趣的信息，事件通知服務(wù)負(fù)責(zé)發(fā)布事件，同時將事件分發(fā)給感興趣的訂閱者。模型采用事件過濾機制、分組共享、隊列優(yōu)先級設(shè)計，提高了事件通知的可靠性。

關(guān)鍵詞：事件通知服務(wù)；發(fā)布／訂閱；事件過濾；事件通道

0 引言

分布式應(yīng)用借助中間件實現(xiàn)了資源共享、功能共享的目的。CORBA(The Common Object Request Broker，公共對象請求代理)技術(shù)通過ORB(Object Request Broker，對象請求代理)把分布的對象連成一個邏輯上統(tǒng)一的整體，對分布式數(shù)據(jù)提供統(tǒng)一的訪問機制。網(wǎng)絡(luò)教育資源是運行在互聯(lián)網(wǎng)上的數(shù)字資源庫，隨著資源庫信息內(nèi)容的不斷擴(kuò)大，在這個海量信息庫中搜索、瀏覽、跟蹤、訂閱信息變得越來越困難。因此，可為用戶訂閱感興趣的信息，當(dāng)有新信息時，能主動通知對這些信息感興趣的用戶的系統(tǒng)，能為用戶提供更好的服務(wù)，加速海量信息的利用。這種系統(tǒng)設(shè)計的關(guān)鍵技術(shù)是事件通知服務(wù)。

1 事件通知服務(wù)結(jié)構(gòu)及功能

事件服務(wù)體現(xiàn)在CORBA服務(wù)器端的ORB中，它為客戶端程序和服務(wù)端實現(xiàn)的對象提供事件通道、事件代理，并實現(xiàn)客戶端程序和服務(wù)端對象之間的事件數(shù)據(jù)的推拉。事件通道可以支持多個消費者和多個供應(yīng)者，支持多對多通信。其中消費方可以請求一個事件，也可以只是接收一個關(guān)于事件的通知。供應(yīng)方可以通過發(fā)布一個單獨的標(biāo)準(zhǔn)的請求與消費方快速地建立聯(lián)系來進(jìn)行事件通信。產(chǎn)生事件的供應(yīng)方不必知道消費方的身份，同樣接收事件的消費者也不需要知道供應(yīng)者的身份。事件本身不是一個對象。但事件通道是一個對象，通過事件通道可以讓多個供應(yīng)者和多個消費者進(jìn)行異步的通信，事件通道本身既充當(dāng)一個事件的消費者也充當(dāng)該事件的供應(yīng)者。事件通道是標(biāo)準(zhǔn)的CORBA對象，通過使用標(biāo)準(zhǔn)的CORBA請求來完成通信。事件服務(wù)可以用于提供一個“變化通知”，當(dāng)某個對象發(fā)生改變時(例如它的狀態(tài)被修改)，將產(chǎn)生一個事件并被廣播到對該事件感興趣的一方。在這里，發(fā)生了改變的對象扮演了供應(yīng)方，接收到通知的一方扮演了消費方，而事件通道對象則充當(dāng)了消費方和供應(yīng)方的中介。通知服務(wù)的結(jié)構(gòu)模型如圖1所示。

圖1 通知服務(wù)結(jié)構(gòu)模型

OMG的事件服務(wù)支持二種類型的事件通信：unTyped和Typed類型。對unTyped事件類型通信，它將所有事件轉(zhuǎn)換成anys格式。但許多應(yīng)用程序需要更強壯的自定義類型事件信息，為適應(yīng)這種需求，OMG的事件服務(wù)定義了接口和便于支持typed的事件通道。但這種typed難以理解和實現(xiàn)，因為這個原因，CORBA通知服務(wù)引進(jìn)了一個新的事件信息structuredEvent。在通知服務(wù)中結(jié)構(gòu)體事件能被直接傳輸，不需要打包成Any類型。

通知服務(wù)支持三種事件類型：Any、Structured Event、TypedEvent，這三種事件類型可在通道中轉(zhuǎn)換。它比OMG的事件服務(wù)提供了更廣范圍的應(yīng)用，且在性能、Qos(Quality of Service：服務(wù)質(zhì)量)方面更勝一籌。

CORBA的事件通知服務(wù)規(guī)范擴(kuò)展了OMG的事件服務(wù)，添加了如下的新特性：

(1)可以以明確定義數(shù)據(jù)結(jié)構(gòu)的形式傳輸事件，增加了Anys類型和自定義事件類型的事件服務(wù)。

(2)通過對通道中的每一個代理添加過濾器，客戶端可以明確指定要接收的事件類型。

(3)供應(yīng)者能發(fā)現(xiàn)通道中客戶需求事件，按需提供事件，避免傳送客戶不需要的事件。

(4)可以對每個通道、每個代理、每個事件配置不同質(zhì)量的服務(wù)。

(5)終端用戶可使用現(xiàn)存的方便的過濾器構(gòu)造流經(jīng)通道的事件結(jié)構(gòu)。

通知服務(wù)支持明確定義的工廠接口。事件通道工廠用于創(chuàng)建通知通道新的實例，創(chuàng)建時客戶端可指定通道支持的各種Qos和管理屬性。通道中設(shè)置的標(biāo)準(zhǔn)的管理屬性主要包括：通道中最大事件數(shù)、最大隊列長度、最大數(shù)量的消費者和供應(yīng)者。

事件通道工廠是通知服務(wù)中的一個被明確定義成工廠的接口，它產(chǎn)生出自然被繼承的服務(wù)體系，例如事件通道工廠創(chuàng)建事件通道對象。事件通道對象本質(zhì)上也是一個工廠，能創(chuàng)建管理者，而代理對象則由管理者創(chuàng)建。對象的識別標(biāo)志由所創(chuàng)建對象的對象分配，是惟一的。通道中所有對象能得到子對象的引用外，還可對父親對象反向引用。這種設(shè)計原則大大提高了通知服務(wù)事件通道的管理能力，使任何一個通道的客戶端都能發(fā)現(xiàn)所有兼容通道中的對象，并啟動通道內(nèi)的任一對象。

每一個管理接口實質(zhì)上也是一個工廠，能創(chuàng)建代理接口。管理對象有自己的Qos和過濾器對象，每一個代理對象繼承了創(chuàng)建自己的管理對象的Qos特性，與管理對象關(guān)聯(lián)的過濾器對象的設(shè)置也自動地與該管理對象所創(chuàng)建的所有代理關(guān)聯(lián)，每一個管理對象所創(chuàng)建的所有代理對象間共享一個過濾器對象的設(shè)置。這種共享過濾器的設(shè)置為一組客戶進(jìn)行事件共享、事件訂閱提供了強大的機制，使得根據(jù)訂閱信息對代理對象進(jìn)行分組成為可能。這個特點對ConsumerAdmin對象特別有用，因為它能對一組接收同樣事件設(shè)置有興趣的客戶進(jìn)行優(yōu)化服務(wù)。

通知服務(wù)類型的代理對象能將信息區(qū)分成Any事件、結(jié)構(gòu)體事件、結(jié)構(gòu)體事件序列三種事件格式進(jìn)行收發(fā)。

通知服務(wù)類型的代理對象有兩種不同類型的過濾器：運送過濾器(Forwording Filters)、映射過濾器(Mapping Filters)。運送過濾器可加到所有類型的代理對象中，并包含代理要運送的事件；映射過濾器只附加到供應(yīng)商代理對象，并只對供應(yīng)商代理接收的事件的優(yōu)先級或生命周期屬性有效。這兩種類型的過濾器可顯式或隱式分配到代理對象中。

在不改變通知服務(wù)的接口下，可添加新的Qos和管理屬性，新添加部分看作是接口的擴(kuò)展而不是修改。

2 基于通知服務(wù)的資源訂閱系統(tǒng)設(shè)計

在網(wǎng)絡(luò)教育資源系統(tǒng)設(shè)計中，考慮到有海量的信息資源的共享，所面向的用戶也是有相當(dāng)規(guī)模的，因此事件通知的服務(wù)設(shè)計成多個事件代理組成的分布式系統(tǒng)。每一個供應(yīng)者代理對應(yīng)一個過濾器，事件服務(wù)可有多個消費者和多個供應(yīng)者。事件通知服務(wù)模型如圖2所示。

圖2 事件通知服務(wù)模式

在分布式環(huán)境下，CORBA的通知服務(wù)支持事件共享、事件訂閱功能。在網(wǎng)絡(luò)教育資源管理系統(tǒng)中，信息內(nèi)容可按主題、內(nèi)容、作者等進(jìn)行分類，用戶可根據(jù)主題或內(nèi)容等分類方式訂閱需求信息，系統(tǒng)還可對訂閱同一信息的用戶進(jìn)行分組管理。圖3為按主題內(nèi)容的發(fā)布訂閱模型。

圖3 事件的訂閱與發(fā)布

圖3表示事件的發(fā)布與接收情況。e1、e2是發(fā)布者發(fā)布的事件，訂閱者l訂閱信息s1，訂閱者2訂閱信息s2，事務(wù)通知服務(wù)分別將訂閱信息和發(fā)布事件匹配，最后將el發(fā)送給訂閱者1，將e1、e2發(fā)送給訂閱者2。

2．1分組訂閱機制

在圖2所示的系統(tǒng)中，建立了一個分組管理機制，在通道與客戶間共享訂閱，對不同的訂閱信息分配不同的事件優(yōu)先權(quán)，對一定范圍的優(yōu)先權(quán)事件進(jìn)行分組管理，同一組的訂閱消費者分享同一個線程，同一個過濾器，以節(jié)省系統(tǒng)資源。

事件供應(yīng)者提供事件類型，消費者可以根據(jù)提供的事件類型信息(咨詢事件類型庫)查找事件包含的屬性名和類型，然后填寫訂閱單。消費者也可使用obtain-offered-types操作(在供應(yīng)者代理接口)查找當(dāng)前通道中提供的事件類型的設(shè)置。事件通道集合消費者所需的事件類型，調(diào)用Subscription-change變更訂閱。供應(yīng)者也可在ProxyConsumer接口調(diào)用obtain-subscription-types獲得通道中消費者所需的事件類型。

NotifySubscribe提供訂閱變更操作接口，它支持所有供應(yīng)者代理接口和ConsumerAdmin接口，也支持事件的供應(yīng)者。

2．2事件過濾機制

在通知服務(wù)事件通道內(nèi)的每一個管理和代理對象都可與一個或更多個過濾器對象關(guān)聯(lián)。這些過濾器對象可根據(jù)不同的Qos需求被重定義在通知服務(wù)事件通道的同一服務(wù)器進(jìn)程，或重新駐留在他們自己的地址空間里。

在通知服務(wù)中過濾器對象用管理接口，管理一個或多個代理對象。每一個代理實質(zhì)上有兩種過濾器：一是與管理對象關(guān)聯(lián)的過濾器，另一是直接與自己關(guān)聯(lián)的過濾器。創(chuàng)建管理對象時，決定由它所創(chuàng)建的代理對象是否應(yīng)用兩套過濾器。如果一個代理既不與管理對象關(guān)聯(lián)，也不與它自己的過濾器管理接口關(guān)聯(lián)，則它將傳送所有接收到的事件。

代理對象每接收一個事件，過濾器被激發(fā)并執(zhí)行過濾操作。每接收一個事件時，通道內(nèi)的代理對象會激發(fā)一個最接近的匹配操作，被過濾的事件目錄作為輸入。激發(fā)的匹配操作如下：

boolean match(in any filterable_data)；

boolean match_sturcturedfin CosNotification：：Structured

Event filterable_data)；

boolean match_typed(in CosNotification：：PropertySeq

fiIterable_data)：

以上操作的結(jié)果是一個布爾值，當(dāng)過濾對象封裝了一個或多個合適的結(jié)果時返回true，否則返回1。如果代理有多個過濾器對象關(guān)聯(lián)，則它將激發(fā)每一個關(guān)聯(lián)的過濾器對象，直到有一個返回true，或所有都為1。當(dāng)所有匹配結(jié)果都為1時，代理將放棄事件。否則事件將提取給代理(當(dāng)過濾器被消費者代理執(zhí)行時，事件提取給供應(yīng)者代理，當(dāng)過濾器被供應(yīng)者代理執(zhí)行時，事件被提取給消費者)。如果代理還有其它事件等待傳送，當(dāng)前事件被放入隊列，等待傳送，否則事件被馬上傳送。

2．3事件的優(yōu)先級設(shè)置

每一事件有兩個特殊屬性：優(yōu)先級和生命周期。為了使消費者能有效獲得事件的優(yōu)先權(quán)和生命周期屬性，通知服務(wù)方引進(jìn)了過濾器對象的映射概念。每一個過濾器對象能封裝一個或更多個對，并有一個默認(rèn)值關(guān)聯(lián)。根據(jù)映射過濾器中的優(yōu)先屬性，供應(yīng)者代理激發(fā)映射過濾器的最接近的匹配操作。每一個供應(yīng)者代理可與一個映射過濾器關(guān)聯(lián)，能影響它所接收事件的優(yōu)先權(quán)屬性。每一個映射過濾器能封裝一個或多個constraint-value對，并有一個默認(rèn)值與它關(guān)聯(lián)。當(dāng)有優(yōu)先級關(guān)聯(lián)時，供應(yīng)者代理將遵循下列規(guī)則：當(dāng)有優(yōu)先屬性關(guān)聯(lián)時，使用這個值，否則查看是否有通過代理對象繼承的相關(guān)的優(yōu)先屬性可用，如果都沒有可用的優(yōu)先值，則輸出參數(shù)返回匹配的操作。映射過濾器接口定義如下：

interface Mapping Filter{

readonly attribute string constraint_grammar；

readonly attribute CORBA：：TypeCode Value_type；

readonly attribute any default_Value；…}；

優(yōu)先變量priority為屬于short類型，默認(rèn)的優(yōu)先值為0。事件分發(fā)的模式，設(shè)置為PriorityOrder時，則通道按優(yōu)先權(quán)值序列傳送信息給消費者。

2．4隊列優(yōu)先級

事件的分發(fā)有四種模式：按事件接收次序先接收的先分發(fā)，按事件接收次序先接收的后分發(fā)，按事件優(yōu)先級次序分發(fā)，實時分發(fā)。按事件優(yōu)先級次序進(jìn)行分發(fā)的情況下，若有新事件到來，則依次和隊列中的每個事件的優(yōu)先級進(jìn)行比較來決定插入位置。這樣新生成的隊列仍然嚴(yán)格按優(yōu)先級高低排序。

為確保不同的優(yōu)先級事件進(jìn)入不同的隊列，并保證優(yōu)先級高的事件首先被發(fā)送，可對每個供應(yīng)者代理建立和最大優(yōu)先級數(shù)目相同的隊列。

const sting MaxQueueLength=“MaxQueueLength”：

當(dāng)供應(yīng)者發(fā)出信息傳輸請求時，服務(wù)器將派生一個線程將事件送入事件通道，由該通道創(chuàng)建消費者管理對象，再由消費者管理對象創(chuàng)建供應(yīng)者代理，將事件存放進(jìn)供應(yīng)者事件隊列中。另一個等待的線程負(fù)責(zé)從事件隊列中取出事件，將其分發(fā)給不同的訂閱消費者。在此過程中，流經(jīng)管理對象和代理對象的事件傳送請求都將得到優(yōu)先響應(yīng)。

3 結(jié)束語

事件通知服務(wù)在分布式系統(tǒng)應(yīng)用中有很大的優(yōu)勢。在教育資源的訂閱中，根據(jù)用戶訂閱信息進(jìn)行點對點的消息發(fā)送，減少了網(wǎng)絡(luò)流量，為訂閱系統(tǒng)提供了更高的靈活性和可靠性。本文利用事件過濾機制和分組共享機制對事件通道進(jìn)行優(yōu)化，提高了事件服務(wù)的可靠性。

注：本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文。