Issue 5439: processing TaggedComponents within an IOR (corba-rtf)
Source: International Business Machines (Ms. Anne E. Collins, nobody)
Nature: Uncategorized Issue
Severity: 
Summary: The overhead of processing TaggedComponents within an IOR becomes
significant when done many times, as in the case of J2EE
implementations where multiple interceptors are used.


The definition of IORs in the IOP module is intended to support
transmission and interoperability, rather than efficient access to the
local, ORB specific, internal structure.


I would like to propose that an abstract model of an IOR is introduced
which recognises that many of the constituent parts of IOR profiles are
identical for different objects, along the following lines:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object ID.
   - an IIOPProfileTemplate has IIOP addressing information, and contains
     TaggedComponents.
   - a TaggedComponent has an ID and data
   - a TaggedComponentFactory creates a TaggedComponent
   - a TaggedProfileFactory creates a TaggedProfile


with corresponding IDL definitions that allow the language bindings
to optimise conversion between transmission and internal IOR formats
to provide a performant and natural interface for IOR access.


Rationale:
In Java, for example, it should be possible to manipulate IOR
TaggedProfiles and IIOPProfileTemplate TaggedComponents using the
facilities of the Java collections framework, or at least some
equivalent facility that is a natural Java idiom.


Templates can be used to create IIOPProfiles because the basic object
adapter model for object creation is to establish many of the properties
of an IOR when the object adapter is created.


- This has been present for the POA essentially from the beginning, since
  policies can only be passed to create_POA, and cannot be changed on an
  existing POA.
- The Portable Interceptors work has also made this clear, since the IOR
  interceptor establish_components method, which is the only time that
  user code can add tagged components to an IOR, is only guaranteed to
  be called once for each distinct set of server policies i.e need only
  be run when an object adapter is created.
- It is also likely that more than one object within an adapter will
  map to a TCP endpoint.


TaggedProfile and TaggedComponent are intended as frameworks that may be
extended to support application defined tagged profiles and components.
To support this it is necessary to be able to register TaggedProfile and
TaggedComponentFactory instances with an ORB, in which case any IOR
unmarshalled by that ORB instance will use the registered factory
to unmarshal the tagged profile or component.



Since there has already been quite a bit of discussion about this in the
Java RTF, here is a proposal for review:-



Proposal:


- add the following sections after the IOR Interceptor Overview:-



21.5.2 An Abstract Model for IORs


To support efficient access to IORs, avoiding repeated marshaling and
demarshaling of IOR components, it is helpful to have an abstract model
of the, ORB specific, local representation of an IOR.


Recognising that many of the constituent parts of IOR profiles are
identical for different objects allows the following model to be
defined:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object ID.
   - an IIOPProfileTemplate has IIOP addressing information, and contains
     TaggedComponents.
   - a TaggedComponent has an ID and data
   - a TaggedComponentFactory creates a TaggedComponent
   - a TaggedProfileFactory creates a TaggedProfile



21.5.3 Local IOR Interfaces


The following interfaces provide access to the data within a local IOR
using this model.


TaggedProfile and TaggedComponent are generic interfaces. Users of the ORB
may create implementations of them. Corresponding factories may be
registered with the IORFactory.


The IORFactory is obtained through a call to
ORB::resolve_initial_references ("IORFactory") and may also be used to
obtain an IOR for an Object.


An ORB must return all tagged profiles in an IOR through the IOR
getProfiles operations. The ProfileIterator interface allows a client
to iterate through the TaggedProfiles using the next operation.
Those profiles whose ids have a registered TaggedProfileFactory will
be made available in the form returned by the registered factory's
TaggedProfileFactory create operation, which must return a subtype of
TaggedProfile.


An ORB will provide a TaggedProfileFactory implementation for the
IIOPProfile.


Profiles with ids for which no TaggedProfileFactory has been registered
will be made available as instances of a generic ORB implementation of
TaggedProfile.



Similarly, an ORB must return all tagged components in an IIOP profile
through the IIOPProfile().getTemplate().getComponents() operations.
The ComponentIterator interface allows a client to iterate through the
TaggedComponents using the next operation.
Those components whose ids have a registered TaggedComponentFactory
will be made available in the form returned by the registered factory's
TaggedComponentFactory create operation, which must return a subtype of
TaggedComponent.
Components with ids for which no TaggedComponentFactory has been
registered will be made available as instances of a generic ORB
implementation of TaggedComponent.



module PortableInterceptor {


  local interface TaggedComponent {
      readonly attribute IOP::ComponentId component_id;
      readonly attribute CORBA::OctetSeq component_data;
      IOP::TaggedComponent convert();
  };


  local interface ComponentIterator {
      TaggedComponent next();
      boolean has_next();
  };


  local interface TaggedProfile {
      readonly attribute IOP::ProfileId profile_id;
      readonly attribute CORBA::OctetSeq profile_data;
      IOP::TaggedProfile convert();
  };


  local interface ProfileIterator {
      TaggedProfile next();
      boolean has_next();
  };


  local interface IOR {
      readonly attribute string type_id;
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id);
  };


  local interface IIOPProfileTemplate {
      readonly attribute IIOP::Version iiop_version;
      readonly attribute string host;
      readonly attribute unsigned short port;
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
  };


  local interface IIOPProfile:TaggedProfile {
      readonly attribute CORBA::OctetSeq  object_key;
      readonly attribute IIOPProfileTemplate profile_template;
  };


  local interface TaggedComponentFactory {


      readonly attribute IOP::ComponentId factory_id;
      TaggedComponent create_tagged_component
         (in CORBA::OctetSeq component_data);
  };


  local interface TaggedProfileFactory {


      readonly attribute IOP::ProfileId factory_id;
      TaggedProfile create_tagged_profile
         (in CORBA::OctetSeq profile_data);
  };


  local interface IORFactory {


    IOR  create_ior (in Object obj);
    void register_tagged_profile_factory (in TaggedProfileFactory tpf);
    void register_tagged_component_factory (in TaggedComponentFactory tcf);
  };


};



21.5.3.1 IOR Factory Interface


   create_ior
   Return an IOR relating to the given Object.


   If create_ior is invoked when the object reference is not bound,
   standard system exception BAD_INV_ORDER with minor code n will be
   raised.


   register_tagged_profile_factory
   Register a TaggedProfileFactory to create TaggedProfiles with the id
   returned by the given factory's getId method. If a TaggedProfileFactory
   already exists for the given id, standard system exception
   BAD_INV_ORDER is raised with a standard minor code of n+1.
   Instances of this interface may be defined by users to support custom
   tagged profiles.


   register_tagged_component_factory
   Register a TaggedComponentFactory to read TaggedComponents with the id
   returned by the given factory's getId method. If a
   TaggedComponentFactory already exists for the given id, standard system
   exception BAD_INV_ORDER is raised with a standard minor code of n+2.
   Instances of this interface may be defined by users to support custom
   tagged components.


21.5.3.2 IOR Interface


   This interface gives access to a local representation of an
   IOP::IOR.


   type_id
   The type id string from the IOR.


   get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


   get_profiles_by_id
   Returns an iterator over the TaggedProfiles with the given
   Profileid.



21.5.3.3 TaggedProfile Interface


   This interface gives access to a local representation of an
   IOP::TaggedProfile.


   profile_id
   This attribute is the identifier for this TaggedProfile.


   profile_data
   This attribute is the data from the TaggedProfile. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedProfile


21.5.3.4 TaggedComponent Interface


   This interface gives access to a local representation of an
   IOP::TaggedComponent.


   component_id
   This attribute is the identifier for this TaggedComponent.


   component_data
   This attribute is the data from the TaggedComponent. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedComponent.


21.5.3.5 TaggedProfileFactory Interface


   factory_id
   This attribute is the identifier of profiles created by this
   TaggedProfileFactory.


   create
   Create a TaggedProfile from the given profile_data.


21.5.3.6 TaggedComponentFactory Interface


   factory_id
   This attribute is the identifier of components created by this
   TaggedComponentFactory.


   create
   Create a TaggedComponent from the given component_data.


21.5.3.7 ProfileIterator Interface


   next
   Returns the next TaggedProfile in the iteration. If next is called
   after the last TaggedProfile has been returned, BAD_INV_ORDER will
   be raised with a standard minor code of n+3.


   If an IOR is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.8 ComponentIterator Interface


   next
   Returns the next TaggedComponent in the iteration. If next is called
   after the last TaggedComponent has been returned, BAD_INV_ORDER will
   be raised with a standard minor code of n+3.


   If a profile is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.9 IIOPProfile Interface


   object_key
   This attribute is the Object key contained in this IIOPProfile.


   profile_template
   This attribute is the IIOPProfileTemplate associated with this
   IIOPProfile.



21.5.3.10 IIOPProfileTemplate Interface


   iiop_version
   This attribute is the GIOP version of this profile. If the major
   value is 1 and the minor value is 0, this profile cannot contain
   any TaggedComponents.


   host
   This attribute is the host name string of this IIOPProfileTemplate.


   port
   This attribute is the port number of this IIOPProfileTemplate.


   get_components
   Return an iterator over the TaggedComponents within the
   IIOPProfileTemplate.


   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.



In current Section 21.5.3:
- add the following after the ORBInfo Interface


  local interface IORInfo_3_n:IORInfo {
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id);
  };



- add the following sections:


21.5.3.4  get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


21.5.3.5  get_profiles_by_id
   Returns an iterator over the TaggedProfiles within the IOR with the
   given Profileid.


   Parameter   Description
   profile_id  The IOP::ProfileId of the profiles in the iteration
               to be returned.



- add the IORFactory to the list of reserved ObjectIds for
  resolve_initial_references in section 4.5.2
Resolution: 
Revised Text: 
Actions taken:
June 25, 2002: received issue
April 11, 2012: Deferred
Discussion: 

End of Annotations:=====
Subject: Re: IOR processing performance 
To: issues@omg.org 
Cc: corba-rtf@omg.org 
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001 
From: "Ann Dalton1" <ann_dalton@uk.ibm.com> 
Date: Mon, 24 Jun 2002 14:59:36 +0100 
X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a
|January 7, 2002) at 
 24/06/2002 14:59:08 


The following issue was raised and discussed, arising as it does from
the requirements of J2EE implementations, within the Java RTF, as
issue 4945, see http://cgi.omg.org/issues/java-rtf.html#Issue4945.


The views expressed by members of the Java RTF suggested it should
be handled by the core RTF, as there is nothing specific to Java in
the requirement.


So, with apologies to those who monitor the activity of both RTFs.....
I'd like to raise the following new issue in the core RTF.


Problem summary:
The overhead of processing TaggedComponents within an IOR becomes
significant when done many times, as in the case of J2EE
implementations where multiple interceptors are used.


The definition of IORs in the IOP module is intended to support
transmission and interoperability, rather than efficient access to the
local, ORB specific, internal structure.


I would like to propose that an abstract model of an IOR is introduced
which recognises that many of the constituent parts of IOR profiles
are
identical for different objects, along the following lines:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object ID.
   - an IIOPProfileTemplate has IIOP addressing information, and
   contains
     TaggedComponents.
   - a TaggedComponent has an ID and data
   - a TaggedComponentFactory creates a TaggedComponent
   - a TaggedProfileFactory creates a TaggedProfile


with corresponding IDL definitions that allow the language bindings
to optimise conversion between transmission and internal IOR formats
to provide a performant and natural interface for IOR access.


Rationale:
In Java, for example, it should be possible to manipulate IOR
TaggedProfiles and IIOPProfileTemplate TaggedComponents using the
facilities of the Java collections framework, or at least some
equivalent facility that is a natural Java idiom.


Templates can be used to create IIOPProfiles because the basic object
adapter model for object creation is to establish many of the
properties
of an IOR when the object adapter is created.


- This has been present for the POA essentially from the beginning,
  since
  policies can only be passed to create_POA, and cannot be changed on
  an
  existing POA.
- The Portable Interceptors work has also made this clear, since the
  IOR
  interceptor establish_components method, which is the only time that
  user code can add tagged components to an IOR, is only guaranteed to
  be called once for each distinct set of server policies i.e need
  only
  be run when an object adapter is created.
- It is also likely that more than one object within an adapter will
  map to a TCP endpoint.


TaggedProfile and TaggedComponent are intended as frameworks that may
be
extended to support application defined tagged profiles and
components.
To support this it is necessary to be able to register TaggedProfile
and
TaggedComponentFactory instances with an ORB, in which case any IOR
unmarshalled by that ORB instance will use the registered factory
to unmarshal the tagged profile or component.



Since there has already been quite a bit of discussion about this in
the
Java RTF, here is a proposal for review:-



Proposal:


- add the following sections after the IOR Interceptor Overview:-



21.5.2 An Abstract Model for IORs


To support efficient access to IORs, avoiding repeated marshaling and
demarshaling of IOR components, it is helpful to have an abstract
model
of the, ORB specific, local representation of an IOR.


Recognising that many of the constituent parts of IOR profiles are
identical for different objects allows the following model to be
defined:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object ID.
   - an IIOPProfileTemplate has IIOP addressing information, and
   contains
     TaggedComponents.
   - a TaggedComponent has an ID and data
   - a TaggedComponentFactory creates a TaggedComponent
   - a TaggedProfileFactory creates a TaggedProfile



21.5.3 Local IOR Interfaces


The following interfaces provide access to the data within a local IOR
using this model.


TaggedProfile and TaggedComponent are generic interfaces. Users of the
ORB
may create implementations of them. Corresponding factories may be
registered with the IORFactory.


The IORFactory is obtained through a call to
ORB::resolve_initial_references ("IORFactory") and may also be used to
obtain an IOR for an Object.


An ORB must return all tagged profiles in an IOR through the IOR
getProfiles operations. The ProfileIterator interface allows a client
to iterate through the TaggedProfiles using the next operation.
Those profiles whose ids have a registered TaggedProfileFactory will
be made available in the form returned by the registered factory's
TaggedProfileFactory create operation, which must return a subtype of
TaggedProfile.


An ORB will provide a TaggedProfileFactory implementation for the
IIOPProfile.


Profiles with ids for which no TaggedProfileFactory has been
registered
will be made available as instances of a generic ORB implementation of
TaggedProfile.



Similarly, an ORB must return all tagged components in an IIOP profile
through the IIOPProfile().getTemplate().getComponents() operations.
The ComponentIterator interface allows a client to iterate through the
TaggedComponents using the next operation.
Those components whose ids have a registered TaggedComponentFactory
will be made available in the form returned by the registered
factory's
TaggedComponentFactory create operation, which must return a subtype
of
TaggedComponent.
Components with ids for which no TaggedComponentFactory has been
registered will be made available as instances of a generic ORB
implementation of TaggedComponent.



module PortableInterceptor {


  local interface TaggedComponent {
      readonly attribute IOP::ComponentId component_id;
      readonly attribute CORBA::OctetSeq component_data;
      IOP::TaggedComponent convert();
  };


  local interface ComponentIterator {
      TaggedComponent next();
      boolean has_next();
  };


  local interface TaggedProfile {
      readonly attribute IOP::ProfileId profile_id;
      readonly attribute CORBA::OctetSeq profile_data;
      IOP::TaggedProfile convert();
  };


  local interface ProfileIterator {
      TaggedProfile next();
      boolean has_next();
  };


  local interface IOR {
      readonly attribute string type_id;
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId
      profile_id);
  };


  local interface IIOPProfileTemplate {
      readonly attribute IIOP::Version iiop_version;
      readonly attribute string host;
      readonly attribute unsigned short port;
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
  };


  local interface IIOPProfile:TaggedProfile {
      readonly attribute CORBA::OctetSeq  object_key;
      readonly attribute IIOPProfileTemplate profile_template;
  };


  local interface TaggedComponentFactory {


      readonly attribute IOP::ComponentId factory_id;
      TaggedComponent create_tagged_component
         (in CORBA::OctetSeq component_data);
  };


  local interface TaggedProfileFactory {


      readonly attribute IOP::ProfileId factory_id;
      TaggedProfile create_tagged_profile
         (in CORBA::OctetSeq profile_data);
  };


  local interface IORFactory {


    IOR  create_ior (in Object obj);
    void register_tagged_profile_factory (in TaggedProfileFactory
    tpf);
    void register_tagged_component_factory (in TaggedComponentFactory
    tcf);
  };


};



