CORBA对象生命周期之生命周期的评估(图)(3)

　　评估POA代

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

　　1. POA体系结构

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

图2

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

图3

　　图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对象间的绑定只为特定的请求而创建（当使用伺服对象定位器时），或者绑定会比请求期存在得更久（当使用伺服对象激活器时）。

图4

　　5. 无状态伺服对象

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

　　6. 有状态伺服对象

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

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

[上一页]　[1]　[2]　[3]