Issue 3661: Two-phased IORInterceptor (interceptors-rtf)
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity: 
Summary: An IORInterceptor operation which runs after
IORInterceptor::establish_components is needed to "get" all the
established components.  Something like:

   void components_available( in IORInfo info ) ;

It would not be legal to call

   IORInfo::add_ior_component

nor

   IORInfo::add_ior_component_to_profile

in

   IORInfo::components_available

The two-phases are conceptually similar to the ORBInitializer
pre_init/post_init pattern of registering references in pre_init and
resolving them in post_init. <p>

The complete set of established components are obtained in the form of
an "IORTemplate" (see the issue by that name). <p>


Resolution: Exact text to be determined as a new issue if this issue passes.
Revised Text: 
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue
Discussion: 

End of Annotations:=====
Date: Tue, 30 May 2000 08:21:13 -0700 (PDT)
Message-Id: <200005301521.IAA18900@shorter.eng.sun.com>
From: Harold Carr <harold.carr@eng.sun.com>
To: interceptors-ftf@omg.org, issues@omg.org
Subject: Two-phased IORInterceptor
Content-Type: text
X-UIDL: ^=(e9"HG!!So0e9\S'e9


An IORInterceptor operation which runs after
IORInterceptor::establish_components is needed to "get" all the
established components.  Something like:

   void components_available( in IORInfo info ) ;

It would not be legal to call

   IORInfo::add_ior_component

nor

   IORInfo::add_ior_component_to_profile

in

   IORInfo::components_available

The two-phases are conceptually similar to the ORBInitializer
pre_init/post_init pattern of registering references in pre_init and
resolving them in post_init. <p>

The complete set of established components are obtained in the form of
an "IORTemplate" (see the issue by that name). <p>

Date: Tue, 30 May 2000 10:33:28 -0700 (PDT)
Message-Id: <200005301733.KAA29297@shorter.eng.sun.com>
From: Harold Carr <harold.carr@eng.sun.com>
To: interceptors-ftf@omg.org, issues@omg.org
Subject: Portable Activation Framework using Portable Interceptors
Content-Type: text
X-UIDL: BMhd9FO!e9BIBe9&$>e9

Jurgen,

this is a discussion of issues I raised earlier, please do not make
this an issue.

All,


OK, as promised, here are how the issues I raised relate to building a
portable activation service.

Please keep in mind, *THIS IS A USE-CASE*.  We are *NOT* trying to
standardize location/activation services.  We are proposing
changes/extensions to portable interceptors based on our prototype of
an activation service built using portable interceptors.

I've identified the portions of the service which require
changes/extensions to the existing PI spec by preceding them with
"PI FTF".


    ORBD Startup

- PI FTF - ORBD is started on same port -ORBPersistentServerPort.
- ORBD specifies its ORBInitializer class.
- ORBDInitializer creates and registers activator reference in 
     initial references.
- ORBDInitializer creates and registers a ServerRequestInterceptor.


    Server Startup

- PI FTF - started with PersistentServerId (passed by activator).
- Activator passes appropriate ORBInitializer class.
- ORBInitializer pre_init creates and registers IORInterceptor.
- ORBInitializer post_init uses
- ORBInitInfo::resolve_initial_references
     to obtain a reference to the Activator which it gives to
- IORInterceptor
     for use during POA creation.


    Server POA Creation

In IORInterceptor:


- PI FTF - everything happens in new point: components_available.
- PI FTF - need access to POA LifeSpanPolicy (to determine if
- PERSISTENT).
- If persistent then do the following steps.
- PI FTF - get the IORTemplate associated with this POA.
- Register that template with the activator.
- Get the activator's template.
- PI FTF - set the adapter's template to the activator's template.
- Now, any references created by this POA will "point" to the
     activator (and contain components appropriate for the activator).
- PI FTF - the IORInterceptor must be called each time a POA is
     (re)created to enable it to exchange information with the
- activator.


    ORBD Server Request Interceptor

- Get the adapter_id from ServerRequestInfo.
- Lookup the template associated with this id.
- If it doesn't exist then request is for the ORBD.
- Otherwise
- Get the object_id from ServerRequestInfo.
- PI FTF - Use the object id to create a new reference from the
- server's
     template.
- Raise ForwardRequest.


    Misc

- PI FTF - not explicit is the fact that Java ORBs need an ORB ID for
     persistent references to be unique: serverId | orbId | poa
     path/name.

- PI FTF - when an object adapter is destroyed it notifies the
     activator of this fact so that the activator may reclaim
     resources.


Cheers,
Harold