21.5.3.1 IOR Factory Interface


   create_ior
   Return an IOR relating to the given Object.


   If create_ior is invoked when the object reference is not bound,
   standard system exception BAD_INV_ORDER with minor code n will be
   raised.


   register_tagged_profile_factory
   Register a TaggedProfileFactory to create TaggedProfiles with the
   id
   returned by the given factory's getId method. If a
   TaggedProfileFactory
   already exists for the given id, standard system exception
   BAD_INV_ORDER is raised with a standard minor code of n+1.
   Instances of this interface may be defined by users to support
   custom
   tagged profiles.


   register_tagged_component_factory
   Register a TaggedComponentFactory to read TaggedComponents with the
   id
   returned by the given factory's getId method. If a
   TaggedComponentFactory already exists for the given id, standard
   system
   exception BAD_INV_ORDER is raised with a standard minor code of
   n+2.
   Instances of this interface may be defined by users to support
   custom
   tagged components.


21.5.3.2 IOR Interface


   This interface gives access to a local representation of an
   IOP::IOR.


   type_id
   The type id string from the IOR.


   get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


   get_profiles_by_id
   Returns an iterator over the TaggedProfiles with the given
   Profileid.



21.5.3.3 TaggedProfile Interface


   This interface gives access to a local representation of an
   IOP::TaggedProfile.


   profile_id
   This attribute is the identifier for this TaggedProfile.


   profile_data
   This attribute is the data from the TaggedProfile. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedProfile


21.5.3.4 TaggedComponent Interface


   This interface gives access to a local representation of an
   IOP::TaggedComponent.


   component_id
   This attribute is the identifier for this TaggedComponent.


   component_data
   This attribute is the data from the TaggedComponent. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedComponent.


21.5.3.5 TaggedProfileFactory Interface


   factory_id
   This attribute is the identifier of profiles created by this
   TaggedProfileFactory.


   create
   Create a TaggedProfile from the given profile_data.


21.5.3.6 TaggedComponentFactory Interface


   factory_id
   This attribute is the identifier of components created by this
   TaggedComponentFactory.


   create
   Create a TaggedComponent from the given component_data.


21.5.3.7 ProfileIterator Interface


   next
   Returns the next TaggedProfile in the iteration. If next is called
   after the last TaggedProfile has been returned, BAD_INV_ORDER will
   be raised with a standard minor code of n+3.


   If an IOR is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.8 ComponentIterator Interface


   next
   Returns the next TaggedComponent in the iteration. If next is
   called
   after the last TaggedComponent has been returned, BAD_INV_ORDER
   will
   be raised with a standard minor code of n+3.


   If a profile is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.9 IIOPProfile Interface


   object_key
   This attribute is the Object key contained in this IIOPProfile.


   profile_template
   This attribute is the IIOPProfileTemplate associated with this
   IIOPProfile.



21.5.3.10 IIOPProfileTemplate Interface


   iiop_version
   This attribute is the GIOP version of this profile. If the major
   value is 1 and the minor value is 0, this profile cannot contain
   any TaggedComponents.


   host
   This attribute is the host name string of this IIOPProfileTemplate.


   port
   This attribute is the port number of this IIOPProfileTemplate.


   get_components
   Return an iterator over the TaggedComponents within the
   IIOPProfileTemplate.


   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.



In current Section 21.5.3:
- add the following after the ORBInfo Interface


  local interface IORInfo_3_n:IORInfo {
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId
      profile_id);
  };



- add the following sections:


21.5.3.4  get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


21.5.3.5  get_profiles_by_id
   Returns an iterator over the TaggedProfiles within the IOR with the
   given Profileid.


   Parameter   Description
   profile_id  The IOP::ProfileId of the profiles in the iteration
               to be returned.



- add the IORFactory to the list of reserved ObjectIds for
  resolve_initial_references in section 4.5.2



Subject: Re: Issue 5439 - processing TaggedComponents within an IOR 
To: Eoghan Glynn <eglynn@iona.com> 
Cc: corba-rtf@omg.org 
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001 
From: "Ann Dalton1" <ann_dalton@uk.ibm.com> 
Date: Thu, 27 Jun 2002 16:05:13 +0100 
X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a
|January 7, 2002) at 
 27/06/2002 16:04:46 



Eoghan,
Replies, inline.
Thanks again,
Ann



Eoghan Glynn wrote:


>This looks like a much better approach.
>
>A few points though to consider ...
>
>1. Why does IORFactory::create_ior() require that the object be
>bound?
>Surely the underlying IOR can be manipulated independently of whether
>the object is  actually bound or not? (though of course if the object
>was created for example from a corbaloc, then if it not bound there
>is
>no opportunity for the target server to forward a more complete IOR
>containing a full set of tagged components, so the IOR may not in a
>sense be "complete").


I guess it doesn't. I'm probably being over cautious here. The
statement
    "If create_ior is invoked when the object reference is not bound,
    standard system exception BAD_INV_ORDER with minor code n will be
    raised."
can be removed.


>2. Rather than specify the profile tag via a
>TaggedProfileFactory::factory_id attribute, I would instead specify
this
>as a parameter to IORFactory::register_tagged_profile_factory() and
>TaggedProfileFactory::create_tagged_profile(), as this would allow a
>single factory implementation to be used to handle more than one
profile
>tag. Similarly for component factories.


Either way works. I think your proposal is slightly more flexible, and
perhaps more in keeping with the policy factory registration; the
original proposal is simpler and avoids runtime checking of ProfileId,
and consequent mismatch handling. (I'm not suggesting errors are
likely with either scheme - I'm sure an ORB can handle matching ids to
factories. In the original proposal I would expect an error to cause a
MARSHAL exception, I guess a revised proposal should specify an
exception).
I'd be happy with whichever approach the RTF thinks most appropriate.


>
>3. Surely the profiles and components in an IOR are immutable and
>therefore the issue about whether an IOR or profile is modified while
>the profiles or components are being iterated over does need to be
>considered?


Did you mean "does need to be considered" or "doesn't need to be.."?


Assuming the latter, I think the issue does need to be considered
since these Profiles and TaggedComponents may be being made available
during IOR creation. (the statement re the iterator next operations
is where I think it is considered)


>4. Shouldn't the IIOPProfileTemplate interface provide an operation
    to
>allow it to be instantiated as an IIOPProfile by providing an object
    key?


Is this for completeness, or do you have a scenario in mind?


>5. I think you should allow ORB implementations to impose constraints
    on
>the semantics of profile and component factories - for example
    requiring
>that all profile or components created are flyweighted (i.e. only one
>instance of a particular profile or component is created by the
    factory
>during its lifetime - if a profile or component containing the same
    data
>is request more than once, the same profile or component instance is
>returned). Towards this end, I think it would be better to rename the
>create_* operations as get_* to avoid the implication that a new
    profile
>or component is created.


I'm not particularly concerned about the name but, since the factories
are being asked to return a Profile or Component based on the supplied
input data, it seems that create is generally more appropriate than
get. If an implementation chooses not to impose such a constraint,
then
get_* seems inappropriate.


>6. What about the other common profile and component types (e.g.
>multi-component profiles, codsets components etc...). Surely there
>should be profile- or component-specific sub-interfaces defined for
>these types also?


As discussed in the Java RTF, I think it is more important to have an
extensible framework than to define every possible profile or
component.
I think it's necessary to give ORB based products a mechanism to
handle
profiles and components that are specific to them, and to define those
profiles and tagged components that are owned and created by the ORB
but need to be accessed by other products. In the problem I'm
currently
trying to address (the needs of J2EE implementations), the IIOPProfile
is the only one I know to be in that category. I would prefer not to
define APIs for profiles and components that are purely internal to
the
ORB, and to defer definitions of those for which there is no known
requirement to subsequent issues, when the requirement is known and
any particulars of it can be addressed.


I can see that this could be the case for the multi-component profile.
Would the following do what you need?


  local interface MultipleComponentProfile:TaggedProfile {
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
  };


21.5.3.11 MultipleComponentProfile Interface


   get_components
   Return an iterator over the TaggedComponents within the
   MultipleComponentProfile.


   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.


and replace section 21.5.3 paragraph 5 with
   An ORB will provide TaggedProfileFactory implementations for the
   IIOPProfile and MultipleComponentProfile.



Is it necessary to define the codesets component? I had thought it
was purely of internal ORB interest.


>
>Cheers,
>Eoghan

Date: Thu, 27 Jun 2002 12:05:29 -0700 (PDT) 
From: Ken Cavanaugh <Ken.Cavanaugh@Sun.COM> 
Reply-To: Ken Cavanaugh <Ken.Cavanaugh@Sun.COM> 
Subject: Re: Issue 5439 - processing TaggedComponents within an IOR 
To: eglynn@iona.com, ann_dalton@uk.ibm.com 
Cc: corba-rtf@omg.org 
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc 


A few additional comments:


>>
>>1. Why does IORFactory::create_ior() require that the object be
bound?
>>Surely the underlying IOR can be manipulated independently of
whether
>>the object is  actually bound or not? (though of course if the
object
>>was created for example from a corbaloc, then if it not bound there
is
>>no opportunity for the target server to forward a more complete IOR
>>containing a full set of tagged components, so the IOR may not in a
>>sense be "complete").
>
>I guess it doesn't. I'm probably being over cautious here. The
>statement
>    "If create_ior is invoked when the object reference is not bound,
>    standard system exception BAD_INV_ORDER with minor code n will be
>    raised."
>can be removed.
>


If an object reference does not have an IOR, then create_ior should
just
do the implicit activation like so many other operations
(e.g. object_to_string
and marshalling already do this).  


>>2. Rather than specify the profile tag via a
>>TaggedProfileFactory::factory_id attribute, I would instead specify
this
>>as a parameter to IORFactory::register_tagged_profile_factory() and
>>TaggedProfileFactory::create_tagged_profile(), as this would allow a
>>single factory implementation to be used to handle more than one
profile
>>tag. Similarly for component factories.
>
>Either way works. I think your proposal is slightly more flexible,
and
>perhaps more in keeping with the policy factory registration; the
>original proposal is simpler and avoids runtime checking of
ProfileId,
>and consequent mismatch handling. (I'm not suggesting errors are
>likely with either scheme - I'm sure an ORB can handle matching ids
to
>factories. In the original proposal I would expect an error to cause
a
>MARSHAL exception, I guess a revised proposal should specify an
exception).
>I'd be happy with whichever approach the RTF thinks most appropriate.
>


I'm happy with either approach as well.


>>
>>3. Surely the profiles and components in an IOR are immutable and
>>therefore the issue about whether an IOR or profile is modified
while
>>the profiles or components are being iterated over does need to be
>>considered?
>
>Did you mean "does need to be considered" or "doesn't need to be.."?
>
>Assuming the latter, I think the issue does need to be considered
>since these Profiles and TaggedComponents may be being made available
>during IOR creation. (the statement re the iterator next operations
>is where I think it is considered)


I agree with Eoghan: the IOR is immutable, and in fact, the components
and
profiles do not change, even during object reference creation (or
whenever
the object reference gets an IOR).  PI and ORT have both made it clear
that the structure of the IOR is established when the object adapter
is created.
Creating an IOR for an object reference amounts to setting the object
ID
in the object key(s) in the IOR.


Ken.

Subject: Re: Issue 5439 - processing TaggedComponents within an IOR 
To: Ken Cavanaugh <Ken.Cavanaugh@sun.com> 
Cc: corba-rtf@omg.org, eglynn@iona.com 
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001 
From: "Ann Dalton1" <ann_dalton@uk.ibm.com> 
Date: Thu, 27 Jun 2002 21:32:47 +0100 
X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a
|January 7, 2002) at 
 27/06/2002 21:33:18 



And a few more replies:


Ken Cavanaugh wrote:


>A few additional comments:
>
>>>
>>>1. Why does IORFactory::create_ior() require that the object be
>bound?
>>>Surely the underlying IOR can be manipulated independently of
>whether
>>>the object is  actually bound or not? (though of course if the
>object
>>>was created for example from a corbaloc, then if it not bound there
>is
>>>no opportunity for the target server to forward a more complete IOR
>>>containing a full set of tagged components, so the IOR may not in a
>>>sense be "complete").
>>
>>I guess it doesn't. I'm probably being over cautious here. The
>>statement
>>    "If create_ior is invoked when the object reference is not
>bound,
>>    standard system exception BAD_INV_ORDER with minor code n will
>be
>>    raised."
>>can be removed.
>>
>
>If an object reference does not have an IOR, then create_ior should
>just
>do the implicit activation like so many other operations (e.g.
object_to_string
>and marshalling already do this).


ok. Since this behaviour isn't specified for object_to_string (or, at
least,
I couldn't find it), I guess it isn't necessary to specify it here
either.


>
>>>2. Rather than specify the profile tag via a
>>>TaggedProfileFactory::factory_id attribute, I would instead specify
this
>>>as a parameter to IORFactory::register_tagged_profile_factory() and
>>>TaggedProfileFactory::create_tagged_profile(), as this would allow
a
>>>single factory implementation to be used to handle more than one
profile
>>>tag. Similarly for component factories.
>>
>>Either way works. I think your proposal is slightly more flexible,
and
>>perhaps more in keeping with the policy factory registration; the
>>original proposal is simpler and avoids runtime checking of
ProfileId,
>>and consequent mismatch handling. (I'm not suggesting errors are
>>likely with either scheme - I'm sure an ORB can handle matching ids
to
>>factories. In the original proposal I would expect an error to cause
a
>>MARSHAL exception, I guess a revised proposal should specify an
exception).
>>I'd be happy with whichever approach the RTF thinks most
appropriate.
>>
>
>I'm happy with either approach as well.
>
>>>
>>>3. Surely the profiles and components in an IOR are immutable and
>>>therefore the issue about whether an IOR or profile is modified
while
>>>the profiles or components are being iterated over does need to be
>>>considered?
>>
>>Did you mean "does need to be considered" or "doesn't need to be.."?
>>
>>Assuming the latter, I think the issue does need to be considered
>>since these Profiles and TaggedComponents may be being made
available
>>during IOR creation. (the statement re the iterator next operations
>>is where I think it is considered)
>
>I agree with Eoghan: the IOR is immutable, and in fact, the
components and
>profiles do not change, even during object reference creation (or
whenever
>the object reference gets an IOR).  PI and ORT have both made it
clear
>that the structure of the IOR is established when the object adapter
is
created.
>Creating an IOR for an object reference amounts to setting the object
ID
>in the object key(s) in the IOR.


I'm sorry, even if the IORInterceptors are only run at adapter
creation, I
don't understand how the Profile can be immutable at that time i.e
when
get_profiles is called on IORInfo, as that's when TaggedComponents are
added to it?


>
>Ken.


Ann

Sender: jbiggar@Resonate.com 
Date: Thu, 27 Jun 2002 14:10:06 -0700 
From: Jonathan Biggar <jon@floorboard.com> 
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) 
X-Accept-Language: en 
To: Ann Dalton1 <ann_dalton@uk.ibm.com> 
CC: Ken Cavanaugh <Ken.Cavanaugh@sun.com>, corba-rtf@omg.org,
eglynn@iona.com 
Subject: Re: Issue 5439 - processing TaggedComponents within an IOR 


Ann Dalton1 wrote:
> >>>1. Why does IORFactory::create_ior() require that the object be
bound?
> >>>Surely the underlying IOR can be manipulated independently of
whether
> >>>the object is  actually bound or not? (though of course if the
object
> >>>was created for example from a corbaloc, then if it not bound
there is
> >>>no opportunity for the target server to forward a more complete
IOR
> >>>containing a full set of tagged components, so the IOR may not in
a
> >>>sense be "complete").
> >>
> >>I guess it doesn't. I'm probably being over cautious here. The
> >>statement
> >>    "If create_ior is invoked when the object reference is not
bound,
> >>    standard system exception BAD_INV_ORDER with minor code n will
be
> >>    raised."
> >>can be removed.
> >>
> >
> >If an object reference does not have an IOR, then create_ior should
just
> >do the implicit activation like so many other operations (e.g.
> object_to_string
> >and marshalling already do this).
> 
> ok. Since this behaviour isn't specified for object_to_string (or,
at
> least,
> I couldn't find it), I guess it isn't necessary to specify it here
either.


Can we be careful we are not mixing up object activation and binding? 
The former is a server side activity, and the latter is a client side
activity.  On the client side, if you have a reference, you
theoretically have the IOR available, whether or not the reference is
bound or not.


-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org



