鞏方浩，祈明龍

（武漢理工大學(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ā)難度。現(xiàn)有CORBA通信模式主要有同步、One-way、延遲同步等。但它們都未實現(xiàn)或未完全實現(xiàn)消息通信的異步。

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

1 事件服務(wù)

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

1.1 事件通道

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

圖1 事件通道

1.2 事件服務(wù)模型

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

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

圖 2 Push模型

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

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

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

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

圖3 混合模型

一個事件通道里的消費者和提供者可以根據(jù)實際需求選擇是Push方式還是Pull方式,進(jìn)而組成各種各樣的通信模型。事件通道提供接口設(shè)置這些通信方式。以消費者為例，它首先要獲得一個事件通道對象，然后獲得該事件通道的消費者管理接口ConsumerAdmin，接著取得代理對象。由于消費者和提供者之間通信必須通過代理來完成，所以消費者獲得一個提供者代理,提供者獲得一個消費者代理,代理之間完成信息交換。當(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）主動向消費者傳遞數(shù)據(jù)時，提供者會從SupplierAdmin處獲得調(diào)用ProxyPushConsumer對象的push方法，將事件數(shù)據(jù)推向事件通道。然后事件通道查詢ConsumerAdmin上的所有代理對象，調(diào)用ProxyPushSupplier對象的Push方法，將事件數(shù)據(jù)從事件通道推給消費者。而對于ProxyPullSupplier的所有事件則保存在隊列中，直到調(diào)用pull方法才能將它們從隊列中拉走。

1.3 CosEventChannelAdmin模塊

CORBA規(guī)范中定義一個CosEventChannelAdmin模塊[6]，用來定義提供者和消費者之間通信所用到的各種接口和異常，包括 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)用接口的延遲同步模型可以放松同步的約束，延遲同步客戶在多個不同的時間點查詢應(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ā)出后的不同時間點上，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來實現(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通信模型的缺陷，從某種意義上說，真正實現(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異步消息的研究與實現(xiàn)[J].電子學(xué)報，2004，32（11）： 1820-1823.