基于CORBA事件服務(wù)的異步通信

鞏方浩，祈明龍

（武漢理工大學(xué) 計算機(jī)學(xué)院，湖北 武漢 430070）

公用對象請求代理體系結(jié)構(gòu)CORBA（Common Object Request Broker Architecture）[1]是對象管理組織 OMG（Object Management Group）提出的對象中間件的標(biāo)準(zhǔn)與開發(fā)規(guī)范。隨著CORBA技術(shù)的不斷完善，CORBA在分布式環(huán)境中的應(yīng)用越來越廣泛。CORBA技術(shù)使得應(yīng)用程序?qū)h(yuǎn)端對象的調(diào)用透明化，在編碼時，開發(fā)人員可以無需考慮系統(tǒng)軟硬件平臺、網(wǎng)絡(luò)協(xié)議直接進(jìn)行開發(fā)，使得開發(fā)工作不必糾纏于底層網(wǎng)絡(luò)編程的細(xì)節(jié)，降低了開發(fā)難度?，F(xiàn)有CORBA通信模式主要有同步、One-way、延遲同步等。但它們都未實(shí)現(xiàn)或未完全實(shí)現(xiàn)消息通信的異步。

針對現(xiàn)有通信模式的時間、空間、流程高耦合的缺點(diǎn)，對象管理組織（OMG）已對此制定出新的CORBA異步通信機(jī)制規(guī)范。利用異步通信機(jī)制，客戶端和服務(wù)端可以實(shí)現(xiàn)真正的異步通信，了解CORBA核心技術(shù)ORB的處理過程。這里提出一種基于CORBA事件服務(wù)的異步通信方案，該方案是在CORBA事件服務(wù)的基礎(chǔ)上實(shí)現(xiàn)信息的異步傳輸，并進(jìn)行一定程度的優(yōu)化。

1 事件服務(wù)

CORBA事件服務(wù)通過對事件（由對象產(chǎn)生并傳送給其他對象）封裝而提供了基本的消息傳遞功能。在事件被產(chǎn)生之后，CORBA事件服務(wù)是將事件從事件提供者對象傳送給事件消費(fèi)者對象的一種機(jī)制[2]。事件服務(wù)允許對象動態(tài)地注冊或注銷他們感興趣的特定事件，事件服務(wù)在相互不很了解的對象之間建立起一條寬松耦合的事件通道,它是連接消費(fèi)者和提供者之間的橋梁（事件服務(wù)中,客戶端被稱為服務(wù)消費(fèi)者Consumer；而服務(wù)端被稱為服務(wù)提供者Supplier），它實(shí)際是一個CORBA對象,允許多個消費(fèi)者和多個提供者與其相連接,既可以代理消費(fèi)者,又可以代理提供者,使得消費(fèi)者和提供者可以異步通信。

1.1 事件通道

對象之間事件的傳送是借助一個稱為“事件通道”（Event channel）的對象來進(jìn)行的。事件通道是一個既是事件提供者又是事件消費(fèi)者的插入對象，它允許多個事件提供者和多個事件消費(fèi)者異步地通信而無需相互了解。提供者和消費(fèi)者不是直接交互作用，而是從事件通道那里獲得一個代理對象，讓代理對象在將來的事件交換中代表自己[3]。事件通道負(fù)責(zé)將事件從“提供者”對象傳送給“消費(fèi)者”對象。因此，事件的傳遞經(jīng)歷了2個階段，即從提供者到事件通道的階段以及從事件通道到消費(fèi)者的階段，如圖1所示。

圖1 事件通道

1.2 事件服務(wù)模型

事件服務(wù)有Push、Pull、Push/Pull、Pull/Push等4種基本模型。

1）Push模型 在Push模型中，提供者通過 PushConsumer接口調(diào)用Push操作將事件數(shù)據(jù)推給事件通道，然后事件通道以同樣的方式將事件數(shù)據(jù)推給消費(fèi)者。圖2展示了一個消費(fèi)者和一個提供者通過事件通道通信的Push模型。

圖 2 Push模型

2）Pull模型 在Pull模型中，消費(fèi)者向提供者請求事件數(shù)據(jù)，事件通道在這里充當(dāng)請求代理,由它先接受來自消費(fèi)者的請求，再將其轉(zhuǎn)告給提供者。一個消費(fèi)者和一個提供者通過事件通道進(jìn)行通信的Pull模型類似圖2，不同之處是將Push命令變?yōu)镻ull操作[4]。

3）Push/Pull模型 該模型是提供者將事件數(shù)據(jù)推給事件通道，事件通道將數(shù)據(jù)排成隊列，等待消費(fèi)者發(fā)出pull命令提取數(shù)據(jù)。

4）Pull/Push模型 該模型是指由事件通道充當(dāng)代理對象，由它向提供者請求服務(wù)并將服務(wù)推向相關(guān)的提供者。