Date: Fri, 28 Jun 2002 12:18:24 +0100 
From: eglynn@iona.com 
Organization: IONA Technologies 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 
X-Accept-Language: en-us 
To: Ann Dalton1 <ann_dalton@uk.ibm.com> 
CC: corba-rtf@omg.org 
Subject: Re: Issue 5439 - processing TaggedComponents within an IOR 
X-OriginalArrivalTime: 28 Jun 2002 11:18:06.0071 (UTC)
FILETIME=[79B5C070:01C21E95] 



Comments inline ...


Ann Dalton1 wrote:


1. Why does IORFactory::create_ior() require that the object be bound?
Surely the underlying IOR can be manipulated independently of whether
the object is  actually bound or not? (though of course if the object
was created for example from a corbaloc, then if it not bound there is
no opportunity for the target server to forward a more complete IOR
containing a full set of tagged components, so the IOR may not in a
sense be "complete").


I guess it doesn't. I'm probably being over cautious here. The
statement
    "If create_ior is invoked when the object reference is not bound,
    standard system exception BAD_INV_ORDER with minor code n will be
    raised."
can be removed.



OK. The issue of whether the object reference is bound, or indeed
whether the target object is activated, should be orthogonal to the
issue of processing the IOR. I think it would be a good idea to name
the operation get_ior(), rather than create_ior(), as a pre-existing
IOR may well be returned.



2. Rather than specify the profile tag via a
TaggedProfileFactory::factory_id attribute, I would instead specify
this
as a parameter to IORFactory::register_tagged_profile_factory() and
TaggedProfileFactory::create_tagged_profile(), as this would allow a
single factory implementation to be used to handle more than one
profile
tag. Similarly for component factories.


Either way works. I think your proposal is slightly more flexible, and
perhaps more in keeping with the policy factory registration; the
original proposal is simpler and avoids runtime checking of ProfileId,
and consequent mismatch handling. (I'm not suggesting errors are
likely with either scheme - I'm sure an ORB can handle matching ids to
factories. In the original proposal I would expect an error to cause a
MARSHAL exception, I guess a revised proposal should specify an
exception).
I'd be happy with whichever approach the RTF thinks most appropriate.



OK.


3. Surely the profiles and components in an IOR are immutable and
therefore the issue about whether an IOR or profile is modified while
the profiles or components are being iterated over does need to be
considered?


Did you mean "does need to be considered" or "doesn't need to be.."?



I meant "doesn't need to be ..."



Assuming the latter, I think the issue does need to be considered
since these Profiles and TaggedComponents may be being made available
during IOR creation. (the statement re the iterator next operations
is where I think it is considered)



The profiles of an IOR or the components of a profile cannot be
iterated over until after the IOR or profile is created. Once created
the IOR and profile should be considered immutable, so the set being
iterated over cannot change during the iteration. Hence I don't think
this issue needs to be considered in the description of the iterators.



4. Shouldn't the IIOPProfileTemplate interface provide an operation to
allow it to be instantiated as an IIOPProfile by providing an object
key?


Is this for completeness, or do you have a scenario in mind?



For completeness I guess. Most scenarios where a profile would need to
be created from a profile template are probably internal to the ORB
and don't need to be exposed via these interfaces.



5. I think you should allow ORB implementations to impose constraints
   on
the semantics of profile and component factories - for example
   requiring
that all profile or components created are flyweighted (i.e. only one
instance of a particular profile or component is created by the
   factory
during its lifetime - if a profile or component containing the same
   data
is request more than once, the same profile or component instance is
returned). Towards this end, I think it would be better to rename the
create_* operations as get_* to avoid the implication that a new
   profile
or component is created.


I'm not particularly concerned about the name but, since the factories
are being asked to return a Profile or Component based on the supplied
input data, it seems that create is generally more appropriate than
get. If an implementation chooses not to impose such a constraint,
then
get_* seems inappropriate.



Well get_*() leaves the issue open as to whether a new or pre-existing
object is returns. create_*() implies the former is the case.



6. What about the other common profile and component types (e.g.
multi-component profiles, codsets components etc...). Surely there
should be profile- or component-specific sub-interfaces defined for
these types also?


As discussed in the Java RTF, I think it is more important to have an
extensible framework than to define every possible profile or
component.
I think it's necessary to give ORB based products a mechanism to
handle
profiles and components that are specific to them, and to define those
profiles and tagged components that are owned and created by the ORB
but need to be accessed by other products. In the problem I'm
currently
trying to address (the needs of J2EE implementations), the IIOPProfile
is the only one I know to be in that category. I would prefer not to
define APIs for profiles and components that are purely internal to
the
ORB, and to defer definitions of those for which there is no known
requirement to subsequent issues, when the requirement is known and
any particulars of it can be addressed.
I can see that this could be the case for the multi-component profile.
Would the following do what you need?
  local interface MultipleComponentProfile:TaggedProfile {
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
  };
21.5.3.11 MultipleComponentProfile Interface
   get_components
   Return an iterator over the TaggedComponents within the
   MultipleComponentProfile.
   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.
and replace section 21.5.3 paragraph 5 with
   An ORB will provide TaggedProfileFactory implementations for the
   IIOPProfile and MultipleComponentProfile.



OK.


Is it necessary to define the codesets component? I had thought it
was purely of internal ORB interest.


Its hard to second guess what standard components an app may be
interested in. For example a logging mechanism may be interested in
recording the codesets advertized in various IORs. A management
infrastructure might be interested in reporting failover address in
TAG_ALTERNATE_IIOP_ADDRESS components, etc, etc ...


Then you also have the issue of standard v. proprietary profile and
component types and the purpose of exposing the profile and component
factory interfaces. Surely this purpose is so that the ORB may use the
factory to create a type-specific profile or component, but *not* so
that the application may assume this responsibility for standard
profile or components. So shouldn't it be noted that the ORB will
provide factories for all the standard profile and component types it
supports (not just for IIOP/MC profiles as per your proposal), and
also for any ORB-specific proprietary profile and component types it
provides. An application would generally only register factories for
application-specific profile or component types. Obviously
BAD_INV_ORDER  would be thrown if an app tries to do otherwise, but it
would be as well to note this explicitly IMO.


Cheers,
Eoghan.



-- 


Eoghan Glynn, Principal Engineer, IONA Technologies.


"END 2 ANYWHERE"                 http://www.iona.com
The IONA Building                mailto:eglynn@iona.com
Shelbourne Road                  tel :+353-1-6372439
Ballsbridge                      cell:+353-86-8175024
Dublin 4
Ireland

Subject: Re: Issue 5439 - processing TaggedComponents within an IOR 
To: eglynn@iona.com 
Cc: corba-rtf@omg.org 
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001 
From: "Ann Dalton1" <ann_dalton@uk.ibm.com> 
Date: Tue, 2 Jul 2002 17:13:01 +0100 
X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a
|January 7, 2002) at 
 02/07/2002 17:12:34 



again, inline....


Eoghan Glynn wrote:
>
>Comments inline ...
>
>Ann Dalton1 wrote:
>
>>Eoghan Glynn wrote:
>>>
>>>1. Why does IORFactory::create_ior() require that the object be
bound?
>>>Surely the underlying IOR can be manipulated independently of
whether
>>>the object is  actually bound or not? (though of course if the
object
>>>was created for example from a corbaloc, then if it not bound there
is
>>>no opportunity for the target server to forward a more complete IOR
>>>containing a full set of tagged components, so the IOR may not in a
>>>sense be "complete").
>>>
>>
>> I guess it doesn't. I'm probably being over cautious here. The
>> statement
>>     "If create_ior is invoked when the object reference is not
bound,
>>     standard system exception BAD_INV_ORDER with minor code n will
be
>>     raised."
>> can be removed.
>
>
>OK. The issue of whether the object reference is bound, or indeed
>whether the target object is activated, should be orthogonal to the
>issue of processing the IOR. I think it would be a good idea to name
the
>operation get_ior(), rather than create_ior(), as a pre-existing IOR
may
>well be returned.
>


OK. get_ior is fine by me.


>
>>>2. Rather than specify the profile tag via a
>>>TaggedProfileFactory::factory_id attribute, I would instead specify
this
>>>as a parameter to IORFactory::register_tagged_profile_factory() and
>>>TaggedProfileFactory::create_tagged_profile(), as this would allow
a
>>>single factory implementation to be used to handle more than one
profile
>>>tag. Similarly for component factories.
>>>
>>
>> Either way works. I think your proposal is slightly more flexible,
and
>> perhaps more in keeping with the policy factory registration; the
>> original proposal is simpler and avoids runtime checking of
ProfileId,
>> and consequent mismatch handling. (I'm not suggesting errors are
>> likely with either scheme - I'm sure an ORB can handle matching ids
to
>> factories. In the original proposal I would expect an error to
cause a
>> MARSHAL exception, I guess a revised proposal should specify an
exception).
>> I'd be happy with whichever approach the RTF thinks most
appropriate.
>
>
>OK.


Not sure how we decide this. Does anyone else have a view?


>
>>>3. Surely the profiles and components in an IOR are immutable and
>>>therefore the issue about whether an IOR or profile is modified
while
>>>the profiles or components are being iterated over does need to be
>>>considered?
>>>
>>
>> Did you mean "does need to be considered" or "doesn't need to
be.."?
>
>
>I meant "doesn't need to be ..."
>
>
>> Assuming the latter, I think the issue does need to be considered
>> since these Profiles and TaggedComponents may be being made
available
>> during IOR creation. (the statement re the iterator next operations
>> is where I think it is considered)
>
>
>The profiles of an IOR or the components of a profile cannot be
iterated
>over until after the IOR or profile is created. Once created the IOR
and
>profile should be considered immutable, so the set being iterated
over
>cannot change during the iteration. Hence I don't think this issue
needs
>to be considered in the description of the iterators.
>


I agree that the problem doesn't arise when the IOR getProfiles
operation
is used, but I don't understand how the Profile can be immutable when
the
IORInfo version is used during IOR creation, as that's when
TaggedComponents
may be added to it?


>
>>>4. Shouldn't the IIOPProfileTemplate interface provide an operation
to
>>>allow it to be instantiated as an IIOPProfile by providing an
object
key?
>>>
>>
>> Is this for completeness, or do you have a scenario in mind?
>
>
>For completeness I guess. Most scenarios where a profile would need
to
>be created from a profile template are probably internal to the ORB
and
>don't need to be exposed via these interfaces.


I had thought so, but we could add
      IIOPProfile create_profile(in CORBA::OctetSeq  object_key);


to the IIOPProfileTemplate interface if you like? With the following
description in section 21.5.3.10


   create_profile
   Create an IIOPProfile from this template and the given object_key.


I'll continue to think about whether any similar operations are
required
for the other interfaces. Any thoughts?


>
>>>5. I think you should allow ORB implementations to impose
constraints on
>>>the semantics of profile and component factories - for example
requiring
>>>that all profile or components created are flyweighted (i.e. only
one
>>>instance of a particular profile or component is created by the
factory
>>>during its lifetime - if a profile or component containing the same
data
>>>is request more than once, the same profile or component instance
is
>>>returned). Towards this end, I think it would be better to rename
the
>>>create_* operations as get_* to avoid the implication that a new
profile
>>>or component is created.
>>>
>>
>> I'm not particularly concerned about the name but, since the
factories
>> are being asked to return a Profile or Component based on the
supplied
>> input data, it seems that create is generally more appropriate than
>> get. If an implementation chooses not to impose such a constraint,
then
>> get_* seems inappropriate.
>
>
>Well get_*() leaves the issue open as to whether a new or
pre-existing
>object is returns. create_*() implies the former is the case.


Having said I'm not particularly concerned, I'm not sure get_* leaves
the
issue any more open than create_*. get_* implies that a pre-existing
object
will be returned if available. create_* seems more natural for a
method
where the input data completely defines the result.


Again, does anyone else have a view?


>
>>>6. What about the other common profile and component types (e.g.
>>>multi-component profiles, codsets components etc...). Surely there
>>>should be profile- or component-specific sub-interfaces defined for
>>>these types also?
>>>
>>
>> As discussed in the Java RTF, I think it is more important to have
an
>> extensible framework than to define every possible profile or
component.
>> I think it's necessary to give ORB based products a mechanism to
handle
>> profiles and components that are specific to them, and to define
those
>> profiles and tagged components that are owned and created by the
ORB
>> but need to be accessed by other products. In the problem I'm
currently
>> trying to address (the needs of J2EE implementations), the
IIOPProfile
>> is the only one I know to be in that category. I would prefer not
to
>> define APIs for profiles and components that are purely internal to
the
>> ORB, and to defer definitions of those for which there is no known
>> requirement to subsequent issues, when the requirement is known and
>> any particulars of it can be addressed.
>>
>> I can see that this could be the case for the multi-component
profile.
>> Would the following do what you need?
>>
>>   local interface MultipleComponentProfile:TaggedProfile {
>>       ComponentIterator get_components();
>>       ComponentIterator get_components_by_id (in IOP::ComponentId
id);
>>   };
>>
>> 21.5.3.11 MultipleComponentProfile Interface
>>
>>    get_components
>>    Return an iterator over the TaggedComponents within the
>>    MultipleComponentProfile.
>>
>>    get_components_by_id
>>    Returns an iterator over the TaggedComponents with the given
>>    ComponentId.
>>
>> and replace section 21.5.3 paragraph 5 with
>>    An ORB will provide TaggedProfileFactory implementations for the
>>    IIOPProfile and MultipleComponentProfile.
>
>
>OK.
>
>> Is it necessary to define the codesets component? I had thought it
>> was purely of internal ORB interest.
>
>Its hard to second guess what standard components an app may be
>interested in. For example a logging mechanism may be interested in
>recording the codesets advertized in various IORs. A management
>infrastructure might be interested in reporting failover address in
>TAG_ALTERNATE_IIOP_ADDRESS components, etc, etc ...
>
>Then you also have the issue of standard v. proprietary profile and
>component types and the purpose of exposing the profile and component
>factory interfaces. Surely this purpose is so that the ORB may use
the
>factory to create a type-specific profile or component, but *not* so
>that the application may assume this responsibility for standard
profile
>or components.


Agreed.


>So shouldn't it be noted that the ORB will provide
>factories for all the standard profile and component types it
>supports
>(not just for IIOP/MC profiles as per your proposal), and also for
>any
>ORB-specific proprietary profile and component types it provides. An
>application would generally only register factories for
>application-specific profile or component types. Obviously
>BAD_INV_ORDER
>  would be thrown if an app tries to do otherwise, but it would be as
>well to note this explicitly IMO.
>


I'd be happy to replace the statement re IIOP/MC profiles with the
following:-
   An ORB will provide factories for all the standard profile and
   component types it supports, and also for any ORB-specific
   proprietary profile and component types it provides.


It is then up to the ORB whether it relies on the default, generic
implementations or something more specific.



>Cheers,
>Eoghan.

Date: Wed, 03 Jul 2002 14:01:30 +0100 
From: eglynn@iona.com 
Organization: IONA Technologies 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 
X-Accept-Language: en-us 
To: Ann Dalton1 <ann_dalton@uk.ibm.com> 
CC: corba-rtf@omg.org 
Subject: Re: Issue 5439 - processing TaggedComponents within an IOR 
X-OriginalArrivalTime: 03 Jul 2002 13:00:56.0896 (UTC)
FILETIME=[ABDFAC00:01C22291] 



Ann Dalton1 wrote:



The profiles of an IOR or the components of a profile cannot be
iterated
over until after the IOR or profile is created. Once created the IOR
and
profile should be considered immutable, so the set being iterated over
cannot change during the iteration. Hence I don't think this issue
needs
to be considered in the description of the iterators.
I agree that the problem doesn't arise when the IOR getProfiles
operation
is used, but I don't understand how the Profile can be immutable when
the
IORInfo version is used during IOR creation, as that's when
TaggedComponents
may be added to it?



Well its clear if you take the view that neither the IOR nor its
constituent profiles have actually been created until the completion
of the "assembly phase" for the IOR or "IOR template". This phase may
involve internal ORB components such as transports as well as
application-provided IORInterceptors. During this phase the ORB
assembles profile and component data, but doesn't have to actually
instantiate any profiles - rather it may simply collect the data from
the various paritipants in the assembly process. So the sequence of
components in a profile could be fixed when the profile is created,
allowing it to be immutable. Similiarly with the sequence of profiles
constituting an IOR.


