Issue 4945: IOR processing performance (corba-rtf) Source: International Business Machines (Ms. Anne E. Collins, ann_collins(at)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 request interceptors are used. IOR access and creation performance could be improved by making better use of Java facilities to provide access to an IOR's components without the overhead of CDR encoding, and by recognising that many of the constituent parts of an IOR are identical for all objects within an object adapter. I would like to propose that we introduce a Java API for IOR, along the following lines:- An abstract model of an IOR could be defined as follows: an IOR has a type ID string, and contains TaggedProfile instances an IIOPProfile is a TaggedProfile an IIOPProfile is composed of an IIOPProfileTemplate and an object ID an IIOPProfileTemplate has an ObjectKeyTemplate, and contains TaggedComponents a TaggedComponent has an ID, and can be written to an OuputStream. a TaggedComponentFactory reads a TaggedComponent from an InputStream. It should be possible to manipulate IOR TaggedProfiles and IIOPProfileTemplate TaggedComponents using all of the facilities in the Java collections framework. Templates can be used to create IIOPProfile and ObjectKey because the basic object adapter model for object creation is to establish all properties of an IOR (except for type and object ID) 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 runs only when an object adapter is created, which is the only time that user code can add tagged components to an IOR. TaggedComponent is a framework that may be extended to support application defined TaggedComponents. It would be necessary to be able to register TaggedComponentFactory instances with an ORB, in which case any IOR unmarshalled by that ORB instance would use the registered TaggedComponentFactory to unmarshal the TaggedComponent. In order to use the IOR API, a method would be needed, probably on ORB, to obtain an abstract IOR from an object reference. Resolution: Revised Text: Actions taken: March 6, 2002: received issue February 24, 2003: moved to Core RTF April 28, 2003: closed issue Discussion: Resolution: A long discussion in the RTF concluded that this issue was language indepedent, and so belonged in the core RTF (see core issue 5439). End of Annotations:===== Subject: IOR processing performance To: java-rtf@omg.org Cc: issues@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ann Dalton1" Date: Wed, 6 Mar 2002 10:38:07 +0000 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.8 |June 18, 2001) at 06/03/2002 10:36:57 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: BhC!!+ZSd9(4-!!<28e9 The overhead of processing TaggedComponents within an IOR becomes significant when done many times, as in the case of J2EE implementations where multiple request interceptors are used. IOR access and creation performance could be improved by making better use of Java facilities to provide access to an IOR's components without the overhead of CDR encoding, and by recognising that many of the constituent parts of an IOR are identical for all objects within an object adapter. I would like to propose that we introduce a Java API for IOR, along the following lines:- An abstract model of an IOR could be defined as follows: an IOR has a type ID string, and contains TaggedProfile instances an IIOPProfile is a TaggedProfile an IIOPProfile is composed of an IIOPProfileTemplate and an object ID an IIOPProfileTemplate has an ObjectKeyTemplate, and contains TaggedComponents a TaggedComponent has an ID, and can be written to an OuputStream. a TaggedComponentFactory reads a TaggedComponent from an InputStream. It should be possible to manipulate IOR TaggedProfiles and IIOPProfileTemplate TaggedComponents using all of the facilities in the Java collections framework. Templates can be used to create IIOPProfile and ObjectKey because the basic object adapter model for object creation is to establish all properties of an IOR (except for type and object ID) 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 runs only when an object adapter is created, which is the only time that user code can add tagged components to an IOR. TaggedComponent is a framework that may be extended to support application defined TaggedComponents. It would be necessary to be able to register TaggedComponentFactory instances with an ORB, in which case any IOR unmarshalled by that ORB instance would use the registered TaggedComponentFactory to unmarshal the TaggedComponent. In order to use the IOR API, a method would be needed, probably on ORB, to obtain an abstract IOR from an object reference. Subject: Re: issue 4945 -- IOR processing performance To: Ken Cavanaugh Cc: Java RTF X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Tue, 30 Apr 2002 21:57:02 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 30/04/2002 21:56:20 X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g3UKwOe18349 I propose that this issue be resolved by the addition of a new set of APIs to the Java ORB Portability Interfaces chapter. Here is a first draft for review:- 1.21.10 J2EE APIs 1.21.10.1 Overview The APIs specified here, although they may be generally useful, are introduced primarily for the efficient support of J2EE. The overhead of processing TaggedComponents within an IOR becomes significant when done many times, as in the case of J2EE implementations where multiple request interceptors are used. The IOR API improves the performance of IOR access and creation by - making better use of Java facilities to provide access to an IOR's components without the overhead of CDR encoding. - recognising that many of the constituent parts of IOR profiles are identical for all objects within an object adapter, and can thus be abstracted out into a template. 1.21.10.2 IOR APIs Introduction The APIs described in this section imply the following abstract model of an IOR. - an IOR has a type ID string, and contains TaggedProfile instances - an IIOPProfile is a TaggedProfile - an IIOPProfile is composed of an IIOPProfileTemplate and an object ID - an IIOPProfileTemplate has IIOP addressing information, and contains TaggedComponents - a TaggedComponent has an ID, and can be written to an OuputStream - a TaggedComponentFactory reads a TaggedComponent from an InputStream The IOR APIs are found in the org.omg.CORBA.portable and org.omg.CORBA_n_m.portable packages. The ORB object is used as a factory to create an IOR from an Object reference. TaggedComponent is a generic interface for all tagged components. Users of the ORB may create implementations of this class and also corresponding factories of type TaggedComponentFactory. The factories can be registered with an ORB instance, in which case they will be used to unmarshal IORs containing the registered tagged component. package org.omg.CORBA; interface ORB { org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object); void register_tagged_component_factory(TaggedComponentFactory tcf); } package org.omg.CORBA.portable; interface IOR { public java.lang.String getTypeId(); public java.util.Iterator getProfiles(); public java.util.Iterator getProfiles(int id); } interface TaggedProfile { public int getProfileId(); } interface IIOPProfile extends TaggedProfile { public byte[] getObjectKey(); public IIOPProfileTemplate getTemplate(); } interface IIOPProfileTemplate { public java.util.Iterator getComponents(); public java.util.Iterator getComponents(int id); public byte getMajorVersion(); public byte getMinorVersion(); public java.lang.String getHost(); public int getPort(); } interface TaggedComponent { public int getId(); public void write(org.omg.CORBA.portable.OutputStream os); } interface TaggedComponentFactory { public int getId(); public TaggedComponent read(org.omg.CORBA.portable.InputStream is); } ORB Method Semantics create_IOR Return the IOR for the given Object reference. 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, BAD_INV_ORDER is raised with a standard minor code of n. Instances of this interface may be defined by users to support custom tagged components. IOR Method Semantics getTypeId Return the type id string from the IOR. getProfiles() Return an iterator over the list of tagged profiles within the IOR. It is not possible to modify the list through this iterator. getProfiles(int id) Return an iterator over the list of tagged profiles with identifier id. It is not possible to modify the list through this iterator. TaggedProfile Method Semantics getProfileId Return the profile identifier. IIOPProfile Method Semantics getObjectKey Return the Object key contained in this IIOPProfile. getTemplate Return the IIOPProfileTemplate associated with this IIOPProfile. IIOPProfileTemplate Method Semantics getComponents() Return an iterator over the list of tagged components within the IIOPProfileTemplate. It is not possible to modify the list through this iterator. getComponents(int id) Return an iterator over the list of tagged components with identifier id. It is not possible to modify the list through this iterator. getMajorVersion Return the GIOP major version of this profile. getMinorVersion Return the GIOP minor version of this profile. If the major version is 1 and the minor version is 0, this profile cannot contain any tagged components. getHost Return the host name string from the IIOP profile. getPort Return the port number from the IIOP profile. TaggedComponent Method Semantics getId Return the identifier for this tagged component. write Write this tagged component to the OutputStream os. TaggedComponentFactory Method Semantics getId Return the identifier for this tagged component factory. read Read a tagged component from the InputStream is. Date: Tue, 30 Apr 2002 14:43:18 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4945 -- IOR processing performance To: Ken.Cavanaugh@sun.com, ann_dalton@uk.ibm.com Cc: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Ann, This looks like a good start. I'll go over it in more detail, but one quick comment: all of the interfaces should be local interfaces. This makes it very easy to implement them, and introduces no ORB overhead on method invocations. This is especially useful for the TaggedComponentFactory, which must be implemented by the user. Also, the interfaces need to be placed into IDL modules and mapped into the appropriate Java package. This is necessary to determine exactly what the correct respository ID is for each interface. Thanks, Ken. Date: Tue, 30 Apr 2002 18:02:27 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en To: Ken Cavanaugh Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: issue 4945 -- IOR processing performance Ken Cavanaugh wrote: > > Ann, > > This looks like a good start. I'll go over it in more detail, > but one quick comment: all of the interfaces should be local > interfaces. This makes it very easy to implement them, and > introduces no ORB overhead on method invocations. This is especially > useful for the TaggedComponentFactory, which must be implemented > by the user. > > Also, the interfaces need to be placed into IDL modules and mapped > into the appropriate Java package. This is necessary to determine > exactly what the correct respository ID is for each interface. Presumably this is the case except for the operation in the ORB interface, since RepID if any for that interface is already known. As for the rest, I'd suggest that you create a Java specific module, unless you want o spend a lot of time discussing how all this will work in C++, Cobol and LISP:-). One other thing, you can completely eliminate any changes to the ORB interface by simply having a new parameter value for resolve_initial_references like "IORFactory", which would return a local object IORFactory which looks like: local interface IORFactory { org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object); void register_tagged_component_factory(TaggedComponentFactory tcf); }; That way you can factor this entire thing into a module of its own. Just a random thought to consider. Jishnu. Date: Tue, 30 Apr 2002 15:12:43 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4945 -- IOR processing performance To: Ken.Cavanaugh@sun.com, jishnu_mukerji@hp.com Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Jishnu Mukerji >X-Accept-Language: en >MIME-Version: 1.0 >To: Ken Cavanaugh >Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org >Subject: Re: issue 4945 -- IOR processing performance >Content-Transfer-Encoding: 7bit > >Ken Cavanaugh wrote: >> >> Ann, >> >> This looks like a good start. I'll go over it in more detail, >> but one quick comment: all of the interfaces should be local >> interfaces. This makes it very easy to implement them, and >> introduces no ORB overhead on method invocations. This is >especially >> useful for the TaggedComponentFactory, which must be implemented >> by the user. >> >> Also, the interfaces need to be placed into IDL modules and mapped >> into the appropriate Java package. This is necessary to determine >> exactly what the correct respository ID is for each interface. > >Presumably this is the case except for the operation in the ORB >interface, since RepID if any for that interface is already known. As >for the rest, I'd suggest that you create a Java specific module, >unless >you want o spend a lot of time discussing how all this will work in >C++, >Cobol and LISP:-). > Actually, on looking at this again, I realized that Ann was writing Java, and I was thinking about IDL! Sorry about the confusion on my part. >One other thing, you can completely eliminate any changes to the ORB >interface by simply having a new parameter value for >resolve_initial_references like "IORFactory", which would return a >local >object IORFactory which looks like: > >local interface IORFactory { > org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object); > void register_tagged_component_factory(TaggedComponentFactory tcf); >}; > This approach would actually force the entire package to be written as local IDL interfaces instead of Java interfaces. However, we can just introduce the Java operations directly into the Java mapping for the ORB pseudo object. This continues to extend the overly large ORB interface, but makes it clear that this set of IOR APIs is only for Java (which should have been clear to me in the first place, since this uses java.util.Iterator in several places). Ken. Date: Tue, 30 Apr 2002 18:16:22 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en To: Ken Cavanaugh Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: issue 4945 -- IOR processing performance Ken Cavanaugh wrote: > > >From: Jishnu Mukerji > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: Ken Cavanaugh > >Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org > >Subject: Re: issue 4945 -- IOR processing performance > >Content-Transfer-Encoding: 7bit > > > >Ken Cavanaugh wrote: > >> > >> Ann, > >> > >> This looks like a good start. I'll go over it in more detail, > >> but one quick comment: all of the interfaces should be local > >> interfaces. This makes it very easy to implement them, and > >> introduces no ORB overhead on method invocations. This is especially > >> useful for the TaggedComponentFactory, which must be implemented > >> by the user. > >> > >> Also, the interfaces need to be placed into IDL modules and mapped > >> into the appropriate Java package. This is necessary to determine > >> exactly what the correct respository ID is for each interface. > > > >Presumably this is the case except for the operation in the ORB > >interface, since RepID if any for that interface is already known. As > >for the rest, I'd suggest that you create a Java specific module, unless > >you want o spend a lot of time discussing how all this will work in C++, > >Cobol and LISP:-). > > > > Actually, on looking at this again, I realized that Ann was writing > Java, and I was thinking about IDL! Sorry about the confusion on > my part. > > >One other thing, you can completely eliminate any changes to the ORB > >interface by simply having a new parameter value for > >resolve_initial_references like "IORFactory", which would return a local > >object IORFactory which looks like: > > > >local interface IORFactory { > > org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object); > > void register_tagged_component_factory(TaggedComponentFactory tcf); > >}; > > > > This approach would actually force the entire package to be written as > local IDL interfaces instead of Java interfaces. However, we can > just introduce the Java operations directly into the Java mapping for > the ORB pseudo object. This continues to extend the overly large ORB > interface, but makes it clear that this set of IOR APIs is only > for Java (which should have been clear to me in the first place, since > this uses java.util.Iterator in several places). > > Ken. Ken, I was hoping that you will reach the conclusion that you reached.:-) Keep this purely in the Java Portability part. Don't touch the language independant part for this one. Jishnu. -- Jishnu Mukerji Senior Systems Architect, SSO Staff Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA tel:+1 973 443 7528 mailto:jishnu_mukerji@hp.com X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Apr 2002 15:48:58 -0700 To: Jishnu Mukerji , Ken Cavanaugh From: Andy Piper Subject: Re: issue 4945 -- IOR processing performance Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org At 06:16 PM 4/30/02 -0400, Jishnu Mukerji wrote: I was hoping that you will reach the conclusion that you reached.:-) Keep this purely in the Java Portability part. Don't touch the language independant part for this one. Right. I would like to see some discussion as to how this relates to org.omg.IOP.* This package already has most of these types defined although obviously most of these are IDL-centric. Maybe the two have no relation, but in that case we need to make it clear why. andy Date: Tue, 30 Apr 2002 18:58:14 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4945 -- IOR processing performance To: jishnu_mukerji@hp.com, Ken.Cavanaugh@sun.com, andyp@bea.com Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >X-Sender: andyp@san-francisco.beasys.com >To: Jishnu Mukerji , Ken Cavanaugh >From: Andy Piper >Subject: Re: issue 4945 -- IOR processing performance >Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org >Mime-Version: 1.0 > >At 06:16 PM 4/30/02 -0400, Jishnu Mukerji wrote: >>I was hoping that you will reach the conclusion that you reached.:-) >>Keep this purely in the Java Portability part. Don't touch the >language >>independant part for this one. > >Right. > >I would like to see some discussion as to how this relates to >org.omg.IOP.* > >This package already has most of these types defined although >obviously >most of these are IDL-centric. Maybe the two have no relation, but in >that >case we need to make it clear why. > org.omg.IOP.* basically defines the structures used to represent IORs in the GIOP encoding. This means for example that an IOR contains a type string followed by a sequence of CDR encapsulated profiles. Similarly, an IIOP profile contains a sequence of CDR encapsulated components. However, an ORB may choose not to represent IORs this way internally for efficiency of processing. For example, CSIv2 data is contained inside a tagged component inside an IIOP profile. Accessing this data from org.omg.IOP.* definitions requires unmarshalling using codecs, which is quite slow. Exposing IORs with the proposed APIs is more efficient, because the proposed APIs can be mapped efficiently onto an internal ORB specific representation of an IOR. For example, a CSIv2 implementation would register tagged component factories specific to CSIv2. When an ORB unmarshalls an IOR (or at some later time), it can unmarshal the data once, and make it efficiently available whenever it is needed. This has become a problem mostly due to portable interceptors, which often require access to data inside the IOR. Ken. Date: Fri, 03 May 2002 12:10:46 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ann Dalton1 CC: Ken Cavanaugh , Java RTF Subject: Re: issue 4945 -- IOR processing performance X-OriginalArrivalTime: 03 May 2002 11:10:31.0951 (UTC) FILETIME=[23E689F0:01C1F293] Ann, I have a few issues with your proposal, which I believe exposes too much of the ORB's internal IOR management logic. First your idea of codifying the concept of an IOR template associated with an object adapter instance. While its likely that many ORB implementations follow this pattern (the IONA ORB included), I don't think this is required anywhere in the spec. Is it required for example that all IIOP profiles in IORs associated with a particular object adapter instance share all the values (host, port etc.) encapsulated in your IIOPProfileTemplate interface? I don't think its prescribed that a object adapter instance maps onto a TCP endpoint, and am concenred about unduely contstraining POA implementations. Secondly, what mechanism is proposed to acquire a reference to a particular profile type? Checking the TaggedProfile.getProfileId() against org.omg.IOP.TAG_INTERNET_IOP and then casting down to org.omg.CORBA_n_m.portable.IIOPProfile? Is it intended that a convenience interface is introduced for each new profile type that's defined (e.g. for new transports such as MIOP)? If you're going to go that far, why not introduce convenience interfaces for each tagged component also - i.e. everything from AlternateIIOPAddressComponent to CodeSetsComponent etc. It seems to me that the net effect would be to introduce a whole layer of duplication between the CORBA::IOP IDL definitions and the org.omg.CORBA_n_m.portable package, with all the issues around consistency and versioning that this would imply. Thirdly individual ORB implementations may have introduced certain optimizations in IOR management, for example around flyweighting, that may require that the semantics of profile and component factories are constrained in certain ways. I'm not sure how this can be accomodated in you proposal. Finally I'd like to understand what performance benefits this would provide to portable interceptors. In my understanding, PIs currently may access a particular tagged component from the target IOR via ClientRequestInfo::get_effective_component() - the octet sequence body of the componment must then be explicitly demarshalled by the PI, which obviously incurs some cost. However it seems the same cost is incurred under your proposal via TaggedComponent.write(). I don't see the benefit unless there's a TaggedComponent specialization for each tag, which would provide direct access to the elements of the component body. However introducing a convenience interfaces for each tagged components is IMO a bad idea from a duplication/consistency/versioning point of view as explained above. Regards, Eoghan. Ann Dalton1 wrote: > > I propose that this issue be resolved by the addition of a new set > of APIs to the Java ORB Portability Interfaces chapter. Here is a > first draft for review:- > > 1.21.10 J2EE APIs > > 1.21.10.1 Overview > The APIs specified here, although they may be generally useful, are > introduced primarily for the efficient support of J2EE. > > The overhead of processing TaggedComponents within an IOR becomes > significant when done many times, as in the case of J2EE implementations > where multiple request interceptors are used. The IOR API improves the > performance of IOR access and creation by > - making better use of Java facilities to provide access to an IOR's > components without the overhead of CDR encoding. > - recognising that many of the constituent parts of IOR profiles are > identical for all objects within an object adapter, and can thus be > abstracted out into a template. > > 1.21.10.2 IOR APIs > > Introduction > The APIs described in this section imply the following abstract model of > an IOR. > - an IOR has a type ID string, and contains TaggedProfile instances > - an IIOPProfile is a TaggedProfile > - an IIOPProfile is composed of an IIOPProfileTemplate and an object ID > - an IIOPProfileTemplate has IIOP addressing information, and contains > TaggedComponents > - a TaggedComponent has an ID, and can be written to an OuputStream > - a TaggedComponentFactory reads a TaggedComponent from an InputStream > > The IOR APIs are found in the org.omg.CORBA.portable and > org.omg.CORBA_n_m.portable packages. The ORB object is used as a factory > to create an IOR from an Object reference. > > TaggedComponent is a generic interface for all tagged components. Users of > the ORB may create implementations of this class and also corresponding > factories of type TaggedComponentFactory. The factories can be registered > with an ORB instance, in which case they will be used to unmarshal IORs > containing the registered tagged component. > > package org.omg.CORBA; > > interface ORB { > org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object); > void register_tagged_component_factory(TaggedComponentFactory tcf); > } > > package org.omg.CORBA.portable; > > interface IOR { > public java.lang.String getTypeId(); > public java.util.Iterator getProfiles(); > public java.util.Iterator getProfiles(int id); > } > > interface TaggedProfile { > public int getProfileId(); > } > > interface IIOPProfile extends TaggedProfile { > public byte[] getObjectKey(); > public IIOPProfileTemplate getTemplate(); > } > > interface IIOPProfileTemplate { > public java.util.Iterator getComponents(); > public java.util.Iterator getComponents(int id); > public byte getMajorVersion(); > public byte getMinorVersion(); > public java.lang.String getHost(); > public int getPort(); > } > > interface TaggedComponent { > public int getId(); > public void write(org.omg.CORBA.portable.OutputStream os); > } > > interface TaggedComponentFactory { > public int getId(); > public TaggedComponent read(org.omg.CORBA.portable.InputStream is); > } > > ORB Method Semantics > > create_IOR > Return the IOR for the given Object reference. > > 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, BAD_INV_ORDER is raised with a > standard minor code of n. > Instances of this interface may be defined by users to support custom > tagged components. > > IOR Method Semantics > > getTypeId > Return the type id string from the IOR. > > getProfiles() > Return an iterator over the list of tagged profiles within the IOR. > It is not possible to modify the list through this iterator. > > getProfiles(int id) > Return an iterator over the list of tagged profiles with identifier id. > It is not possible to modify the list through this iterator. > > TaggedProfile Method Semantics > > getProfileId > Return the profile identifier. > > IIOPProfile Method Semantics > > getObjectKey > Return the Object key contained in this IIOPProfile. > > getTemplate > Return the IIOPProfileTemplate associated with this IIOPProfile. > > IIOPProfileTemplate Method Semantics > > getComponents() > Return an iterator over the list of tagged components within the > IIOPProfileTemplate. > It is not possible to modify the list through this iterator. > > getComponents(int id) > Return an iterator over the list of tagged components with identifier > id. > It is not possible to modify the list through this iterator. > > getMajorVersion > Return the GIOP major version of this profile. > > getMinorVersion > Return the GIOP minor version of this profile. If the major version is 1 > and the > minor version is 0, this profile cannot contain any tagged components. > > getHost > Return the host name string from the IIOP profile. > > getPort > Return the port number from the IIOP profile. > > TaggedComponent Method Semantics > > getId > Return the identifier for this tagged component. > > write > Write this tagged component to the OutputStream os. > > TaggedComponentFactory Method Semantics > > getId > Return the identifier for this tagged component factory. > > read > Read a tagged component from the InputStream is. -- 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 X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 May 2002 11:14:45 -0700 To: Ken Cavanaugh , jishnu_mukerji@hp.com, Ken.Cavanaugh@Sun.COM From: Andy Piper Subject: Re: issue 4945 -- IOR processing performance Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org Ok, understand. So does this mean that we will have two competing sets of API's available to interceptors? I guess that's my point - the use cases for these two things are essentially the same. It would be helpful if the structure and docs could somehow reflect what is to be used when. andy At 06:58 PM 4/30/02 -0700, Ken Cavanaugh wrote: >X-Sender: andyp@san-francisco.beasys.com >To: Jishnu Mukerji , Ken Cavanaugh >From: Andy Piper >Subject: Re: issue 4945 -- IOR processing performance >Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org >Mime-Version: 1.0 > >At 06:16 PM 4/30/02 -0400, Jishnu Mukerji wrote: >>I was hoping that you will reach the conclusion that you reached.:-) >>Keep this purely in the Java Portability part. Don't touch the >language >>independant part for this one. > >Right. > >I would like to see some discussion as to how this relates to >org.omg.IOP.* > >This package already has most of these types defined although >obviously >most of these are IDL-centric. Maybe the two have no relation, but in >that >case we need to make it clear why. > org.omg.IOP.* basically defines the structures used to represent IORs in the GIOP encoding. This means for example that an IOR contains a type string followed by a sequence of CDR encapsulated profiles. Similarly, an IIOP profile contains a sequence of CDR encapsulated components. However, an ORB may choose not to represent IORs this way internally for efficiency of processing. For example, CSIv2 data is contained inside a tagged component inside an IIOP profile. Accessing this data from org.omg.IOP.* definitions requires unmarshalling using codecs, which is quite slow. Exposing IORs with the proposed APIs is more efficient, because the proposed APIs can be mapped efficiently onto an internal ORB specific representation of an IOR. For example, a CSIv2 implementation would register tagged component factories specific to CSIv2. When an ORB unmarshalls an IOR (or at some later time), it can unmarshal the data once, and make it efficiently available whenever it is needed. This has become a problem mostly due to portable interceptors, which often require access to data inside the IOR. Ken. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 May 2002 11:17:08 -0700 To: Eoghan Glynn , Ann Dalton1 From: Andy Piper Subject: Re: issue 4945 -- IOR processing performance Cc: Ken Cavanaugh , Java RTF At 12:10 PM 5/3/02 +0100, Eoghan Glynn wrote: Ann, I have a few issues with your proposal, which I believe exposes too much of the ORB's internal IOR management logic. First your idea of codifying the concept of an IOR template associated with an object adapter instance. While its likely that many ORB implementations follow this pattern (the IONA ORB included), I don't think this is required anywhere in the spec. Is it required for example that all IIOP profiles in IORs associated with a particular object adapter instance share all the values (host, port etc.) encapsulated in your IIOPProfileTemplate interface? I don't think its prescribed that a object adapter instance maps onto a TCP endpoint, and am concenred about unduely contstraining POA implementations. Secondly, what mechanism is proposed to acquire a reference to a particular profile type? Checking the TaggedProfile.getProfileId() against org.omg.IOP.TAG_INTERNET_IOP and then casting down to org.omg.CORBA_n_m.portable.IIOPProfile? Is it intended that a convenience interface is introduced for each new profile type that's defined (e.g. for new transports such as MIOP)? If you're going to go that far, why not introduce convenience interfaces for each tagged component also - i.e. everything from AlternateIIOPAddressComponent to CodeSetsComponent etc. It seems to me that the net effect would be to introduce a whole layer of duplication between the CORBA::IOP IDL definitions and the org.omg.CORBA_n_m.portable package, with all the issues around consistency and versioning that this would imply. Thirdly individual ORB implementations may have introduced certain optimizations in IOR management, for example around flyweighting, that may require that the semantics of profile and component factories are constrained in certain ways. I'm not sure how this can be accomodated in you proposal. Finally I'd like to understand what performance benefits this would provide to portable interceptors. In my understanding, PIs currently may access a particular tagged component from the target IOR via ClientRequestInfo::get_effective_component() - the octet sequence body of the componment must then be explicitly demarshalled by the PI, which obviously incurs some cost. However it seems the same cost is incurred under your proposal via TaggedComponent.write(). I don't see the benefit unless there's a TaggedComponent specialization for each tag, which would provide direct access to the elements of the component body. However introducing a convenience interfaces for each tagged components is IMO a bad idea from a duplication/consistency/versioning point of view as explained above. Agree andy Subject: To: Eoghan Glynn Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Tue, 7 May 2002 21:27:58 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 07/05/2002 21:27:23 Eoghan, Have tried to answer your points, below. Thanks, Ann >Eoghan Glynn wrote: > >Ann, > >I have a few issues with your proposal, which I believe exposes too >much >of the ORB's internal IOR management logic. > >First your idea of codifying the concept of an IOR template >associated >with an object adapter instance. While its likely that many ORB >implementations follow this pattern (the IONA ORB included), I don't >think this is required anywhere in the spec. Is it required for >example >that all IIOP profiles in IORs associated with a particular object >adapter instance share all the values (host, port etc.) encapsulated >in >your IIOPProfileTemplate interface? I don't think its prescribed that >a >object adapter instance maps onto a TCP endpoint, and am concenred >about >unduely contstraining POA implementations. I don't think the proposal constrains all IORs associated with a particular object adapter to reference the same IIOPProfileTemplate, although it is likely that they will. It just recognises that many IORs are likely to share those IIOP characteristics that have been grouped together. It would be possible to implement the API by having each IOR reference a unique template, or by having groups of IORs within different object adapters share a template. > >Secondly, what mechanism is proposed to acquire a reference to a >particular profile type? Checking the TaggedProfile.getProfileId() >against org.omg.IOP.TAG_INTERNET_IOP and then casting down to >org.omg.CORBA_n_m.portable.IIOPProfile? Is it intended that a >convenience interface is introduced for each new profile type that's >defined (e.g. for new transports such as MIOP)? If you're going to go >that far, why not introduce convenience interfaces for each tagged >component also - i.e. everything from AlternateIIOPAddressComponent >to >CodeSetsComponent etc. It seems to me that the net effect would be to >introduce a whole layer of duplication between the CORBA::IOP IDL >definitions and the org.omg.CORBA_n_m.portable package, with all the >issues around consistency and versioning that this would imply. The reference can be obtained by supplying the TAG_INTERNET_IOP id to the getProfiles(id) method, or checking as you suggest. The convenience interface is introduced for the IIOP profile as the IIOP profile information may be supplied to the base ORB by the J2EE implementation. I'm not sugggesting introducing further such interfaces but would look at each/any case on its merits. > >Thirdly individual ORB implementations may have introduced certain >optimizations in IOR management, for example around flyweighting, >that >may require that the semantics of profile and component factories are >constrained in certain ways. I'm not sure how this can be accomodated >in >you proposal. Do you have an example in mind? > >Finally I'd like to understand what performance benefits this would >provide to portable interceptors. In my understanding, PIs currently >may >access a particular tagged component from the target IOR via >ClientRequestInfo::get_effective_component() - the octet sequence >body >of the componment must then be explicitly demarshalled by the PI, >which >obviously incurs some cost. However it seems the same cost is >incurred >under your proposal via TaggedComponent.write(). I don't see the >benefit >unless there's a TaggedComponent specialization for each tag, which >would provide direct access to the elements of the component body. >However introducing a convenience interfaces for each tagged >components >is IMO a bad idea from a duplication/consistency/versioning point of >view as explained above. The TaggedComponentFactory instances registered with the ORB to demarshal TCs can be specialized as required, as can the TaggedComponent instances used by the PIs to write them. I wasn't suggesting we define Java portable interfaces for each one. > >Regards, >Eoghan. > >Ann Dalton1 wrote: >> >> I propose that this issue be resolved by the addition of a new set >> of APIs to the Java ORB Portability Interfaces chapter. Here is a >> first draft for review:- >> >> 1.21.10 J2EE APIs >> >> 1.21.10.1 Overview >> The APIs specified here, although they may be generally useful, are >> introduced primarily for the efficient support of J2EE. >> >> The overhead of processing TaggedComponents within an IOR becomes >> significant when done many times, as in the case of J2EE >implementations >> where multiple request interceptors are used. The IOR API improves >the >> performance of IOR access and creation by >> - making better use of Java facilities to provide access to an >IOR's >> components without the overhead of CDR encoding. >> - recognising that many of the constituent parts of IOR profiles >are >> identical for all objects within an object adapter, and can thus >be >> abstracted out into a template. >> >> 1.21.10.2 IOR APIs >> >> Introduction >> The APIs described in this section imply the following abstract >model of >> an IOR. >> - an IOR has a type ID string, and contains TaggedProfile >instances >> - an IIOPProfile is a TaggedProfile >> - an IIOPProfile is composed of an IIOPProfileTemplate and an >object ID >> - an IIOPProfileTemplate has IIOP addressing information, and contains >> TaggedComponents >> - a TaggedComponent has an ID, and can be written to an >OuputStream >> - a TaggedComponentFactory reads a TaggedComponent from an InputStream >> >> The IOR APIs are found in the org.omg.CORBA.portable and >> org.omg.CORBA_n_m.portable packages. The ORB object is used as a >factory >> to create an IOR from an Object reference. >> >> TaggedComponent is a generic interface for all tagged >components. Users of >> the ORB may create implementations of this class and also >corresponding >> factories of type TaggedComponentFactory. The factories can be registered >> with an ORB instance, in which case they will be used to unmarshal >IORs >> containing the registered tagged component. >> >> package org.omg.CORBA; >> >> interface ORB { >> org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object); >> void register_tagged_component_factory(TaggedComponentFactory tcf); >> } >> >> package org.omg.CORBA.portable; >> >> interface IOR { >> public java.lang.String getTypeId(); >> public java.util.Iterator getProfiles(); >> public java.util.Iterator getProfiles(int id); >> } >> >> interface TaggedProfile { >> public int getProfileId(); >> } >> >> interface IIOPProfile extends TaggedProfile { >> public byte[] getObjectKey(); >> public IIOPProfileTemplate getTemplate(); >> } >> >> interface IIOPProfileTemplate { >> public java.util.Iterator getComponents(); >> public java.util.Iterator getComponents(int id); >> public byte getMajorVersion(); >> public byte getMinorVersion(); >> public java.lang.String getHost(); >> public int getPort(); >> } >> >> interface TaggedComponent { >> public int getId(); >> public void write(org.omg.CORBA.portable.OutputStream os); >> } >> >> interface TaggedComponentFactory { >> public int getId(); >> public TaggedComponent >read(org.omg.CORBA.portable.InputStream is); >> } >> >> ORB Method Semantics >> >> create_IOR >> Return the IOR for the given Object reference. >> >> 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, BAD_INV_ORDER is raised with a >> standard minor code of n. >> Instances of this interface may be defined by users to support >custom >> tagged components. >> >> IOR Method Semantics >> >> getTypeId >> Return the type id string from the IOR. >> >> getProfiles() >> Return an iterator over the list of tagged profiles within the >IOR. >> It is not possible to modify the list through this iterator. >> >> getProfiles(int id) >> Return an iterator over the list of tagged profiles with >identifier id. >> It is not possible to modify the list through this iterator. >> >> TaggedProfile Method Semantics >> >> getProfileId >> Return the profile identifier. >> >> IIOPProfile Method Semantics >> >> getObjectKey >> Return the Object key contained in this IIOPProfile. >> >> getTemplate >> Return the IIOPProfileTemplate associated with this IIOPProfile. >> >> IIOPProfileTemplate Method Semantics >> >> getComponents() >> Return an iterator over the list of tagged components within the >> IIOPProfileTemplate. >> It is not possible to modify the list through this iterator. >> >> getComponents(int id) >> Return an iterator over the list of tagged components with >identifier >> id. >> It is not possible to modify the list through this iterator. >> >> getMajorVersion >> Return the GIOP major version of this profile. >> >> getMinorVersion >> Return the GIOP minor version of this profile. If the major >version >> is 1 and the minor version is 0, this profile cannot contain any >> tagged components. >> >> getHost >> Return the host name string from the IIOP profile. >> >> getPort >> Return the port number from the IIOP profile. >> >> TaggedComponent Method Semantics >> >> getId >> Return the identifier for this tagged component. >> >> write >> Write this tagged component to the OutputStream os. >> >> TaggedComponentFactory Method Semantics >> >> getId >> Return the identifier for this tagged component factory. >> >> read >> Read a tagged component from the InputStream is. > >-- > >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 4945 - IOR processing performance To: Eoghan Glynn Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Tue, 7 May 2002 21:35:21 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 07/05/2002 21:34:40 Eoghan, Have tried to answer your points, below. Thanks, Ann >Eoghan Glynn wrote: > >Ann, > >I have a few issues with your proposal, which I believe exposes too >much >of the ORB's internal IOR management logic. > >First your idea of codifying the concept of an IOR template >associated >with an object adapter instance. While its likely that many ORB >implementations follow this pattern (the IONA ORB included), I don't >think this is required anywhere in the spec. Is it required for >example >that all IIOP profiles in IORs associated with a particular object >adapter instance share all the values (host, port etc.) encapsulated >in >your IIOPProfileTemplate interface? I don't think its prescribed that >a >object adapter instance maps onto a TCP endpoint, and am concenred >about >unduely contstraining POA implementations. I don't think the proposal constrains all IORs associated with a particular object adapter to reference the same IIOPProfileTemplate, although it is likely that they will. It just recognises that many IORs are likely to share those IIOP characteristics that have been grouped together. It would be possible to implement the API by having each IOR reference a unique template, or by having groups of IORs within different object adapters share a template. > >Secondly, what mechanism is proposed to acquire a reference to a >particular profile type? Checking the TaggedProfile.getProfileId() >against org.omg.IOP.TAG_INTERNET_IOP and then casting down to >org.omg.CORBA_n_m.portable.IIOPProfile? Is it intended that a >convenience interface is introduced for each new profile type that's >defined (e.g. for new transports such as MIOP)? If you're going to go >that far, why not introduce convenience interfaces for each tagged >component also - i.e. everything from AlternateIIOPAddressComponent >to >CodeSetsComponent etc. It seems to me that the net effect would be to >introduce a whole layer of duplication between the CORBA::IOP IDL >definitions and the org.omg.CORBA_n_m.portable package, with all the >issues around consistency and versioning that this would imply. The reference can be obtained by supplying the TAG_INTERNET_IOP id to the getProfiles(id) method, or checking as you suggest. The convenience interface is introduced for the IIOP profile as the IIOP profile information may be supplied to the base ORB by the J2EE implementation. I'm not sugggesting introducing further such interfaces but would look at each/any case on its merits. > >Thirdly individual ORB implementations may have introduced certain >optimizations in IOR management, for example around flyweighting, >that >may require that the semantics of profile and component factories are >constrained in certain ways. I'm not sure how this can be accomodated >in >you proposal. Do you have an example in mind? > >Finally I'd like to understand what performance benefits this would >provide to portable interceptors. In my understanding, PIs currently >may >access a particular tagged component from the target IOR via >ClientRequestInfo::get_effective_component() - the octet sequence >body >of the componment must then be explicitly demarshalled by the PI, >which >obviously incurs some cost. However it seems the same cost is >incurred >under your proposal via TaggedComponent.write(). I don't see the >benefit >unless there's a TaggedComponent specialization for each tag, which >would provide direct access to the elements of the component body. >However introducing a convenience interfaces for each tagged >components >is IMO a bad idea from a duplication/consistency/versioning point of >view as explained above. The TaggedComponentFactory instances registered with the ORB to demarshal TCs can be specialized as required, as can the TaggedComponent instances used by the PIs to write them. I wasn't suggesting we define Java portable interfaces for each one. > >Regards, >Eoghan. > >Ann Dalton1 wrote: >> >> I propose that this issue be resolved by the addition of a new set >> of APIs to the Java ORB Portability Interfaces chapter. Here is a >> first draft for review:- >> >> 1.21.10 J2EE APIs >> >> 1.21.10.1 Overview >> The APIs specified here, although they may be generally useful, are >> introduced primarily for the efficient support of J2EE. >> >> The overhead of processing TaggedComponents within an IOR becomes >> significant when done many times, as in the case of J2EE >implementations >> where multiple request interceptors are used. The IOR API improves >the >> performance of IOR access and creation by >> - making better use of Java facilities to provide access to an >IOR's >> components without the overhead of CDR encoding. >> - recognising that many of the constituent parts of IOR profiles >are >> identical for all objects within an object adapter, and can thus >be >> abstracted out into a template. >> >> 1.21.10.2 IOR APIs >> >> Introduction >> The APIs described in this section imply the following abstract >model of >> an IOR. >> - an IOR has a type ID string, and contains TaggedProfile >instances >> - an IIOPProfile is a TaggedProfile >> - an IIOPProfile is composed of an IIOPProfileTemplate and an >object ID >> - an IIOPProfileTemplate has IIOP addressing information, and contains >> TaggedComponents >> - a TaggedComponent has an ID, and can be written to an >OuputStream >> - a TaggedComponentFactory reads a TaggedComponent from an InputStream >> >> The IOR APIs are found in the org.omg.CORBA.portable and >> org.omg.CORBA_n_m.portable packages. The ORB object is used as a >factory >> to create an IOR from an Object reference. >> >> TaggedComponent is a generic interface for all tagged >components. Users of >> the ORB may create implementations of this class and also >corresponding >> factories of type TaggedComponentFactory. The factories can be registered >> with an ORB instance, in which case they will be used to unmarshal >IORs >> containing the registered tagged component. >> >> package org.omg.CORBA; >> >> interface ORB { >> org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object); >> void register_tagged_component_factory(TaggedComponentFactory tcf); >> } >> >> package org.omg.CORBA.portable; >> >> interface IOR { >> public java.lang.String getTypeId(); >> public java.util.Iterator getProfiles(); >> public java.util.Iterator getProfiles(int id); >> } >> >> interface TaggedProfile { >> public int getProfileId(); >> } >> >> interface IIOPProfile extends TaggedProfile { >> public byte[] getObjectKey(); >> public IIOPProfileTemplate getTemplate(); >> } >> >> interface IIOPProfileTemplate { >> public java.util.Iterator getComponents(); >> public java.util.Iterator getComponents(int id); >> public byte getMajorVersion(); >> public byte getMinorVersion(); >> public java.lang.String getHost(); >> public int getPort(); >> } >> >> interface TaggedComponent { >> public int getId(); >> public void write(org.omg.CORBA.portable.OutputStream os); >> } >> >> interface TaggedComponentFactory { >> public int getId(); >> public TaggedComponent >read(org.omg.CORBA.portable.InputStream is); >> } >> >> ORB Method Semantics >> >> create_IOR >> Return the IOR for the given Object reference. >> >> 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, BAD_INV_ORDER is raised with a >> standard minor code of n. >> Instances of this interface may be defined by users to support >custom >> tagged components. >> >> IOR Method Semantics >> >> getTypeId >> Return the type id string from the IOR. >> >> getProfiles() >> Return an iterator over the list of tagged profiles within the >IOR. >> It is not possible to modify the list through this iterator. >> >> getProfiles(int id) >> Return an iterator over the list of tagged profiles with >identifier id. >> It is not possible to modify the list through this iterator. >> >> TaggedProfile Method Semantics >> >> getProfileId >> Return the profile identifier. >> >> IIOPProfile Method Semantics >> >> getObjectKey >> Return the Object key contained in this IIOPProfile. >> >> getTemplate >> Return the IIOPProfileTemplate associated with this IIOPProfile. >> >> IIOPProfileTemplate Method Semantics >> >> getComponents() >> Return an iterator over the list of tagged components within the >> IIOPProfileTemplate. >> It is not possible to modify the list through this iterator. >> >> getComponents(int id) >> Return an iterator over the list of tagged components with >identifier >> id. >> It is not possible to modify the list through this iterator. >> >> getMajorVersion >> Return the GIOP major version of this profile. >> >> getMinorVersion >> Return the GIOP minor version of this profile. If the major >version >> is 1 and the minor version is 0, this profile cannot contain any >> tagged components. >> >> getHost >> Return the host name string from the IIOP profile. >> >> getPort >> Return the port number from the IIOP profile. >> >> TaggedComponent Method Semantics >> >> getId >> Return the identifier for this tagged component. >> >> write >> Write this tagged component to the OutputStream os. >> >> TaggedComponentFactory Method Semantics >> >> getId >> Return the identifier for this tagged component factory. >> >> read >> Read a tagged component from the InputStream is. > >-- > >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 4945 - IOR processing performance To: Eoghan Glynn Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Fri, 10 May 2002 14:17:26 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 10/05/2002 14:16:45 Eoghan, Some further thoughts, Cheers, Ann Eoghan Glynn wrote: > > True, your proposal doesn't *require* that there's a 1:1 mapping >between > object adapters and templates, but it certainly suggests that is >likely > to be the case ("recognising that many of the constituent parts of >IOR > profiles are identical for all objects within an object adapter"). I > don't think its appropriate to colour the spec with any assumptions > about ORB implementation strategy. I agree that the spec is not the place for implementation strategies. It would be better if this introductory paragraph said something like "recognising that many of the constituent parts of IOR profiles are identical for different objects" > If a convenience interface is not supplied for a particular profile type > (other that TAG_INTERNET_IOP), then I can't see how these proposed > interfaces provide any help at all. For example, supposing I want to > parse a multi-component profile - I call > IOR.getProfiles(TAG_MULTIPLE_COMPONENTS) and get back a TaggedProfile. > However this object is completely useless to me as I can't either: > > a) down-cast it to a specialized MultiComponentProfile that provides > direct access to the profile specific data > > or: > > b) access the profile body as a byte[] and demarshall directly. I'm not sure that it's right to assert that the proposal is no help at all just because it doesn't help with processing all profile types, but a) If there is a need to access TAG_MULTIPLE_COMPONENTS from Java in this way, a convenience interface could be defined. I would prefer not to do so unless/until there is a requirement for it. If we were to proceed with this API, would you like to see a MultipleComponentsProfile interface defined? b) Would adding a general purpose method to access the profile body make it more acceptable? e.g add one or both of the following methods to the TaggedProfile interface. public byte[] getEncapsulation(); public void write(org.omg.CORBA.portable.OutputStream os); defined as getEncapsulation Returns all the information encapsulated by this tagged profile as a byte array. write Write this tagged profile to the OutputStream os. > Similarly I'd need a specialized TaggedComponent interface for each > component type present in the multi-component profile, otherwise I'd > end > up either directly parsing the component bodies or using a > proprietary > component-specific interface as before. As you say this is a similar concern. The intention is that consumers of tagged components will provide implementations of the TaggedComponentFactory that the ORB will use when demarshaling, and corresponding TaggedComponent implementations for marshaling. I think the main difference is that these are likely to be contained within a service implementation and less likely to be required across product implementations. Where they are more general, i.e defined in the core but need to be accessed by non-core services, then appropriate convenience APIs could be defined. As above, I'd rather do that when/if there is a requirement. The proposal for TaggedComponent already includes a generalised write method; alternatively/additionally a getEncapsulation could be provided to return the component data as a byte []. > Without going into detail on the IOR management strategy used by the > IONA ORB, suffice to say that extensive use is made of the > flyweighting > pattern for scalability reasons, which constrains the semantics of > profile and component factories. I'm concerned that, since it is necessary to access this core data from other products i.e J2EE implementations from a variety of vendors, there should be an efficient standard way to do it, without relying on proprietary features of any particular J2SE implementation. Is it possible to modify the API proposal in a way that would make it more acceptable to/convenient for IONA? > Again I don't see the point unless there are convenience interfaces > available for *all* the standard component types - i.e. what benefit > is > there in providing a Java portable interface to get a reference to a > TaggedCommponent, but then having to cast down to a proprietary > specialized interface in order to derive any performance > improvement? I'm sorry, I don't understand this concern. Even if all known tagged component types had convenience interfaces, would you not still expect to get the TaggedComponent and cast down to the specialized subtype? The advantage is surely in being able to demarshal the data once, hold the data as a Java object and use the registered, albeit proprietary or service defined, class to handle it. > If this mechanism really is required, then IMO the Java portability > layer is the wrong place to define it. Why not add analogous IDL > interfaces to the IOP IDL module so that any language mapping may > take > advantage, and needless duplication is avoided? The driver for this is to avoid the overhead of repeated demarshaling of CDR encapsulations when there are Java facilities that could be used to access the data more efficiently. I don't think I can add anything to Ken's response to Jishnu earlier:- org.omg.IOP.* basically defines the structures used to represent IORs in the GIOP encoding. This means for example that an IOR contains a type string followed by a sequence of CDR encapsulated profiles. Similarly, an IIOP profile contains a sequence of CDR encapsulated components. However, an ORB may choose not to represent IORs this way internally for efficiency of processing. For example, CSIv2 data is contained inside a tagged component inside an IIOP profile. Accessing this data from org.omg.IOP.* definitions requires unmarshalling using codecs, which is quite slow. Exposing IORs with the proposed APIs is more efficient, because the proposed APIs can be mapped efficiently onto an internal ORB specific representation of an IOR. For example, a CSIv2 implementation would register tagged component factories specific to CSIv2. When an ORB unmarshalls an IOR (or at some later time), it can unmarshal the data once, and make it efficiently available whenever it is needed. This has become a problem mostly due to portable interceptors, which often require access to data inside the IOR. Date: Tue, 14 May 2002 13:46:16 +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 CC: java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance X-OriginalArrivalTime: 14 May 2002 12:46:01.0795 (UTC) FILETIME=[4DB29930:01C1FB45] [resent after several failed attempts to get thru to java-rtf@omg.org] Ann, Thanks for the reponse ... comments line. Ann Dalton1 wrote: > I don't think the proposal constrains all IORs associated with a > particular object adapter to reference the same IIOPProfileTemplate, > although it is likely that they will. It just recognises that many > IORs are likely to share those IIOP characteristics that have been > grouped together. It would be possible to implement the API by having > each IOR reference a unique template, or by having groups of IORs > within different object adapters share a template. True, your proposal doesn't *require* that there's a 1:1 mapping between object adapters and templates, but it certainly suggests that is likely to be the case ("recognising that many of the constituent parts of IOR profiles are identical for all objects within an object adapter"). I don't think its appropriate to colour the spec with any assumptions about ORB implementation strategy. > The reference can be obtained by supplying the TAG_INTERNET_IOP > id to the getProfiles(id) method, or checking as you suggest. The > convenience interface is introduced for the IIOP profile as the > IIOP > profile information may be supplied to the base ORB by the J2EE > implementation. I'm not sugggesting introducing further > suchinterfaces > but would look at each/any case on its merits. If a convenience interface is not supplied for a particular profile type (other that TAG_INTERNET_IOP), then I can't see how these proposed interfaces provide any help at all. For example, supposing I want to parse a multi-component profile - I call IOR.getProfiles(TAG_MULTIPLE_COMPONENTS) and get back a TaggedProfile. However this object is completely useless to me as I can't either: a) down-cast it to a specialized MultiComponentProfile that provides direct access to the profile specific data or: b) access the profile body as a byte[] and demarshall directly. Similarly I'd need a specialized TaggedComponent interface for each component type present in the multi-component profile, otherwise I'd end up either directly parsing the component bodies or using a proprietary component-specific interface as before. So my argument is that in order for the proposal to be useful, specialized convenience interfaces must be provided for each profile and component type, but this approach would lead to horrible duplication, versioning and consistency issues viz. the IOP IDL. > Do you have an example in mind? Without going into detail on the IOR management strategy used by the IONA ORB, suffice to say that extensive use is made of the flyweighting pattern for scalability reasons, which constrains the semantics of profile and component factories. > The TaggedComponentFactory instances registered with the ORB to demarshal > TCs can be specialized as required, as can the TaggedComponent instances > used by the PIs to write them. I wasn't suggesting we define Java portable > interfaces for each one. Again I don't see the point unless there are convenience interfaces available for *all* the standard component types - i.e. what benefit is there in providing a Java portable interface to get a reference to a TaggedCommponent, but then having to cast down to a proprietary specialized interface in order to derive any performance improvement? If this mechanism really is required, then IMO the Java portability layer is the wrong place to define it. Why not add analogous IDL interfaces to the IOP IDL module so that any language mapping may take advantage, and needless duplication is avoided? 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: Tue, 14 May 2002 13:47:01 +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 CC: java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance X-OriginalArrivalTime: 14 May 2002 12:46:47.0202 (UTC) FILETIME=[68C32820:01C1FB45] Ann, Comments inline ... Ann Dalton1 wrote: > I agree that the spec is not the place for implementation strategies. It would be better if this introductory paragraph said something like "recognising that many of the constituent parts of IOR profiles are identical for different objects" OK. I'm not sure that it's right to assert that the proposal is no help at all just because it doesn't help with processing all profile types, but My assertion was that the proposal as it stands doesn't help at all for profile types other than TAG_INTERNET_IOP. a) If there is a need to access TAG_MULTIPLE_COMPONENTS from Java in this way, a convenience interface could be defined. I would prefer not to do so unless/until there is a requirement for it. If we were to proceed with this API, would you like to see a MultipleComponentsProfile interface defined? There's nothing language specific about TAG_MULTIPLE_COMPONENTS - a C++, or Ada, or Smalltalk, or COBOL application that processes IORs is just as likely to come across a multi-compoent profile as a Java application. My point is that the logical conclusion to your proposal is that a convenience interface should be defined for every standard profile and component type - otherwise applications would have to take an inconsistent approach to processing IORs, depending on the profile and component types encountered. However all of these types are already defined in the IOP IDL - so what do we gain by defining conveneience interfaces only in Java? A whole lot of grief when it comes to maintaining consistency between the IOP IDL and the Java convenience interfaces given that these would described in different specs and maintained by different RTFs. So if convenience interfaces are really required, I would argue strongly that the only correct way to define these interfaces is IDL. b) Would adding a general purpose method to access the profile body make it more acceptable? e.g add one or both of the following methods to the TaggedProfile interface. public byte[] getEncapsulation(); public void write(org.omg.CORBA.portable.OutputStream os); defined as getEncapsulation Returns all the information encapsulated by this tagged profile as a byte array. write Write this tagged profile to the OutputStream os. Well this would be required for the proposed TaggedProfile interface to be in any way usable for profile type other than IIOP. The problem still though is that nothing is really gained from a performance point of view over the old way of processing a non-IIOP profile. Without a specialized interface for the profile type that gives direct access to the elements of the profile body, obviously the profile body needs to be explicitly demarhsalled as before. At the risk of repeating my argument - these interfaces need to be complete in terms of profile and component type coverage to be useful, however the more complete they are the worse the duplication issue between the new Java interfaces and the existing IOP IDL becomes. As you say this is a similar concern. The intention is that consumers of tagged components will provide implementations of the TaggedComponentFactory that the ORB will use when demarshaling, and corresponding TaggedComponent implementations for marshaling. Are you suggesting that some non-ORB code that wants to efficiently examine the contents of say the codesets component would have to usurp the ORB in terms of taking over the process of marshalling and unmarshalling this component type?? This make absolutely no sense to me, except in the case where the component type is proprietary to the non-ORB code. For all standard components types the ORB must IMO be the agent that controls how and when marshalling and demarshalling occurs, otherwise scalable IOR management is completely shot. I think the main difference is that these are likely to be contained within a service implementation and less likely to be required across product implementations. Where they are more general, i.e defined in the core but need to be accessed by non-core services, then appropriate convenience APIs could be defined. As above, I'd rather do that when/if there is a requirement. The proposal for TaggedComponent already includes a generalised write method; alternatively/additionally a getEncapsulation could be provided to return the component data as a byte []. Again, what does getEncapsulation() give us that isn't already provided by IOP::TaggedComponent::component_data? I'm concerned that, since it is necessary to access this core data from other products i.e J2EE implementations from a variety of vendors, there should be an efficient standard way to do it, without relying on proprietary features of any particular J2SE implementation. Is it possible to modify the API proposal in a way that would make it more acceptable to/convenient for IONA? Making it non-Java-specific would make it a lot more acceptable. I'm sorry, I don't understand this concern. Even if all known tagged component types had convenience interfaces, would you not still expect to get the TaggedComponent and cast down to the specialized subtype? Again you can't safely down-cast unless you're guaranteed that there are convenience types defined for every component type. So either these specialized convenience types are standardized or properietary - if they're standardized, we end up a consistency problem viz the IOP IDL - if they're proprietary, what advantage is there in using a mechanism that half-standard (i.e. the TaggedComponent super-interface) and half-proprietary (i.e. the specialized component-specific sub-interface). The advantage is surely in being able to demarshal the data once, hold the data as a Java object and use the registered, albeit proprietary or service defined, class to handle it. Why can't a component be demarshalled just once and the component data stored as things currently stand? The driver for this is to avoid the overhead of repeated demarshaling of CDR encapsulations when there are Java facilities that could be used to access the data more efficiently. I don't think I can add anything to Ken's response to Jishnu earlier:- org.omg.IOP.* basically defines the structures used to represent IORs in the GIOP encoding. This means for example that an IOR contains a type string followed by a sequence of CDR encapsulated profiles. Similarly, an IIOP profile contains a sequence of CDR encapsulated components. However, an ORB may choose not to represent IORs this way internally for efficiency of processing. For example, CSIv2 data is contained inside a tagged component inside an IIOP profile. Accessing this data from org.omg.IOP.* definitions requires unmarshalling using codecs, which is quite slow. Exposing IORs with the proposed APIs is more efficient, because the proposed APIs can be mapped efficiently onto an internal ORB specific representation of an IOR. For example, a CSIv2 implementation would register tagged component factories specific to CSIv2. When an ORB unmarshalls an IOR (or at some later time), it can unmarshal the data once, and make it efficiently available whenever it is needed. This has become a problem mostly due to portable interceptors, which often require access to data inside the IOR. There's nothing there to support a Java only set of convenience interfaces. I think we may be begining to argue round in circles here. The basis of my position is that: 1. any proposal around standardized IOR management must not unduely constrain existing ORB implementations 2. for these convenience interfaces to be useful, they must be defined for all profile and component types 3. if these interfaces are required, then the appropriate way to define them is in IDL as opposed to a language mapping, as there's nothing Java specific about IOR processing by non-ORB code 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: Tue, 14 May 2002 09:32:08 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4945 -- IOR processing performance To: ann_dalton@uk.ibm.com, eglynn@iona.com Cc: Ken.Cavanaugh@sun.com, java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc I've been a bit busy lately, but I have a few comments: > >Ann, > >I have a few issues with your proposal, which I believe exposes too >much >of the ORB's internal IOR management logic. > >First your idea of codifying the concept of an IOR template >associated >with an object adapter instance. While its likely that many ORB >implementations follow this pattern (the IONA ORB included), I don't >think this is required anywhere in the spec. Yes, it is. This is one of the results of the object reference template adoption. Looking at the CORBA 3.0 draft (orbrev/02-02-01.pdf), section 21.5.3.1 says "An object reference template is associated with an object adapter." and an object reference template has a method that creates an object reference given an object id. >Is it required for example >that all IIOP profiles in IORs associated with a particular object >adapter instance share all the values (host, port etc.) encapsulated >in >your IIOPProfileTemplate interface? I don't think its prescribed that >a >object adapter instance maps onto a TCP endpoint, and am concenred >about >unduely contstraining POA implementations. That's true, it is not prescribed. The most important data to access is the components, so we could probably not expose the IIOP address in the IIOPProfile. > >Secondly, what mechanism is proposed to acquire a reference to a >particular profile type? Checking the TaggedProfile.getProfileId() >against org.omg.IOP.TAG_INTERNET_IOP and then casting down to >org.omg.CORBA_n_m.portable.IIOPProfile? It would be simple enough to allow registration of TaggedProfileFactories that could create the appropriate type of TaggedProfile, much as in the TaggedComponent case. Extensibility is more important than completeness here. >Is it intended that a >convenience interface is introduced for each new profile type that's >defined (e.g. for new transports such as MIOP)? If you're going to go >that far, why not introduce convenience interfaces for each tagged >component also - i.e. everything from AlternateIIOPAddressComponent >to >CodeSetsComponent etc. It seems to me that the net effect would be to >introduce a whole layer of duplication between the CORBA::IOP IDL >definitions and the org.omg.CORBA_n_m.portable package, with all the >issues around consistency and versioning that this would imply. > There are two entirely different data models here: the CORBA::IOP package defines the GIOP encoding of the component and profile information, while the Java view defines the information. We want to be able to deal with different encodings than GIOP (e.g. SOAP, proprietary compressed formats, custom doors-based subcontracts) that may not look at all like GIOP. But the information must be made available on demand or else various ORB services will not work correctly. >Thirdly individual ORB implementations may have introduced certain >optimizations in IOR management, for example around flyweighting, >that >may require that the semantics of profile and component factories are >constrained in certain ways. I'm not sure how this can be accomodated >in >you proposal. > >Finally I'd like to understand what performance benefits this would >provide to portable interceptors. In my understanding, PIs currently >may >access a particular tagged component from the target IOR via >ClientRequestInfo::get_effective_component() - the octet sequence >body >of the componment must then be explicitly demarshalled by the PI, >which >obviously incurs some cost. However it seems the same cost is >incurred >under your proposal via TaggedComponent.write(). I think this is actually TaggedComponentFactory.read() > I don't see the benefit >unless there's a TaggedComponent specialization for each tag, which >would provide direct access to the elements of the component body. >However introducing a convenience interfaces for each tagged >components >is IMO a bad idea from a duplication/consistency/versioning point of >view as explained above. > One obvious points is that repeated invocations to the same object reference benefit much more from the approach Ann has described. A conversion needs to take place at most once from the marshalled GIOP form to the internal Java form, whether this is described as an Any or explicitly as in the proposal. The current approach basically says each time the interceptor is called, the conversion takes place, while in the new proposal, the conversion takes place at most once after an object reference is unmarshalled. Ken. Date: Tue, 14 May 2002 09:53:25 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 4945 - IOR processing performance To: ann_dalton@uk.ibm.com, eglynn@iona.com Cc: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc C1FB45] > > >Ann, > >Comments inline ... > > >There's nothing language specific about TAG_MULTIPLE_COMPONENTS - a >C++, >or Ada, or Smalltalk, or COBOL application that processes IORs is >just >as likely to come across a multi-compoent profile as a Java >application. > >My point is that the logical conclusion to your proposal is that a >convenience interface should be defined for every standard profile >and >component type - otherwise applications would have to take an >inconsistent approach to processing IORs, depending on the profile >and >component types encountered. However all of these types are already >defined in the IOP IDL - so what do we gain by defining conveneience >interfaces only in Java? One of the biggest gains is the use of java.util.Iterator in the interface. This allows mapping any of a number of internal implementation strategies to an Iterator, rather than gathering all the results into a temporary array (which is the only collection type available in IDL) for things like iterator() and iteratorById( int ). Now, we could create an IDL analog of java.util.Iterator, but then we are duplicating Java functionality in IDL. The goal here is to produce the most efficient and natural interface possible for Java only. If C++ wants something like this, it would be quite different, probably making use of STL. >A whole lot of grief when it comes to >maintaining consistency between the IOP IDL and the Java convenience >interfaces given that these would described in different specs and >maintained by different RTFs. So if convenience interfaces are really >required, I would argue strongly that the only correct way to define >these interfaces is IDL. > This is the big problem with IDL: it is a very weak subset of the language that it is mapped to. A good use of Java is more important that providing IDL here. > >> b) Would adding a general purpose method to access the profile body >> make it more acceptable? e.g add one or both of the following methods >> to the TaggedProfile interface. >> >> public byte[] getEncapsulation(); >> >> public void write(org.omg.CORBA.portable.OutputStream os); >> >> defined as >> getEncapsulation >> Returns all the information encapsulated by this tagged profile as >> a byte array. >> >> write >> Write this tagged profile to the OutputStream os. > > >> As you say this is a similar concern. The intention is that consumers of >> tagged components will provide implementations of the >> TaggedComponentFactory >> that the ORB will use when demarshaling, and corresponding TaggedComponent >> implementations for marshaling. > > >Are you suggesting that some non-ORB code that wants to efficiently >examine the contents of say the codesets component would have to usurp >the ORB in terms of taking over the process of marshalling and >unmarshalling this component type?? This make absolutely no sense to me, >except in the case where the component type is proprietary to the >non-ORB code. This is the case that matters, since that is exactly what CSIv2 is. I do not want it to be necessary to build CSIv2 into the ORB in order to efficiently implement it. > >Making it non-Java-specific would make it a lot more acceptable. > > >> I'm sorry, I don't understand this concern. Even if all known >tagged >> component types had convenience interfaces, would you not still >> expect to get the TaggedComponent and cast down to the specialized >> subtype? > > >Again you can't safely down-cast unless you're guaranteed that there >are >convenience types defined for every component type. So either these >specialized convenience types are standardized or properietary - if >they're standardized, we end up a consistency problem viz the IOP IDL >- >if they're proprietary, what advantage is there in using a mechanism >that half-standard (i.e. the TaggedComponent super-interface) and >half-proprietary (i.e. the specialized component-specific >sub-interface). > I can safely downcast to those component types that I have regisitered, which is all I care about. >> The advantage is surely in being able to demarshal the data >> once, hold the data as a Java object and use the registered, albeit >> proprietary or service defined, class to handle it. > > >Why can't a component be demarshalled just once and the component >> data >stored as things currently stand? Where do you put the information? ClientRequestInfo::effective_profile is by definition an IOP::TaggedProfile, which is defined by the Java language mapping in a particular way as an IDL struct. This is not really designed to be extensible to add additional information, scuh as would be required to store the Any returned from a Codec::decode_value call. In fact, the information would need to be associated with the byte[] from the TaggedProfile. It's hard to see a really efficient way to solve this. I suppose a weak reference object identity hash table could be used, but this still adds a bit more overhead than is really necessary. > > >> The driver for this is to avoid the overhead of repeated >demarshaling of >> CDR encapsulations when there are Java facilities that could be >used to >> access the data more efficiently. I don't think I can add anything >to >> Ken's response to Jishnu earlier:- >> >> org.omg.IOP.* basically defines the structures used to represent >IORs >> in the GIOP encoding. This means for example that an IOR contains >a >> type string followed by a sequence of CDR encapsulated profiles. >> Similarly, an IIOP profile contains a sequence of CDR encapsulated >> components. However, an ORB may choose not to represent IORs this >way >> internally for efficiency of processing. For example, CSIv2 data >is >> contained inside a tagged component inside an IIOP profile. >Accessing >> this data from org.omg.IOP.* definitions requires unmarshalling >using >> codecs, which is quite slow. >> >> Exposing IORs with the proposed APIs is more efficient, because the >> proposed APIs can be mapped efficiently onto an internal ORB >specific >> representation of an IOR. For example, a CSIv2 implementation >would >> register tagged component factories specific to CSIv2. When an ORB >> unmarshalls an IOR (or at some later time), it can unmarshal the >data >> once, and make it efficiently available whenever it is needed. >This >> has become a problem mostly due to portable interceptors, which >often >> require access to data inside the IOR. > > >There's nothing there to support a Java only set of convenience >interfaces. > I agree with that, as far as the above quote goes. >I think we may be begining to argue round in circles here. The basis of >my position is that: > >1. any proposal around standardized IOR management must not unduely >constrain existing ORB implementations I agree with this. > >2. for these convenience interfaces to be useful, they must be defined >for all profile and component types I think it is more important for the proposal to be extensible, because otherwise you are saying all of the Component and Profile types are known to the ORB, which violates modularity, and ignores the fact that standards evolve. > >3. if these interfaces are required, then the appropriate way to define >them is in IDL as opposed to a language mapping, as there's nothing Java >specific about IOR processing by non-ORB code > I disagree with 3. It is important to have the best Java interface possible, and this cannot be done in IDL. Ken. Date: Tue, 14 May 2002 09:59:22 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 4945 - IOR processing performance To: ann_dalton@uk.ibm.com, eglynn@iona.com Cc: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >Ann, > >Thanks for the reponse ... comments line. > >Ann Dalton1 wrote: > > I don't think the proposal constrains all IORs associated with a > > particular object adapter to reference the same >IIOPProfileTemplate, > > although it is likely that they will. It just recognises that >many > > IORs are likely to share those IIOP characteristics that have >been > > grouped together. It would be possible to implement the API by >having > > each IOR reference a unique template, or by having groups of IORs > > within different object adapters share a template. > >True, your proposal doesn't *require* that there's a 1:1 mapping >between >object adapters and templates, but it certainly suggests that is >likely >to be the case ("recognising that many of the constituent parts of >IOR >profiles are identical for all objects within an object adapter"). I >don't think its appropriate to colour the spec with any assumptions >about ORB implementation strategy. ORT says a lot more about this. orbrev/02-02-01, section 21.5.4.1: "In the case of the POA, these calls [to establish_components and components_established] are made each time POA::create_POA is called." I already pointed out section 21.5.3.1: "An object reference template is associated with an object adapter." This is not intended to unduly constrain the ORB implementation, but it does say that there is a template (which has an identity, and can create object references) associated with an object adapter. > > > The reference can be obtained by supplying the TAG_INTERNET_IOP > > id to the getProfiles(id) method, or checking as you suggest. The > > convenience interface is introduced for the IIOP profile as the IIOP > > profile information may be supplied to the base ORB by the J2EE > > implementation. I'm not sugggesting introducing further suchinterfaces > > but would look at each/any case on its merits. > >If a convenience interface is not supplied for a particular profile type >(other that TAG_INTERNET_IOP), then I can't see how these proposed >interfaces provide any help at all. For example, supposing I want to >parse a multi-component profile - I call >IOR.getProfiles(TAG_MULTIPLE_COMPONENTS) and get back a TaggedProfile. >However this object is completely useless to me as I can't either: > >a) down-cast it to a specialized MultiComponentProfile that provides >direct access to the profile specific data > We should look at making the proposal handle non-IIOP profiles types as well, via a factory registration. Ken. Date: Tue, 14 May 2002 18:55:27 +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: Ken Cavanaugh CC: ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance X-OriginalArrivalTime: 14 May 2002 17:55:14.0876 (UTC) FILETIME=[803217C0:01C1FB70] Ken, I have to disagree with your points on IDL. First array is not the only collections type - there is also sequence. I can't see the difficulty with usage from Java or any other language of a TaggedProfile convenience interface defined in IDL and exposing a readonly attribute which is a sequence of TaggedComponent. What's so awkward about: TaggedComponent[] components = profile.components(); for (int i = 0 ; i < components.length() ; i++) { if (component.tag() == some_tag) { // narrow to the appropriate TaggedComponent IDL sub-interface // giving direct access to the component body elements } } as opposed to: Iterator iter = profile.components(); while (iter.nasNext()) { TaggedComponent component = (TaggedComponent)iter.next(); if (component.tag() == some_tag) { // downcast to the appropriate TaggedComponent Java sub-interface // giving direct access to the component body elements } } The up-side of defining these interfaces in IDL in terms of programming language independence IMO out-weighs the down-side of these interfaces not being completely natural in any individual language. I'd consider this a fairly fundamental tenet of CORBA. As long as the implementation of TaggedProfile isn't required to return a copy of the components sequence (which I don't believe it should as its a readonly attribute on a local interface), then I don't see an efficiency issue either in the IDL. Secondly, I'm so much argueing that the convenience interface should be defined in the CORBA::IOP IDL module, as that they should defined in some CORBA IDL instead of a language mapping. As you say, the primary focus of the IOP IDL is specify the wire format of profiles, components etc. Thirdly, I don't see the issue with regard to a CSIv2 implementation not being baked into the ORB core. Surely the question of packaging CSIv2 as a separate plugin or extension is orthogonal to whether IDL or Java interfaces are used to facilitate convenient and efficient processing of IORs? Cheers, Eoghan Ken Cavanaugh wrote: C1FB45] Ann, Comments inline ... There's nothing language specific about TAG_MULTIPLE_COMPONENTS - a C++, or Ada, or Smalltalk, or COBOL application that processes IORs is just as likely to come across a multi-compoent profile as a Java application. My point is that the logical conclusion to your proposal is that a convenience interface should be defined for every standard profile and component type - otherwise applications would have to take an inconsistent approach to processing IORs, depending on the profile and component types encountered. However all of these types are already defined in the IOP IDL - so what do we gain by defining conveneience interfaces only in Java? One of the biggest gains is the use of java.util.Iterator in the interface. This allows mapping any of a number of internal implementation strategies to an Iterator, rather than gathering all the results into a temporary array (which is the only collection type available in IDL) for things like iterator() and iteratorById( int ). Now, we could create an IDL analog of java.util.Iterator, but then we are duplicating Java functionality in IDL. The goal here is to produce the most efficient and natural interface possible for Java only. If C++ wants something like this, it would be quite different, probably making use of STL. A whole lot of grief when it comes to maintaining consistency between the IOP IDL and the Java convenience interfaces given that these would described in different specs and maintained by different RTFs. So if convenience interfaces are really required, I would argue strongly that the only correct way to define these interfaces is IDL. This is the big problem with IDL: it is a very weak subset of the language that it is mapped to. A good use of Java is more important that providing IDL here. b) Would adding a general purpose method to access the profile body make it more acceptable? e.g add one or both of the following methods to the TaggedProfile interface. public byte[] getEncapsulation(); public void write(org.omg.CORBA.portable.OutputStream os); defined as getEncapsulation Returns all the information encapsulated by this tagged profile as a byte array. write Write this tagged profile to the OutputStream os. As you say this is a similar concern. The intention is that consumers of tagged components will provide implementations of the TaggedComponentFactory that the ORB will use when demarshaling, and corresponding TaggedComponent implementations for marshaling. Are you suggesting that some non-ORB code that wants to efficiently examine the contents of say the codesets component would have to usurp the ORB in terms of taking over the process of marshalling and unmarshalling this component type?? This make absolutely no sense to me, except in the case where the component type is proprietary to the non-ORB code. This is the case that matters, since that is exactly what CSIv2 is. I do not want it to be necessary to build CSIv2 into the ORB in order to efficiently implement it. Making it non-Java-specific would make it a lot more acceptable. I'm sorry, I don't understand this concern. Even if all known tagged component types had convenience interfaces, would you not still expect to get the TaggedComponent and cast down to the specialized subtype? Again you can't safely down-cast unless you're guaranteed that there are convenience types defined for every component type. So either these specialized convenience types are standardized or properietary - if they're standardized, we end up a consistency problem viz the IOP IDL - if they're proprietary, what advantage is there in using a mechanism that half-standard (i.e. the TaggedComponent super-interface) and half-proprietary (i.e. the specialized component-specific sub-interface). I can safely downcast to those component types that I have regisitered, which is all I care about. The advantage is surely in being able to demarshal the data once, hold the data as a Java object and use the registered, albeit proprietary or service defined, class to handle it. Why can't a component be demarshalled just once and the component data stored as things currently stand? Where do you put the information? ClientRequestInfo::effective_profile is by definition an IOP::TaggedProfile, which is defined by the Java language mapping in a particular way as an IDL struct. This is not really designed to be extensible to add additional information, scuh as would be required to store the Any returned from a Codec::decode_value call. In fact, the information would need to be associated with the byte[] from the TaggedProfile. It's hard to see a really efficient way to solve this. I suppose a weak reference object identity hash table could be used, but this still adds a bit more overhead than is really necessary. The driver for this is to avoid the overhead of repeated demarshaling of CDR encapsulations when there are Java facilities that could be used to access the data more efficiently. I don't think I can add anything to Ken's response to Jishnu earlier:- org.omg.IOP.* basically defines the structures used to represent IORs in the GIOP encoding. This means for example that an IOR contains a type string followed by a sequence of CDR encapsulated profiles. Similarly, an IIOP profile contains a sequence of CDR encapsulated components. However, an ORB may choose not to represent IORs this way internally for efficiency of processing. For example, CSIv2 data is contained inside a tagged component inside an IIOP profile. Accessing this data from org.omg.IOP.* definitions requires unmarshalling using codecs, which is quite slow. Exposing IORs with the proposed APIs is more efficient, because the proposed APIs can be mapped efficiently onto an internal ORB specific representation of an IOR. For example, a CSIv2 implementation would register tagged component factories specific to CSIv2. When an ORB unmarshalls an IOR (or at some later time), it can unmarshal the data once, and make it efficiently available whenever it is needed. This has become a problem mostly due to portable interceptors, which often require access to data inside the IOR. There's nothing there to support a Java only set of convenience interfaces. I agree with that, as far as the above quote goes. I think we may be begining to argue round in circles here. The basis of my position is that: 1. any proposal around standardized IOR management must not unduely constrain existing ORB implementations I agree with this. 2. for these convenience interfaces to be useful, they must be defined for all profile and component types I think it is more important for the proposal to be extensible, because otherwise you are saying all of the Component and Profile types are known to the ORB, which violates modularity, and ignores the fact that standards evolve. 3. if these interfaces are required, then the appropriate way to define them is in IDL as opposed to a language mapping, as there's nothing Java specific about IOR processing by non-ORB code I disagree with 3. It is important to have the best Java interface possible, and this cannot be done in IDL. Ken. -- 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: Tue, 14 May 2002 12:45:08 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 4945 - IOR processing performance To: eglynn@iona.com Cc: ken.cavanaugh@sun.com, ann_dalton@uk.ibm.com, java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: eglynn@iona.com >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 >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: ann_dalton@uk.ibm.com, java-rtf@omg.org >Subject: Re: Issue 4945 - IOR processing performance >Content-Transfer-Encoding: 7bit >X-OriginalArrivalTime: 14 May 2002 17:55:14.0876 (UTC) >FILETIME=[803217C0:01C1FB70] > > >Ken, > >I have to disagree with your points on IDL. > >First array is not the only collections type - there is also >sequence. I They both map to a Java array. There is no easy way to get java.util.Iterator from IDL. >can't see the difficulty with usage from Java or any other language of a >TaggedProfile convenience interface defined in IDL and exposing a >readonly attribute which is a sequence of TaggedComponent. > >What's so awkward about: > > TaggedComponent[] components = profile.components(); > for (int i = 0 ; i < components.length() ; i++) > { > if (component.tag() == some_tag) > { > // narrow to the appropriate TaggedComponent IDL sub-interface > // giving direct access to the component body elements > } > } > >as opposed to: > > Iterator iter = profile.components(); > while (iter.nasNext()) > { > TaggedComponent component = (TaggedComponent)iter.next(); > if (component.tag() == some_tag) > { > // downcast to the appropriate TaggedComponent Java sub-interface > // giving direct access to the component body elements > } > } > Both are equivalent, except that the cost of constructing the array may be higher than constructing an iterator. I need to allocate an array and completely fill in all elements before returning it, whereas in the iterator case, I only need to construct those elements that are actually requested. For example, if I call iteratorById( IIOP_PROFILE_ID ) then I could optimize this so that other profiles are not even unmarshalled. This cannot be done with an array. >The up-side of defining these interfaces in IDL in terms of programming >language independence IMO out-weighs the down-side of these interfaces >not being completely natural in any individual language. I'd consider >this a fairly fundamental tenet of CORBA. For me, a natural Java mapping is more important. This really is a position that the RTF as a whole must decide. If the answer is IDL, this issue is no longer a Java issue, but a core issue. Remember what we are trying to do with this issue and the other one (on connection interceptors/SSL support): standardize extensions to CORBA for the support of J2EE app servers (hence Java only). The problems are indeed more general than this, but only by narrowing the scope of the solution can we possibly arrive at a standard solution. > >As long as the implementation of TaggedProfile isn't required to >return >a copy of the components sequence (which I don't believe it should as >its a readonly attribute on a local interface), then I don't see an >efficiency issue either in the IDL. As I said above, requiring this to be in IDL either constrains the ORB implementation or forces a potentially expensive conversion operation. > >Secondly, I'm so much argueing that the convenience interface should >be --------------^ not??? >defined in the CORBA::IOP IDL module, as that they should defined in >some CORBA IDL instead of a language mapping. As you say, the primary >focus of the IOP IDL is specify the wire format of profiles, >components >etc. If we went with IDL, I would agree with you here. > >Thirdly, I don't see the issue with regard to a CSIv2 implementation >not >being baked into the ORB core. Surely the question of packaging CSIv2 >as >a separate plugin or extension is orthogonal to whether IDL or Java >interfaces are used to facilitate convenient and efficient processing >of >IORs? > These are separate questions indeed. My argument here is more completeness vs. extensibility: I don't care whether all components and profiles in CORBA version X are included, but I do care that all components and profiles in any version of CORBA (plus any proprietary ones people come up with) can be handled in the same manner. Ken. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 May 2002 12:55:14 -0700 To: Ken Cavanaugh , ann_dalton@uk.ibm.com, eglynn@iona.com From: Andy Piper Subject: Re: Issue 4945 - IOR processing performance Cc: java-rtf@omg.org At 09:53 AM 5/14/2002 -0700, Ken Cavanaugh wrote: I disagree with 3. It is important to have the best Java interface possible, and this cannot be done in IDL. Right! andy Date: Tue, 14 May 2002 23:20:01 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en To: eglynn@iona.com CC: java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance Eoghan, Even though CORBA is language-neutral, all its implementations and applications are in some language. We need to walk the fine line of providing support and interoperability for all languages while not allowing this to constrain us to suboptimal "least common denominator" approaches that will lead to CORBA becoming uncompetitive and irrelevant. Simon Andy Piper wrote: > > At 09:53 AM 5/14/2002 -0700, Ken Cavanaugh wrote: > >I disagree with 3. It is important to have the best Java interface > >possible, and this cannot be done in IDL. > > Right! > > andy -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Reply-To: "Michi Henning" From: "Michi Henning" To: "Simon Nash" , Cc: Subject: Re: Issue 4945 - IOR processing performance Date: Wed, 15 May 2002 08:53:11 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > Eoghan, > Even though CORBA is language-neutral, all its implementations and applications > are in some language. We need to walk the fine line of providing > support and > interoperability for all languages while not allowing this to > constrain us to > suboptimal "least common denominator" approaches that will lead to > CORBA > becoming uncompetitive and irrelevant. I won't take sides in this particular case, but I'd like to caution people against creating custom language mappings unless there is a really pressing need. One of the nice things about CORBA is that, once I know the language mapping, all I need to see is the IDL and I automatically know how to use the corresponding API. Now, for particular APIs, it is possible to come up with language mappings that are more elegant or more efficient than the API generated by the normal mapping rules. However, doing this extracts a price: I now not only have to know the language mapping, but also the exception to the language mapping for this particular API. So, there is a trade-off between convenience and/or efficiency, and the ergonomics of the platform. For C++, this particular trade-off has gone in the wrong direction. All the custom mappings for the various PIDL objects, such as TypeCode, are maybe easier to use and more efficient, but they make it *very* much harder to remember it all, to the point where some APIs are usable only with the reference manual at hand. (Note that this was one of the reasons why we did away with PIDL -- the added complexity wasn't worth the gain in convenience and efficiency.) Also, I believe that a language mapping isn't meant to create custom mappings for anything other than IDL types that are marked native or PIDL. Everything else, I believe, must follow normal mapping rules. Anyway, please be careful about adding custom mappings -- it is very easy to make things worse overeall even though, locally (for a particular API), they are improved. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 Triodia Technologies http://www.triodia.com/staff/michi Date: Wed, 15 May 2002 09:44:38 +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: Ken Cavanaugh CC: ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance X-OriginalArrivalTime: 15 May 2002 08:44:19.0246 (UTC) FILETIME=[B3EAFCE0:01C1FBEC] Ken, I guess we'll have to agree to differ on the question of whether this proposed facility should be defined in a language specific way. I don't accept that the there's a significant usability handicap in IDL accessed from Java - e.g. it would possible be to define an local ComponentIterator interface in IDL is this is considered crucial, in the style of the CosNaming::BindingIterator interface. Similarly I don't think its necessarily true that the implementation of a local IDL interface would perform any better or worse that a native Java one based on java.util.Iterator. Obviously it would be more natural for Java programmers to use APIs defined in the native Java style, but I don't think this convenience is worth the loss of the consistency across languages that IDL brings to the table. It also seems to me that there is nothing about IOR processing that is specific to J2EE app servers, in the sense that its likely a standardized IOR management/processing facility would be just as useful to say a C++ infrastructure built obver COBRA. Cheers, Eoghan Ken Cavanaugh wrote: From: eglynn@iona.com 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 MIME-Version: 1.0 To: Ken Cavanaugh CC: ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2002 17:55:14.0876 (UTC) FILETIME=[803217C0:01C1FB70] Ken, I have to disagree with your points on IDL. First array is not the only collections type - there is also sequence. I They both map to a Java array. There is no easy way to get java.util.Iterator from IDL. can't see the difficulty with usage from Java or any other language of a TaggedProfile convenience interface defined in IDL and exposing a readonly attribute which is a sequence of TaggedComponent. What's so awkward about: TaggedComponent[] components = profile.components(); for (int i = 0 ; i < components.length() ; i++) { if (component.tag() == some_tag) { // narrow to the appropriate TaggedComponent IDL sub-interface // giving direct access to the component body elements } } as opposed to: Iterator iter = profile.components(); while (iter.nasNext()) { TaggedComponent component = (TaggedComponent)iter.next(); if (component.tag() == some_tag) { // downcast to the appropriate TaggedComponent Java sub-interface // giving direct access to the component body elements } } Both are equivalent, except that the cost of constructing the array may be higher than constructing an iterator. I need to allocate an array and completely fill in all elements before returning it, whereas in the iterator case, I only need to construct those elements that are actually requested. For example, if I call iteratorById( IIOP_PROFILE_ID ) then I could optimize this so that other profiles are not even unmarshalled. This cannot be done with an array. The up-side of defining these interfaces in IDL in terms of programming language independence IMO out-weighs the down-side of these interfaces not being completely natural in any individual language. I'd consider this a fairly fundamental tenet of CORBA. For me, a natural Java mapping is more important. This really is a position that the RTF as a whole must decide. If the answer is IDL, this issue is no longer a Java issue, but a core issue. Remember what we are trying to do with this issue and the other one (on connection interceptors/SSL support): standardize extensions to CORBA for the support of J2EE app servers (hence Java only). The problems are indeed more general than this, but only by narrowing the scope of the solution can we possibly arrive at a standard solution. As long as the implementation of TaggedProfile isn't required to return a copy of the components sequence (which I don't believe it should as its a readonly attribute on a local interface), then I don't see an efficiency issue either in the IDL. As I said above, requiring this to be in IDL either constrains the ORB implementation or forces a potentially expensive conversion operation. Secondly, I'm so much argueing that the convenience interface should be --------------^ not??? defined in the CORBA::IOP IDL module, as that they should defined in some CORBA IDL instead of a language mapping. As you say, the primary focus of the IOP IDL is specify the wire format of profiles, components etc. If we went with IDL, I would agree with you here. Thirdly, I don't see the issue with regard to a CSIv2 implementation not being baked into the ORB core. Surely the question of packaging CSIv2 as a separate plugin or extension is orthogonal to whether IDL or Java interfaces are used to facilitate convenient and efficient processing of IORs? These are separate questions indeed. My argument here is more completeness vs. extensibility: I don't care whether all components and profiles in CORBA version X are included, but I do care that all components and profiles in any version of CORBA (plus any proprietary ones people come up with) can be handled in the same manner. Ken. -- 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: Wed, 15 May 2002 12:09:25 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Ken Cavanaugh Cc: ann_dalton@uk.ibm.com, eglynn@iona.com, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance Ken Cavanaugh wrote: > > C1FB45] > > > >I think we may be begining to argue round in circles here. The basis of > >my position is that: > > > >1. any proposal around standardized IOR management must not unduely > >constrain existing ORB implementations > > I agree with this. Agreed. > > > >2. for these convenience interfaces to be useful, they must be defined > >for all profile and component types > > I think it is more important for the proposal to be extensible, because > otherwise you are saying all of the Component and Profile types > are known to the ORB, which violates modularity, and ignores the > fact that standards evolve. Agreed about that too. > > > >3. if these interfaces are required, then the appropriate way to define > >them is in IDL as opposed to a language mapping, as there's nothing Java > >specific about IOR processing by non-ORB code > > > > I disagree with 3. It is important to have the best Java interface > possible, and this cannot be done in IDL. I too sort of disagree with 3 and agree with what Ken says in the second sentence, but with a twist as you will see below. While I agree that it may be a good thing to define an IDL interface to do this, I don't think that precludes doing a special Java interface for enhancing binary portability and efficiency of Java stuff. No other language mapping has either the goal or the capability of producing a binary portable version of the system as Java does (well some day C# might if OMG ever gets around to do a C# mapping:-)), so IMHO the needs of enhancing/enabling efficient and performant binary portability for Java does take some precedence. There are other things that have been done special case for the Java language mapping for this reason too. So my take is, we should let the Java language mapping deal with this specific J2EE related issue, and if there is a great desire to produce a language independant facility we could raise a separate issue in Core and discuss it there, or issue an RFP or do an RFC or whatever. I think it is exceedingly important to provide efficient facilities to support J2EE for CORBA to remain relevant in that space. BTW, this position is stated primarily with my HP represntative hat on, and in addition I am comfortable supporting this position with my AB hat on. I do not state this position with any of my Chairs hats on - in that role I am neutral on this matter. Jishnu. Date: Wed, 15 May 2002 10:05:32 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 4945 - IOR processing performance To: Ken.Cavanaugh@sun.com, eglynn@iona.com Cc: ann_dalton@uk.ibm.com, java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: eglynn@iona.com >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 >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: ann_dalton@uk.ibm.com, java-rtf@omg.org >Subject: Re: Issue 4945 - IOR processing performance >Content-Transfer-Encoding: 7bit >X-OriginalArrivalTime: 15 May 2002 08:44:19.0246 (UTC) FILETIME=[B3EAFCE0:01C1FBEC] > > >Ken, > >I guess we'll have to agree to differ on the question of whether this >proposed facility should be defined in a language specific way. > >I don't accept that the there's a significant usability handicap in >IDL >accessed from Java - e.g. it would possible be to define an local >ComponentIterator interface in IDL is this is considered crucial, in >the >style of the CosNaming::BindingIterator interface. I agree that this is possible. It is slightly less natural than using java.util.Iterator, and I would prefer the more natural Java approach, but as you said, we agree to differ here. I would be willing to adopt any approach that the RTF agrees to. By the way, I would just use an IDL analog (has_next(), next()) of the java.util.iterator interface, since we do not need a remotely accessible iterator. > >Similarly I don't think its necessarily true that the implementation >of >a local IDL interface would perform any better or worse that a native >Java one based on java.util.Iterator. Performance should be about the same. Implementing a custom Java iterator or a custom IDL iterator is very similar. > >Obviously it would be more natural for Java programmers to use APIs >defined in the native Java style, but I don't think this convenience >is >worth the loss of the consistency across languages that IDL brings to >the table. > >It also seems to me that there is nothing about IOR processing that >is >specific to J2EE app servers, in the sense that its likely a >standardized IOR management/processing facility would be just as >useful >to say a C++ infrastructure built obver COBRA. > This is probably true also. Ken. Date: Wed, 15 May 2002 18:49:39 +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: Jishnu Mukerji CC: Ken Cavanaugh , ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance X-OriginalArrivalTime: 15 May 2002 17:49:22.0897 (UTC) FILETIME=[D8D01C10:01C1FC38] Jishnu Mukerji wrote: IMHO the needs of enhancing/enabling efficient and performant binary portability for Java does take some precedence. Jishnu, Wouldn't standardized IDL interfaces also guarantee Java binary portability (via the generated Java code, assuming a constant IDL->Java mapping)? Also I'd assert that an implementation based on local IDL interfaces could be just as performant as one based on native Java interfaces. 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: Wed, 15 May 2002 14:32:45 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: eglynn@iona.com Cc: Ken Cavanaugh , ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance eglynn@iona.com wrote: > > Jishnu Mukerji wrote: > > > IMHO the needs of enhancing/enabling > > efficient and performant binary portability for Java does take some > > precedence. > > Jishnu, > > Wouldn't standardized IDL interfaces also guarantee Java binary > portability (via the generated Java code, assuming a constant IDL->Java > mapping)? > > Also I'd assert that an implementation based on local IDL interfaces > could be just as performant as one based on native Java interfaces. If the assertion that an implementation in Java based on local IDL interfaces would be just as performant and as natural to use for the Java programmers as the Java interface, can be established to be valid, then I'd go for IDL only interface. If we cannot establish the varacity of that assertion, I'd go for the Java special case + the IDL interface. So I guess people can start providing supporting evidence for their respective assertions.:-) Jishnu. Date: Thu, 16 May 2002 11:24:46 +0800 From: Cuie Zhao Subject: Re: Issue 4945 - IOR processing performance To: Jishnu Mukerji Cc: Ken Cavanaugh , ann_dalton@uk.ibm.com, eglynn@iona.com, java-rtf@omg.org X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en Jishnu Mukerji wrote: > > > > > > > >3. if these interfaces are required, then the appropriate way to >define > > >them is in IDL as opposed to a language mapping, as there's >nothing Java > > >specific about IOR processing by non-ORB code > > > > > > > I disagree with 3. It is important to have the best Java >interface > > possible, and this cannot be done in IDL. > > I too sort of disagree with 3 and agree with what Ken says in the >second > sentence, but with a twist as you will see below. While I agree that >it > may be a good thing to define an IDL interface to do this, I don't >think > that precludes doing a special Java interface for enhancing binary > portability and efficiency of Java stuff. No other language mapping >has > either the goal or the capability of producing a binary portable >version > of the system as Java does (well some day C# might if OMG ever gets > around to do a C# mapping:-)), so IMHO the needs of >enhancing/enabling > efficient and performant binary portability for Java does take some > precedence. There are other things that have been done special case >for > the Java language mapping for this reason too. > I generally agree with Jishnu & Ken. However, I'd like to see more evidences/emerging scenarios for the need of the mentioned portability which I see as the main reason for standardizing the APIs by this issue. Performance/efficiency wise, I think most ORBs probably have done / can do their own optimizations either in a similar fashion as Ann proposed, or in one way or the other to achive the same goal. Regards, // Cuie Subject: Re: Issue 4945 - IOR processing performance To: Ken Cavanaugh , eglynn@iona.com, Jishnu Mukerji Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Tue, 11 Jun 2002 23:57:40 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 11/06/2002 23:57:11 I have no technical objection to local IDL interfaces for this either, but I do think it's important that it be standardised. The requirement is to support J2EE implementations such that they don't have dependencies on a particular vendor's Java SDK. It is thus, although potentially applicable to other languages, a Java specific requirement. If it were to be defined in IDL, I would expect to add to the IOP and IIOP modules. Is this what you envisaged? It could be considered to introduce unnecessary 'stuff' for all, for what is a Java specific requirement. And I assume it would necessitate a Core RTF issue? Although we must of course ensure that what is defined is robust, if it's required only for Java, and is purely a local server concern, I think we should define what's necessary for Java rather than a more general solution that will, and should, receive additional scrutiny. Ann Ken Cavanaugh cc: Ann Dalton1/UK/IBM@IBMGB, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance 15/05/2002 18:05 Please respond to Ken Cavanaugh >From: eglynn@iona.com >User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; >rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 Subject: Re: issue 4945 -- IOR processing performance To: Ken.Cavanaugh@Sun.COM Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Thu, 13 Jun 2002 00:02:53 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 00:04:03 Ken, please accept this proposal for issue 4945. Thanks, Ann Proposal: The following APIs to be added to the Java ORB Portability Interfaces chapter as follows:- 1.21.10 J2EE APIs 1.21.10.1 Overview The APIs specified here, although they may be generally useful, are introduced primarily to support J2EE implementations efficiently, without requiring proprietary ORB extensions. The overhead of processing TaggedComponents within an IOR becomes significant when done many times, as in the case of J2EE implementations where multiple request interceptors are used. The IOR API improves the performance of IOR access and creation by - making better use of Java facilities to provide access to an IOR's components without the overhead of CDR encoding. - recognising that many of the constituent parts of IOR profiles are identical for different objects, and can thus be abstracted out into a template. 1.21.10.2 IOR APIs Introduction The APIs described in this section are concerned with mapping to an ORB specific internal representation of an IOR and are additional to the structures used to represent IORs in the GIOP encoding, defined in the IOP IDL module. The APIs imply the following abstract model of an IOR. - an IOR has a type ID string, and contains TaggedProfile instances - a TaggedProfile has an ID, and can be written to an OuputStream - 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 can be written to an OuputStream - a TaggedComponentFactory reads a TaggedComponent from an InputStream - a TaggedProfileFactory reads a TaggedProfile from an InputStream The IOR APIs are found in the org.omg.CORBA.portable and org.omg.CORBA_n_m.portable packages. The ORB object is used as a factory to create an IOR from an Object reference. TaggedProfile and TaggedComponent are generic interfaces. Users of the ORB may create implementations of them. Corresponding factories may be registered with an ORB instance to be used when unmarshalling IORs containing such tagged profiles and or components. package org.omg.CORBA; interface ORB { org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object obj); void register_tagged_profile_factory (org.omg.CORBA.portable.TaggedProfileFactory tpf); void register_tagged_component_factory (org.omg.CORBA.portable.TaggedComponentFactory tcf); } package org.omg.CORBA.portable; public interface IOR { public java.lang.String getTypeId(); public java.util.Iterator getProfiles(); public java.util.Iterator getProfiles(int id); } public interface TaggedProfile { public int getId(); public byte[] getEncapsulation(); public void write(org.omg.CORBA.portable.OutputStream os); } public interface TaggedProfileFactory { public int getId(); public TaggedProfile read(org.omg.CORBA.portable.InputStream is); } public interface IIOPProfile extends TaggedProfile { public byte[] getObjectKey(); public IIOPProfileTemplate getTemplate(); } public interface IIOPProfileTemplate { public java.util.Iterator getComponents(); public java.util.Iterator getComponents(int id); public byte getMajorVersion(); public byte getMinorVersion(); public java.lang.String getHost(); public int getPort(); } public interface TaggedComponent { public int getId(); public void write(org.omg.CORBA.portable.OutputStream os); } public interface TaggedComponentFactory { public int getId(); public TaggedComponent read(org.omg.CORBA.portable.InputStream is); } ORB Method Semantics create_IOR Return the IOR for the given Object reference. register_tagged_profile_factory Register a TaggedProfileFactory to read TaggedProfiles with the id returned by the given factory's getId method. If a TaggedProfileFactory already exists for the given id, BAD_INV_ORDER is raised with a standard minor code of n. 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, BAD_INV_ORDER is raised with a standard minor code of m. Instances of this interface may be defined by users to support custom tagged components. IOR Method Semantics getTypeId Return the type id string from the IOR. getProfiles() Return an iterator over the list of TaggedProfiles within the IOR. It is not possible to modify the list through this iterator. getProfiles(int id) Return an iterator over the list of TaggedProfiles with identifier id. It is not possible to modify the list through this iterator. TaggedProfile Method Semantics getId Return the profile identifier. getEncapsulation Returns all the information encapsulated by this TaggedProfile as a byte array. write Write this TaggedProfile to the OutputStream os. TaggedProfileFactory Method Semantics getId Return the identifier for this TaggedProfileFactory. read Read a TaggedProfile from the InputStream is. IIOPProfile Method Semantics getObjectKey Return the Object key contained in this IIOPProfile. getTemplate Return the IIOPProfileTemplate associated with this IIOPProfile. IIOPProfileTemplate Method Semantics getComponents() Return an iterator over the list of TaggedComponents within the IIOPProfileTemplate. It is not possible to modify the list through this iterator. getComponents(int id) Return an iterator over the list of TaggedComponents with identifier id. It is not possible to modify the list through this iterator. getMajorVersion Return the GIOP major version of this profile. getMinorVersion Return the GIOP minor version of this profile. If the major version is 1 and the minor version is 0, this profile cannot contain any TaggedComponents. getHost Return the host name string from this IIOPProfileTemplate. getPort Return the port number from this IIOPProfileTemplate. TaggedComponent Method Semantics getId Return the identifier for this TaggedComponent. getEncapsulation Returns all the information encapsulated by this TaggedComponent as a byte array. write Write this TaggedComponent to the OutputStream os. TaggedComponentFactory Method Semantics getId Return the identifier for this TaggedComponentFactory. read Read a TaggedComponent from the InputStream is. Date: Wed, 12 Jun 2002 16:44:55 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4945 -- IOR processing performance To: Ken.Cavanaugh@sun.com, ann_dalton@uk.ibm.com Cc: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >Subject: Re: issue 4945 -- IOR processing performance >To: Ken.Cavanaugh@sun.com >Cc: java-rtf@omg.org >From: "Ann Dalton1" >X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a >|January 7, 2002) at 13/06/2002 00:04:03 >MIME-Version: 1.0 > >Ken, please accept this proposal for issue 4945. >Thanks, >Ann This looks pretty good to me. I have a few comments inline below. I plan to put this up for a vote this week, if possible. > > >Proposal: >The following APIs to be added to the Java ORB Portability Interfaces >chapter as follows:- > > >1.21.10 J2EE APIs > >1.21.10.1 Overview >The APIs specified here, although they may be generally useful, are >introduced primarily to support J2EE implementations efficiently, >without requiring proprietary ORB extensions. > >The overhead of processing TaggedComponents within an IOR becomes >significant when done many times, as in the case of J2EE >implementations >where multiple request interceptors are used. The IOR API improves >the >performance of IOR access and creation by >- making better use of Java facilities to provide access to an IOR's > components without the overhead of CDR encoding. >- recognising that many of the constituent parts of IOR profiles are > identical for different objects, and can thus be abstracted out >into > a template. > > >1.21.10.2 IOR APIs > >Introduction >The APIs described in this section are concerned with mapping to an >ORB >specific internal representation of an IOR and are additional to the >structures used to represent IORs in the GIOP encoding, defined in >the >IOP IDL module. > >The APIs imply the following abstract model of an IOR. > - an IOR has a type ID string, and contains TaggedProfile >instances > - a TaggedProfile has an ID, and can be written to an OuputStream > - 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 can be written to an >OuputStream > - a TaggedComponentFactory reads a TaggedComponent from an >InputStream > - a TaggedProfileFactory reads a TaggedProfile from an InputStream > >The IOR APIs are found in the org.omg.CORBA.portable and >org.omg.CORBA_n_m.portable packages. The ORB object is used as a >factory >to create an IOR from an Object reference. > >TaggedProfile and TaggedComponent are generic interfaces. Users of >the >ORB may create implementations of them. Corresponding factories may >be >registered with an ORB instance to be used when unmarshalling IORs >containing such tagged profiles and or components. > > package org.omg.CORBA; > > interface ORB { > org.omg.CORBA.portable.IOR create_IOR(org.omg.CORBA.Object >obj); > void register_tagged_profile_factory > (org.omg.CORBA.portable.TaggedProfileFactory tpf); > void register_tagged_component_factory > (org.omg.CORBA.portable.TaggedComponentFactory tcf); > } > > package org.omg.CORBA.portable; > > public interface IOR { > public java.lang.String getTypeId(); > public java.util.Iterator getProfiles(); > public java.util.Iterator getProfiles(int id); > } > > public interface TaggedProfile { > public int getId(); > public byte[] getEncapsulation(); > public void write(org.omg.CORBA.portable.OutputStream os); > } The getEncapsulation() method here needs to decide what encoding to use Current possibilities are GIOP 1.0-1.3 (or soon 1.4). Mostly this does not matter, but for example wide characters are encoded differently in GIOP 1.1 and 1.2. Perhaps we need to pass an org.omg.IOP.Encoding argument to getEncapsultion? > > public interface TaggedProfileFactory { > public int getId(); > public TaggedProfile read(org.omg.CORBA.portable.InputStream >is); > } > > public interface IIOPProfile extends TaggedProfile { > public byte[] getObjectKey(); > public IIOPProfileTemplate getTemplate(); > } > > public interface IIOPProfileTemplate { > public java.util.Iterator getComponents(); > public java.util.Iterator getComponents(int id); > public byte getMajorVersion(); > public byte getMinorVersion(); > public java.lang.String getHost(); > public int getPort(); > } > > public interface TaggedComponent { > public int getId(); > public void write(org.omg.CORBA.portable.OutputStream os); > } > > public interface TaggedComponentFactory { > public int getId(); > public TaggedComponent read(org.omg.CORBA.portable.InputStream >is); > } > > >ORB Method Semantics > > create_IOR > Return the IOR for the given Object reference. > > register_tagged_profile_factory > Register a TaggedProfileFactory to read TaggedProfiles with the id > returned by the given factory's getId method. If a >TaggedProfileFactory > already exists for the given id, BAD_INV_ORDER is raised with a > standard minor code of n. > Instances of this interface may be defined by users to support >custom > tagged profiles. Can we assume that an IIOPProfile factory is always registered? > > 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, BAD_INV_ORDER is raised with a > standard minor code of m. > Instances of this interface may be defined by users to support >custom > tagged components. Can we assume that any standard tagged components are already registered? If so, which ones? > >IOR Method Semantics > > getTypeId > Return the type id string from the IOR. > > getProfiles() > Return an iterator over the list of TaggedProfiles within the IOR. > It is not possible to modify the list through this iterator. > > getProfiles(int id) > Return an iterator over the list of TaggedProfiles with identifier >id. > It is not possible to modify the list through this iterator. > >TaggedProfile Method Semantics > > getId > Return the profile identifier. > > getEncapsulation > Returns all the information encapsulated by this TaggedProfile as > a byte array. > > write > Write this TaggedProfile to the OutputStream os. > >TaggedProfileFactory Method Semantics > > getId > Return the identifier for this TaggedProfileFactory. > > read > Read a TaggedProfile from the InputStream is. > >IIOPProfile Method Semantics > > getObjectKey > Return the Object key contained in this IIOPProfile. > > getTemplate > Return the IIOPProfileTemplate associated with this IIOPProfile. > > >IIOPProfileTemplate Method Semantics > > getComponents() > Return an iterator over the list of TaggedComponents within the > IIOPProfileTemplate. > It is not possible to modify the list through this iterator. > > getComponents(int id) > Return an iterator over the list of TaggedComponents with >identifier id. > It is not possible to modify the list through this iterator. > > getMajorVersion > Return the GIOP major version of this profile. > > getMinorVersion > Return the GIOP minor version of this profile. If the major >version is 1 >and the > minor version is 0, this profile cannot contain any >TaggedComponents. > > getHost > Return the host name string from this IIOPProfileTemplate. > > getPort > Return the port number from this IIOPProfileTemplate. > > >TaggedComponent Method Semantics > > getId > Return the identifier for this TaggedComponent. > > getEncapsulation > Returns all the information encapsulated by this TaggedComponent > as a byte array. > > write > Write this TaggedComponent to the OutputStream os. > >TaggedComponentFactory Method Semantics > > getId > Return the identifier for this TaggedComponentFactory. > > read > Read a TaggedComponent from the InputStream is. > > What does the ORB do if it encounters a profile or component for which it has no factory registered? The Sun implementation just stores such profiles and components in their marshalled form, and makes them available directly as a generic implementation of the appropriate interface. I think you need to add a general description of how object references are made available in this form. The spec should not have wording that dictates when the factories are applied (e.g. when the IOR is unmarshalled, or lazily on demand). I suggest replacing the fourth paragraph under 1.21.10.1 with something like: "TaggedProfile and TaggedComponent are generic interfaces. Users of the ORB may create implementations of them. Corresponding factories may be registered with an ORB instance. An ORB must return all tagged profiles in an IOR through the IOR.getProfiles() methods. Those profiles whose ids have a registered TaggedProfileFactory will be made available in the form returned by the registered factories' TaggedProfileFactory.read() method, which must return a subtype of TaggedProfile. Profile ids for which no TaggedProfileFactory has been registered will be made available directly as instances of TaggedProfile (which will of course be implemented by some ORB implementation class that implements the TaggedProfile interface). Similarly, an ORB must return all tagged components in an IIOP profile through the IIOPProfile.getProfiles() methods. Those components whose ids have a registered TaggedComponentFactory will be made available in the form returned by the registered factories' TaggedComponentFactory.read() method, which must return a subtype of TaggedComponent. Component ids for which no TaggedComponentFactory has been registered will be made available directly as instances of TaggedComponent (which will of course be implemented by some ORB implementation class that implements the TaggedComponent interface)." Alternatively, you could decide to do a version of this such that only components and factories with registered factories are returned. I'm comfortable with going either way, but of course the ORB must preserve IOR profiles and components in either case. I think it is currently illegal for an ORB to drop components or profiles that it does not understand. Ken. Date: Thu, 13 Jun 2002 08:39:18 +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 CC: Ken Cavanaugh , Jishnu Mukerji , java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance X-OriginalArrivalTime: 13 Jun 2002 07:39:10.0276 (UTC) FILETIME=[67F84040:01C212AD] Ann, I don't want to rehash all the arguments I made previously on this thread. However I must say that I *strongly* believe that the Java mapping is not the right place to define these interfaces. There is nothing Java-specific about the proposed convenience interfaces for IOR processing - the fact this facility would be particularly useful to some J2EE implementations does not make it a Java-specific requirement. That a more general facility defined in IDL and available to all language mappings would receive further scrutiny from the core RFT etc. is not a valid argument IMO - the Java RTF should not be treated as a convenient back-door to standardize non-Java-specific facilites. /Eoghan. Ann Dalton1 wrote: I have no technical objection to local IDL interfaces for this either, but I do think it's important that it be standardised. The requirement is to support J2EE implementations such that they don't have dependencies on a particular vendor's Java SDK. It is thus, although potentially applicable to other languages, a Java specific requirement. If it were to be defined in IDL, I would expect to add to the IOP and IIOP modules. Is this what you envisaged? It could be considered to introduce unnecessary 'stuff' for all, for what is a Java specific requirement. And I assume it would necessitate a Core RTF issue? Although we must of course ensure that what is defined is robust, if it's required only for Java, and is purely a local server concern, I think we should define what's necessary for Java rather than a more general solution that will, and should, receive additional scrutiny. Ann Ken Cavanaugh cc: Ann Dalton1/UK/IBM@IBMGB, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance 15/05/2002 18:05 Please respond to Ken Cavanaugh From: eglynn@iona.com 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 MIME-Version: 1.0 To: Ken Cavanaugh CC: ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2002 08:44:19.0246 (UTC) FILETIME=[B3EAFCE0:01C1FBEC] Ken, I guess we'll have to agree to differ on the question of whether this proposed facility should be defined in a language specific way. I don't accept that the there's a significant usability handicap in IDL accessed from Java - e.g. it would possible be to define an local ComponentIterator interface in IDL is this is considered crucial, in the style of the CosNaming::BindingIterator interface. I agree that this is possible. It is slightly less natural than using java.util.Iterator, and I would prefer the more natural Java approach, but as you said, we agree to differ here. I would be willing to adopt any approach that the RTF agrees to. By the way, I would just use an IDL analog (has_next(), next()) of the java.util.iterator interface, since we do not need a remotely accessible iterator. Similarly I don't think its necessarily true that the implementation of a local IDL interface would perform any better or worse that a native Java one based on java.util.Iterator. Performance should be about the same. Implementing a custom Java iterator or a custom IDL iterator is very similar. Obviously it would be more natural for Java programmers to use APIs defined in the native Java style, but I don't think this convenience is worth the loss of the consistency across languages that IDL brings to the table. It also seems to me that there is nothing about IOR processing that is specific to J2EE app servers, in the sense that its likely a standardized IOR management/processing facility would be just as useful to say a C++ infrastructure built obver COBRA. This is probably true also. Ken. -- 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 4945 - IOR processing performance To: eglynn@iona.com Cc: java-rtf@omg.org, Jishnu Mukerji , Ken Cavanaugh X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Thu, 13 Jun 2002 23:22:43 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 23:22:12 Eoghan, This issue arises because of a desire to use natural, performant Java facilities from a vendor J2EE implementation based on a Java SDK ORB. Although we could standardize this API for all languages, that would make it less natural for Java and it's not clear there's any requirement for it from anything other than Java. Also, I believe it's important for us to provide timely, efficient standards for Java where these are needed. If we can't do this, the CORBA standards risk being sidelined in favour of other approaches over which the OMG has no control or scrutiny. Ann eglynn@iona.com To: Ann Dalton1/UK/IBM@IBMGB 13/06/2002 08:39 cc: Ken Cavanaugh , Jishnu Mukerji Please respond to , java-rtf@omg.org eglynn Subject: Re: Issue 4945 - IOR processing performance Ann, I don't want to rehash all the arguments I made previously on this thread. However I must say that I *strongly* believe that the Java mapping is not the right place to define these interfaces. There is nothing Java-specific about the proposed convenience interfaces for IOR processing - the fact this facility would be particularly useful to some J2EE implementations does not make it a Java-specific requirement. That a more general facility defined in IDL and available to all language mappings would receive further scrutiny from the core RFT etc. is not a valid argument IMO - the Java RTF should not be treated as a convenient back-door to standardize non-Java-specific facilites. /Eoghan. Ann Dalton1 wrote: > > I have no technical objection to local IDL interfaces for this >either, but > I > do think it's important that it be standardised. The requirement is >to > support > J2EE implementations such that they don't have dependencies on a particular > vendor's Java SDK. It is thus, although potentially applicable to >other > languages, a Java specific requirement. > > If it were to be defined in IDL, I would expect to add to the IOP >and IIOP > modules. Is this what you envisaged? It could be considered to >introduce > unnecessary 'stuff' for all, for what is a Java specific >requirement. > And I assume it would necessitate a Core RTF issue? > > Although we must of course ensure that what is defined is robust, > if it's required only for Java, and is purely a local server >concern, I > think > we should define what's necessary for Java rather than a more >general > solution > that will, and should, receive additional scrutiny. > > Ann > > > > > Ken Cavanaugh > n.com> cc: Ann Dalton1/UK/IBM@IBMGB, java-rtf@omg.org > Subject: Re: Issue 4945 - IOR processing performance > 15/05/2002 18:05 > Please respond to > Ken Cavanaugh > > > > > > > >>From: eglynn@iona.com >>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 >>MIME-Version: 1.0 >>To: Ken Cavanaugh >>CC: ann_dalton@uk.ibm.com, java-rtf@omg.org >>Subject: Re: Issue 4945 - IOR processing performance >>Content-Transfer-Encoding: 7bit >>X-OriginalArrivalTime: 15 May 2002 08:44:19.0246 (UTC) >> > FILETIME=[B3EAFCE0:01C1FBEC] > >> >>Ken, >> >>I guess we'll have to agree to differ on the question of whether >this >>proposed facility should be defined in a language specific way. >> >>I don't accept that the there's a significant usability handicap in >IDL >>accessed from Java - e.g. it would possible be to define an local >>ComponentIterator interface in IDL is this is considered crucial, in >the >>style of the CosNaming::BindingIterator interface. >> > > I agree that this is possible. It is slightly less natural than >using > java.util.Iterator, and I would prefer the more natural Java >approach, > but as you said, we agree to differ here. I would be willing to >adopt > any approach that the RTF agrees to. > > By the way, I would just use an IDL analog (has_next(), next()) of > the java.util.iterator interface, since we do not need a remotely > accessible iterator. > > >>Similarly I don't think its necessarily true that the implementation >of >>a local IDL interface would perform any better or worse that a >native >>Java one based on java.util.Iterator. >> > > Performance should be about the same. Implementing a custom Java iterator > or a custom IDL iterator is very similar. > > >>Obviously it would be more natural for Java programmers to use APIs >>defined in the native Java style, but I don't think this convenience >is >>worth the loss of the consistency across languages that IDL brings >to >>the table. >> >>It also seems to me that there is nothing about IOR processing that >is >>specific to J2EE app servers, in the sense that its likely a >>standardized IOR management/processing facility would be just as >useful >>to say a C++ infrastructure built obver COBRA. >> >> > > This is probably true also. > > Ken. > > > > > > > -- 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, 14 Jun 2002 11:46:21 +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 CC: java-rtf@omg.org, Jishnu Mukerji , Ken Cavanaugh Subject: Re: Issue 4945 - IOR processing performance X-OriginalArrivalTime: 14 Jun 2002 10:46:20.0127 (UTC) FILETIME=[B7E546F0:01C21390] Ann, I'm not trying to be obnoxious here, but we already discussed the performance issue on this thread with, if memory serves, the conclusion that there's no reason an implementation of a local IDL interface should be any less performant than an implementation of a native Java interface. We've also discussed the issue of API "naturalness" - e.g. whether java.util.Iterator is inherently better than an iterator interface defined in IDL. I don't think there is a significant issue here - if Java programmers are comfortable programming to the PortableInterceptor IDL (portable interceptors having the most obvious requirement for parsing IORs), then surely they would also be happy coding against IOR processing IDL? Pushing the "naturalness" argument to its logical conclusion would involve dropping IDL altogether and just defining everything in Java, which I don't think is the right way to go, given that one of CORBA's strongest assets continues to be multi-lingual support. Agreed that there's no evidence of demand for this facility in other languages, but of course we haven't actually looked for any evidence by for example raising this issue with the core RTF. Given that there's nothing Java-specific about IOR processing, I think the balance of probabilities is that this facility would be generally useful. Cheers, Eoghan Ann Dalton1 wrote: Eoghan, This issue arises because of a desire to use natural, performant Java facilities from a vendor J2EE implementation based on a Java SDK ORB. Although we could standardize this API for all languages, that would make it less natural for Java and it's not clear there's any requirement for it from anything other than Java. Also, I believe it's important for us to provide timely, efficient standards for Java where these are needed. If we can't do this, the CORBA standards risk being sidelined in favour of other approaches over which the OMG has no control or scrutiny. Ann eglynn@iona.com To: Ann Dalton1/UK/IBM@IBMGB 13/06/2002 08:39 cc: Ken Cavanaugh , Jishnu Mukerji Please respond to , java-rtf@omg.org eglynn Subject: Re: Issue 4945 - IOR processing performance Ann, I don't want to rehash all the arguments I made previously on this thread. However I must say that I *strongly* believe that the Java mapping is not the right place to define these interfaces. There is nothing Java-specific about the proposed convenience interfaces for IOR processing - the fact this facility would be particularly useful to some J2EE implementations does not make it a Java-specific requirement. That a more general facility defined in IDL and available to all language mappings would receive further scrutiny from the core RFT etc. is not a valid argument IMO - the Java RTF should not be treated as a convenient back-door to standardize non-Java-specific facilites. /Eoghan. Ann Dalton1 wrote: I have no technical objection to local IDL interfaces for this either, but I do think it's important that it be standardised. The requirement is to support J2EE implementations such that they don't have dependencies on a particular vendor's Java SDK. It is thus, although potentially applicable to other languages, a Java specific requirement. If it were to be defined in IDL, I would expect to add to the IOP and IIOP modules. Is this what you envisaged? It could be considered to introduce unnecessary 'stuff' for all, for what is a Java specific requirement. And I assume it would necessitate a Core RTF issue? Although we must of course ensure that what is defined is robust, if it's required only for Java, and is purely a local server concern, I think we should define what's necessary for Java rather than a more general solution that will, and should, receive additional scrutiny. Ann Ken Cavanaugh cc: Ann Dalton1/UK/IBM@IBMGB, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance 15/05/2002 18:05 Please respond to Ken Cavanaugh From: eglynn@iona.com 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 MIME-Version: 1.0 To: Ken Cavanaugh CC: ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: Issue 4945 - IOR processing performance Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2002 08:44:19.0246 (UTC) FILETIME=[B3EAFCE0:01C1FBEC] Subject: Re: Issue 4945 - IOR processing performance To: eglynn@iona.com, Ken Cavanaugh Cc: java-rtf@omg.org, Jishnu Mukerji X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Wed, 26 Jun 2002 21:01:08 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 26/06/2002 21:01:58 Eoghan, Ok, you force me to reflect more carefully and I think you're right. I was overly influenced by my concern to have these APIs standardised in some way, so was disinclined to change tack, and risk not getting them standardised at all. In addition, having now tried both options, I think the IDL approach works better. I have therefore raised core issue 5439. Ken, I assume this can be closed 'no change' in the next cleanup? Thanks, Ann eglynn@iona.com To: Ann Dalton1/UK/IBM@IBMGB 14/06/2002 11:46 cc: java-rtf@omg.org, Jishnu Mukerji , Please respond to Ken Cavanaugh eglynn Subject: Re: Issue 4945 - IOR processing performance Ann, I'm not trying to be obnoxious here, but we already discussed the performance issue on this thread with, if memory serves, the conclusion that there's no reason an implementation of a local IDL interface should be any less performant than an implementation of a native Java interface. We've also discussed the issue of API "naturalness" - e.g. whether java.util.Iterator is inherently better than an iterator interface defined in IDL. I don't think there is a significant issue here - if Java programmers are comfortable programming to the PortableInterceptor IDL (portable interceptors having the most obvious requirement for parsing IORs), then surely they would also be happy coding against IOR processing IDL? Pushing the "naturalness" argument to its logical conclusion would involve dropping IDL altogether and just defining everything in Java, which I don't think is the right way to go, given that one of CORBA's strongest assets continues to be multi-lingual support. Agreed that there's no evidence of demand for this facility in other languages, but of course we haven't actually looked for any evidence by for example raising this issue with the core RTF. Given that there's nothing Java-specific about IOR processing, I think the balance of probabilities is that this facility would be generally useful. Cheers, Eoghan Ann Dalton1 wrote: > Eoghan, > This issue arises because of a desire to use natural, performant > Java facilities from a vendor J2EE implementation based on a Java > SDK ORB. Although we could standardize this API for all languages, > that would make it less natural for Java and it's not clear there's > any requirement for it from anything other than Java. > Also, I believe it's important for us to provide timely, efficient > standards for Java where these are needed. If we can't do this, the > CORBA standards risk being sidelined in favour of other approaches > over which the OMG has no control or scrutiny. > Ann > > > > > eglynn@iona.com > To: Ann Dalton1/UK/IBM@IBMGB > 13/06/2002 08:39 cc: Ken Cavanaugh , Jishnu Mukerji > Please respond to , java-rtf@omg.org > eglynn Subject: Re: Issue 4945 - IOR processing performance > > > > > > > > Ann, > > I don't want to rehash all the arguments I made previously on this > thread. However I must say that I *strongly* believe that the Java > mapping is not the right place to define these interfaces. There is > nothing Java-specific about the proposed convenience interfaces for >IOR > processing - the fact this facility would be particularly useful to >some > J2EE implementations does not make it a Java-specific >requirement. That > a more general facility defined in IDL and available to all language > mappings would receive further scrutiny from the core RFT etc. is >not a > valid argument IMO - the Java RTF should not be treated as a >convenient > back-door to standardize non-Java-specific facilites. > > /Eoghan. > > Ann Dalton1 wrote: > > >>I have no technical objection to local IDL interfaces for this >either, >> > but > >>I >>do think it's important that it be standardised. The requirement is >to >>support >>J2EE implementations such that they don't have dependencies on a >> > particular > >>vendor's Java SDK. It is thus, although potentially applicable to >other >>languages, a Java specific requirement. >> >>If it were to be defined in IDL, I would expect to add to the IOP >and >> > IIOP > >>modules. Is this what you envisaged? It could be considered to >introduce >>unnecessary 'stuff' for all, for what is a Java specific >requirement. >>And I assume it would necessitate a Core RTF issue? >> >>Although we must of course ensure that what is defined is robust, >>if it's required only for Java, and is purely a local server >concern, I >>think >>we should define what's necessary for Java rather than a more >general >>solution >>that will, and should, receive additional scrutiny. >> >>Ann >> >> >> >> >> > >> Ken Cavanaugh >> > >> > > Ken.Cavanaugh@sun.com, eglynn@iona.com > >> n.com> cc: Ann >> > Dalton1/UK/IBM@IBMGB, java-rtf@omg.org > >> Subject: Re: Issue >4945 - >> > IOR processing performance > >> 15/05/2002 18:05 >> > >> Please respond to >> > >> Ken Cavanaugh >> > > > >> >> >> >> >>>From: eglynn@iona.com >>>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 >>>MIME-Version: 1.0 >>>To: Ken Cavanaugh >>>CC: ann_dalton@uk.ibm.com, java-rtf@omg.org >>>Subject: Re: Issue 4945 - IOR processing performance >>>Content-Transfer-Encoding: 7bit >>>X-OriginalArrivalTime: 15 May 2002 08:44:19.0246 (UTC) >>> >>> >>FILETIME=[B3EAFCE0:01C1FBEC] >> >> >>>Ken, >>> >>>I guess we'll have to agree to differ on the question of whether >this >>>proposed facility should be defined in a language specific way. >>> >>>I don't accept that the there's a significant usability handicap in >IDL >>>accessed from Java - e.g. it would possible be to define an local >>>ComponentIterator interface in IDL is this is considered crucial, >in the >>>style of the CosNaming::BindingIterator interface. >>> >>> >>I agree that this is possible. It is slightly less natural than >using >>java.util.Iterator, and I would prefer the more natural Java >approach, >>but as you said, we agree to differ here. I would be willing to >adopt >>any approach that the RTF agrees to. >> >>By the way, I would just use an IDL analog (has_next(), next()) of >>the java.util.iterator interface, since we do not need a remotely >>accessible iterator. >> >> >> >>>Similarly I don't think its necessarily true that the >implementation of >>>a local IDL interface would perform any better or worse that a >native >>>Java one based on java.util.Iterator. >>> >>> >>Performance should be about the same. Implementing a custom Java >> > iterator > >>or a custom IDL iterator is very similar. >> >> >> >>>Obviously it would be more natural for Java programmers to use APIs >>>defined in the native Java style, but I don't think this >convenience is >>>worth the loss of the consistency across languages that IDL brings >to >>>the table. >>> >>>It also seems to me that there is nothing about IOR processing that >is >>>specific to J2EE app servers, in the sense that its likely a >>>standardized IOR management/processing facility would be just as >useful >>>to say a C++ infrastructure built obver COBRA. >>> >>> >>> >>This is probably true also. >> >>Ken. >> >> >> >> >> >> >> >> > > > -- > > 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 > > > > > > > -- 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: Wed, 26 Jun 2002 13:12:54 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 4945 - IOR processing performance To: eglynn@iona.com, Ken.Cavanaugh@Sun.COM, ann_dalton@uk.ibm.com Cc: java-rtf@omg.org, jishnu_mukerji@hp.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc > >Ken, >I assume this can be closed 'no change' in the next cleanup? > Yes. I'll put forth a motion to close 4945 in the next vote of the RTF (sometime in July). Ken.