除了以上基本模型外，還可以將它們混合使用。消費(fèi)者和提供者通過事件通道進(jìn)行通信的混合模型如圖3所示[5]。

圖3 混合模型

一個事件通道里的消費(fèi)者和提供者可以根據(jù)實(shí)際需求選擇是Push方式還是Pull方式,進(jìn)而組成各種各樣的通信模型。事件通道提供接口設(shè)置這些通信方式。以消費(fèi)者為例，它首先要獲得一個事件通道對象，然后獲得該事件通道的消費(fèi)者管理接口ConsumerAdmin，接著取得代理對象。由于消費(fèi)者和提供者之間通信必須通過代理來完成，所以消費(fèi)者獲得一個提供者代理,提供者獲得一個消費(fèi)者代理,代理之間完成信息交換。當(dāng)Consumer為主動方（PullConsumer）時，Consumer就會主動的“拉”事件，這時它就會向ConsumerAdmin申請獲得對象ProxyPullSupplier，然后調(diào)用該對象的pull方法；反之，當(dāng)Consumer為被動方(PushConsumer)時，它被動接收事件數(shù)據(jù)，這時它會申請獲得對象ProxyPushSupplier，調(diào)用給對象的Push方法。對于Suppliers也有類似的過程，只不過當(dāng) Supplier為主動提供者（PushSupplier）時，它會獲得對象ProxyPushConsumer；當(dāng)為被動方時，它會獲得對象ProxyPull-Consumer。

當(dāng)提供者（Supplier）主動向消費(fèi)者傳遞數(shù)據(jù)時，提供者會從SupplierAdmin處獲得調(diào)用ProxyPushConsumer對象的push方法，將事件數(shù)據(jù)推向事件通道。然后事件通道查詢ConsumerAdmin上的所有代理對象，調(diào)用ProxyPushSupplier對象的Push方法，將事件數(shù)據(jù)從事件通道推給消費(fèi)者。而對于ProxyPullSupplier的所有事件則保存在隊列中，直到調(diào)用pull方法才能將它們從隊列中拉走。

1.3 CosEventChannelAdmin模塊

CORBA規(guī)范中定義一個CosEventChannelAdmin模塊[6]，用來定義提供者和消費(fèi)者之間通信所用到的各種接口和異常，包括 2個異常（AlreadyConnected和 TypeError）和 7個接口（ProxyPushConsumer,ProxyPullSupplier,ProxyPullConsumer,ProxyPushSupplier,ConsumerAdmin,SupplierAdmin,EventChannel）。

CosEventChannelAdmin模塊的定義如下：

2 CORBA異步通信機(jī)制的不足

以上簡單說明了事件服務(wù)的幾種模型。而傳統(tǒng)上，基于CORBA標(biāo)準(zhǔn)的分布對象計算模型的應(yīng)用主要在3種調(diào)用模型中選擇：One-way操作、同步操作和采用動態(tài)調(diào)用接口（DII）的延遲同步操作。這3種模式基本能夠滿足一般C/S應(yīng)用的需要，但卻很難滿足現(xiàn)代的應(yīng)用需求。在這些環(huán)境下，開發(fā)人員需要一種能夠提供完善的異步特性的釣魚模型，而這種異步特性是傳統(tǒng)調(diào)用模型無法提供的。為了解決異步性缺乏的問題，這里對3種模型進(jìn)行相應(yīng)的改進(jìn)。例如對于同步操作，可以對每個同步操作的請求響應(yīng)對都啟用一個不同的線程，但這種方法會隨著線程的增加而消耗大量的系統(tǒng)資源，從而影響系統(tǒng)的可伸縮性。另外有些軟件是按照單線程的模式設(shè)計的，如果把它們繼承到多線程環(huán)境下，必須考慮線程的安全問題等。而采用動態(tài)調(diào)用接口的延遲同步模型可以放松同步的約束，延遲同步客戶在多個不同的時間點(diǎn)查詢應(yīng)答是否返回，它本質(zhì)上沒有解決同步的問題，仍需通過客戶應(yīng)用主動向ORB進(jìn)行查詢和等待才能取得應(yīng)答，而且這種模型存在編程復(fù)雜、內(nèi)存分配和數(shù)據(jù)拷貝過多等問題，導(dǎo)致模型效率低下、編程繁瑣[7]。One-way機(jī)制存在對傳輸層的依賴和best-effort語義問題，Server目標(biāo)對象需要2套服務(wù)代碼，一套針對同步和DII操作，另一套針對One-way操作，使得Server變得冗余龐大。

3 通信模型

3.1 模型的結(jié)構(gòu)

圖4 異步輪詢模型