Cheers,
Eoghan




-- 


Eoghan Glynn, Principal Engineer, IONA Technologies.


"END 2 ANYWHERE"                 http://www.iona.com
The IONA Building                mailto:eglynn@iona.com
Shelbourne Road                  tel :+353-1-6372439
Ballsbridge                      cell:+353-86-8175024
Dublin 4
Ireland


Date: Fri, 09 Aug 2002 17:08:31 -0400 
From: Jishnu Mukerji <jishnu_mukerji@hp.com> 
Organization: Hewlett-Packard 
X-Mailer: Mozilla 4.79 [en] (Win98; U) 
X-Accept-Language: en 
To: corba-rtf@omg.org 
Cc: Louise Moser <moser@alpha.ece.ucsb.edu>, 
   Ann Dalton <ann_dalton@uk.ibm.com> 
Subject: Time to get started again 


Folks,


We have 48 unresolved issues on the table. If you have any fovorites
that you'd like to see resolved, the best way is to point me to a
plausible resolution that I can followup upon and bring to vote ASAP.


Take a look at 


http://cgi.omg.org/pub/orbrev/drafts/corba_rtf-ytbr.html


for the current open issues. If the date on it is 8 July it is missing
issue 5467. I am arranging to update that file and should have the 9
August version in place before the day is out.


I have two specific question (for now). I am CC-ing Louise Moser for
the
second one:


1) Ann Dalton had been shepherding Issue 5439 "Processing
TaggedComponents within an IOR
http://cgi.omg.org/issues/issue5439.txt . Is this one pretty ready to
go? If so could Ann or someone else please put together a final
proposed
resolution taking into consoderation all the email discussion, and
then
we can put it to vote?


Subject: Re: Issue 5439 - processing TaggedComponents within an IOR 
To: Jishnu Mukerji <jishnu_mukerji@hp.com> 
Cc: corba-rtf@omg.org 
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001 
From: "Ann Dalton1" <ann_dalton@uk.ibm.com> 
Date: Mon, 19 Aug 2002 13:47:57 +0100 
X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a
|January 7, 2002) at 
 19/08/2002 13:47:55 



Jishnu,


I think we're almost ready for a final proposal, see below, but there
were a couple of issues from Eoghan we failed to resolve (see archive
for full details). Currently they are left unchanged pending any
comments from other RTF members:-


> 1. Rather than specify the profile tag via a
> TaggedProfileFactory::factory_id attribute, should it be specified
as
> a parameter to IORFactory::register_tagged_profile_factory() and
> TaggedProfileFactory::create_tagged_profile()?
I think it's simpler and requires less runtime checking to leave as
proposed, but either would be ok.


> 2. The profiles and components in an IOR are immutable and therefore
     the
> issue about whether an IOR or profile is modified while the profiles
     or
> components are being iterated over doesn't need to be considered?
I think the issue does need to be considered since these Profiles and
TaggedComponents may be being made available during IOR creation when
the IORInfo version is used.


> 3. It would be better to rename the TaggedComponent and Profile
     Factory
> create_* operations as get_* to avoid the implication that a new
> profile or component is created.
The issue is whether one or the other is more flexible re allowing or
requiring a pre-existing object is returned. I prefer create and
Eoghan prefers get, but either would be ok.


Thanks,
Ann



==========================================================================
Revised Proposal:


- add the following sections after the IOR Interceptor Overview:-



21.5.2 An Abstract Model for IORs


To support efficient access to IORs, avoiding repeated marshaling and
demarshaling of IOR components, it is helpful to have an abstract
model
of the, ORB specific, local representation of an IOR.


Recognising that many of the constituent parts of IOR profiles are
identical for different objects allows the following model to be
defined:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object ID.
   - an IIOPProfileTemplate has IIOP addressing information, and
   contains
     TaggedComponents.
   - a TaggedComponent has an ID and data
   - a TaggedComponentFactory creates a TaggedComponent
   - a TaggedProfileFactory creates a TaggedProfile



21.5.3 Local IOR Interfaces


The following interfaces provide access to the data within a local IOR
using this model.


TaggedProfile and TaggedComponent are generic interfaces. Users of the
ORB
may create implementations of them. Corresponding factories may be
registered with the IORFactory. The IORFactory is obtained through a
call
to ORB::resolve_initial_references ("IORFactory") and may also be used
to
obtain an IOR for an Object.


An ORB must return all tagged profiles in an IOR through the IOR
getProfiles operations. The ProfileIterator interface allows a client
to iterate through the TaggedProfiles using the next operation.
Those profiles whose ids have a registered TaggedProfileFactory will
be made available in the form returned by the registered factory's
TaggedProfileFactory create operation, which must return a subtype of
TaggedProfile.


Profiles with ids for which no TaggedProfileFactory has been
registered
will be made available as instances of a generic ORB implementation of
TaggedProfile.



Similarly, an ORB must return all tagged components in an IIOP profile
through the IIOPProfile().getTemplate().getComponents() operations.
The ComponentIterator interface allows a client to iterate through the
TaggedComponents using the next operation.
Those components whose ids have a registered TaggedComponentFactory
will be made available in the form returned by the registered
factory's
TaggedComponentFactory create operation, which must return a subtype
of
TaggedComponent.
Components with ids for which no TaggedComponentFactory has been
registered will be made available as instances of a generic ORB
implementation of TaggedComponent.


An ORB will provide factories for all the standard profile and
component types it supports, and also for any ORB-specific proprietary
profile and component types it provides.




module PortableInterceptor {


  local interface TaggedComponent {
      readonly attribute IOP::ComponentId component_id;
      readonly attribute CORBA::OctetSeq component_data;
      IOP::TaggedComponent convert();
  };


  local interface ComponentIterator {
      TaggedComponent next();
      boolean has_next();
  };


  local interface TaggedProfile {
      readonly attribute IOP::ProfileId profile_id;
      readonly attribute CORBA::OctetSeq profile_data;
      IOP::TaggedProfile convert();
  };


  local interface ProfileIterator {
      TaggedProfile next();
      boolean has_next();
  };


  local interface IOR {
      readonly attribute string type_id;
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId
      profile_id);
  };


  local interface IIOPProfile;                  // Forward declaration


  local interface IIOPProfileTemplate {
      readonly attribute IIOP::Version iiop_version;
      readonly attribute string host;
      readonly attribute unsigned short port;
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
      IIOPProfile create_profile(in CORBA::OctetSeq  object_key);
  };


  local interface IIOPProfile:TaggedProfile {
      readonly attribute CORBA::OctetSeq  object_key;
      readonly attribute IIOPProfileTemplate profile_template;
  };


  local interface MultipleComponentProfile:TaggedProfile {
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
  };


  local interface TaggedComponentFactory {


      readonly attribute IOP::ComponentId factory_id;
      TaggedComponent create_tagged_component
         (in CORBA::OctetSeq component_data);
  };


  local interface TaggedProfileFactory {


      readonly attribute IOP::ProfileId factory_id;
      TaggedProfile create_tagged_profile
         (in CORBA::OctetSeq profile_data);
  };


  local interface IORFactory {


    IOR  get_ior (in Object obj);
    void register_tagged_profile_factory
       (in TaggedProfileFactory tpf);
    void register_tagged_component_factory
       (in TaggedComponentFactory tcf);
  };


};



21.5.3.1 IOR Factory Interface


   get_ior
   Return an IOR relating to the given Object.


   register_tagged_profile_factory
   Register a TaggedProfileFactory to create TaggedProfiles with the
   id
   returned by the given factory's getId method. If a
   TaggedProfileFactory
   already exists for the given id, standard system exception
   BAD_INV_ORDER is raised with a standard minor code of n+1.
   Instances of this interface may be defined by users to support
   custom
   tagged profiles.


   register_tagged_component_factory
   Register a TaggedComponentFactory to read TaggedComponents with the
   id
   returned by the given factory's getId method. If a
   TaggedComponentFactory already exists for the given id, standard
   system
   exception BAD_INV_ORDER is raised with a standard minor code of
   n+2.
   Instances of this interface may be defined by users to support
   custom
   tagged components.


21.5.3.2 IOR Interface


   This interface gives access to a local representation of an
   IOP::IOR.


   type_id
   The type id string from the IOR.


   get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


   get_profiles_by_id
   Returns an iterator over the TaggedProfiles with the given
   Profileid.



21.5.3.3 TaggedProfile Interface


   This interface gives access to a local representation of an
   IOP::TaggedProfile.


   profile_id
   This attribute is the identifier for this TaggedProfile.


   profile_data
   This attribute is the data from the TaggedProfile. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedProfile


21.5.3.4 TaggedComponent Interface


   This interface gives access to a local representation of an
   IOP::TaggedComponent.


   component_id
   This attribute is the identifier for this TaggedComponent.


   component_data
   This attribute is the data from the TaggedComponent. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedComponent.


21.5.3.5 TaggedProfileFactory Interface


   factory_id
   This attribute is the identifier of profiles created by this
   TaggedProfileFactory.


   create
   Create a TaggedProfile from the given profile_data.


21.5.3.6 TaggedComponentFactory Interface


   factory_id
   This attribute is the identifier of components created by this
   TaggedComponentFactory.


   create
   Create a TaggedComponent from the given component_data.


21.5.3.7 ProfileIterator Interface


   next
   Returns the next TaggedProfile in the iteration. If next is called
   after the last TaggedProfile has been returned, BAD_INV_ORDER will
   be raised with a standard minor code of n+3.


   If an IOR is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.8 ComponentIterator Interface


   next
   Returns the next TaggedComponent in the iteration. If next is
   called
   after the last TaggedComponent has been returned, BAD_INV_ORDER
   will
   be raised with a standard minor code of n+3.


   If a profile is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.9 IIOPProfile Interface


   object_key
   This attribute is the Object key contained in this IIOPProfile.


   profile_template
   This attribute is the IIOPProfileTemplate associated with this
   IIOPProfile.



21.5.3.10 IIOPProfileTemplate Interface


   iiop_version
   This attribute is the GIOP version of this profile. If the major
   value is 1 and the minor value is 0, this profile cannot contain
   any TaggedComponents.


   host
   This attribute is the host name string of this IIOPProfileTemplate.


   port
   This attribute is the port number of this IIOPProfileTemplate.


   get_components
   Return an iterator over the TaggedComponents within the
   IIOPProfileTemplate.


   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.


   create_profile
   Create an IIOPProfile from this template and the given object_key.



21.5.3.11 MultipleComponentProfile Interface


   get_components
   Return an iterator over the TaggedComponents within the
   MultipleComponentProfile.


   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.



In current Section 21.5.3:
- add the following after the ORBInfo Interface


  local interface IORInfo_3_n:IORInfo {
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId
      profile_id);
  };



- add the following sections:


21.5.3.4  get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


21.5.3.5  get_profiles_by_id
   Returns an iterator over the TaggedProfiles within the IOR with the
   given Profileid.


   Parameter   Description
   profile_id  The IOP::ProfileId of the profiles in the iteration
               to be returned.



- add the IORFactory to the list of reserved ObjectIds for
  resolve_initial_references in section 4.5.2



Sender: jbiggar@Resonate.com 
Date: Wed, 23 Oct 2002 13:20:40 -0700 
From: Jonathan Biggar <jon@floorboard.com> 
X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) 
X-Accept-Language: en 
To: corba-rtf@omg.org 
Subject: Re: Question about 5439 


Jishnu Mukerji wrote:
> 
> I need your exper opinion. The proposed resolution for 5439 which
> appears near the end of the archive
> http://cgi.omg.org/issues/issue5439.txt appears all seet to be voted
on.
> Does this in any way overlap with some of the recently adopted
> specifications as in Protocol Framework and the GIOP/SCTP
> specifications? If not I am happy to put this up for vote modulo one
> comment. Since this is a significant new addition, I'd prefer to see
it
> added in a new module of its own. It just makes housekeeping
somewhat
> easier.
> 
> Comments? Thoughts?


When rereviewing this proposal, I wondered whether local objects or
valuetypes were the right data abstraction to use here.  If the data
was
expressed using valuetypes, then it can automatically be passed from
one
process to another without conversion into the IOP:: form.  This might
be useful, for example, for communication between a server and the
Implementation Repository.


-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org


Date: Wed, 27 Nov 2002 16:54:38 -0500 
From: Jishnu Mukerji <jishnu@hp.com> 
Organization: Software Global Business Unit, Hewlett-Packard 
X-Mailer: Mozilla 4.79 [en] (Win98; U) 
X-Accept-Language: en 
To: CORBA Core RTF <corba-rtf@omg.org> 
Subject: Proposed resolution for Issue 5439 


This issue has been discussed to death. Since there is a complete
proposal on the table I am obliged to put it up for a vote, unless
someone has a showstopping technical problem with it. So unless we
hear
of such, this will appear in a vote in the near future.


Jishnu.
____________________________________________________________________



Issue 5439: processing TaggedComponents within an IOR (corba-rtf) 
(Interop New)


Click http://cgi.omg.org/issues/issue5439.txt for this issue's
archive.
Source: International Business Machines (Ms. Anne E. Dalton,
ann_dalton@uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
The overhead of processing TaggedComponents within an IOR becomes
significant when done many times, as in the case of J2EE
implementations where multiple interceptors are used.


 . . . see archive for details  . . . . 


Resolution: This has been discussed for quite a while. See discussion
above and in archive for justification. Make the 
following changes


Revised Text:
In formal/02-06-01 make the following changes:


1. Add the following sections after the IOR Interceptor Overview:-


21.5.2 An Abstract Model for IORs


To support efficient access to IORs, avoiding repeated marshaling and
demarshaling of IOR components, it is helpful to have an abstract
model of the, ORB specific, local representation of an IOR.


Recognising that many of the constituent parts of IOR profiles are
identical for different objects allows the following model to be
defined:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object ID.
   - an IIOPProfileTemplate has IIOP addressing information, and
   contains
     TaggedComponents.
   - a TaggedComponent has an ID and data
   - a TaggedComponentFactory creates a TaggedComponent
   - a TaggedProfileFactory creates a TaggedProfile


21.5.3 Local IOR Interfaces


The following interfaces provide access to the data within a local IOR
using this model.


TaggedProfile and TaggedComponent are generic interfaces. Users of the
ORB may create implementations of them. Corresponding factories may be
registered with the IORFactory. The IORFactory is obtained through a
call to ORB::resolve_initial_references ("IORFactory") and may also be
used
to obtain an IOR for an Object.


An ORB must return all tagged profiles in an IOR through the IOR
getProfiles operations. The ProfileIterator interface allows a client
to iterate through the TaggedProfiles using the next operation.
Those profiles whose ids have a registered TaggedProfileFactory will
be made available in the form returned by the registered factory's
TaggedProfileFactory create operation, which must return a subtype of
TaggedProfile.


Profiles with ids for which no TaggedProfileFactory has been
registered will be made available as instances of a generic ORB
implementation of
TaggedProfile.


Similarly, an ORB must return all tagged components in an IIOP profile
through the IIOPProfile().getTemplate().getComponents() operations.
The ComponentIterator interface allows a client to iterate through the
TaggedComponents using the next operation.
Those components whose ids have a registered TaggedComponentFactory
will be made available in the form returned by the registered
factory's TaggedComponentFactory create operation, which must return a
subtype
of TaggedComponent. Components with ids for which no
TaggedComponentFactory has been registered will be made available as
instances of a generic ORB implementation of TaggedComponent.


An ORB will provide factories for shall the standard profile and
component types it supports, and also for any ORB-specific proprietary
profile and component types it provides.


module PortableInterceptor {


  local interface TaggedComponent {
      readonly attribute IOP::ComponentId component_id;
      readonly attribute CORBA::OctetSeq component_data;
      IOP::TaggedComponent convert();
  };


  local interface ComponentIterator {
      TaggedComponent next();
      boolean has_next();
  };


  local interface TaggedProfile {
      readonly attribute IOP::ProfileId profile_id;
      readonly attribute CORBA::OctetSeq profile_data;
      IOP::TaggedProfile convert();
  };


  local interface ProfileIterator {
      TaggedProfile next();
      boolean has_next();
  };


  local interface IOR {
      readonly attribute string type_id;
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId
      profile_id);
  };


  local interface IIOPProfile;                  // Forward declaration


  local interface IIOPProfileTemplate {
      readonly attribute IIOP::Version iiop_version;
      readonly attribute string host;
      readonly attribute unsigned short port;
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
      IIOPProfile create_profile(in CORBA::OctetSeq  object_key);
  };


  local interface IIOPProfile:TaggedProfile {
      readonly attribute CORBA::OctetSeq  object_key;
      readonly attribute IIOPProfileTemplate profile_template;
  };


  local interface MultipleComponentProfile:TaggedProfile {
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
  };


  local interface TaggedComponentFactory {


      readonly attribute IOP::ComponentId factory_id;
      TaggedComponent create_tagged_component
         (in CORBA::OctetSeq component_data);
  };


  local interface TaggedProfileFactory {


      readonly attribute IOP::ProfileId factory_id;
      TaggedProfile create_tagged_profile
         (in CORBA::OctetSeq profile_data);
  };


  local interface IORFactory {


    IOR  get_ior (in Object obj);
    void register_tagged_profile_factory
       (in TaggedProfileFactory tpf);
    void register_tagged_component_factory
       (in TaggedComponentFactory tcf);
  };
};



