巩方浩，祈明龙

（武汉理工大学 计算机学院，湖北 武汉 430070）

公用对象请求代理体系结构CORBA（Common Object Request Broker Architecture）[1]是对象管理组织 OMG（Object Management Group）提出的对象中间件的标准与开发规范。随着CORBA技术的不断完善，CORBA在分布式环境中的应用越来越广泛。CORBA技术使得应用程序对远端对象的调用透明化，在编码时，开发人员可以无需考虑系统软硬件平台、网络协议直接进行开发，使得开发工作不必纠缠于底层网络编程的细节，降低了开发难度。现有CORBA通信模式主要有同步、One-way、延迟同步等。但它们都未实现或未完全实现消息通信的异步。

针对现有通信模式的时间、空间、流程高耦合的缺点，对象管理组织（OMG）已对此制定出新的CORBA异步通信机制规范。利用异步通信机制，客户端和服务端可以实现真正的异步通信，了解CORBA核心技术ORB的处理过程。这里提出一种基于CORBA事件服务的异步通信方案，该方案是在CORBA事件服务的基础上实现信息的异步传输，并进行一定程度的优化。

1 事件服务

CORBA事件服务通过对事件（由对象产生并传送给其他对象）封装而提供了基本的消息传递功能。在事件被产生之后，CORBA事件服务是将事件从事件提供者对象传送给事件消费者对象的一种机制[2]。事件服务允许对象动态地注册或注销他们感兴趣的特定事件，事件服务在相互不很了解的对象之间建立起一条宽松耦合的事件通道,它是连接消费者和提供者之间的桥梁（事件服务中,客户端被称为服务消费者Consumer；而服务端被称为服务提供者Supplier），它实际是一个CORBA对象,允许多个消费者和多个提供者与其相连接,既可以代理消费者,又可以代理提供者,使得消费者和提供者可以异步通信。

1.1 事件通道

对象之间事件的传送是借助一个称为“事件通道”（Event channel）的对象来进行的。事件通道是一个既是事件提供者又是事件消费者的插入对象，它允许多个事件提供者和多个事件消费者异步地通信而无需相互了解。提供者和消费者不是直接交互作用，而是从事件通道那里获得一个代理对象，让代理对象在将来的事件交换中代表自己[3]。事件通道负责将事件从“提供者”对象传送给“消费者”对象。因此，事件的传递经历了2个阶段，即从提供者到事件通道的阶段以及从事件通道到消费者的阶段，如图1所示。

图1 事件通道

1.2 事件服务模型

事件服务有Push、Pull、Push/Pull、Pull/Push等4种基本模型。

1）Push模型 在Push模型中，提供者通过 PushConsumer接口调用Push操作将事件数据推给事件通道，然后事件通道以同样的方式将事件数据推给消费者。图2展示了一个消费者和一个提供者通过事件通道通信的Push模型。

图 2 Push模型

2）Pull模型 在Pull模型中，消费者向提供者请求事件数据，事件通道在这里充当请求代理,由它先接受来自消费者的请求，再将其转告给提供者。一个消费者和一个提供者通过事件通道进行通信的Pull模型类似图2，不同之处是将Push命令变为Pull操作[4]。

3）Push/Pull模型 该模型是提供者将事件数据推给事件通道，事件通道将数据排成队列，等待消费者发出pull命令提取数据。

4）Pull/Push模型 该模型是指由事件通道充当代理对象，由它向提供者请求服务并将服务推向相关的提供者。

除了以上基本模型外，还可以将它们混合使用。消费者和提供者通过事件通道进行通信的混合模型如图3所示[5]。

图3 混合模型

一个事件通道里的消费者和提供者可以根据实际需求选择是Push方式还是Pull方式,进而组成各种各样的通信模型。事件通道提供接口设置这些通信方式。以消费者为例，它首先要获得一个事件通道对象，然后获得该事件通道的消费者管理接口ConsumerAdmin，接着取得代理对象。由于消费者和提供者之间通信必须通过代理来完成，所以消费者获得一个提供者代理,提供者获得一个消费者代理,代理之间完成信息交换。当Consumer为主动方（PullConsumer）时，Consumer就会主动的“拉”事件，这时它就会向ConsumerAdmin申请获得对象ProxyPullSupplier，然后调用该对象的pull方法；反之，当Consumer为被动方(PushConsumer)时，它被动接收事件数据，这时它会申请获得对象ProxyPushSupplier，调用给对象的Push方法。对于Suppliers也有类似的过程，只不过当 Supplier为主动提供者（PushSupplier）时，它会获得对象ProxyPushConsumer；当为被动方时，它会获得对象ProxyPull-Consumer。

当提供者（Supplier）主动向消费者传递数据时，提供者会从SupplierAdmin处获得调用ProxyPushConsumer对象的push方法，将事件数据推向事件通道。然后事件通道查询ConsumerAdmin上的所有代理对象，调用ProxyPushSupplier对象的Push方法，将事件数据从事件通道推给消费者。而对于ProxyPullSupplier的所有事件则保存在队列中，直到调用pull方法才能将它们从队列中拉走。

