在服务器端，服务器的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对象的生命周期。
