Issues for Object Reference Template Finalization Task Force discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 4440: Object Adapter name problem in ORT
Issue 4445: Interoperability of ObjectReferenceTemplate and Factory.
Issue 4476: There is no way to modify a POA's ORT and append to it
Issue 4478: Creating IORs

Issue 4440: Object Adapter name problem in ORT (ort-ftf)

The adopted specification for the Object Reference Template is
ptc/01-04-03.  This specification introduces adapter names for 
object adapters. Adapter names are needed in the definition of the
ObjectReferenceTemplate abstract valuetype.  An AdapterName is
simply a sequence of strings that is used to identify an
instance of an object adapter.

In the case of the POA, the spec defines the AdapterName as follows
in section 21.5.2.1:

	In the case of the POA, the adapter name shall be the sequence
	of names starting with the root POA that is required to reach 
	the POA using the find_POA call.  The name of the root POA is
	the empty sequence.
	
Also, in section 21.3.14.6:

	The adapter_name attribute defines a name for the object adapter that
	services requestws for the invoked object.  In the case of the POA,
	the adapter_name is the sequence of names from the root PAO to the POA
	that services the request.  The root POA is not named in this sequence.
	
The problem here is that the POA occupies the entire name space of 
possible adapter names, so an ORB that supports other proprietary
object adapters cannot unambiguously identify instances of other 
object adapter through ServerRequestInfo.adapter_name.

Nothing in the specs (I think the submission does say this somewhere)
say that the valuetypes defined in this spec and implemented by the ORB
vendor are not expected to be transmitted across different ORB
implementations.

Proposal:

Add paragraph to 51.5.3.1:

Concrete definitions and implementations of ObjectReferenceTemplate and
ObjectReferenceFactory are ORB implementation specific and are not
defined as they are not expected to be exchanged between ORB
implementations.

If I wish to register an ORF (ObjectReferenceFactory) as the current
factory, there is no way for it to append to the current template. In
other words, an updated factory can only replace the original but not
say add another profile to the one the given POA would generate w/ the
adapter template.

As an inverse, there is no way for a POA to require or even request an
ORF to include profiles that it deems fit.

Proposal:

Add a parameter to make_object

Object make_object( in string repositoryId, in ObjectId id,
ObjectReferenceTemplate template);

Add the following methods to ObjectReferenceTemplate

abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory {
  readonly attribute ServerId server_id ;
  readonly attribute ORBId orb_id ;
  readonly attribute AdapterName adapter_name;
  ProfileSeq getProfiles(in string repositoryId, in ObjectId id);
  ComponentSeq getComponents(in IOP::ProfileId profile_id);  
};

where ProfileSeq is defined as

module IOP {
  typedef sequence <TaggedProfile> ProfileSeq;
  typedef sequence <TaggedComponent> ComponentSeq;
}

Add the following sections:

21.5.3.8 getProfiles

This returns the set of profiles that the POA would have generated using
its default template. This can optionally be included in the generated
IOR.
[ED: This is independent of make_object, because make_object returns an
object reference from which profiles would have to be extracted for
inclusion]

21.5.3.9 getComponents
This returns set of components that would have been include in the
profile with the id profile_id and allows the factory to choose to
include those in the profiles that it generates.

After a long discussion, we agreed on the following summary of this issue:

Users of ORT may wish to accommodate the following two scenarios: 
The birth address optimization: when a persistent objref is created, include the profile(s) for the transient address of the server as well as the profile(s) that contain the permanent IOR address. 
In a complex system with multiple authentication servers, the IMR and other CORBA servers may not all support the same authentication policies. This leads to a need for the IMR to construct a transient objref that points to the current incarnation of a persistent server and has security information in the IOR that is appropriate for that particular server. 
These scenarios are somewhat awkward to address with the current ORT definition for several reasons. The issue here focuses on the following problems: 
A user defined IORInterceptor may need to determine whether the current_factory and adapter_template are actually the same valuetype or not. 
Getting access to the profiles in an object reference is quite cumbersome, and possibly not portable. 
Resolution: 

Add operations on the ObjectReferenceFactory to test for equality and generate a sequence of tagged profiles

>         // ulgy conversion to objectref: we should think about
>         // creating utilities for IOR<->objref conversion

I meant to raise that second issue (the ugly IOR to ObjRef conversion).
It is too painful and I think we should address it. I can think of a few
possible solutions.

1. have make object just return profiles, so the ORB can do the
conversion internally.
2. Add a method on the ORT to provide this functionality
3. Add a separate CODEC interface to manufacture IORs from Profiles
(IORFactory, rir etc)

I meant to raise that second issue (the ugly IOR to ObjRef conversion). I can think of a few possible solutions: 
Have make_object just return profiles, so the ORB can do the conversion internally. 
Add a method on the ORT to provide this functionality. 
Add a separate CODEC interface to manufacture IORs from profiles (IORFactory, rir, etc.) 

--------------------------------------------------------------------------------
After much discussion, a proposal was put forth to declare the intended usages behind issues 4476 and 4478 as out of scope for the ORT specification. This proposal passed in Vote 3.