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