CORBA对象生命周期之生命周期的评估-Java基础-Java-编程开发

<script type="text/javascript">google_ad_client = "pub-8800625213955058";/* 336x280, 创建于 07-11-21 */google_ad_slot = "0989131976";google_ad_width = 336;google_ad_height = 280;//</script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

评估准则

我们已经地讨论了CORBA对象的生命周期，包括生命周期事件，对早期和后期绑定的讨论，以及CORBA对象实现的一般分类。显然，用户希望ORB提供的应用程序能支持所有这些CORBA对象生命周期不同方面的有效实现。ORB通过对象适配器（OA）来提供这种支持。下面定义了一系列的评估准则，通过这些准则可对对象适配器进行涉及CORBA对象生命周期有效支持的分析。然后用户采纳这些不同的评估准则，并把它们应用到BOA和POA代的对象适配器中。

·适配器结构-- 最为重要的方面是适配器的一般结构。

·对象标识-- CORBA系统中的对象标识不是小问题，必须仔细检验特定的ORB代如何为CORBA对象支持对象标识的概念。

·早期绑定-- 用户需要检验不同ORB代支持早期绑定的方式。这里值得注意的是绑定和伺服对象创建相互间有多大程度的关联。

·后期绑定-- 不同ORB为后期绑定提供的机制必须要检验，特别是关于用来支持持久对象的应用程序的有用性。

·无状态伺服对象-- 用户想要检验ORB代为实现无状态伺服对象而提供的支持。思路是对于无状态伺服对象，用户并不真正需要每个CORBA对象代表一个伺服对象实例-- 一个单独的伺服对象可以作为多个CORBA对象的瞬态胶囊，并在每个请求的基础上设定一个特别CORBA对象的标识。

·有状态伺服对象-- 正如前面讨论过的，对于有状态伺服对象，确保用户不必为每个请求重新激活这些伺服对象，并且激活伺服对象未超过某一阈值，这通常是很重要的。

评估BOA代

下面想在上述定义的每个与对象生命周期相关的评估准则下探讨基本对象适配器，说明对可移植对象适配器完成的工作。

1. BOA 体系结构

前面提过，BOA体系结构在很多方面是极其模糊的。应用程序要求用来有效管理对象生命周期的很多特征都不够具体。BOA定义了一些激活CORBA服务器和CORBA对象实现的函数。不幸的是，BOA侧重于服务器激活，而不是像后期绑定和动态对象激活这些重要的问题。BOA还为对象引用的生成和解释定义了一些函数。BOA隐含了伺服对象和CORBA对象间的一对一关系，即对于特定服务器支持的每个CORBA对象要求有一专用的伺服对象实例。

因为BOA规范过于模糊，所以本文使用IONA Technologies Orbix 2.x ORB作为参考实现。同样，我们的目的不是要给出不同BOA代ORB的全面比较，而是使用ORB作为例子来讨论一般的概念。

2. 对象标识

BOA代的ORB把对象引用和创建时的引用数据相关联。引用数据是8位位组序列，并由ORB控制。这就使在遵循CORBA的方式中提供应用程序定义的对象I D变得困难。Orbix ORB提供了_marker() API来为CORBA对象指明应用程序定义的引用数据。marker是一字符串，由应用程序提供，并作为引用数据的一部分由ORB存储。

3. 早期绑定

如前所述，大多数BOA代ORB在客户端桩类层次和服务器端框架类层次之间提供了紧密的耦合。这样做的结果是伺服对象的创建通常会间接导致对象的激活，因为伺服对象继承了构造方法，这个构造方法能间接在伺服对象和ORB运行时模块之间创建绑定。这就暗示，如果用户想把对象引用返回给客户机，也就要创建和激活伺服对象实例，即使用早期绑定。

4. 后期绑定

BOA结构并没有定义ORB和应用程序之间如何交互以支持后期绑定，或是通过命令进行对象激活。因此，本文把Orbix ORB作为BOA ORB如何论述这个问题的例子。

Orbix ORB使用图3所示的装载器机制来支持后期绑定。如前所述，装载器扮演伺服对象管理器的角色。基本思想是应用程序把装载器实例注册到ORB运行时模块。ORB运行时模块在对象故障的情况下依次激活装载器上的load( )方法。这就给了装载器一个机会来激活请求对象，这样ORB就可以分派它。

应用程序的职责是决定伺服对象是只为特定的请求服务还是为后面的请求继续保持激活。ORB i x装载器特征可被应用程序用来实现为对象伺服对象池模式，而这些对象可用命令，即持久对象激活。

5. 无状态伺服对象

BOA代ORB实现并没有为无状态伺服对象提供特别的支持。基本上， CORBA对象和伺服对象之间一对一的关系暗示着必须为每个CORBA对象激活一个伺服对象。根据实例化和激活一无状态伺服对象的花费，用户要决定它是否值得实现为池模式，以减少对象激活/冻结的次数。这包括调查由ORB强加的伺服对象激活和冻结的开销，以及和应用程序相关的花费。问题在于从性能的角度来看是在每个请求的基础上激活伺服对象昂贵，还是维护一对象池昂贵。

6. 有状态伺服对象

前面讨论过，对于有状态的伺服对象，伺服对象的激活/冻结是很昂贵的，特别是如果它包括了数据库的查找。在这种情况下，把后期绑定和对象池结合起来就很有意义。因为BOA规范在这里不是很明确，所以必须为后期绑定而依赖于专有的ORB支持，象ORBix装载器。

[1][2]