21.5.3.1 IOR Factory Interface


   get_ior
   Return an IOR relating to the given Object.


   register_tagged_profile_factory
   Register a TaggedProfileFactory to create TaggedProfiles with the
   id returned by the given factory's getId method. If a
   TaggedProfileFactory already exists for the given id, standard 
   system exception BAD_INV_ORDER is raised with a standard 
   minor code of n+1. Instances of this interface may be defined by 
   users to support custom tagged profiles.


   register_tagged_component_factory
   Register a TaggedComponentFactory to read TaggedComponents with the
   id returned by the given factory's getId method. If a
   TaggedComponentFactory already exists for the given id, standard
   system exception BAD_INV_ORDER is raised with a standard minor 
   code of n+2. Instances of this interface may be defined by users to
support
   custom tagged components.


21.5.3.2 IOR Interface


   This interface gives access to a local representation of an
   IOP::IOR.


   type_id
   The type id string from the IOR.


   get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


   get_profiles_by_id
   Returns an iterator over the TaggedProfiles with the given
   Profileid.


21.5.3.3 TaggedProfile Interface


   This interface gives access to a local representation of an
   IOP::TaggedProfile.


   profile_id
   This attribute is the identifier for this TaggedProfile.


   profile_data
   This attribute is the data from the TaggedProfile. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedProfile


21.5.3.4 TaggedComponent Interface


   This interface gives access to a local representation of an
   IOP::TaggedComponent.


   component_id
   This attribute is the identifier for this TaggedComponent.


   component_data
   This attribute is the data from the TaggedComponent. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedComponent.


21.5.3.5 TaggedProfileFactory Interface


   factory_id
   This attribute is the identifier of profiles created by this
   TaggedProfileFactory.


   create
   Create a TaggedProfile from the given profile_data.


21.5.3.6 TaggedComponentFactory Interface


   factory_id
   This attribute is the identifier of components created by this
   TaggedComponentFactory.


   create
   Create a TaggedComponent from the given component_data.


21.5.3.7 ProfileIterator Interface


   next
   Returns the next TaggedProfile in the iteration. If next is called
   after the last TaggedProfile has been returned, BAD_INV_ORDER will
   be raised with a standard minor code of n+3.


   If an IOR is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.8 ComponentIterator Interface


   next
   Returns the next TaggedComponent in the iteration. If next is
   called after the last TaggedComponent has been returned,
BAD_INV_ORDER
   will be raised with a standard minor code of n+3.


   If a profile is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.9 IIOPProfile Interface


   object_key
   This attribute is the Object key contained in this IIOPProfile.


   profile_template
   This attribute is the IIOPProfileTemplate associated with this
   IIOPProfile.


21.5.3.10 IIOPProfileTemplate Interface


   iiop_version
   This attribute is the GIOP version of this profile. If the major
   value is 1 and the minor value is 0, this profile cannot contain
   any TaggedComponents.


   host
   This attribute is the host name string of this IIOPProfileTemplate.


   port
   This attribute is the port number of this IIOPProfileTemplate.


   get_components
   Return an iterator over the TaggedComponents within the
   IIOPProfileTemplate.


   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.


   create_profile
   Create an IIOPProfile from this template and the given object_key.


21.5.3.11 MultipleComponentProfile Interface


   get_components
   Return an iterator over the TaggedComponents within the
   MultipleComponentProfile.



   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.


In current Section 21.5.5:


2. add the following after the ORBInfo Interface


  local interface IORInfo_3_1:IORInfo {
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId
      profile_id);
  };


3. add the following sections:


21.5.5.4  get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


21.5.5.5  get_profiles_by_id
   Returns an iterator over the TaggedProfiles within the IOR with the
   given Profileid.


   Parameter   Description
   profile_id  The IOP::ProfileId of the profiles in the iteration
               to be returned.



4. add the IORFactory to the list of reserved ObjectIds for
  resolve_initial_references in section 4.5.2


Actions taken: Incorporate changes and close issue



From: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us> 
Subject: Re: CORBA Core RTF Vote 10 Announcement 
To: jishnu@hp.com (Jishnu Mukerji) 
Date: Mon, 9 Dec 2002 12:50:44 -0800 (PST) 
Cc: corba-rtf@omg.org (CORBA Core RTF) 
X-Mailer: ELM [version 2.5 PL2] 


ORCL votes as follows:
  YES to all except:


  ABSTAIN: 1139 - yes to jishnu's proposed editorial fixes


  NO: 5439 - seems to be too big a change w/o multiple vendor
  implementation
             experience


  jeff


'Jishnu Mukerji' writes:
> 
> Folks,
> 
> Vote 10 of the CORBA Core RTF is now available at:
> 
> http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote_10.html
> 
> It is due on December 9, so you have 6 days to vote on it. 
> 
> Please do vote early and vote often. As usual if you do vote often,
> only the last vote cast by you will count.
> 
> The following additional files have been posted too:
> 
> 1. Updated list of issues Yet To Be Resolved (YTBR) at
> 
> http://cgi.omg.org/pub/orbrev/drafts/corba_rtf-ytbr.html
> 
> 2. List of issues that have been resolved so far at
> 
> http://cgi.omg.org/pub/orbrev/drafts/corba_rtf_resolved2.html
> 
> 3. Final Results of vote 8
> 
> http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote8_results.html
> 
> 4. Preliminary Results of Vote 9 (record of votes received uptil 3pm
EST
> today)
> 
> http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote9_results.html
> 
> Remember, Vote 11 will go out on Thursday consisting of 4 issue
packet
> dealing with the addition of ORB accessor to Object.
> 
> Thanks for all your efforts, cooperation and indulgence,
> 
> Jishnu.
> -- 
> Jishnu Mukerji
> Senior Systems Architect        1001 Frontier Road, Suite 300
> Technology Office               Bridgewater NJ 08807, USA
> Software Global Business Unit   Tel: +1 908 243 8924
> Hewlett-Packard Company         Fax: +1 908 243 8850
>                                 mailto: jishnu@hp.com
> 



-- 
Jeff Mischkinsky                
jmischki@dcn.davis.ca.us        +1 530-758-9850
jeff.mischkinsky@oracle.com     +1 650-506-1975



Date: Mon, 09 Dec 2002 16:07:20 -0500 
From: Jishnu Mukerji <jishnu@hp.com> 
Organization: Software Global Business Unit, Hewlett-Packard 
X-Mailer: Mozilla 4.79 [en] (Win98; U) 
X-Accept-Language: en 
Cc: CORBA Core RTF <corba-rtf@omg.org> 
Subject: Re: CORBA Core RTF Vote 10 Announcement 




Tom Rutt wrote:
> 
> Jishnu Mukerji wrote:


> > > Also the following paragraph:
> > > > > > ORB may create implementations of them. Corresponding
factories may be
> > > registered with the IORFactory. The IORFactory is obtained
through a
> > > call to ORB::resolve_initial_references ("IORFactory") and may
also be used
> > > to obtain an IOR for an Object.
> > > > > > uses the > >
> > No.
> 
> Where else is this "generic interface" technique used in other CORBA
specs?


I don't know. What is a generic interface technique?:-/


Would it be better to say "TaggedProfile and TaggedComponent are
interfaces for which implementations may be provided in ORBs" or some
such?


BTW, there is one more slight problem with the resolution for 5439.
There is no item that describes the new minor codes that need to be
created.


So we will go for a re-vote on this one too with the things that are
fixable between now and Friday.


On my list (i.e. things that I can handle) so far are:


1. Clarification removing "generic technique".


2. Add item for specifying new minor codes for BAD_INV_ORDER.


Any other changes will need to behandled by the author of the proposal
(which ain't me) Ann Dalton, or anyone else that is more connected
with
the technical content of the proposal than me.


Bob Kukura wrote:
> 5439 - No - This kind of extension to the portable interceptors 
> specification may be too big a change for an RTF. Even if it isn't,
this 
> particular set of interfaces puts significant new contraints on ORB 
> implementations that do not seem to be justified, and our feedback
on 
> earlier proposals does not seem to have been incorporated.


That one nedds to be taken up with the author of the proposal, But,
Bob,
could you be a little more specific about which specific feedbacks
youa
re alluding to? I think that will help everyone else get a bearing on
the discussion.


Thanks,


Jishnu.



Subject: Re: Issue 5439 in CORBA Core RTF Vote 10 
To: tom@coastin.com 
Cc: CORBA Core RTF <corba-rtf@omg.org>, Jishnu Mukerji <jishnu@hp.com> 
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001 
From: "Ann Dalton1" <ann_dalton@uk.ibm.com> 
Date: Tue, 10 Dec 2002 13:30:40 +0000 
X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a
|January 7, 2002) at 
 10/12/2002 13:36:19 


Tom,
I've not much to add to responses already given by Jishnu and others,
but here is my attempt to answer your concerns. I'll incorporate this
and the other comments into a revised proposal.
Re timing, Jishnu, should I submit a draft revised proposal tomorrow?
Ann



Tom Rutt wrote:
>Issue 5439: processing TaggedComponents within an IOR  -  Fujitsu
Votes NO
>
>This seems like a lot to add in an RTF.
>
>The statement in the proposal for abstract model:
>
>"
>Recognising that many of the constituent parts of IOR profiles are
>identical for different objects allows the following model to be
>defined:-
>   - an IOR has a type ID string, and contains TaggedProfile
instances
>   - a TaggedProfile has an ID and data
>   - an IIOPProfile is a TaggedProfile; it is composed of an
>     IIOPProfileTemplate and an object ID.
>   - an IIOPProfileTemplate has IIOP addressing information, and
contains
>     TaggedComponents.
>
> "
>does not include the iiop version and it mistakenly calls the Object
Key
the
>Object ID.


The text didn't include the iiop version because this is introductory
material that attempts to describe the major components of the
model. The
IIOP version is included in the definition of the IIOPProfileTemplate
local interface in 21.5.3 below. I wouldn't want to necessarily
include
every data item as that might be both confusing and duplicative,
giving
the usual problems of maintaining the same information in multiple
places.
However version can be added, see revised text below.


I think it could be argued that, without any capitalisation, "object
ID"
is just a term for any object identifier but I agree it would be
better
to avoid any ambiguity and refer to it as an object_key.


>Also the "identical for different objects" could mean same syntax or
 same
>values.  It is not clear what the intent is for this.  The model
 seems
valid
>just for the common syntax and I do not see anything in the model
 which
>exploits two objects with common component values included in each of
them.
>
I intended "are identical for different objects" to mean same values
for different objects. If that's not clear, it could be reworded to
say "are common for different objects" or "have identical values for
different objects". Do you have a preference?


The provision of the IIOPProfileTemplate allows, but doesn't require,
an
ORB to allow multiple objects to share the information contained
therein.


So, would you prefer the following revised text:-


Recognising that many of the constituent parts of IOR profiles have
identical values for different objects allows the following model to
be
defined:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object_key.
   - an IIOPProfileTemplate has IIOP addressing and version
   information,
     contains TaggedComponents and may be referenced by more than one
     IIOPProfile.


>In the rationale section, the following also appears:
>"
>with corresponding IDL definitions that allow the language bindings
>to optimise conversion between transmission and internal IOR formats
>to provide a performant and natural interface for IOR access.
>"
>
>It is not clear whether there have to be different language binding
>optimizations for this, or are they automatically mapped, as local
>interfaces.


I believe the proposed interfaces, as automatically mapped to Java at
least, will enable ORBs to provide access to IORs with significantly
better performance than that available at present using codecs. I
wouldn't expect to introduce any language specific mapping for Java
or any other language, but I guess that would be up to the relevant
RTFs. The comment was merely to explain the purpose of introducing
such a model. Since it isn't part of the proposed spec change, I'm not
sure it helps to reword it.


>
>Also the following paragraph:
>"
>TaggedProfile and TaggedComponent are generic interfaces. Users of
>the
>ORB may create implementations of them. Corresponding factories may
>be
>registered with the IORFactory. The IORFactory is obtained through a
>call to ORB::resolve_initial_references ("IORFactory") and may also
>be
used
>to obtain an IOR for an Object.
>"
>
>uses the term "generic interface".  Is this a new concept?


I used the term "generic" merely in the sense of not "specific" i.e
they apply to any TaggedProfile or TaggedComponent. ORB users may
refer
to specific TaggedProfile/Component types by defining, and registering
a factory for, inheriting subtypes. Re Jishnu's suggestion, would
it be better to say
"TaggedProfile and TaggedComponent are interfaces for which
implementations
may be provided by ORBs and services. Corresponding....."


>
>I do not get the confidence that this is sufficiently thought out,
>especially for multiple programming language environments.  I would
>like
to
>see some demonstration that it works, especially the generic
>interface
>concept, but there is no FTF for an RTF.
>
>This seems too much for an RTF revision.  I would prefer an RFC or
>RFP on
>this focused topic.  That is Why I vote no on this proposed
>resolution.


I brought this to the OMG, initially as a Java issue then, when that
RTF
thought it more generally applicable, as a Core RTF issue, since it
seemed to me important that CORBA function required by a J2EE
implementation
be standardized and not merely added in a proprietary manner by
individual
JDK vendors. I thought CORBA extensions should be standardized by the
OMG
rather than added, with less consultation and review, by the JCP.
I hadn't thought this proposal was significantly larger than other
pieces
of work undertaken previously by the Core RTF.



Date: Tue, 10 Dec 2002 11:36:07 -0500 
From: Jishnu Mukerji <jishnu@hp.com> 
Organization: Software Global Business Unit, Hewlett-Packard 
X-Mailer: Mozilla 4.79 [en] (Win98; U) 
X-Accept-Language: en 
To: Ann Dalton1 <ann_dalton@uk.ibm.com> 
Cc: tom@coastin.com, CORBA Core RTF <corba-rtf@omg.org> 
Subject: Re: Issue 5439 in CORBA Core RTF Vote 10 




Ann Dalton1 wrote:
> 
> Tom,
> I've not much to add to responses already given by Jishnu and
others,
> but here is my attempt to answer your concerns. I'll incorporate
this
> and the other comments into a revised proposal.
> Re timing, Jishnu, should I submit a draft revised proposal
tomorrow?


Yes, that will be fine.


Thanks,


Jishnu.


Date: Tue, 10 Dec 2002 12:35:53 -0500 
From: Tom Rutt <tom@coastin.com> 
Reply-To: tom@coastin.com 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) 
X-Accept-Language: en 
To: Ann Dalton1 <ann_dalton@uk.ibm.com> 
CC: CORBA Core RTF <corba-rtf@omg.org>, Jishnu Mukerji <jishnu@hp.com> 
Subject: Re: Issue 5439 in CORBA Core RTF Vote 10 


Thanks for your response:


My comments are in line.


Ann Dalton1 wrote:


