在服务器端,服务器的ORB在运行时从网络读取请求,并通过调用在第一个安装的消息拦截器上的receive_message( )开始处理请求。ORB用对象关键词以标识目标必须含有POA的名字,通过POA才能到达该对象。找到正确的P O A后,下一步是寻找对象本身,这个工作如何完成取决于为对象的POA定义的策略。如果对象能够定位,ORB通过调用在第一个安装的请求拦截器上的target_invoke( )来继续处理请求,拦截器则使用DII函数invoke( )来依次继续处理请求,这在客户端中已经讨论过。这里假设只安装了一个请求拦截器,请求最后会被分派到目标对象的实现。
当对象完成处理请求后,消息拦截器的invoke( )调用返回,拦截器现在就有机会在返回到ORB运行时模块之前通过激发请求对象上的result( )来检验操作的结果。服务器端的最后一件事是ORB对服务器消息拦截器上的send_message( )的激发。在客户端,拦截器以类似的方式来处理:首先ORB调用消息拦截器上的receive_message( )方法,然后请求拦截器对invoke( )的阻塞调用返回,并使这些调用能检验请求的结果。最后,由客户机激发的在代理上的方法返回,向客户机提供结果。
POA规范第一版的问题在于很难决定生命周期中的事件的确切顺序,特别是在服务器端。例如,规范没有明确定义在服务器端的的哪个时段为特定的请求分配线程--很多线程策略要求在请求对象中提供的信息。另外,规范没有清楚规定POA和与请求拦截器有关的对象查找的顺序,所以在流程图中,这个顺序是基于它们的逻辑关系。
我们要识别两代不同的CORBA:BOA(基本对象适配器)代和P O A(可移植对象适配器)代。这样区分将允许我们定义在核心ORB体系结构演变过程中两个重要的里程碑。
1、BOA代 CORBA体系结构的BOA代定义对象适配器是"应用程序用来访问ORB函数的主要接口..它包括..生成对象引用的接口,含有一个或多个程序的注册实现和激活实现所需的接口。"
要注意,当谈论到注册和激活实现时, BOA着重于CORBA服务器实现,而不是CORBA对象实现。BOA规范的一个主要不足就是它面对这样的问题时的不确定性。对于生成的服务器端框架缺少命名约定也是一个例证,这使得以遵循CORBA的方式来关联框架和对象实现变得不可能。本文使用IONA Technologies的Orbix 2.x的CORBA实现来作为ORB的BOA代的基准。
2、POA代 可移植对象适配器试图一方面克服最初BOA规范的不确定性,另一方面又为对象生命周期管理提供一整套的高级服务。
对POA本身的深入讨论可在Schmidt和Vinoski的书中找到,其中还提供了如下定义:"对象适配器是CORBA组件,负责使CORBA的对象概念能适应编程语言的伺服对象概念。"这个定义强调对实现的注册和激活从过程级转移到了对象级。对于对象生命周期, POA本身并不是在CORBA体系结构演变过程中唯一令人感兴趣的变化。其他令人感兴趣的新特征包括拦截器,它允许对激发生命周期,以及服务上下文( service context)的监控。服务上下文支持以标准的CORBA激发来发送额外的信息。尽管最后这两个特征和对象适配器的概念无关,我们仍然把它们纳入"POA代"定义中。这意味着本文对BOA和POA两代的观点节略了CORBA的详尽版本的历史,使用户能够侧重于概念。
下面主要讨论CORBA对象的生命周期及其实现,从总体上看一下对象生命周期,然后再探讨BOA和POA两代ORB的细节。我们以应用程序而不是ORB的角度来看待对象生命周期,所以要首先看一下应用程序通常要求什么来有效地管理CORBA对象的生命周期。
查看本文来源