1.3 CosEventChannelAdmin模块

CORBA规范中定义一个CosEventChannelAdmin模块[6]，用来定义提供者和消费者之间通信所用到的各种接口和异常，包括 2个异常（AlreadyConnected和 TypeError）和 7个接口（ProxyPushConsumer,ProxyPullSupplier,ProxyPullConsumer,ProxyPushSupplier,ConsumerAdmin,SupplierAdmin,EventChannel）。

CosEventChannelAdmin模块的定义如下：

2 CORBA异步通信机制的不足

以上简单说明了事件服务的几种模型。而传统上，基于CORBA标准的分布对象计算模型的应用主要在3种调用模型中选择：One-way操作、同步操作和采用动态调用接口（DII）的延迟同步操作。这3种模式基本能够满足一般C/S应用的需要，但却很难满足现代的应用需求。在这些环境下，开发人员需要一种能够提供完善的异步特性的钓鱼模型，而这种异步特性是传统调用模型无法提供的。为了解决异步性缺乏的问题，这里对3种模型进行相应的改进。例如对于同步操作，可以对每个同步操作的请求响应对都启用一个不同的线程，但这种方法会随着线程的增加而消耗大量的系统资源，从而影响系统的可伸缩性。另外有些软件是按照单线程的模式设计的，如果把它们继承到多线程环境下，必须考虑线程的安全问题等。而采用动态调用接口的延迟同步模型可以放松同步的约束，延迟同步客户在多个不同的时间点查询应答是否返回，它本质上没有解决同步的问题，仍需通过客户应用主动向ORB进行查询和等待才能取得应答，而且这种模型存在编程复杂、内存分配和数据拷贝过多等问题，导致模型效率低下、编程繁琐[7]。One-way机制存在对传输层的依赖和best-effort语义问题，Server目标对象需要2套服务代码，一套针对同步和DII操作，另一套针对One-way操作，使得Server变得冗余庞大。

3 通信模型

3.1 模型的结构

图4 异步轮询模型

针对CORBA现有通信模型存在的不足，在事件服务的基础上，以传统的调用模型为原型，得到一种新的模型，它既支持应答的获取，又能够以一种异步的方式处理应答。该模型的结构如图4所示。图4可分为3个模块：Client接收模块，ORB处理模块，Server提供模块。当Client引发一个调用时，系统会自动生成一个ReplyHandler对象，并注册到ORB中。Client发出请求后，继续处理其他事情。在请求发出后的不同时间点上，Client会向ReplyHandler询问返回的应答情况。当有应答从Server返回到ORB中时，ORB通过回调把应答存储到缺省的ReplyHandler中。如果Client再次询问ReplyHandler对象是否有返回的应答时，就可以从ReplyHandler中提取存储的应答，并进行处理。通过该模型可以看出，Client发出请求后可以在需要时主动取得应答，如果把ReplyHandler的生命周期与Client分离，为ReplyHandler设计持久的生命周期和存储能力，即使Client处于不活动的状态，应答同样能被保存下来。当Client再次活动时，同样可以获得应答。

3.2 模型的工作原理

为了避免多线程带来的安全性、同步、互斥等问题，模型依然采用单线程结构，在同一进程空间下支持ReplyHandler对象和Client的应用逻辑。针对每一个接口定义文件，IDL编译器会为它们生成消息回调的相应构件。当Client向Server发出异步调用时，将携带一个ReplyHandler对象作为第1个请求参数。ReplyHandler并没有直接发送给Server，而是在IIOPClient Table中注册。当Server的应答返回时，IIOPClient被Reactor管理的事件循环引发执行。首先，通过报文重组，把异步调用的应答转换为新的请求报文，提交给CallBack，然后定位ReplyHandler对象，找到合适的回调路线。找到适配的ReplyHandler后通过其CallBack Skeleton交给相应的ReplyHandler对象，Client对返回的应答进行相应的处理[8]。

这里存在一个问题，就是当Client正在提交请求时，如何将线程资源从Client的应用逻辑分给ORB，让ORB来实现对象的回调。这里采用ORB某个时间占有一段资源去执行回调的方法。Client应用逻辑发送一条新的请求时，线程会从应用逻辑进入ORB核心。这时IIOPClient查询当前连接上是否有前面异步调用返回的应答。若有，IIOPClient对应答执行一个回调操作，直到应答全部处理完，接着再发送新的请求。如果应用逻辑总是有请求发出，异步调用的应答总有机会被调用。该模型的工作原理如图5所示。

图5 模型工作原理图

4 结束语

本文对CORBA的事件服务及异步通信机制进行了较深入研究，并在传统通信模型的基础上提出了异步轮询模型，通过这种模型克服了传统CORBA通信模型的缺陷，从某种意义上说，真正实现了信息的异步通信。

[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服务[M].北京：电子工业出版社，2002.

[4]OMG.CORBA系统结构、原理与规范[M].北京：电子工业出版社,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原理及应用[M].北京：北京邮电大学出版社，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异步消息的研究与实现[J].电子学报，2004，32（11）： 1820-1823.