> Tom,
> I've not much to add to responses already given by Jishnu and
> others,
> but here is my attempt to answer your concerns. I'll incorporate
> this
> and the other comments into a revised proposal.
> Re timing, Jishnu, should I submit a draft revised proposal
> tomorrow?
> Ann
>
> Tom Rutt wrote:
> >Issue 5439: processing TaggedComponents within an IOR  -  Fujitsu
> Votes NO
> >
> >This seems like a lot to add in an RTF.
> >
> >The statement in the proposal for abstract model:
> >
> >"
> >Recognising that many of the constituent parts of IOR profiles are
> >identical for different objects allows the following model to be
> >defined:-
> >   - an IOR has a type ID string, and contains TaggedProfile
> instances
> >   - a TaggedProfile has an ID and data
> >   - an IIOPProfile is a TaggedProfile; it is composed of an
> >     IIOPProfileTemplate and an object ID.
> >   - an IIOPProfileTemplate has IIOP addressing information, and
> contains
> >     TaggedComponents.
> >
> > "
> >does not include the iiop version and it mistakenly calls the
> Object Key
> the
> >Object ID.
>
> The text didn't include the iiop version because this is
> introductory
> material that attempts to describe the major components of the
> model. The
> IIOP version is included in the definition of the
> IIOPProfileTemplate
> local interface in 21.5.3 below. I wouldn't want to necessarily
> include
> every data item as that might be both confusing and duplicative,
> giving
> the usual problems of maintaining the same information in multiple
> places.
> However version can be added, see revised text below.
>
> I think it could be argued that, without any capitalisation, "object
> ID"
> is just a term for any object identifier but I agree it would be
> better
> to avoid any ambiguity and refer to it as an object_key.


Jishnu proposed a simple fix to cover both of these.  I agree this is
editorial, but
important because some people only read the intro.


>
>
> >Also the "identical for different objects" could mean same syntax
>or same
> >values.  It is not clear what the intent is for this.  The model
>seems
> valid
> >just for the common syntax and I do not see anything in the model
>which
> >exploits two objects with common component values included in each
>of
> them.
> >
> I intended "are identical for different objects" to mean same values
> for different objects. If that's not clear, it could be reworded to
> say "are common for different objects" or "have identical values for
> different objects". Do you have a preference?
>
> The provision of the IIOPProfileTemplate allows, but doesn't
>require, an
> ORB to allow multiple objects to share the information contained
>therein.
>
> So, would you prefer the following revised text:-
>
> Recognising that many of the constituent parts of IOR profiles have
> identical values for different objects allows the following model to
>be
> defined:-
>    - an IOR has a type ID string, and contains TaggedProfile
>instances
>    - a TaggedProfile has an ID and data
>    - an IIOPProfile is a TaggedProfile; it is composed of an
>      IIOPProfileTemplate and an object_key.
>    - an IIOPProfileTemplate has IIOP addressing and version
>information,
>      contains TaggedComponents and may be referenced by more than
>one
>      IIOPProfile.
>


This wording helps me understand better.


Are the tagged component values themselves sharable across profile
template
instances?  If so this model does not seem to exploit it.


>
> >In the rationale section, the following also appears:
> >"
> >with corresponding IDL definitions that allow the language bindings
> >to optimise conversion between transmission and internal IOR
formats
> >to provide a performant and natural interface for IOR access.
> >"
> >
> >It is not clear whether there have to be different language binding
> >optimizations for this, or are they automatically mapped, as local
> >interfaces.
>
> I believe the proposed interfaces, as automatically mapped to Java
at
> least, will enable ORBs to provide access to IORs with significantly
> better performance than that available at present using codecs. I
> wouldn't expect to introduce any language specific mapping for Java
> or any other language, but I guess that would be up to the relevant
> RTFs. The comment was merely to explain the purpose of introducing
> such a model. Since it isn't part of the proposed spec change, I'm
not
> sure it helps to reword it.
>


Jishnu also provided a suggested edit which fixed much of my concern.


However, if the spec gives special treatment to these beyond their
being
"local" IDL objects, in terms of the language mapping for the local
interfaces,


I have remaining concerns.



> >
> >Also the following paragraph:
> >"
> >TaggedProfile and TaggedComponent are generic interfaces. Users of
> >the
> >ORB may create implementations of them. Corresponding factories may
> >be
> >registered with the IORFactory. The IORFactory is obtained through
> >a
> >call to ORB::resolve_initial_references ("IORFactory") and may also
> >be
> used
> >to obtain an IOR for an Object.
> >"
> >
> >uses the term "generic interface".  Is this a new concept?
>
> I used the term "generic" merely in the sense of not "specific" i.e
> they apply to any TaggedProfile or TaggedComponent. ORB users may
> >refer
> to specific TaggedProfile/Component types by defining, and
> >registering
> a factory for, inheriting subtypes. Re Jishnu's suggestion, would
> it be better to say
> "TaggedProfile and TaggedComponent are interfaces for which
> >implementations
> may be provided by ORBs and services. Corresponding....."


Excusing my rusty recollection of  POA details,  could you please
clarify
whether the
standard POA mechanisms are used to instantiate these taggedProfile
and
taggedComponent local object implementations?


My concern, please educate me if it is wrong, is that these new
profile and
component factories for IORs could cause portability problems across
orbs.


Does the ORB vendor provide these factory impementations, or the orb
user?


>
> >
> >I do not get the confidence that this is sufficiently thought out,
> >especially for multiple programming language environments.  I would
like
> to
> >see some demonstration that it works, especially the generic
interface
> >concept, but there is no FTF for an RTF.
> >
> >This seems too much for an RTF revision.  I would prefer an RFC or
RFP on
> >this focused topic.  That is Why I vote no on this proposed
resolution.
>
> I brought this to the OMG, initially as a Java issue then, when that
RTF
> thought it more generally applicable, as a Core RTF issue, since it
> seemed to me important that CORBA function required by a J2EE
> implementation
> be standardized and not merely added in a proprietary manner by
individual
> JDK vendors. I thought CORBA extensions should be standardized by
the OMG
> rather than added, with less consultation and review, by the JCP.
> I hadn't thought this proposal was significantly larger than other
pieces
> of work undertaken previously by the Core RTF.


If you can clarify my understanding of who implements each of these
local
interfaces and their factories, in terms of ORB provider and ORB user
application,
and show me that this is nothing new, then my concerns could go away.


--
----------------------------------------------------
Tom Rutt  email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Subject: Re: Issue 5439 in CORBA Core RTF Vote 10 
To: tom@coastin.com 
Cc: CORBA Core RTF <corba-rtf@omg.org>, Jishnu Mukerji <jishnu@hp.com> 
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001 
From: "Ann Dalton1" <ann_dalton@uk.ibm.com> 
Date: Thu, 12 Dec 2002 14:23:29 +0000 
X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a
|January 7, 2002) at 
 12/12/2002 14:24:04 



Tom,
Some further responses inline.
Ann


Tom Rutt wrote:
> Thanks for your response:
>
> My comments are in line.
>
> Ann Dalton1 wrote:
>
> > Tom,
> > I've not much to add to responses already given by Jishnu and
others,
> > but here is my attempt to answer your concerns. I'll incorporate
this
> > and the other comments into a revised proposal.
> > Re timing, Jishnu, should I submit a draft revised proposal
tomorrow?
> > Ann
> >
> > Tom Rutt wrote:
> > >Issue 5439: processing TaggedComponents within an IOR  -  Fujitsu
Votes NO
> > >
> > >This seems like a lot to add in an RTF.
> > >
> > >The statement in the proposal for abstract model:
> > >
> > >"
> > >Recognising that many of the constituent parts of IOR profiles
are
> > >identical for different objects allows the following model to be
> > >defined:-
> > >   - an IOR has a type ID string, and contains TaggedProfile
instances
> > >   - a TaggedProfile has an ID and data
> > >   - an IIOPProfile is a TaggedProfile; it is composed of an
> > >     IIOPProfileTemplate and an object ID.
> > >   - an IIOPProfileTemplate has IIOP addressing information, and
contains
> > >     TaggedComponents.
> > >
> > > "
> > >does not include the iiop version and it mistakenly calls the
Object
Key
> > the
> > >Object ID.
> >
> > The text didn't include the iiop version because this is
introductory
> > material that attempts to describe the major components of the
model.
The
> > IIOP version is included in the definition of the
IIOPProfileTemplate
> > local interface in 21.5.3 below. I wouldn't want to necessarily
include
> > every data item as that might be both confusing and duplicative,
giving
> > the usual problems of maintaining the same information in multiple
places.
> > However version can be added, see revised text below.
> >
> > I think it could be argued that, without any capitalisation,
"object
ID"
> > is just a term for any object identifier but I agree it would be
better
> > to avoid any ambiguity and refer to it as an object_key.
>
> Jishnu proposed a simple fix to cover both of these.  I agree this
is
> editorial, but important because some people only read the intro.


Ok, fine. I have incorporated it into the revised text.


>
> >
> >
> > >Also the "identical for different objects" could mean same syntax
or
same
> > >values.  It is not clear what the intent is for this.  The model
seems
> > valid
> > >just for the common syntax and I do not see anything in the model
which
> > >exploits two objects with common component values included in
each of
> > them.
> > >
> > I intended "are identical for different objects" to mean same
values
> > for different objects. If that's not clear, it could be reworded
to
> > say "are common for different objects" or "have identical values
for
> > different objects". Do you have a preference?
> >
> > The provision of the IIOPProfileTemplate allows, but doesn't
require,
an
> > ORB to allow multiple objects to share the information contained
therein.
> >
> > So, would you prefer the following revised text:-
> >
> > Recognising that many of the constituent parts of IOR profiles
have
> > identical values for different objects allows the following model
to be
> > defined:-
> >    - an IOR has a type ID string, and contains TaggedProfile
instances
> >    - a TaggedProfile has an ID and data
> >    - an IIOPProfile is a TaggedProfile; it is composed of an
> >      IIOPProfileTemplate and an object_key.
> >    - an IIOPProfileTemplate has IIOP addressing and version
information,
> >      contains TaggedComponents and may be referenced by more than
one
> >      IIOPProfile.
> >
>
> This wording helps me understand better.


Ok, good.


>
> Are the tagged component values themselves sharable across profile
template
> instances?  If so this model does not seem to exploit it.






>
> >
> > >In the rationale section, the following also appears:
> > >"
> > >with corresponding IDL definitions that allow the language
bindings
> > >to optimise conversion between transmission and internal IOR
formats
> > >to provide a performant and natural interface for IOR access.
> > >"
> > >
> > >It is not clear whether there have to be different language
binding
> > >optimizations for this, or are they automatically mapped, as
local
> > >interfaces.
> >
> > I believe the proposed interfaces, as automatically mapped to Java
at
> > least, will enable ORBs to provide access to IORs with
significantly
> > better performance than that available at present using codecs. I
> > wouldn't expect to introduce any language specific mapping for
Java
> > or any other language, but I guess that would be up to the
relevant
> > RTFs. The comment was merely to explain the purpose of introducing
> > such a model. Since it isn't part of the proposed spec change, I'm
not
> > sure it helps to reword it.
> >
>
> Jishnu also provided a suggested edit which fixed much of my
concern.


Yes, I'll include that in the revised proposal.


>
> However, if the spec gives special treatment to these beyond their
>being
> "local" IDL objects, in terms of the language mapping for the local
> interfaces, I have remaining concerns.


Not sure I understand. No special treatment is being proposed here. Do
you mean in the language specs? If so, I guess that would be in a
separate
issue, possibly in a separate RTF. I'm not proposing that any such
issue
be raised though.


>
>
> > >
> > >Also the following paragraph:
> > >"
> > >TaggedProfile and TaggedComponent are generic interfaces. Users
>of the
> > >ORB may create implementations of them. Corresponding factories
>may be
> > >registered with the IORFactory. The IORFactory is obtained
>through a
> > >call to ORB::resolve_initial_references ("IORFactory") and may
>also be
> > used
> > >to obtain an IOR for an Object.
> > >"
> > >
> > >uses the term "generic interface".  Is this a new concept?
> >
> > I used the term "generic" merely in the sense of not "specific"
>i.e
> > they apply to any TaggedProfile or TaggedComponent. ORB users may
>refer
> > to specific TaggedProfile/Component types by defining, and
>registering
> > a factory for, inheriting subtypes. Re Jishnu's suggestion, would
> > it be better to say
> > "TaggedProfile and TaggedComponent are interfaces for which
implementations
> > may be provided by ORBs and services. Corresponding....."
>
> Excusing my rusty recollection of POA details, could you please
>clarify
> whether the standard POA mechanisms are used to instantiate these
> taggedProfile and taggedComponent local object implementations?
>


Again, I'm not sure I've understand your question. I didn't think the
POA
would be involved in creating local objects.


> My concern, please educate me if it is wrong, is that these new
  profile
and
> component factories for IORs could cause portability problems across
orbs.
>
> Does the ORB vendor provide these factory impementations, or the orb
user?


As stated in 21.5.3
"TaggedProfile and TaggedComponent are interfaces for which
implementations
may be provided by ORBs and services."
and
"An ORB shall provide factories for the standard profile and
component types it supports, and also for any ORB-specific proprietary
profile and component types it provides."


It is the intention that an ORB will provide factory implementations
for any TaggedProfile and TaggedComponent types for those it
supports i.e those defined in the CORBA spec at the supported level.
An ORB needs to provide, at minimum, a generic (apologies for the
term)
implementation to support any TaggedProfile and TaggedComponent types
that have no other factory registered.
The interfaces are provided to allow service providers e.g J2EE
vendors
plugging in SSL, Transaction services, Activity services etc. via
portable interceptors to have improved access to the components
defined in
these specifications by providing the appropriate factories.


>
> >
> > >
> > >I do not get the confidence that this is sufficiently thought
out,
> > >especially for multiple programming language environments.  I
would
like
> > to
> > >see some demonstration that it works, especially the generic
interface
> > >concept, but there is no FTF for an RTF.
> > >
> > >This seems too much for an RTF revision.  I would prefer an RFC
or RFP
on
> > >this focused topic.  That is Why I vote no on this proposed
resolution.
> >
> > I brought this to the OMG, initially as a Java issue then, when
that
RTF
> > thought it more generally applicable, as a Core RTF issue, since
it
> > seemed to me important that CORBA function required by a J2EE
> > implementation
> > be standardized and not merely added in a proprietary manner by
individual
> > JDK vendors. I thought CORBA extensions should be standardized by
the
OMG
> > rather than added, with less consultation and review, by the JCP.
> > I hadn't thought this proposal was significantly larger than other
pieces
> > of work undertaken previously by the Core RTF.
>
> If you can clarify my understanding of who implements each of these
local
> interfaces and their factories, in terms of ORB provider and ORB
user
> application,
> and show me that this is nothing new, then my concerns could go
away.
>
As above, ORBs will provide implementations/factories for the
components
they support (which may merely be a single generic implementation for
the
TaggedComponent and TaggedProfile super types). Users (typically
products
providing ORB extensions via portable interceptors) may provide
implementations/factories for the components they own, or they may
rely
on the default (generic) ORB provided implementation.



Date: Thu, 12 Dec 2002 10:49:11 -0800 (PST) 
From: Ken Cavanaugh <Ken.Cavanaugh@Sun.COM> 
Reply-To: Ken Cavanaugh <Ken.Cavanaugh@Sun.COM> 
Subject: Re: Issue 5439 in CORBA Core RTF Vote 10 
To: tom@coastin.com, ann_dalton@uk.ibm.com 
Cc: corba-rtf@omg.org, jishnu@hp.com 
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc 


A small comment:



>
>Tom Rutt wrote:
>> Thanks for your response:
>>
>> My comments are in line.
>>
>> Ann Dalton1 wrote:
>>
>> > Tom,


...



>> > >
>> > >Also the following paragraph:
>> > >"
>> > >TaggedProfile and TaggedComponent are generic interfaces. Users
>> > >of the
>> > >ORB may create implementations of them. Corresponding factories
>> > >may be
>> > >registered with the IORFactory. The IORFactory is obtained
>> > >through a
>> > >call to ORB::resolve_initial_references ("IORFactory") and may
>> > >also be
>> > used
>> > >to obtain an IOR for an Object.
>> > >"
>> > >
>> > >uses the term "generic interface".  Is this a new concept?
>> >
>> > I used the term "generic" merely in the sense of not "specific"
>> > >i.e
>> > they apply to any TaggedProfile or TaggedComponent. ORB users may
>> > >refer
>> > to specific TaggedProfile/Component types by defining, and
>> > >registering
>> > a factory for, inheriting subtypes. Re Jishnu's suggestion, would
>> > it be better to say
>> > "TaggedProfile and TaggedComponent are interfaces for which
>implementations
>> > may be provided by ORBs and services. Corresponding....."
>>
>> Excusing my rusty recollection of POA details, could you please
>> > >clarify
>> whether the standard POA mechanisms are used to instantiate these
>> taggedProfile and taggedComponent local object implementations?
>>
>
>Again, I'm not sure I've understand your question. I didn't think the
>> > >POA
>would be involved in creating local objects.