針對CORBA現(xiàn)有通信模型存在的不足，在事件服務(wù)的基礎(chǔ)上，以傳統(tǒng)的調(diào)用模型為原型，得到一種新的模型，它既支持應(yīng)答的獲取，又能夠以一種異步的方式處理應(yīng)答。該模型的結(jié)構(gòu)如圖4所示。圖4可分為3個模塊：Client接收模塊，ORB處理模塊，Server提供模塊。當(dāng)Client引發(fā)一個調(diào)用時，系統(tǒng)會自動生成一個ReplyHandler對象，并注冊到ORB中。Client發(fā)出請求后，繼續(xù)處理其他事情。在請求發(fā)出后的不同時間點(diǎn)上，Client會向ReplyHandler詢問返回的應(yīng)答情況。當(dāng)有應(yīng)答從Server返回到ORB中時，ORB通過回調(diào)把應(yīng)答存儲到缺省的ReplyHandler中。如果Client再次詢問ReplyHandler對象是否有返回的應(yīng)答時，就可以從ReplyHandler中提取存儲的應(yīng)答，并進(jìn)行處理。通過該模型可以看出，Client發(fā)出請求后可以在需要時主動取得應(yīng)答，如果把ReplyHandler的生命周期與Client分離，為ReplyHandler設(shè)計持久的生命周期和存儲能力，即使Client處于不活動的狀態(tài)，應(yīng)答同樣能被保存下來。當(dāng)Client再次活動時，同樣可以獲得應(yīng)答。

3.2 模型的工作原理

為了避免多線程帶來的安全性、同步、互斥等問題，模型依然采用單線程結(jié)構(gòu)，在同一進(jìn)程空間下支持ReplyHandler對象和Client的應(yīng)用邏輯。針對每一個接口定義文件，IDL編譯器會為它們生成消息回調(diào)的相應(yīng)構(gòu)件。當(dāng)Client向Server發(fā)出異步調(diào)用時，將攜帶一個ReplyHandler對象作為第1個請求參數(shù)。ReplyHandler并沒有直接發(fā)送給Server，而是在IIOPClient Table中注冊。當(dāng)Server的應(yīng)答返回時，IIOPClient被Reactor管理的事件循環(huán)引發(fā)執(zhí)行。首先，通過報文重組，把異步調(diào)用的應(yīng)答轉(zhuǎn)換為新的請求報文，提交給CallBack，然后定位ReplyHandler對象，找到合適的回調(diào)路線。找到適配的ReplyHandler后通過其CallBack Skeleton交給相應(yīng)的ReplyHandler對象，Client對返回的應(yīng)答進(jìn)行相應(yīng)的處理[8]。

這里存在一個問題，就是當(dāng)Client正在提交請求時，如何將線程資源從Client的應(yīng)用邏輯分給ORB，讓ORB來實(shí)現(xiàn)對象的回調(diào)。這里采用ORB某個時間占有一段資源去執(zhí)行回調(diào)的方法。Client應(yīng)用邏輯發(fā)送一條新的請求時，線程會從應(yīng)用邏輯進(jìn)入ORB核心。這時IIOPClient查詢當(dāng)前連接上是否有前面異步調(diào)用返回的應(yīng)答。若有，IIOPClient對應(yīng)答執(zhí)行一個回調(diào)操作，直到應(yīng)答全部處理完，接著再發(fā)送新的請求。如果應(yīng)用邏輯總是有請求發(fā)出，異步調(diào)用的應(yīng)答總有機(jī)會被調(diào)用。該模型的工作原理如圖5所示。

圖5 模型工作原理圖

4 結(jié)束語

本文對CORBA的事件服務(wù)及異步通信機(jī)制進(jìn)行了較深入研究，并在傳統(tǒng)通信模型的基礎(chǔ)上提出了異步輪詢模型，通過這種模型克服了傳統(tǒng)CORBA通信模型的缺陷，從某種意義上說，真正實(shí)現(xiàn)了信息的異步通信。

[1]Object Management Group.Common object request broker architecture 08-01-04[S].2008.

[2]Object Management Group.Event service 04-10-02[S].2004.

[3]OMG.CORBA服務(wù)[M].北京：電子工業(yè)出版社，2002.

[4]OMG.CORBA系統(tǒng)結(jié)構(gòu)、原理與規(guī)范[M].北京：電子工業(yè)出版社,2000.

[5]Carlos O'Ryan，David L Levine，Douglas C Schmidt，et al.Applying a scalable CORBA event service to large-scale distributed interactive simulations[A].The 1st International Workshop on Object-Oriented Real-Time Dependable Systems(WORDS 99F)[C].Monterey,California,USA，1999.

[6]朱其亮，鄭斌.CORBA原理及應(yīng)用[M].北京：北京郵電大學(xué)出版社，2001.

[7]GUO Yin-zhang，YAN Xiao-fen.Study on asynchronous communication in distributed object-oriented middleware based on mixed model of mobile agent and P/S[J].IEEE，2008.978-1-4244-2108-4/08.

[8]張志偉，郭長國，蔡俊亞，等.CORBA異步消息的研究與實(shí)現(xiàn)[J].電子學(xué)報，2004，32（11）： 1820-1823.