评估准则

我们已经地讨论了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装载器。 评估poa代

现在把评估准则应用到可移植对象适配器。

1. poa体系结构

poa体系结构在开始时可算是占绝对优势的，因为它为管理伺服对象和corba对象提供了很多先进的特性。幸运的是，以很简单的方式来开始使用poa是可能的。但是，不同对象类型的不同需求确实需要poa的高级支持机制。

图4给出了poa结构顶层元素的概述。orb通过poa来管理伺服对象。每个orb和一个poa关联。通过调用poa上的create_poa( )并传递新poa的名字，poa可用来创建嵌套的poa，这是创建新poa的唯一方法，意味着应用程序不能提供它自己的poa实现。相反，应用程序通过把新poa和一系列策略关联来定义新poa的具体行为。这些策略根据如伺服对象激活、伺服对象生命期限、i d管理和线程分配等事项来定义poa的行为。

图5给出了poa和伺服对象之间关系的概述。poa规范采用术语"化身" (incarnation)来指出伺服对象和corba对象的关联。在类图中，可以看到这个化身关系，它由对象i d来完成，即poa可通过相关联的对象i d来定位伺服对象。显然，每个poa可以和多个伺服对象相关联。令人惊奇的是一个单独的伺服对象可代表多个corba对象！事实上，为多个对象注册一个伺服对象不仅是可能的，甚至注册一个缺省的伺服对象，用来获取没有通过i d而和伺服对象明确相关联的对象的所有请求也是可能的。本文会在下面讨论这个特征的有用性。poa规范还引入了术语"神化（etherealize）"，它是化身的反义。这就是把伺服对象与corba对象间的关联取消的操作。

2. 对象标识

corba的poa代对术语"对象关键字"和对象id有明确的区分。对象关键字在通信结束点标识对象。例如，对象关键字可含有poa的名字，通过这个名字可到达目标对象实现。另外，对象关键字还可包含一对象id。对象id标识和具体poa相关的对象。根据特定的poa策略，新创建对象的id可由poa或应用程序定义。

3. 早期绑定

为了使用poa的早期绑定，要以明确的激活来使用称为伺服对象保留的策略（用activate_object( )或activate_object_with_id( )）。

要注意， poa规范把伺服对象的激活和对象引用的创建相隔离。现在把对象引用返回给客户机并不一定意味着服务器必须激活对象；即用户没有执行早期绑定也可以返回对象引用。这意味着用户可以更多地使用后期绑定。当使用无状态服务器和代表所有无状态伺服对象的单独伺服对象的结合时，就会有好处；在这种情况下，用户只需实例化一个单独的伺服对象，并把它作为缺省的伺服对象注册。缺省的伺服对象会为所有对象处理即将到来的请求，我们只要简单地创建和输出这些对象的引用就能使它们变为可用。

4. 后期绑定

poa支持伺服对象管理器的概念作为后期绑定的基础机制，如图6所描述。在对象故障的情况下， poa会激发注册的伺服对象管理器，试图获取请求对象的化身。这意味着伺服对象和corba对象间的绑定只为特定的请求而创建（当使用伺服对象定位器时），或者绑定会比请求期存在得更久（当使用伺服对象激活器时）。

5. 无状态伺服对象

poa规范以两种方式提供对无状态伺服对象的支持。首先，应用程序可注册一个缺省的伺服对象，它可以为所有通过特定poa能访问到的对象处理到来的请求。其次，可以使用伺服对象定位器：伺服对象定位器使伺服对象只在请求期间对poa可用。这意味着伺服对象会在请求期间采用一个特定的id。poa提供一个api，使伺服对象在执行请求时能找出它自己当前的识别。

6. 有状态伺服对象

如前面所讨论的，对于有状态伺服对象，用户通常想维护激活伺服对象的池来减少花费巨大的激活的次数。一个重要的问题是谁来实际维护corba对象到伺服对象的映射。图5指出了伺服对象通过它的id和poa关联。但是情况并不总是如此。有了伺服对象定位器机制，用户可以在每个请求的基础上创建对象/伺服对象关联。注意伺服对象定位器通常在orb的控制之外来管理自己的对象id/伺服对象映射。这是实现有效的驱逐机制的最简易方法。

从上面的讨论中，我们可以看出，boa规范经常是很模糊的，并没有表达很多要求用来有效管理远程激发和corba对象生命周期的特性。poa规范初看上去过于复杂，但另一方面， poa规范覆盖了很多boa代orb以专有方式实现的特性，而这些特性并没有被boa规范所覆盖。最后，开发者可用简单的方式来使用poa，以后根据需要可利用更多的特性。