That's correct.  The Java mapping for local interfaces (for example)
simply creates local objects by directly calling new on a constructor.
No POA (or any other ORB) involvment is present.



Ken.


From: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us> 
Subject: Re: CORBA Core Vote 13 - Issue 5439 
To: jishnu@hp.com (Jishnu Mukerji) 
Date: Fri, 13 Dec 2002 16:19:14 -0800 (PST) 
Cc: corba-rtf@omg.org (CORBA Core RTF) 
X-Mailer: ELM [version 2.5 PL2] 


Hi,
  
  There were questions raised about issue 5439 in the previous
  vote. My interest
  is in finding out how much implementation experience vendors have
  had
  in implementing the proposed change. 
  
  My concern is that the proposal is rather large and involved. There
  is
  no finalization phase for RTFs so we have to get it right.


  I think we should be comfortable that the liklihood of creating
  (yet) another
  spectacle of "urgent changes" to "urgent changes" is quite low.


  thx,
    jeff
-- 
Jeff Mischkinsky                
jmischki@dcn.davis.ca.us        +1 530-758-9850
jeff.mischkinsky@oracle.com     +1 650-506-1975


From: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us> 
Subject: Re: CORBA Core Vote 13 Announcement 
To: jishnu@hp.com (Jishnu Mukerji) 
Date: Thu, 2 Jan 2003 10:50:09 -0800 (PST) 
Cc: corba-rtf@omg.org (CORBA Core RTF) 
X-Mailer: ELM [version 2.5 PL2] 


ORCL votes as follows:
 1139 - yes
 5296 - yes
 5439 - abstain
 5626 - abstain
 R5 - abstain


WRT to 5439:
  Based upon reading it, the propsal looks reasonable to me (and I
  would
  agree that it has been need for a long time). However, it is
  is a significant and rather large change that involves some rather
  key
  pieces of ORB functionality. IMO, review of it requires
  implmentation
  experience, which I am not in a position to do. Hence my abstain,
  rather
  than yes.


  Because of the nature of the RTF process, once this is approved, it
  goes
  into the core immediately. I would very much like to avoid a repeat
  of the spectacle of multiple urgent review processes to fix first
  a bug in the proposal, and then bugs in the urgent review proposal,
  etc., etc.
  (Based upon past experience, it seems to me that this kind of change
   has a reasonably high probability (far greater than epsilon ;-)
   of triggering such an unfortunate series of events.)


  When the AB reviews the RTF report I intend to raise the question of
  implementation experience and will vote to withold approval until we
  have sufficient experience. My (personal) definition of sufficient
  is 
  (at least) 2 independent implementations which will
  interoperate. That
  means they use the facility to produce IORs which can be consumed
  by the others.


  cheers,
   jeff






'Jishnu Mukerji' writes:
> 
> 
> 
> Jishnu Mukerji wrote:
> > 
> > Folks,
> > 
> >  Vote 13  available at:
> > 
> > http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote_13.html
> > 
> > It is due on January 3, so you have many days to vote on it.
> > 
> > Please do vote early and vote often. As usual if you do vote
often,
> > only the last vote cast by you will count.
> 
> Hope, y'all had a very happy holidays. 
> 
> This is to remind you that Vote 13 votes are due by tomorrow. So
thos of
> you that have not voted yet, please vote early and vote often.
> 
> Thank.
> 
> A Haapy New Year to you all.
> 
> Jishnu.
> 



-- 
Jeff Mischkinsky                
jmischki@dcn.davis.ca.us        +1 530-758-9850
jeff.mischkinsky@oracle.com     +1 650-506-1975

Sender: jon@floorboard.com 
Date: Thu, 02 Jan 2003 11:13:28 -0800 
From: Jonathan Biggar <jon@floorboard.com> 
X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) 
X-Accept-Language: en 
To: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us> 
CC: Jishnu Mukerji <jishnu@hp.com>, CORBA Core RTF <corba-rtf@omg.org> 
Subject: Re: CORBA Core Vote 13 Announcement 


Jeffrey Mischkinsky wrote:
> WRT to 5439:
>   Based upon reading it, the propsal looks reasonable to me (and I
would
>   agree that it has been need for a long time). However, it is
>   is a significant and rather large change that involves some rather
key
>   pieces of ORB functionality. IMO, review of it requires
implmentation
>   experience, which I am not in a position to do. Hence my abstain,
rather
>   than yes.
> 
>   Because of the nature of the RTF process, once this is approved,
it goes
>   into the core immediately. I would very much like to avoid a
repeat
>   of the spectacle of multiple urgent review processes to fix first
>   a bug in the proposal, and then bugs in the urgent review
proposal, etc., etc.
>   (Based upon past experience, it seems to me that this kind of
change
>    has a reasonably high probability (far greater than epsilon ;-)
>    of triggering such an unfortunate series of events.)
> 
>   When the AB reviews the RTF report I intend to raise the question
of
>   implementation experience and will vote to withold approval until
we
>   have sufficient experience. My (personal) definition of sufficient
is
>   (at least) 2 independent implementations which will
interoperate. That
>   means they use the facility to produce IORs which can be consumed
>   by the others.


Jeff, this last sentence suggests you have a misconception of what the
5439 proposal accomplishes.  There's nothing in 5439 that allows a
programmer to construct a new IOR and turn it into an object
reference,
as far as I can see.  Rather, it is a read-only interface to examine
existing IORs that are created through other mechanisms.


As such, I don't see that any interoperability issues are possible. 
There may be issues of whether the proposal can be easily implemented
on
multiple ORBs with different internal architectures (although I don't
see any such problems), and whether the proposal is sufficiently
detailed to ensure portability of code that uses the new features
(this
is the more likely failing), but those aren't  interoperability
problems.


-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

From: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us> 
Subject: Re: CORBA Core Vote 13 Announcement 
To: jon@floorboard.com (Jonathan Biggar) 
Date: Thu, 2 Jan 2003 11:36:28 -0800 (PST) 
Cc: jishnu@hp.com (Jishnu Mukerji), corba-rtf@omg.org (CORBA Core RTF) 
X-Mailer: ELM [version 2.5 PL2] 


'Jonathan Biggar' writes:
> 
> Jeffrey Mischkinsky wrote:
> > WRT to 5439:
> >   Based upon reading it, the propsal looks reasonable to me (and I
would
> >   agree that it has been need for a long time). However, it is
> >   is a significant and rather large change that involves some
rather key
> >   pieces of ORB functionality. IMO, review of it requires
implmentation
> >   experience, which I am not in a position to do. Hence my
abstain, rather
> >   than yes.
> > 
> >   Because of the nature of the RTF process, once this is approved,
it goes
> >   into the core immediately. I would very much like to avoid a
repeat
> >   of the spectacle of multiple urgent review processes to fix
first
> >   a bug in the proposal, and then bugs in the urgent review
proposal, etc., etc.
> >   (Based upon past experience, it seems to me that this kind of
change
> >    has a reasonably high probability (far greater than epsilon ;-)
> >    of triggering such an unfortunate series of events.)
> > 
> >   When the AB reviews the RTF report I intend to raise the
question of
> >   implementation experience and will vote to withold approval
until we
> >   have sufficient experience. My (personal) definition of
sufficient is
> >   (at least) 2 independent implementations which will
interoperate. That
> >   means they use the facility to produce IORs which can be
consumed
> >   by the others.
> 
> Jeff, this last sentence suggests you have a misconception of what
the
> 5439 proposal accomplishes.  There's nothing in 5439 that allows a
> programmer to construct a new IOR and turn it into an object
reference,
> as far as I can see.  Rather, it is a read-only interface to examine
> existing IORs that are created through other mechanisms.
> 
> As such, I don't see that any interoperability issues are possible. 


Jon, 
You're correct.  There is nothing in the proposal that explicitly lets
one
"export" the IOR. I was assuming that it would be possible to do so
via
other means, and just wanted to verify that the object reference would
work
with other orbs. 


If this is in fact not an issue, then there's no interop issue, and my
criteria simply becomes at least 2 independent implementations. We
only
have to deal with correctness and portability issues


thx,
 jeff


> There may be issues of whether the proposal can be easily
  implemented on
> multiple ORBs with different internal architectures (although I
  don't
> see any such problems), and whether the proposal is sufficiently
> detailed to ensure portability of code that uses the new features
  (this
> is the more likely failing), but those aren't  interoperability
> problems.
> 
> -- 
> Jon Biggar
> Floorboard Software
> jon@floorboard.com
> jon@biggar.org
> 



-- 
Jeff Mischkinsky                
jmischki@dcn.davis.ca.us        +1 530-758-9850
jeff.mischkinsky@oracle.com     +1 650-506-1975

Date: Fri, 03 Jan 2003 10:20:09 -0500 
From: Bob Kukura <bob.kukura@iona.com> 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1)
Gecko/20021130 
X-Accept-Language: en-us, en 
To: Jishnu Mukerji <jishnu@hp.com> 
CC: CORBA Core RTF <corba-rtf@omg.org>, 
   Rebecca Bergersen <rebecca.bergersen@iona.com>, 
   Eoghan Glynn <eglynn@iona.com> 
Subject: Re: CORBA Core Vote 13 Announcement 
X-OriginalArrivalTime: 03 Jan 2003 15:23:07.0079 (UTC)
FILETIME=[04444D70:01C2B33C] 


IONA votes as follows:


1139 - Yes
5296 - Yes
5439 - No - I've examined the current proposal closely, and still have
significant concerns. Assuming an ORB has a "better" native
representation of IORs that needs to be retained, this proposal will
require the addition of mechanisms both to wrap the native
representation with the portable representation, and to wrap the
portable representation with the native representation. In addition to
the added complexity and code bloat, I'm not convinced implementing
these interfaces via such wrappers will actually achieve the stated
purpose of reducing the "overhead of processing TaggedComponents",
particularly if the wrappers need to be dynamically instantiated each
time the IOR information is accessed. The proposed interfaces are not
adequate to replace the native IOR representations of the ORBs with
which I am familiar with, and I don't believe standardizing such
interfaces is possible without requiring standardization of other
details of ORB implementations.
5626 - No - I'm not convinced that the added complexity of delaying
the transmission of request and reply messages in ORBs communicating
directly over IIOP is justified, and do not recall this being
explicitly discussed during the Messaging RFP submitters
discussions. Unless someone provides a convincing use case for the ORB
honoring the start time policies, I'd prefer this issue being resolved
such that the start time policies have no effect on non-routed
invocations.
R5 - No - I'm not convinced this capability is really required,
although I don't see a major problem implementing the proposal. I am a
bit concerned that portable usage of this mechanism might be difficult
due to different behaviors of ORBs with regard to processing of
forwarded IORs, particularly when concurrent requests are made using
an IOR that requires forwarding, or when an ORB can determing that a
forward applies to a group of related IORs.


-Bob



Jishnu Mukerji wrote:


Folks,


Juergen assures me that Vote 13 of the CORBA Core RTF will be
available
before the and of the day at:


http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote_13.html


It is due on January 3, so you have many days to vote on it. 
Please do vote early and vote often. As usual if you do vote often,
only the last vote cast by you will count.


The following additional files will also be available before the end
of
the day:


1. Updated list of issues Yet To Be Resolved (YTBR) at


http://cgi.omg.org/pub/orbrev/drafts/corba_rtf-ytbr.html


This assumes that all issues in Vote 12 have passed as they are likely
to given the 13 of the 14 possible votes tallied so far (exit polls
and
all that good stuff you know:-).


2. List of issues that have been resolved so far at


http://cgi.omg.org/pub/orbrev/drafts/corba_rtf_resolved2_121302.html


Again assuming all the resolutions in Vote 12 pass


3. Final Results of vote 10


http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote10_results.html


3. Final Results of vote 11


http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote11_results.html


4. Preliminary Results of Vote 12 (record of votes received uptil
   4:30pm
EST
today)


http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote12_results.html



Thanks for all your efforts, cooperation and indulgence,


Jishnu.


Ps. I will be away on vacation and travelling in Japan, Southeast Asia
and India starting early tomorrow morning and returning afternoon of
the
31st, ready to go off to a New Years Eve dance party.:-) So all of you
have a very Happy celebration of the Winter Solstice of your choice
and
a Happy New Year. I'll e-see (sic!) you all in the new year.


Sender: jon@floorboard.com 
Date: Fri, 03 Jan 2003 11:32:52 -0800 
From: Jonathan Biggar <jon@floorboard.com> 
X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) 
X-Accept-Language: en 
To: Bob Kukura <bob.kukura@iona.com> 
CC: Jishnu Mukerji <jishnu@hp.com>, CORBA Core RTF
<corba-rtf@omg.org>, 
   Rebecca Bergersen <rebecca.bergersen@iona.com>, 
   Eoghan Glynn <eglynn@iona.com> 
Subject: Re: CORBA Core Vote 13 Announcement 


> Bob Kukura wrote:
> >> 5439 - No - I've examined the current proposal closely, and still
> >> have
> >> significant concerns. Assuming an ORB has a "better" native
> >> representation of IORs that needs to be retained, this proposal
> >> will
> >> require the addition of mechanisms both to wrap the native
> >> representation with the portable representation, and to wrap the
> >> portable representation with the native representation. In
> >> addition to
> >> the added complexity and code bloat, I'm not convinced
> >> implementing
> >> these interfaces via such wrappers will actually achieve the
> >> stated
> >> purpose of reducing the "overhead of processing
TaggedComponents",
> >> particularly if the wrappers need to be dynamically instantiated
> >> each
> >> time the IOR information is accessed. The proposed interfaces are
> >> not
> >> adequate to replace the native IOR representations of the ORBs
> >> with
> >> which I am familiar with, and I don't believe standardizing such
> >> interfaces is possible without requiring standardization of other
> >> details of ORB implementations.
> >>
> >>
> > Again, as with my answer to Jeff, I'm not sure why you think this
> > way.
> > Since the proposal is a read-only access to IOR information, I
can't
> > conceive of a requirement to "wrap the portable representation
with
> > the
> > native representation".
> >
> Maybe I'm completely misunderstainding the proposal, but doesn't it
> provide both read-only access to arbitrary IOR information plus a
> mechanism to implement IOR components and/or profiles? If the latter
> mechanism is used, might not this require wrapping those
> user-implemented components or profiles with native interfaces?


No, your second part is a misunderstanding.  What it provides is a
mechanism to register parsers for IOR components & profiles, which are
used to support the read-only access to IOR information.


> >
> > And since object references are effectively constant, there
> >doesn't
> > seem
> > to be a need to "wrap the native representation with the portable
> > representation", at least in a way that makes each call to the
> > portable
> > representation call some equivalent functionality of the native
> > representation.  Instead, the underlying IOR information can be
> > translated from the native format into something efficient for the
> > portable format exactly once, when IORFactory::get_ior is called.
> >
> Who calls get_ior()? If an ORB already has a native mechanism for
> representing IORs, I don't see why it would ever call this new
> operation, except maybe when a portable interceptor requires the
> portable IOR representation. But caching this representation would
> subvert optimizations ORBs might already use to scale to large
> >numbers
> of IORs.


The intent is for the implementor of an IORInterceptor to call
get_ior. 
The ORB itself should never need to call it.


-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

Date: Fri, 03 Jan 2003 14:22:42 -0500 
From: Bob Kukura <bob.kukura@iona.com> 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1)
Gecko/20021130 
X-Accept-Language: en-us, en 
To: Jonathan Biggar <jon@floorboard.com> 
CC: Jishnu Mukerji <jishnu@hp.com>, CORBA Core RTF
<corba-rtf@omg.org>, 
   Rebecca Bergersen <rebecca.bergersen@iona.com>, 
   Eoghan Glynn <eglynn@iona.com> 
Subject: Re: CORBA Core Vote 13 Announcement 
X-OriginalArrivalTime: 03 Jan 2003 19:25:36.0110 (UTC)
FILETIME=[E42A40E0:01C2B35D] 



Jonathan Biggar wrote:

Bob Kukura wrote:
  
IONA votes as follows:

1139 - Yes
5296 - Yes
5439 - No - I've examined the current proposal closely, and still have
significant concerns. Assuming an ORB has a "better" native
representation of IORs that needs to be retained, this proposal will
require the addition of mechanisms both to wrap the native
representation with the portable representation, and to wrap the
portable representation with the native representation. In addition to
the added complexity and code bloat, I'm not convinced implementing
these interfaces via such wrappers will actually achieve the stated
purpose of reducing the "overhead of processing TaggedComponents",
particularly if the wrappers need to be dynamically instantiated each
time the IOR information is accessed. The proposed interfaces are not
adequate to replace the native IOR representations of the ORBs with
which I am familiar with, and I don't believe standardizing such
interfaces is possible without requiring standardization of other
details of ORB implementations.
    

Again, as with my answer to Jeff, I'm not sure why you think this
way. 
Since the proposal is a read-only access to IOR information, I can't
conceive of a requirement to "wrap the portable representation with
the
native representation".
Maybe I'm completely misunderstainding the proposal, but doesn't it
provide both read-only access to arbitrary IOR information plus a
mechanism to implement IOR components and/or profiles? If the latter
mechanism is used, might not this require wrapping those
user-implemented components or profiles with native interfaces? 


And since object references are effectively constant, there doesn't
seem
to be a need to "wrap the native representation with the portable
representation", at least in a way that makes each call to the
portable
representation call some equivalent functionality of the native
representation.  Instead, the underlying IOR information can be
translated from the native format into something efficient for the
portable format exactly once, when IORFactory::get_ior is called.
Who calls get_ior()? If an ORB already has a native mechanism for
representing IORs, I don't see why it would ever call this new
operation, except maybe when a portable interceptor requires the
portable IOR representation. But caching this representation would
subvert optimizations ORBs might already use to scale to large numbers
of IORs.

-Bob


  
Sender: jon@floorboard.com 
Date: Fri, 03 Jan 2003 10:00:33 -0800 
From: Jonathan Biggar <jon@floorboard.com> 
X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) 
X-Accept-Language: en 
To: Bob Kukura <bob.kukura@iona.com> 
CC: Jishnu Mukerji <jishnu@hp.com>, CORBA Core RTF
<corba-rtf@omg.org>, 
   Rebecca Bergersen <rebecca.bergersen@iona.com>, 
   Eoghan Glynn <eglynn@iona.com> 
Subject: Re: CORBA Core Vote 13 Announcement 


Bob Kukura wrote:
> 
> IONA votes as follows:
> 
> 1139 - Yes
> 5296 - Yes
> 5439 - No - I've examined the current proposal closely, and still
have
> significant concerns. Assuming an ORB has a "better" native
> representation of IORs that needs to be retained, this proposal will
> require the addition of mechanisms both to wrap the native
> representation with the portable representation, and to wrap the
> portable representation with the native representation. In addition
to
> the added complexity and code bloat, I'm not convinced implementing
> these interfaces via such wrappers will actually achieve the stated
> purpose of reducing the "overhead of processing TaggedComponents",
> particularly if the wrappers need to be dynamically instantiated
each
> time the IOR information is accessed. The proposed interfaces are
not
> adequate to replace the native IOR representations of the ORBs with
> which I am familiar with, and I don't believe standardizing such
> interfaces is possible without requiring standardization of other
> details of ORB implementations.


Again, as with my answer to Jeff, I'm not sure why you think this
way. 
Since the proposal is a read-only access to IOR information, I can't
conceive of a requirement to "wrap the portable representation with
the
native representation".


And since object references are effectively constant, there doesn't
seem
to be a need to "wrap the native representation with the portable
representation", at least in a way that makes each call to the
portable
representation call some equivalent functionality of the native
representation.  Instead, the underlying IOR information can be
translated from the native format into something efficient for the
portable format exactly once, when IORFactory::get_ior is called.


-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

Date: Fri, 03 Jan 2003 11:45:58 -0500 
From: Tom Rutt <tom@coastin.com> 
Reply-To: tom@coastin.com 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) 
X-Accept-Language: en 
To: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us>, 
   Jishnu Mukerji <jishnu@hp.com>, CORBA Core RTF <corba-rtf@omg.org> 
Subject: Re: CORBA Core Vote 13 Announcement 


I would like to change the Fujitsu vote on 5439 to NO, based on my
implementation
concerns and the additional concerns expressed by Bob Kukura.


Tom Rutt wrote:


> > Fujitsu votes as follows:
> >  1139 - yes
> >  5296 - yes
> >  5439 - abstain, want to see implementation experience (New
> > capabilities)
> >  5626 - yes
> >  R5 - abstain
> >
>
> ----------------------------------------------------
> Tom Rutt  email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133


--
----------------------------------------------------
Tom Rutt  email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Sender: jon@floorboard.com 
Date: Fri, 03 Jan 2003 11:44:40 -0800 
From: Jonathan Biggar <jon@floorboard.com> 
X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) 
X-Accept-Language: en 
CC: CORBA Core RTF <corba-rtf@omg.org> 
Subject: Re:  5439 proposal in vote 13 


The one thing that puzzles me about 5439 is the split of IIOPProfile
vs
IIOPProfileTemplate.  There seems to be some handwaving that since
IORs
often have almost identical information in an IIOP Profile (except for
the object key), that defining the IIOPProfileTemplate local interface
would allow for some reuse or caching that improves efficiency. 
Frankly, I don't see a scenario where that can be practically
accomplished.


Also, the create_profile operation on IIOPProfileTemplate doesn't seem
to accomplish what is intended, since you have to have an
IIOPProfileTemplate before you can create an IIOPProfile, but there's
no
factory to independently create an IIOPPofileTemplate without already
having all of the needed information anyway.


Would any of the submitters of this proposal like to comment?


I'd like to suggest that we revote a modified 5439 proposal in the
next
vote that removes IIOPProfileTemplate by merging all of its readonly
attributes and operations (except create_profile, which would be
dropped) into the IIOPProfile local interface.


-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

Date: Fri, 03 Jan 2003 15:36:58 -0500 
From: Jishnu Mukerji <jishnu@hp.com> 
Organization: Software Global Business Unit, Hewlett-Packard 
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2)
Gecko/20021120 Netscape/7.01 
X-Accept-Language: en-us, en 
To: CORBA Core RTF <corba-rtf@omg.org> 
Subject: Re: 5439 proposal in vote 13 




Jonathan Biggar wrote:
The one thing that puzzles me about 5439 is the split of IIOPProfile
vs
IIOPProfileTemplate.  There seems to be some handwaving that since
IORs
often have almost identical information in an IIOP Profile (except for
the object key), that defining the IIOPProfileTemplate local interface
would allow for some reuse or caching that improves
efficiency. Frankly, I don't see a scenario where that can be
practically
accomplished.
Also, the create_profile operation on IIOPProfileTemplate doesn't seem
to accomplish what is intended, since you have to have an
IIOPProfileTemplate before you can create an IIOPProfile, but there's
no
factory to independently create an IIOPPofileTemplate without already
having all of the needed information anyway.
Would any of the submitters of this proposal like to comment?
I'd like to suggest that we revote a modified 5439 proposal in the
next
vote that removes IIOPProfileTemplate by merging all of its readonly
attributes and operations (except create_profile, which would be
dropped) into the IIOPProfile local interface.


Since there are sufficient number of reasonable questions about the
proposal that need answering and time is running short on this vote, I
think it would be a good idea to revote this one issue resolution
(perhaps with fixes as are being suggested) on a schedule that looks
something like:


Vote available: Thursday Jan 9
Vote due:       Monday Jan 13


This will give sufficient time for fixing confusing language and
establishing better understanding of the proposal among the voters. If
any of you have an objection to this idea of revoting, we can go
through the rigmarole of voting on a motion to reconsider etc. etc.


Comments?


Jishnu.



X-Sender: beckwb@postel 
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 
Date: Fri, 03 Jan 2003 18:07:16 -0500 
To: Jishnu Mukerji <jishnu@hp.com> 
From: bill.beckwith@ois.com 
Subject: Re: CORBA Core RTF Vote 13 
Cc: CORBA Core RTF <corba-rtf@omg.org> 


Objective Interface votes as follows on Core RTF Vote 13.


Issue 1139: YES
Issue 5296: YES
Issue 5439: NO


I'm not convinced that the changes proposed would allow faster
tagged component processing in all situations (few installed
interceptors, many installed interceptors, various implementation
approaches to the specification, etc.).


Issue 5626: YES


List of Issues for the sense of the RTF resolutions:


  R5 (on the matter of how to resolve Issue 5266): Solution 1.


 

Date: Wed, 08 Jan 2003 17:23:54 -0500 
From: Tom Rutt <tom@coastin.com> 
Reply-To: tom@coastin.com 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) 
X-Accept-Language: en 
To: Jishnu Mukerji <jishnu@hp.com> 
CC: CORBA Core RTF <corba-rtf@omg.org> 
Subject: Re: CORBA Core RTF Vote 14 Announcement 


What about Jon Biggar's suggestion of merging interfaces?  This is in
the
archive.


Tom Rutt


Jishnu Mukerji wrote:


> Vote 14 which consists of a revote on the single issue resolution of
> 5439 is now available at:
>
> http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote_14.html
>
> The vote is due at noon on Monday Jan 13 EST (GMT-5). This early
> deadline is necessary in order to be able to file the report by Jan
> 13
> which is two weeks before the OMG meeting. We are already delaying
> submission of the report by a week in order to get final resolution
> of 5439.
>
> So if you are a Core RTF voter, please vote early and vote often
> taking
> into account the discussions that took place around this specific
> issue
> resolution near the end of Vote 13.
>
> Thank you.
>
> Jishnu.
> --
> Jishnu Mukerji
> Senior Systems Architect        1001 Frontier Road, Suite 300
> Technology Office               Bridgewater NJ 08807, USA
> Software Global Business Unit   Tel: +1 908 243 8924
> Hewlett-Packard Company         Fax: +1 908 243 8850
>                                  mailto: jishnu@hp.com


--
----------------------------------------------------
Tom Rutt  email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Date: Thu, 09 Jan 2003 11:57:17 -0500 
From: Jishnu Mukerji <jishnu@hp.com> 
Organization: Software Global Business Unit, Hewlett-Packard 
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2)
Gecko/20021120 Netscape/7.01 
X-Accept-Language: en-us, en 
To: CORBA Core RTF <corba-rtf@omg.org> 
Cc: tom@coastin.com, Ann Dalton <ann_dalton@uk.ibm.com> 
Subject: Re: CORBA Core RTF Vote 14 Announcement 


Tom Rutt wrote:
> What about Jon Biggar's suggestion of merging interfaces?
> This is in the archive.
>
> Tom Rutt


What about it? There is no concrete alternate proposal to vote
on. Just a vague thought about what might be a good thing to do. I
believe it will take a good day or two to modify the proposal to
reflect what Jon suggest.


Ann Dalton says:


Hi Jishnu,
Sorry for not responding on this earlier - I'm afraid I only returned
from
leave today. I may have missed some e-mail but I thought you were
going to
put 5439 up for revote tomorrow? I thought from your notes you were
expecting a response and/or revised proposal re Jon's concerns. 


Ann what are your thoughts on Jon's proposal?


And I was unsure what the
options were re Jeff's concerns that there should be two vendor
implementations before any final agreement?


The only way to address that is for as many as possible saying that
they have tried it out and know it to work. Absent that I think there
is a very good chance of this one getting blocked in the AB this time.


Thanks for your help,
Ann
BTW, there is another problem with the currently proposed resolution
that I just discovered while editing the draft chapters that needs
fixing. The proposal creates a new dependency of the
PortableInterceptor module on the IIOP module, which I don't think is
a very good idea at all. There is no justification for making the
existence of IIOP mandatory for using PortableInterceptors. I have
this sinking feeling that this proposal needs to be revised very
significantly to even get the packaging right.:-(


I think, if we are going to fix this one we need to consider doing the
following:


1. Consider Jon's suggestion and produce something concrete out of it.


2. Factor out the IIOP dependency into a separate module
   .... IIOPIORInterceptor or some such.


3. Also consider putting this entire thing in a separate module from
   the PortableInterceptor module, which is starting to get real
   unwieldy.


If we want to go in this direction, we should consider withdrawing
this proposal from this round of the RTF and deal with it as part of
the next RTF and if necessary do a report with only this resolution
for consideration by the AB at the Orlando meeting. On the whole it
might stand a better chance of making it through if the concerns
raised by no less than four AB members are addressed adequately. It
might also be esier to honestly make the claim about multiple
implementations by that time.


Anyway, these are my thoughts after looking at it from every angle
that I can think of.


I am sorry about this mess. I should have caught the packaging problem
earlier, but then there always are things that slip by.


Jishnu.




From: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us> 
Subject: Re: CORBA Core RTF Vote 14 Announcement 
To: jishnu@hp.com (Jishnu Mukerji) 
Date: Thu, 9 Jan 2003 10:13:00 -0800 (PST) 
Cc: corba-rtf@omg.org (CORBA Core RTF), tom@coastin.com, 
   ann_dalton@uk.ibm.com (Ann Dalton) 
X-Mailer: ELM [version 2.5 PL2] 


Hi,
  I'm afraid I have to agree with Jishnu's conclusions at the end of
  his
  email. 
  This is a large change, and we need to be absolutely sure that we've
  got
  it right.


  As Jishnu says, an F/RTF can pop out a report and ask that it be
  adopted
  at any time. The deadlines are just that, the last possible time
  such an


  So my suggestion is folks continue to iron out the bugs, resolve the 
  issues, AND make sure that we have at least 2 working
  implementations.
  Once the RTF is satisfied, then it can immediately be put forward
  for
  adoption.


  IMO, the RTF has an obligation to not recommend a resolution until
  there is sufficient implementation experience. The AB is should 
  just be a safety check to make sure good hygienic practices have
  been followed.


  cheers,
    jeff



'Jishnu Mukerji' writes:
> 
> Tom Rutt wrote:
>  > What about Jon Biggar's suggestion of merging interfaces?
>  > This is in the archive.
>  >
>  > Tom Rutt
> 
> What about it? There is no concrete alternate proposal to vote
on. Just 
> a vague thought about what might be a good thing to do. I believe it 
> will take a good day or two to modify the proposal to reflect what
Jon 
> suggest.
> 
> Ann Dalton says:
> 
> > Hi Jishnu,
> > Sorry for not responding on this earlier - I'm afraid I only
returned from
> > leave today. I may have missed some e-mail but I thought you were
going to
> > put 5439 up for revote tomorrow? I thought from your notes you
were
> > expecting a response and/or revised proposal re Jon's concerns. 
> 
> Ann what are your thoughts on Jon's proposal?
> 
> > And I was unsure what the
> > options were re Jeff's concerns that there should be two vendor
> > implementations before any final agreement?
> 
> The only way to address that is for as many as possible saying that
they 
> have tried it out and know it to work. Absent that I think there is
a 
> very good chance of this one getting blocked in the AB this time.
> 
> > Thanks for your help,
> > Ann
> BTW, there is another problem with the currently proposed resolution 
> that I just discovered while editing the draft chapters that needs 
> fixing. The proposal creates a new dependency of the
PortableInterceptor 
> module on the IIOP module, which I don't think is a very good idea
at 
> all. There is no justification for making the existence of IIOP 
> mandatory for using PortableInterceptors. I have this sinking
feeling 
> that this proposal needs to be revised very significantly to even
get 
> the packaging right.:-(
> 
> I think, if we are going to fix this one we need to consider doing
the 
> following:
> 
> 1. Consider Jon's suggestion and produce something concrete out of
it.
> 
> 2. Factor out the IIOP dependency into a separate module .... 
> IIOPIORInterceptor or some such.
> 
> 3. Also consider putting this entire thing in a separate module from
the 
> PortableInterceptor module, which is starting to get real unwieldy.
> 
> If we want to go in this direction, we should consider withdrawing
this 
> proposal from this round of the RTF and deal with it as part of the
next 
> RTF and if necessary do a report with only this resolution for 
> consideration by the AB at the Orlando meeting. On the whole it
might 
> stand a better chance of making it through if the concerns raised by
no 
> less than four AB members are addressed adequately. It might also be 
> esier to honestly make the claim about multiple implementations by
that 
> time.
> 
> Anyway, these are my thoughts after looking at it from every angle
that 
> I can think of.
> 
> I am sorry about this mess. I should have caught the packaging
problem 
> earlier, but then there always are things that slip by.
> 
> Jishnu.
> 
> 
> 
> 
> 



-- 
Jeff Mischkinsky                
jmischki@dcn.davis.ca.us        +1 530-758-9850
jeff.mischkinsky@oracle.com     +1 650-506-1975