Issue 4478: Creating IORs (ort-ftf) Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, Vijaykumar.Natarajan@borland.com) Nature: Uncategorized Issue Severity: Summary: > // ulgy conversion to objectref: we should think about > // creating utilities for IOR<->objref conversion I meant to raise that second issue (the ugly IOR to ObjRef conversion). It is too painful and I think we should address it. I can think of a few possible solutions. 1. have make object just return profiles, so the ORB can do the conversion internally. 2. Add a method on the ORT to provide this functionality 3. Add a separate CODEC interface to manufacture IORs from Profiles (IORFactory, rir etc) Resolution: Undo the resolution of issue 4476 and close 4478 no change Revised Text: The revisions are based on the changes introduced by the resolution to issue 4476, so all numbers here assume that 4476 was applied to the Final Adopted specification. The details are as follows: There is no interop or editorial issue for creating a TaggedProfileSeq. The equals and make_profiles operations are removed from ObjectReferenceFactory. Restore section 21.5.3.3 to its state pre vote 2. This section should then read in full: make_object creates an Object Reference from this factory using the given repository ID and object ID. All object refrences created from the same factory share the same profiles and tagged components in their profiles. They may also share some of the data in their object keys, but this is not required. Remove sections 21.5.3.4 and 21.5.3.5. Renumber sections 21.5.3.6-21.5.3.9 to 21.5.3.4-21.5.3.7. Close issue 4478 no change. Note: in writing the report, I realized that this resolution was incomplete, in that the resolution did not mention updating the IDL in sections 21.5.3.1 and 21.10 to remove the equals and make_profiles operations. However, it should be clear from the context that this was the intention, since the purpose of the accepted resolution to issue 4478 was to declare the requested functionality out of scope, which required undoing the adopted resolution to 4476, which included the IDL changes. Actions taken: Incorporate change and close issue. August 14, 2001: received issue Content-Type: APPLICATION/octet-stream; name="ptc.01-08-31.zip"; x-unix-mode=0664 Content-Description: ptc.01-08-31.zip Content-MD5: 6GMZ3w+dK8+vqcq1on3++w== Actions taken: August 14, 2001: received issue Discussion: I meant to raise that second issue (the ugly IOR to ObjRef conversion). I can think of a few possible solutions: Have make_object just return profiles, so the ORB can do the conversion internally. Add a method on the ORT to provide this functionality. Add a separate CODEC interface to manufacture IORs from profiles (IORFactory, rir, etc.) -------------------------------------------------------------------------------- After much discussion, a proposal was put forth to declare the intended usages behind issues 4476 and 4478 as out of scope for the ORT specification. This proposal passed in Vote 3. End of Annotations:===== Date: Mon, 13 Aug 2001 14:12:19 -0700 From: Vijaykumar Natarajan Subject: Creating IORs To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com Message-id: <3B7842B3.3D1717C8@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108131856.LAA14510@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_iXw5VwObgADMoyxLBlvBGQ)" X-UIDL: *1)e9C*id9KT?!!P^od9 Hi all, > // ulgy conversion to objectref: we should think about > // creating utilities for IOR<->objref conversion I meant to raise that second issue (the ugly IOR to ObjRef conversion). It is too painful and I think we should address it. I can think of a few possible solutions. 1. have make object just return profiles, so the ORB can do the conversion internally. 2. Add a method on the ORT to provide this functionality 3. Add a separate CODEC interface to manufacture IORs from Profiles (IORFactory, rir etc) any preferences? Vijay [] vnatarajan1.vcf Date: Mon, 13 Aug 2001 14:26:55 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Creating IORs To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: zKOnlrD2X/uNFqeREDVeAw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: GIBe98I[d9c?9e9Q1F!! >From: Vijaykumar Natarajan >Subject: Creating IORs >To: Ken Cavanaugh >Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, >kkchan@borland.com >MIME-version: 1.0 >X-Accept-Language: en > >Hi all, >> // ulgy conversion to objectref: we should think about >> // creating utilities for IOR<->objref conversion > >I meant to raise that second issue (the ugly IOR to ObjRef >conversion). >It is too painful and I think we should address it. I can think of a >few >possible solutions. > >1. have make object just return profiles, so the ORB can do the >conversion internally. I don't like this approach, as it forces the construction of all objrefs to be forced to fit through an IOR first. It is sometimes a lot more efficient to allow the ObjectReferenceFactory to act as a wrapper around some efficient internal state, and only construct the inefficient IOR form when necessary. >2. Add a method on the ORT to provide this functionality We could do this. Essentially we need ior_to_object and object_to_ior (and these are really very similar to string_to_object and object_to_string). >3. Add a separate CODEC interface to manufacture IORs from Profiles >(IORFactory, rir etc) > This might be the best approach. In general, I would rather take the change to either the core or the PI RTF, as otherwise I think we will need to delay the ORT FTF. So, do we agree that you need the items I listed previously: 1. Convient conversion operations (probably on the ORB) to go between objrefs and IORs (I am not sure that the procedure outlined above is strictly portable, although it seems likely to work on most ORBs). 2. Equality checking on ObjectReferenceFactories, or an attribute to indicate that the current_factory has been modified. 3. Adminstrative ordering of IORInterceptors (nothing new here. There are lots of cases where this is needed in general). If we agree on this, I think we could close the issue (still needs a number) and just fix 2 in the ORT FTF. Thanks, Ken. Date: Tue, 14 Aug 2001 12:03:18 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Creating IORs To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com MIME-Version: 1.0 Content-MD5: Jazm8hbqr97UBFk0VHQxgw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: B>]d9(/He9iT7!!Wg\!! >X-Unix-From: vnatarajan@borland.com Mon Aug 13 14:11:29 2001 >From: Vijaykumar Natarajan >Subject: Creating IORs >To: Ken Cavanaugh >Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, >kkchan@borland.com >MIME-version: 1.0 >X-Accept-Language: en > >Hi all, >> // ulgy conversion to objectref: we should think about >> // creating utilities for IOR<->objref conversion > >I meant to raise that second issue (the ugly IOR to ObjRef >conversion). Please raise this as an issue. >It is too painful and I think we should address it. I can think of a few >possible solutions. > >1. have make object just return profiles, so the ORB can do the >conversion internally. >2. Add a method on the ORT to provide this functionality >3. Add a separate CODEC interface to manufacture IORs from Profiles >(IORFactory, rir etc) > Do we want to raise this in ORT, PI, or core? We could raise it here and then reassign it, or possibly charter an ORT RTF and continue discussing this issue. Thanks, Ken. Date: Tue, 14 Aug 2001 12:09:31 -0700 From: Vijaykumar Natarajan Subject: Re: Proposal for issue TBD (access to IORs in ORT) To: Ken Cavanaugh Cc: ort-ftf@omg.org, kkchan@borland.com, carr@eng.sun.com, jishnu.mukerji@hp.com Message-id: <3B79776B.DB0E9566@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108141900.MAA26918@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_wvvyw7Y1ngBGIGHyFzMbfQ)" X-UIDL: *+Le9*jX!!?!^d9M&)e9 Hi Ken, > Change the IDL for ObjectReferenceFactory in section 21.5.3.1 and in > section 21.10 as follows: > > abstract valuetype ObjectReferenceFactory { > boolean equals( in ObjectReferenceFactory other ) ; > > Object make_object( in string repository_id, in ObjectId id > ) ; > > typedef sequence ProfileSeq ; > > ProfileSeq make_profiles( in string repository_id, in > ObjectId id ) ; > } ; > > (note that the IOP module does not appear to provide a typedef for a > sequence of tagged profiles) I think the ProfileSeq must still go into the IOP module. If one is not defined, we define it. In any case, the IDL in the IOP module is now using deprecated features (anonymous sequences) and should actually use a typedef anyway. Jishnu, Can we update the IOP module in this FTF? or should we transfer that to interop? or core? Vijay [] vnatarajan1.vcf Date: Tue, 14 Aug 2001 12:10:57 -0700 From: Vijaykumar Natarajan Subject: Re: Proposal for issue TBD (access to IORs in ORT) To: Ken Cavanaugh Cc: ort-ftf@omg.org, kkchan@borland.com, carr@eng.sun.com Message-id: <3B7977C1.2E682E3E@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108141900.MAA26918@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_9YKphiRW+apk8IqjTao4Fg)" X-UIDL: ecjd9gQ_d9b`Zd9-]!"! Hi Ken, Other than that comment about IOP::ProfileSeq, this looks good. Vijay Ken Cavanaugh wrote: > > Let's discuss the following proposal and see if it is what we want to > put up for a vote: > > -------------------------- > > Users of ORT may wish to accommodate the following two scenarioes: > > 1. The birth address optimization: when a persistent objref is created, > include the profile(s) for the transient address of the server as well > as the profile(s) that contain the permanent IOR address. > > 2. In a complex system with multiple authentication servers, the IMR and > other CORBA servers may not all support the same authentication > policies. This leads to a need for the IMR to construct a transient > objref that points to the current incarnation of a persistent server > and has security information in the IOR that is appropriate for > that particular server. > > These scenarios are somewhat awkward to address with the current ORT definition > for several reasons. The issue here focuses on the following problems: > > 1. A user defined IORInterceptor may need to determine whether the > current_factory and adapter_template are actually the same valuetype > or not. > > 2. Getting access to the profiles in an object reference is quite cumbersome, > and possibly not portable. > > Proposal: > > Update the ORT specification (ptc/01-04-03) as follows: > > Change the IDL for ObjectReferenceFactory in section 21.5.3.1 and in > section 21.10 as follows: > > abstract valuetype ObjectReferenceFactory { > boolean equals( in ObjectReferenceFactory other ) ; > > Object make_object( in string repository_id, in ObjectId id ) ; > > typedef sequence ProfileSeq ; > > ProfileSeq make_profiles( in string repository_id, in ObjectId id ) ; > } ; > > (note that the IOP module does not appear to provide a typedef for a > sequence of tagged profiles) > > Change section 21.5.3.3 to read (that is, delete the last two sentences > in the section): > > make_object creates an Object Reference from this factory using the given > repository ID and object ID. > > Add new sections: > > 21.5.3.4 make_profiles > > make_profiles returns the sequence of tagged profiles for the IOR that > corresponds to the object reference that would be created by a call > to make_object with the same arguments. > > 21.5.3.5 equals > > equals satisfies the usual reflexive, symmetric, and transitive > properties that equality normally respects. That is, for any > ObjectReferenceFactories X, Y, and Z: > > 1. X.equals( X ) = true > 2. X.equals( Y ) = Y.equals( X ) > 3. if X.equals( Y ) = true and Y.equals( Z ) = true, then X.equals( Z ) = true > > If X and Y are different object adapters, and Xinfo and Yinfo are the > IORInfo objects passed to the IORInterceptor, then > Xinfo.adapter_template().equals( Yinfo.adapter_template() ) = false > > An equals method on a user defined ObjectReferenceFactory must return false when > passed the value of an IORInfo.adapter_template attribute, unless the > user defined make_profiles method returns the same ProfileSeq as the > adapter_template make_profiles method when invoked with the same arguments, > in which case the user defined ObjectReferenceFactory equals method > may return true. > > renumber current sections 21.5.3.4-21.5.3.7 to 21.5.3.6-21.5.3.9 > > -------------------------- > > Thanks, > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Tue, 14 Aug 2001 12:14:57 -0700 From: Vijaykumar Natarajan Subject: Re: Creating IORs To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com Message-id: <3B7978B1.5E142051@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108141903.MAA27170@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_lFIk4o/A2GZmRZpzUt9Kqg)" X-UIDL: *=/!!Y" > >X-Unix-From: vnatarajan@borland.com Mon Aug 13 14:11:29 2001 > >From: Vijaykumar Natarajan > >Subject: Creating IORs > >To: Ken Cavanaugh > >Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com > >MIME-version: 1.0 > >X-Accept-Language: en > > > >Hi all, > >> // ulgy conversion to objectref: we should think about > >> // creating utilities for IOR<->objref conversion > > > >I meant to raise that second issue (the ugly IOR to ObjRef conversion). > > Please raise this as an issue. I thought that mail was it :) > > >It is too painful and I think we should address it. I can think of a few > >possible solutions. > > > >1. have make object just return profiles, so the ORB can do the > >conversion internally. > >2. Add a method on the ORT to provide this functionality > >3. Add a separate CODEC interface to manufacture IORs from Profiles > >(IORFactory, rir etc) > > > > Do we want to raise this in ORT, PI, or core? We could raise it here > and then reassign it, or possibly charter an ORT RTF and continue > discussing this issue. Personally, I think it best fits here. Since the ORFs are the ObjRef creators and they have most (if not exclusive) use for it. As for moving it, if it moves, PI is probably the right place. But, I'd prefer continuing it here (or on an RTF as the case may be). Vijay > > Thanks, > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Thu, 23 Aug 2001 23:13:41 -0700 From: Vijaykumar Natarajan Subject: re: issue 4478 To: ort-ftf@omg.org, Muhammad Arshad Khan , Kay Kit Chan Message-id: <3B85F095.CD2452AD@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en Content-Type: multipart/mixed; boundary="Boundary_(ID_MtXv1u2NhOx7CsHeDci4WQ)" X-UIDL: (\h!!"V=e9'JMe9>*Wd9 Ken, I have a feeling 4478 is worse than I originally thought. I can't seem to figure out a way to create an Object out of an IOR at all (cumbersome or otherwise). The only ORB i can get a handle to is the singleton, which leaves me with nothing to even call object_to_string on. What am I missing? Vijay [] vnatarajan2.vcf Date: Thu, 23 Aug 2001 23:29:52 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: re: issue 4478 To: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, vnatarajan@borland.com Cc: Ken.Cavanaugh@Sun.COM MIME-Version: 1.0 Content-MD5: W6TwY8QAs4Ir5fpK4AwAIA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: I-,e9@HZd97E]!!eHFe9 >From: Vijaykumar Natarajan >Subject: re: issue 4478 >To: ort-ftf@omg.org, Muhammad Arshad Khan , Kay >Kit Chan >MIME-version: 1.0 >X-Accept-Language: en > >Ken, > >I have a feeling 4478 is worse than I originally thought. > >I can't seem to figure out a way to create an Object out of an IOR at >all (cumbersome or otherwise). The only ORB i can get a handle to is >the >singleton, which leaves me with nothing to even call object_to_string >on. > >What am I missing? > Well, I don't think you're missing anything, but it doesn't really matter which ORB you use, so long as it's not the singleton ORB. ior_to_object works exactly like string_to_object: it works for any IOR and creates an objref that is bound to the ORB on which the method was called. However, this doesn't prevent us from either marshalling or invoking the objref. I think perhaps the bigger problem here is the difficulty of getting the ORB that is being created by an ORB.init() call inside the ORB initializer. This is probably the biggest hole today in PI. The only way around it is to arrange after ORB.init() completes to invoke an initilization method on the IOR interceptor object that will be called with components_established later when the adapters are created. Probably the best time to do that is before the POAManagers are activated. This is not a fully general solution, because we often want to simply add interceptors to a program without any change to the program. However, in the context of an IMR, load balancing agent, or similar ORT application, I don't think this is too bad a problem, since the interceptor author and server author are the same developer, who is in complete control of both parts of the code. However, I would still like to see a solution to the ORB access problem. There is of course already a PI issue for it. Solutions span something like: 1. Define a local interface for the ORB, and deprecate the current ORB API. 2. Introduce a native type for the ORB and update the language mappings. 3. Introduce the ORB PIDL into the PI IDL. 4. Others? Did I miss any part of the problems you were thinking about? Thanks, Ken. Date: Thu, 23 Aug 2001 23:42:33 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, vnatarajan@borland.com Message-id: <3B85F758.5AEC5887@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108240629.XAA01228@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_wvK0s9fYcffT5zMREuex3g)" X-UIDL: Jecd9K`id9&c\!!A'G!! Ken, Wouldn't the simplest solution given the magnitude of a IDL ORB solution, be to just change make_object to return the IOR struct. Constructing the Object from the IOR would remain within the client of the ORF. Problem solved. In other words: IOR make_object(....); Vijay Ken Cavanaugh wrote: > >From: Vijaykumar Natarajan > >Subject: re: issue 4478 > >To: ort-ftf@omg.org, Muhammad Arshad Khan , Kay > >Kit Chan > > >MIME-version: 1.0 > >X-Accept-Language: en > > > >Ken, > > > >I have a feeling 4478 is worse than I originally thought. > > > >I can't seem to figure out a way to create an Object out of an IOR > >at > >all (cumbersome or otherwise). The only ORB i can get a handle to > >is the > >singleton, which leaves me with nothing to even call > >object_to_string > >on. > > > >What am I missing? > > > > Well, I don't think you're missing anything, but it doesn't really > matter which ORB you use, so long as it's not the singleton ORB. > ior_to_object works exactly like string_to_object: it works for any > IOR and creates an objref that is bound to the ORB on which the > method was called. However, this doesn't prevent us from either > marshalling or invoking the objref. > > I think perhaps the bigger problem here is the difficulty of getting > the ORB that is being created by an ORB.init() call inside the ORB > initializer. This is probably the biggest hole today in PI. The > >only > way around it is to arrange after ORB.init() completes to invoke an > initilization method on the IOR interceptor object that will be > >called > with components_established later when the adapters are created. > Probably the best time to do that is before the POAManagers are > >activated. > > This is not a fully general solution, because we often want to > >simply > add interceptors to a program without any change to the program. > >However, > in the context of an IMR, load balancing agent, or similar ORT > >application, > I don't think this is too bad a problem, since the interceptor > >author > and server author are the same developer, who is in complete control > >of > both parts of the code. > > However, I would still like to see a solution to the ORB access > >problem. > There is of course already a PI issue for it. Solutions span > >something > like: > > 1. Define a local interface for the ORB, and deprecate the current > >ORB API. > 2. Introduce a native type for the ORB and update the language > >mappings. > 3. Introduce the ORB PIDL into the PI IDL. > 4. Others? > > Did I miss any part of the problems you were thinking about? > > Thanks, > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Thu, 23 Aug 2001 23:59:26 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, vnatarajan@borland.com MIME-Version: 1.0 Content-MD5: YUDx+dGuZqNOXSIePwVkWA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: M/[!!p'5e9Gmn!!:I,!! >From: Vijaykumar Natarajan >Subject: Re: issue 4478 >To: Ken Cavanaugh >Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, vnatarajan@borland.com >MIME-version: 1.0 >X-Accept-Language: en > >Ken, > >Wouldn't the simplest solution given the magnitude of a IDL ORB >solution, be to >just change make_object >to return the IOR struct. Constructing the Object from the IOR would >remain >within the client of the ORF. Problem solved. > >In other words: > IOR make_object(....); > Doing this would impose a very large overhead on ORBs that do not represent IORs internally as IOP::IOR. Why should the ORB supplied implementation of make_object convert from its internal representation (which is very fast for manipulating and invoking) to the IOP::IOR form until it's really necessary, as in marshalling? In some case this is never needed, in others it might not be written to the wire using CDR encapsulation at all. The Sun ORB represents objrefs internally as a Java structure that is basically an IOR template and an object key. Creating an objref simply requires allocating an IOR object, which contains a reference to the immutable IOR template and also to the object key. The representation of the objref on the wire is determined by the presentation layer, and it may not even be CDR (it could be XML based, or it could be based on doors in Solaris). Representing the objref internally as an IOP::IOR compromises the flexibility that is possible here. The obvious problem is that a custom implementation of an ObjectReferenceFactory must implement both make_object and make_profiles. There are different models here, but your use cases require access to an ORB object in order to convert IOP::IOR into an objref. I don't see a good way around this to support both your model and the models that others are using here (at least Sun and OOC). Ken. Date: Fri, 24 Aug 2001 00:43:56 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com Message-id: <3B8605BC.7938604D@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108240659.XAA04687@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_oNacWHiONfTfHaz5RdGlJQ)" X-UIDL: %?8!!71$"!_/Ce92^jd9 Ken, Not really. There are three cases here where make_object may be called. 1. The POA calling make_object on a user defined ORF. 2. The POA calling make_object on its ORT 3. The IORInterceptor calling make_object on the ORT. The case that you are talking about is 2, I believe. That case represents the POA calling make_object internally on its own implementation. Supporting that is easy. Object obj = ((MyTemplateImpl)template).make_object_internal(...); And you don't create an IOR unless case 3 happens and case 1 is the case I'm trying to solve which would be solved because the user has created the IOR struct anyway. I understand your problem, because Borland does the same thing. But as it stands the current spec has no solution to portably convert IORs to Objects and hence unimplementable. Vijay > > Doing this would impose a very > large overhead on ORBs that do not represent IORs internally as >IOP::IOR. > Why should the ORB supplied implementation of make_object convert >from > its internal representation (which is very fast for manipulating and >invoking) > to the IOP::IOR form until it's really necessary, as in marshalling? > In some case this is never needed, in others it might not be written >to > the wire using CDR encapsulation at all. The Sun ORB represents >objrefs > internally as a Java structure that is basically an IOR template and >an > object key. Creating an objref simply requires allocating an IOR >object, > which contains a reference to the immutable IOR template and also to >the > object key. The representation of the objref on the wire is >determined > by the presentation layer, and it may not even be CDR (it could be >XML based, > or it could be based on doors in Solaris). Representing the objref >internally > as an IOP::IOR compromises the flexibility that is possible here. > > The obvious problem is that a custom implementation of an >ObjectReferenceFactory > must implement both make_object and make_profiles. There are >different models > here, but your use cases require access to an ORB object in order to > convert IOP::IOR into an objref. I don't see a good way around this >to support > both your model and the models that others are using here (at least >Sun and > OOC). > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux From: Jeffrey Mischkinsky Message-Id: <200108241636.JAA06858@wheel.dcn.davis.ca.us> Subject: Re: issue 4478 To: Ken.Cavanaugh@Sun.COM Date: Fri, 24 Aug 2001 09:36:47 -0700 (PDT) Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, vnatarajan@borland.com In-Reply-To: <200108240629.XAA01228@taller.eng.sun.com> from "Ken Cavanaugh" at Aug 23, 2001 11:29:52 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: MS8e9,V9e9)O7!!0kOe9 'Ken Cavanaugh' writes: > > > 1. Define a local interface for the ORB, and deprecate the current ORB API. > 2. Introduce a native type for the ORB and update the language mappings. > 3. Introduce the ORB PIDL into the PI IDL. > 4. Others? > > Did I miss any part of the problems you were thinking about? you did miss, MY preferred solution :-) 1a. Define a local interface for the ORB which contains all (or most) of the operations now found in current ORB API, and leave the current ORB API frozen in time, never again to be touched again by human (or alien) hands (or appendages). jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 Date: Fri, 24 Aug 2001 09:47:02 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: Ken.Cavanaugh@sun.com, jmischki@wheel.dcn.davis.ca.us Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, vnatarajan@borland.com, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: I3oYDYa38CgJYZogRt9bEg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: iA[!!TXFe9)d&!!ihFrom: Jeffrey Mischkinsky >Subject: Re: issue 4478 >To: Ken.Cavanaugh@sun.com >Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, vnatarajan@borland.com >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit > >'Ken Cavanaugh' writes: >> >> >> 1. Define a local interface for the ORB, and deprecate the current >ORB API. >> 2. Introduce a native type for the ORB and update the language >mappings. >> 3. Introduce the ORB PIDL into the PI IDL. >> 4. Others? >> >> Did I miss any part of the problems you were thinking about? > >you did miss, MY preferred solution :-) > 1a. Define a local interface for the ORB which contains all (or >most) > of the operations now found in current ORB API, and leave the > current ORB API frozen in time, never again to be touched again >by > human (or alien) hands (or appendages). > Which is really the same as 1, more colorfully phrased :-). But I think we agree on the best solution here to the ORB access problem. It may be time to resurrect the discussion on this issue in the PI and Core RTFs. This ranges from an annoyance to a show stopper for users of PI, depending on exactly what they are trying to do. Ken. Date: Fri, 24 Aug 2001 11:52:39 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: jmischki@wheel.dcn.davis.ca.us, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, vnatarajan@borland.com, carr@eng.sun.com Message-id: <3B86A277.B9A19F8A@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108241647.JAA18850@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_g0OS58clcwpn/BPyO0B8Ng)" X-UIDL: YRfd9Z*_d9HQM!!08D!! It would be a show stopper for ORT, wouldn't it? Since one can't possibly write a portable ORF, w the current set of interfaces. Vijay Ken Cavanaugh wrote: > >From: Jeffrey Mischkinsky > >Subject: Re: issue 4478 > >To: Ken.Cavanaugh@sun.com > >Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, > vnatarajan@borland.com > >MIME-Version: 1.0 > >Content-Transfer-Encoding: 7bit > > > >'Ken Cavanaugh' writes: > >> > >> > >> 1. Define a local interface for the ORB, and deprecate the > >current ORB API. > >> 2. Introduce a native type for the ORB and update the language > >mappings. > >> 3. Introduce the ORB PIDL into the PI IDL. > >> 4. Others? > >> > >> Did I miss any part of the problems you were thinking about? > > > >you did miss, MY preferred solution :-) > > 1a. Define a local interface for the ORB which contains all (or > >most) > > of the operations now found in current ORB API, and leave the > > current ORB API frozen in time, never again to be touched > >again by > > human (or alien) hands (or appendages). > > > > Which is really the same as 1, more colorfully phrased :-). But I > >think > we agree on the best solution here to the ORB access problem. > It may be time to resurrect the discussion on this issue in the > PI and Core RTFs. > > This ranges from an annoyance to a show stopper for users of PI, > depending on exactly what they are trying to do. > > Ken. [] vnatarajan5.vcf Date: Fri, 24 Aug 2001 12:49:15 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: vnatarajan@borland.com Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org, Ken.Cavanaugh@Sun.COM MIME-Version: 1.0 Content-MD5: lxwp+ccscw+jv5+4qBAAlA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: +V-e9T4h!!I#m!!)^Be9 >From: Vijaykumar Natarajan >Subject: Re: issue 4478 >To: Ken Cavanaugh >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, >kkchan@borland.com >MIME-version: 1.0 >X-Accept-Language: en > >Ken, > >Not really. There are three cases here where make_object may be >called. > >1. The POA calling make_object on a user defined ORF. >2. The POA calling make_object on its ORT I do not want there to be any difference in these cases, at least from the POA's viewpoint. The user-defined ObjectReferenceFactory may need to do the conversion in case 1, but it should only pay for this when it is required. >3. The IORInterceptor calling make_object on the ORT. An IORInterceptor does not normally call make_object, it reads and/or writes the adapter_template and current_factory attributes from inside the components_established method. Your use case is that the last IORInterceptor to run always writes to the current_factory an ObjectReferenceFactory that manipulates the profiles in the IORs created from the user-supplied ObjectReferenceFactory, in the case where the adapter_template and the current_factory are not the same ObjectReferenceFactory. One likely variation on this (from Matthew's mail several months ago) is to encode information in the object id that is passed to the make_object method in a custom ObjectReferenceFactory which would look something like: CustomORF implements ObjectReferenceFactory { private ObjectReferenceFactory delegate ; CustomORF( ObjectReferenceFactory orf, ... ) { delegate = orf ; // store other info needed in custom oid } org.omg.CORBA.Object make_object( String repoid, byte[] oid ) { byte[] myoid = ??? ; // some function of info stored and // the oid argument return delegate.make_object( repoid, myoid ) ; } } There is never a need for an IOP::IOR in this case. Introducing one would force 2 conversions: 1. Convert from internal IOR to IOP::IOR in order to get the result from make_object in the form that would be required. 2. Convert from IOP::IOR back to internal IOR form when the object adapter calls make object and needs the internal form. The amount of overhead involved is simply unacceptable. Plus, an IOP::IOR is a very concrete form of an object reference that may not be appropriate for XML or doors based transports, whereas the internal format can be converted as needed into other formats. Conversion is always somewhat inefficient when it involves linearization of an object graph, so I don't want the APIs to force conversions when they are not necessary. > >The case that you are talking about is 2, I believe. That case >represents the POA >calling make_object internally on its own implementation. Supporting >that is easy. > >Object obj = ((MyTemplateImpl)template).make_object_internal(...); But that is illegal by design: see ptc/01-04-03 section 21.5.5.7: "All object references created by the object adapter must be created by calling the make_object method on current_factory" The whole point is that a custom user supplied ORF is used by the Object Adapter directly. I'l grant that it would be possible to do things like make the case where current_factory is never written more efficient, but I want the use cases that do not require access to profiles to be equally efficient. >And you don't create an IOR unless case 3 happens and case 1 is the case I'm trying >to solve which >would be solved because the user has created the IOR struct anyway. > >I understand your problem, because Borland does the same thing. But as it stands the >current spec has no solution to portably convert IORs to Objects and hence >unimplementable. > I think we agree that the only problem is that an ORB is needed for getting access to IOR to objref converters (specified as a result of this issue). There are several ways to accomplish this: 1. Simply require that the ObjectReferenceFactory that is registered be initialized outside of the ORBInitializer that created the ObjectReferenceFactory. This is ugly and makes the code more complex, but that is the current state of the art for PI. This problem pops up again and again for all uses of PI. 2. Really address the underlying problem (see PI issues 3322, 3403, 3429, and 3793, all of which would be solved by either replacing ORBInitInfo with a suitable ORB, or by making such an ORB available from the ORBInitInfo object). 3. A really ugly short term solution is to make an IOR<->objref converter object available from ORBInitInfo, but I would really rather solve the problem completely if possible. However, this could be a direct solution to address your concerns solely in the context of issue 4478. Ken. Date: Fri, 24 Aug 2001 13:42:43 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org Message-id: <3B86BC43.A6E757B0@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108241949.MAA24270@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_tb8wO/0TPmYqxqWbQGh8xg)" X-UIDL: W,bd95X`!!!$E!!pTJe9 Ken, Ken Cavanaugh wrote: > >From: Vijaykumar Natarajan > >Subject: Re: issue 4478 > >To: Ken Cavanaugh > >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, > >kkchan@borland.com > >MIME-version: 1.0 > >X-Accept-Language: en > > > >Ken, > > > >Not really. There are three cases here where make_object may be > >called. > > > >1. The POA calling make_object on a user defined ORF. > >2. The POA calling make_object on its ORT > > I do not want there to be any difference in these cases, at least > >from > the POA's viewpoint. The user-defined ObjectReferenceFactory may > >need > to do the conversion in case 1, but it should only pay for this when > it is required. The user defined one pays for this, period. Even if it has a handle to the ORB. It must first create the IOR struct, somehow convert that to a string and then do an object_to_string on it. There is no way the user defined ORF can avoid creating an IOR struct. And second, I don't see any significant overhead in the POA code if it does: if (the factory is ours) { call make_object_internal() } else { call make_object(); } > >3. The IORInterceptor calling make_object on the ORT. > > An IORInterceptor does not normally call make_object, it reads >and/or > writes the adapter_template and current_factory attributes from > inside the components_established method. You are right, but it is possible and hence the mention. > Your use case is that the > last IORInterceptor to run always writes to the current_factory an > ObjectReferenceFactory that manipulates the profiles in the IORs > created > from the user-supplied ObjectReferenceFactory, in the case where > the adapter_template and the current_factory are not the same > ObjectReferenceFactory. First you assume that's all I care about. My use case is really that I want my POA to be able to add profiles to the object that is created at the end. In the presence of custom ORFs I was perfectly happy w/ the ORF just returning a set of profiles for my POA to include in the IOR that it planned to generate anyway. The current scenario is the best I could convince you to accept for the above ;) > One likely variation on this (from Matthew's mail several months ago) > is to encode information in the object id that is passed to the make_object > method in a custom ObjectReferenceFactory which would look something like: > > CustomORF implements ObjectReferenceFactory { > private ObjectReferenceFactory delegate ; > > CustomORF( ObjectReferenceFactory orf, ... ) > { > delegate = orf ; > // store other info needed in custom oid > } > > org.omg.CORBA.Object make_object( String repoid, byte[] oid ) > { > byte[] myoid = ??? ; // some function of info stored and > // the oid argument > > return delegate.make_object( repoid, myoid ) ; > } > } Two things. I categorize this as a "hack". If the passed in argument is an oid, it should be an oid. If the signature was cast in stone, then that may be a workaround I would use, but defining a spec that says that's how you do things is bad. Second, I still don't understand how that solves any problem. The minute you have a user defined ORF, that ORF has to be creating IOR structs. There is no way you can avoid that. I contend that the case above cannot be implemented using public APIs by a custom ORF. > There is never a need for an IOP::IOR in this case. Introducing one > would force 2 conversions: > > 1. Convert from internal IOR to IOP::IOR in order to get the result > from make_object in the form that would be required. > > 2. Convert from IOP::IOR back to internal IOR form when the object > adapter > calls make object and needs the internal form. > > The amount of overhead involved is simply unacceptable. Plus, an > IOP::IOR > is a very concrete form of an object reference that may not be > appropriate > for XML or doors based transports, whereas the internal format can > be > converted as needed into other formats. Conversion is always > somewhat > inefficient when it involves linearization of an object graph, so I > don't > want the APIs to force conversions when they are not necessary. Note I am not talking about my internal ORFs, I am talking about user defined ORF which cannot be implemented. > > > > > > >The case that you are talking about is 2, I believe. That case >represents the POA > >calling make_object internally on its own >implementation. Supporting that is easy. > > > >Object obj = ((MyTemplateImpl)template).make_object_internal(...); > > But that is illegal by design: see ptc/01-04-03 section 21.5.5.7: > > "All object references created by the object adapter must be created >by calling > the make_object method on current_factory" Note that this is not a user's "current factory". This is my POA's internal template, I'm talking about. Internally, what my POA does with its own template is most certainly its own business. I maintain that a user defined ORF cannot avoid creating IORs. It's moving from IOR to Object that it cannot do. > The whole point is that a custom user supplied ORF is used by the Object Adapter > directly. I'l grant that it would be possible to do things like make the > case where current_factory is never written more efficient, but I want the > use cases that do not require access to profiles to be equally efficient. The latter use case is what I claim is unimplementable. Tell me how a user defined ORF can create an object, given a rep id and an object id. > > > >And you don't create an IOR unless case 3 happens and case 1 is the >case I'm trying > >to solve which > >would be solved because the user has created the IOR struct anyway. > > > >I understand your problem, because Borland does the same thing. But >as it stands the > >current spec has no solution to portably convert IORs to Objects >and hence > >unimplementable. > > > > I think we agree that the only problem is that an ORB is needed for >getting > access to IOR to objref converters (specified as a result of this >issue). > There are several ways to accomplish this: > > 1. Simply require that the ObjectReferenceFactory that is registered >be initialized > outside of the ORBInitializer that created the >ObjectReferenceFactory. This is > ugly and makes the code more complex, but that is the current >state of the art for > PI. This problem pops up again and again for all uses of PI. That is not acceptable. The installation procedures for these are explicit and allows ORF code to be inserted independent of the application. Given the very purpose of ORF is to create object references I think this is within our scope to provide a solution. > > > 2. Really address the underlying problem (see PI issues 3322, 3403, >3429, and 3793, > all of which would be solved by either replacing ORBInitInfo with >a suitable ORB, > or by making such an ORB available from the ORBInitInfo object). I agree. That would really solve the problem. > > > 3. A really ugly short term solution is to make an IOR<->objref >converter object > available from ORBInitInfo, but I would really rather solve the >problem completely > if possible. However, this could be a direct solution to address >your concerns > solely in the context of issue 4478. > > Ken. Vijay -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Fri, 24 Aug 2001 13:57:24 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Vijaykumar Natarajan Cc: Ken Cavanaugh , ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org Message-id: <3B86BFB4.8EFD2AC5@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108241949.MAA24270@taller.eng.sun.com> <3B86BC43.A6E757B0@inprise.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_eSeOzteXy1UfIPMzk7AXWg)" X-UIDL: ?3]!!]C5e9n[?e9Kf_d9 The summary of the problem just to make it clear is: A user defined ORF cannot take a repid and objectid and return an org.omg.CORBA.Object w/o accessing proprietary interfaces. In other words, you cannot write an ORF that will work on other ORBs portably. With access to the ORB, it moves from being impossible to being really inefficient because the only interface on the ORB currently that returns an Object is one that takes a string. i.e. I have to convert my IOR (however I want to represent it in my ORF) and convert that to a string first. Vijay Vijaykumar Natarajan wrote: > Ken, > > Ken Cavanaugh wrote: > > > >From: Vijaykumar Natarajan > > >Subject: Re: issue 4478 > > >To: Ken Cavanaugh > > >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, >kkchan@borland.com > > >MIME-version: 1.0 > > >X-Accept-Language: en > > > > > >Ken, > > > > > >Not really. There are three cases here where make_object may be >called. > > > > > >1. The POA calling make_object on a user defined ORF. > > >2. The POA calling make_object on its ORT > > > > I do not want there to be any difference in these cases, at least >from > > the POA's viewpoint. The user-defined ObjectReferenceFactory may >need > > to do the conversion in case 1, but it should only pay for this >when > > it is required. > > The user defined one pays for this, period. Even if it has a handle >to the ORB. It must > first create the IOR struct, somehow convert that to a string and >then do an > object_to_string on it. There is no way the user defined ORF can >avoid creating an IOR > struct. And second, I don't see any significant overhead in the POA >code if it does: > if (the factory is ours) { > call make_object_internal() > } else { > call make_object(); > } > > > >3. The IORInterceptor calling make_object on the ORT. > > > > An IORInterceptor does not normally call make_object, it reads >and/or > > writes the adapter_template and current_factory attributes from > > inside the components_established method. > > You are right, but it is possible and hence the mention. > > > Your use case is that the > > last IORInterceptor to run always writes to the current_factory an > > ObjectReferenceFactory that manipulates the profiles in the IORs >created > > from the user-supplied ObjectReferenceFactory, in the case where > > the adapter_template and the current_factory are not the same >ObjectReferenceFactory. > > First you assume that's all I care about. My use case is really that >I want my POA to be > able to add profiles to the object that is created at the end. In >the presence of custom > ORFs I was perfectly happy w/ the ORF just returning a set of >profiles for my POA to > include in the IOR that it planned to generate anyway. The current >scenario is the best I > could convince you to accept for the above ;) > > > One likely variation on this (from Matthew's mail several months >ago) > > is to encode information in the object id that is passed to the >make_object > > method in a custom ObjectReferenceFactory which would look >something like: > > > > CustomORF implements ObjectReferenceFactory { > > private ObjectReferenceFactory delegate ; > > > > CustomORF( ObjectReferenceFactory orf, ... ) > > { > > delegate = orf ; > > // store other info needed in custom oid > > } > > > > org.omg.CORBA.Object make_object( String repoid, byte[] >oid ) > > { > > byte[] myoid = ??? ; // some function of info >stored and > > // the oid argument > > > > return delegate.make_object( repoid, myoid ) ; > > } > > } > > Two things. I categorize this as a "hack". If the passed in argument >is an oid, it should > be an oid. If the signature was cast in stone, then that may be a >workaround I would use, > but defining a spec that says that's how you do things is bad. > > Second, I still don't understand how that solves any problem. The >minute you have a user > defined ORF, that ORF has to be creating IOR structs. There is no >way you can avoid that. > > I contend that the case above cannot be implemented using public >APIs by a custom ORF. > > > There is never a need for an IOP::IOR in this case. Introducing >one > > would force 2 conversions: > > > > 1. Convert from internal IOR to IOP::IOR in order to get the >result > > from make_object in the form that would be required. > > > > 2. Convert from IOP::IOR back to internal IOR form when the object >adapter > > calls make object and needs the internal form. > > > > The amount of overhead involved is simply unacceptable. Plus, an >IOP::IOR > > is a very concrete form of an object reference that may not be >appropriate > > for XML or doors based transports, whereas the internal format can >be > > converted as needed into other formats. Conversion is always >somewhat > > inefficient when it involves linearization of an object graph, so >I don't > > want the APIs to force conversions when they are not necessary. > > Note I am not talking about my internal ORFs, I am talking about >user defined ORF which > cannot be implemented. > > > > > > > > > > > > >The case that you are talking about is 2, I believe. That case >represents the POA > > >calling make_object internally on its own >implementation. Supporting that is easy. > > > > > >Object obj = >((MyTemplateImpl)template).make_object_internal(...); > > > > But that is illegal by design: see ptc/01-04-03 section 21.5.5.7: > > > > "All object references created by the object adapter must be >created by calling > > the make_object method on current_factory" > > Note that this is not a user's "current factory". This is my POA's >internal template, I'm > talking about. Internally, what my POA does with its own template is >most certainly its > own business. > I maintain that a user defined ORF cannot avoid creating IORs. It's >moving from IOR to > Object that it cannot do. > > > The whole point is that a custom user supplied ORF is used by the >Object Adapter > > directly. I'l grant that it would be possible to do things like >make the > > case where current_factory is never written more efficient, but I >want the > > use cases that do not require access to profiles to be equally >efficient. > > The latter use case is what I claim is unimplementable. Tell me how >a user defined ORF > can create an object, given a rep id and an object id. > > > > > > > >And you don't create an IOR unless case 3 happens and case 1 is >the case I'm trying > > >to solve which > > >would be solved because the user has created the IOR struct >anyway. > > > > > >I understand your problem, because Borland does the same >thing. But as it stands the > > >current spec has no solution to portably convert IORs to Objects >and hence > > >unimplementable. > > > > > > > I think we agree that the only problem is that an ORB is needed >for getting > > access to IOR to objref converters (specified as a result of this >issue). > > There are several ways to accomplish this: > > > > 1. Simply require that the ObjectReferenceFactory that is >registered be initialized > > outside of the ORBInitializer that created the >ObjectReferenceFactory. This is > > ugly and makes the code more complex, but that is the current >state of the art for > > PI. This problem pops up again and again for all uses of PI. > > That is not acceptable. The installation procedures for these are >explicit and allows ORF > code to be inserted independent of the application. Given the very >purpose of ORF is to > create object references I think this is within our scope to provide >a solution. > > > > > > > 2. Really address the underlying problem (see PI issues 3322, >3403, 3429, and 3793, > > all of which would be solved by either replacing ORBInitInfo >with a suitable ORB, > > or by making such an ORB available from the ORBInitInfo >object). > > I agree. That would really solve the problem. > > > > > > > 3. A really ugly short term solution is to make an IOR<->objref >converter object > > available from ORBInitInfo, but I would really rather solve the >problem completely > > if possible. However, this could be a direct solution to >address your concerns > > solely in the context of issue 4478. > > > > Ken. > > Vijay > -- > This e-mail, and any attachments thereto, is intended only for use >by > the addressee(s) named herein and may contain legally privileged >and/or > confidential information. If you are not the intended recipient of > this e-mail, you are hereby notified that any dissemination, > distribution or copying of this e-mail, and any attachments thereto, >is > strictly prohibited. If you have received this e-mail in error, >please > immediately and permanently delete the original and any copy of any > e-mail and any printout thereof. > > Accelerate your Linux Date: Fri, 24 Aug 2001 14:05:40 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org MIME-Version: 1.0 Content-MD5: 4uZYIpQUv3N8HBxiKpxdIw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: -7F!!S8S!!Ae+!!Z>Ce9 Status: RO >From: Vijaykumar Natarajan >Subject: Re: issue 4478 >To: Ken Cavanaugh >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, >kkchan@borland.com, interceptors-rtf@omg.org >MIME-version: 1.0 >X-Accept-Language: en > >Ken, > >Ken Cavanaugh wrote: > >> >From: Vijaykumar Natarajan >> >Subject: Re: issue 4478 >> >To: Ken Cavanaugh >> >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, >kkchan@borland.com >> >MIME-version: 1.0 >> >X-Accept-Language: en >> > >> >Ken, >> > >> >Not really. There are three cases here where make_object may be >called. >> > >> >1. The POA calling make_object on a user defined ORF. >> >2. The POA calling make_object on its ORT >> >> I do not want there to be any difference in these cases, at least >from >> the POA's viewpoint. The user-defined ObjectReferenceFactory may >need >> to do the conversion in case 1, but it should only pay for this >when >> it is required. > >The user defined one pays for this, period. Even if it has a handle >to the ORB. It must >first create the IOR struct, somehow convert that to a string and >then do an >object_to_string on it. There is no way the user defined ORF can >avoid creating an IOR >struct. And second, I don't see any significant overhead in the POA >code if it does: >if (the factory is ours) { > call make_object_internal() >} else { > call make_object(); >} There is significant overhead in the call to (IOR make_object(...)) if the implementation of make_object does not need access to the profiles. > >> >3. The IORInterceptor calling make_object on the ORT. >> >> An IORInterceptor does not normally call make_object, it reads and/or >> writes the adapter_template and current_factory attributes from >> inside the components_established method. > >You are right, but it is possible and hence the mention. > >> Your use case is that the >> last IORInterceptor to run always writes to the current_factory an >> ObjectReferenceFactory that manipulates the profiles in the IORs created >> from the user-supplied ObjectReferenceFactory, in the case where >> the adapter_template and the current_factory are not the same ObjectReferenceFactory. > >First you assume that's all I care about. My use case is really that I want my POA to be >able to add profiles to the object that is created at the end. In the presence of custom >ORFs I was perfectly happy w/ the ORF just returning a set of profiles for my POA to >include in the IOR that it planned to generate anyway. The current scenario is the best I >could convince you to accept for the above ;) > > >> One likely variation on this (from Matthew's mail several months ago) >> is to encode information in the object id that is passed to the make_object >> method in a custom ObjectReferenceFactory which would look something like: >> >> CustomORF implements ObjectReferenceFactory { >> private ObjectReferenceFactory delegate ; >> >> CustomORF( ObjectReferenceFactory orf, ... ) >> { >> delegate = orf ; >> // store other info needed in custom oid >> } >> >> org.omg.CORBA.Object make_object( String repoid, byte[] oid ) >> { >> byte[] myoid = ??? ; // some function of info stored and >> // the oid argument >> >> return delegate.make_object( repoid, myoid ) ; >> } >> } > >Two things. I categorize this as a "hack". If the passed in argument is an oid, it should >be an oid. If the signature was cast in stone, then that may be a workaround I would use, >but defining a spec that says that's how you do things is bad. The spec does not mandate this, it is one possible way of using it. I plan to do things differently myself, but I think it is a reasonable usage. > >Second, I still don't understand how that solves any problem. The >minute you have a user >defined ORF, that ORF has to be creating IOR structs. There is no way >you can avoid that. > >I contend that the case above cannot be implemented using public APIs >by a custom ORF. Why? I have shown nearly all of the details, the really key point (and the whole point of this spec in the first place) is that ObjectReferenceFactory objects can be created in many different places (=object adapters in different servers across a distributed system) and exchanged simply by marshalling an abstract valuetype. It is not portable, as we have all agreed from the start, but it does work within a single ORB vendor's collection of servers. Our standard IMR persistence scenario is basically an ObjectReferenceFactory exchange between an IMR and a server, as was explained in the RFP response (of course lost in the adopted specification). When the server creates an objref, it simply delegates the creation to the ObjectReferenceFactory that it obtained from the IMR. There is never any need to expose IORs in this scenario. > > >> There is never a need for an IOP::IOR in this case. Introducing >one >> would force 2 conversions: >> >> 1. Convert from internal IOR to IOP::IOR in order to get the result >> from make_object in the form that would be required. >> >> 2. Convert from IOP::IOR back to internal IOR form when the object >adapter >> calls make object and needs the internal form. >> >> The amount of overhead involved is simply unacceptable. Plus, an >IOP::IOR >> is a very concrete form of an object reference that may not be >appropriate >> for XML or doors based transports, whereas the internal format can >be >> converted as needed into other formats. Conversion is always >somewhat >> inefficient when it involves linearization of an object graph, so I >don't >> want the APIs to force conversions when they are not necessary. > >Note I am not talking about my internal ORFs, I am talking about user >defined ORF which >cannot be implemented. > > But it can in many cases. > > >> >> >> >> > >> >The case that you are talking about is 2, I believe. That case >represents the POA >> >calling make_object internally on its own >implementation. Supporting that is easy. >> > >> >Object obj = ((MyTemplateImpl)template).make_object_internal(...); >> >> But that is illegal by design: see ptc/01-04-03 section 21.5.5.7: >> >> "All object references created by the object adapter must be >created by calling >> the make_object method on current_factory" > >Note that this is not a user's "current factory". This is my POA's >internal template, I'm >talking about. Internally, what my POA does with its own template is >most certainly its >own business. I'll agree that you can find ways to optimize the case where the user does not write to current_factory. >I maintain that a user defined ORF cannot avoid creating IORs. It's moving from IOR to >Object that it cannot do. It certainly can avoid creating IORs: we have several different use cases (IMR, load balancing, some kinds of FT) that never require creating IORs directly. It's only when you need to customize the profiles in the IOR that you need direct access to the IOR. > >> The whole point is that a custom user supplied ORF is used by the Object Adapter >> directly. I'l grant that it would be possible to do things like make the >> case where current_factory is never written more efficient, but I want the >> use cases that do not require access to profiles to be equally efficient. > >The latter use case is what I claim is unimplementable. Tell me how a user defined ORF >can create an object, given a rep id and an object id. By delegating to another ObjectReferenceFactory, for example one that was obtained by an IORInterceptor that passes the ObjectReferenceFactory as an argument to a call on a method on the IMR. > >> >> >> >And you don't create an IOR unless case 3 happens and case 1 is the case I'm trying >> >to solve which >> >would be solved because the user has created the IOR struct anyway. >> > >> >I understand your problem, because Borland does the same thing. But as it stands the >> >current spec has no solution to portably convert IORs to Objects and hence >> >unimplementable. >> > I was wondering if you consider the multi-step conversion (get OutputStream from ORB, write out objref, read back as IOP::IOR) to be portable (if you can get access to an ORB object). I'm not convinced that that is really portable (it certainly is ugly). >> >> I think we agree that the only problem is that an ORB is needed for >>getting >> access to IOR to objref converters (specified as a result of this >>issue). >> There are several ways to accomplish this: >> >> 1. Simply require that the ObjectReferenceFactory that is >>registered be initialized >> outside of the ORBInitializer that created the >>ObjectReferenceFactory. This is >> ugly and makes the code more complex, but that is the current >>state of the art for >> PI. This problem pops up again and again for all uses of PI. > >That is not acceptable. The installation procedures for these are >>explicit and allows ORF >code to be inserted independent of the application. Given the very >>purpose of ORF is to >create object references I think this is within our scope to provide >>a solution. I agree that this is a problem. I think in your case you want to install a last interceptor automatically in any arbitrary server, which explains why you find this unacceptable. I have not find it to be impossible so far, just extremely inconvenient. > >> >> >> 2. Really address the underlying problem (see PI issues 3322, 3403, 3429, and 3793, >> all of which would be solved by either replacing ORBInitInfo with a suitable ORB, >> or by making such an ORB available from the ORBInitInfo object). > >I agree. That would really solve the problem. > I think that is the best thing to do here. There are just too many places that are hard to work around without this. You did not comment on approach 3 (IOR<->objref converted in ORBInitInfo). Would you like to consider that as a fallback approach, if we cannot solve the PI ORB issue in general? Ken. Date: Fri, 24 Aug 2001 14:10:38 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: vnatarajan@borland.com Cc: Ken.Cavanaugh@sun.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org MIME-Version: 1.0 Content-MD5: MNiW14bMRCDtRfbIWMtcdA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: hVed9#J2e9$!'e9Y=Be9 Status: RO >From: Vijaykumar Natarajan >Subject: Re: issue 4478 >To: Vijaykumar Natarajan >Cc: Ken Cavanaugh , ort-ftf@omg.org, >akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org >MIME-version: 1.0 >X-Accept-Language: en > >The summary of the problem just to make it clear is: > >A user defined ORF cannot take a repid and objectid and return an >org.omg.CORBA.Object w/o >accessing proprietary interfaces. In other words, you cannot write an >ORF that will work on >other ORBs portably. This is not true. However, the only mechanism currently available is to delegate the make_object call in a user defined ObjectReferenceFactory to another ObjectReferenceFactory, obtained perhaps by a registration call to a different server. If you need to access the profiles of an IOR, we have some difficulties. >With access to the ORB, it moves from being impossible to being really >inefficient because the only interface on the ORB currently that returns an Object is one >that takes a string. i.e. I have to convert my IOR (however I want to represent it in my ORF) >and convert that to a string first. > Right, so we need to solve two problems: 1. Define an IOR<->objref converter interface. 2. Make sure that this interface is available when ORBInitializers are running. Ken. Date: Fri, 24 Aug 2001 14:18:19 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org Message-id: <3B86C49B.B782EF1@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108242110.OAA10457@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_Rv42t6NHpGcV5k0UmTPDBw)" X-UIDL: "'Ud9H~ >From: Vijaykumar Natarajan > >Subject: Re: issue 4478 > >To: Vijaykumar Natarajan > >Cc: Ken Cavanaugh , ort-ftf@omg.org, > >akhan@borland.com, kkchan@borland.com, > interceptors-rtf@omg.org > >MIME-version: 1.0 > >X-Accept-Language: en > > > >The summary of the problem just to make it clear is: > > > >A user defined ORF cannot take a repid and objectid and return an > >org.omg.CORBA.Object w/o > >accessing proprietary interfaces. In other words, you cannot write > >an ORF that will work on > >other ORBs portably. > > This is not true. However, the only mechanism currently available > >is to delegate > the make_object call in a user defined ObjectReferenceFactory to > >another ObjectReferenceFactory, > obtained perhaps by a registration call to a different server. If > >you need to > access the profiles of an IOR, we have some difficulties. > > >With access to the ORB, it moves from being impossible to being > >really > >inefficient because the only interface on the ORB currently that > >returns an Object is one > >that takes a string. i.e. I have to convert my IOR (however I want > >to represent it in my ORF) > >and convert that to a string first. > > > > Right, so we need to solve two problems: > > 1. Define an IOR<->objref converter interface. > > 2. Make sure that this interface is available when ORBInitializers > >are running. > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Fri, 24 Aug 2001 15:26:33 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: vnatarajan@borland.com Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org MIME-Version: 1.0 Content-MD5: QEPsW7S8YTIxSmLZ+XS6jg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: Voad9SS?!!b,_!!)@,e9 Status: RO >From: Vijaykumar Natarajan >Subject: Re: issue 4478 >To: Ken Cavanaugh >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, >kkchan@borland.com, interceptors-rtf@omg.org >MIME-version: 1.0 >X-Accept-Language: en > >Ah, > >I finally see it!! What you are saying is that the custom ORF never >creates an object, it always >delegates to a ORT from the IMR (or whatever) to create the IOR, >which is proprietary anyway etc... > Yes, that's it. >Yes, given the above I am breathing a little easier. However, I still think the simplest solution is as >follows: > >Move the get_profiles call to the ORF. That way, if the POA wants to add its own profiles, it calls >make_profiles, else it calls make_object. That way it is upto the POA to decide if it wants to insert >its profiles or not and calls the appropriate make_object or make_profiles and nobody takes the hit. > I'm not sure how the POA makes this decision in general, but it could certainly be part of proprietary implementation features, perhaps driven by policies. But didn't we just do what you are suggesting for issue 4476? We added make_profiles to the ObjectReferenceFactory. We did not call this get_profiles because the work involved in make_object and make_profiles is essentially the same, in terms of what data is needed (but obviously not the same, in terms of cost of creating the appropriate representation). In any case, we still need to deal with the IOR<->objref conversion issue, as otherwise a custom ObjectReferenceFactory cannot implement make_object when adding profiles to the IOR. It can still implement make_object and make_profiles by delegation if the addition of profiles is not required. Ken. Date: Fri, 24 Aug 2001 19:52:01 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: vnatarajan@borland.com, Ken.Cavanaugh@Sun.COM Cc: ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org MIME-Version: 1.0 Content-MD5: IEdTbqXmFe8a6JiDJOTyKw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: -96e9;PVd9\cA!!4>)e9 Status: RO >From my previous email: > >In any case, we still need to deal with the IOR<->objref conversion >issue, as otherwise >a custom ObjectReferenceFactory cannot implement make_object when >adding profiles to the >IOR. It can still implement make_object and make_profiles by >delegation if the addition >of profiles is not required. > Actually, we don't need the ORB for this at all: we need an interface that can do the conversion, and we need to get it from ORBInitInfo. There are at least two reasonable ways to achieve this: 1. Add IOR<->objref conversion methods to the Codec interface. The CodeFactory is an attribute of ORBInitInfo. 2. Define a new local interface for the converters, and make it available through resolve_initial_references, which is also available in ORBInitInfo (but only during the post_init phase). While I would still like to see the ORB problem solved, we don't need to address it for 4478, as the last thing we want to do in any case is to add more methods to the ORB. Ken. Date: Sat, 25 Aug 2001 11:04:48 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org Message-id: <3B87E8C0.2C2E4EC6@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (Win98; U) Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200108242226.PAA24869@taller.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: E]Ee9oA#e9W%3e9QA\d9 Status: RO Hi Ken, Ken Cavanaugh wrote: > >From: Vijaykumar Natarajan > >Subject: Re: issue 4478 > >To: Ken Cavanaugh > >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, > >kkchan@borland.com, interceptors-rtf@omg.org > >MIME-version: 1.0 > >X-Accept-Language: en > > > >Ah, > > > >I finally see it!! What you are saying is that the custom ORF never > >creates an object, it always > >delegates to a ORT from the IMR (or whatever) to create the IOR, > >which is proprietary anyway etc... > > > > Yes, that's it. > > >Yes, given the above I am breathing a little easier. However, I > >still think the simplest solution is as > >follows: > > > >Move the get_profiles call to the ORF. That way, if the POA wants > >to add its own profiles, it calls > >make_profiles, else it calls make_object. That way it is upto the > >POA to decide if it wants to insert > >its profiles or not and calls the appropriate make_object or > >make_profiles and nobody takes the hit. > > > > I'm not sure how the POA makes this decision in general, but it > >could certainly be part > of proprietary implementation features, perhaps driven by policies. You are right. That can be left upto the ORB/POA implementation. > But didn't we just do what you are suggesting for issue 4476? > We added make_profiles to the ObjectReferenceFactory. We did not > call this get_profiles > because the work involved in make_object and make_profiles is > essentially the same, in > terms of what data is needed (but obviously not the same, in terms > of cost of creating > the appropriate representation). The difference is as follows: In what we suggested for 4476, we added make_profiles to the ORT, which means in order for the POA to get its profiles into the IOR, we had to do this LastInterceptor. What I'm suggesting is to move that to the ORF. This allows the POA to just call make_profiles and add the profiles to its list. Rather than it installing an ORF to the end of the chain that wraps the user ORF and its ORT. That would make this case efficient and straightforward as well. What's more we don't need IOR to ObjRef conversion at all anymore. Because when the POA wants to influence the contents of the IOR, it just calls make_profiles on the current_factory (if current factory was written to) and adds it to the list. (I.e. the factory does not need a way to create Objects, because it doesn't create Objects). Vijay > In any case, we still need to deal with the IOR<->objref conversion issue, as otherwise > a custom ObjectReferenceFactory cannot implement make_object when adding profiles to the > IOR. It can still implement make_object and make_profiles by delegation if the addition > of profiles is not required. > > Ken. Date: Sat, 25 Aug 2001 19:08:04 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org MIME-Version: 1.0 Content-MD5: Zs7dqr2CZl79J4QluOWYvw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: -=1e9V:#e9f~md9BQ;e9 Status: RO > >> But didn't we just do what you are suggesting for issue 4476? >> We added make_profiles to the ObjectReferenceFactory. We did not call this get_profiles >> because the work involved in make_object and make_profiles is essentially the same, in >> terms of what data is needed (but obviously not the same, in terms of cost of creating >> the appropriate representation). > >The difference is as follows: In what we suggested for 4476, we added make_profiles to the ORT, which means in >order for the POA to get its profiles into the IOR, we had to do this LastInterceptor. What I'm suggesting is to >move that to the ORF. This allows the POA to just call make_profiles and add the profiles to its list. Rather -------------------^ Did you mean POA here? >than it installing an ORF to the end of the chain that wraps the user ORF and its ORT. That would make this case >efficient and straightforward as well. make_profiles is on the ObjectReferenceFactory. In fact, there is only a small difference between the Factory and the Template: the Template is_a Factory which is identifiable. If your POA implementation is checking for equality on adapter_template and current_factory, it can do whatever it likes. It can effectively perform the logic I outlined earlier without using an IOR interceptor. It seems like you don't need make_profiles at all. >What's more we don't need IOR to ObjRef conversion at all anymore. Because when the POA wants to influence the >contents of the IOR, it just calls make_profiles on the current_factory (if current factory was written to) and >adds it to the list. (I.e. the factory does not need a way to create Objects, because it doesn't create Objects). > That's good if true: we could just close issue 4478. Ken. Date: Sun, 26 Aug 2001 17:53:47 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com, interceptors-rtf@omg.org Message-id: <3B899A1A.87269545@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108260208.TAA29777@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_joPke3BaC5/K82jLqDli7w)" X-UIDL: $ZM!!]\J!!pX)e9kbjd9 Ken, Ken Cavanaugh wrote: > > > >> But didn't we just do what you are suggesting for issue 4476? > >> We added make_profiles to the ObjectReferenceFactory. We did not call this get_profiles > >> because the work involved in make_object and make_profiles is essentially the same, in > >> terms of what data is needed (but obviously not the same, in terms of cost of creating > >> the appropriate representation). > > > >The difference is as follows: In what we suggested for 4476, we added make_profiles to the ORT, which means in > >order for the POA to get its profiles into the IOR, we had to do this LastInterceptor. What I'm suggesting is to > >move that to the ORF. This allows the POA to just call make_profiles and add the profiles to its list. Rather > > -------------------^ Did you mean POA here? Nope I meant ORF. > >than it installing an ORF to the end of the chain that wraps the user ORF and its ORT. That would make this case > >efficient and straightforward as well. > > make_profiles is on the ObjectReferenceFactory. In fact, there is only a small difference > between the Factory and the Template: the Template is_a Factory which is identifiable. Ah! you are right. make_profiles is on ORF. For some reason, I had the impression that it was on ORT. > > > If your POA implementation is checking for equality on >adapter_template and current_factory, > it can do whatever it likes. It can effectively perform the logic I >outlined earlier without > using an IOR interceptor. It seems like you don't need >make_profiles at all. The POA still needs the make_profiles. I think we are looking at it from two different angles. The way I see this working is as follows: When a POA is ready to create an object and a current_factory has been set, the POA has two choices. If it doesn't want to influence the profiles in the IOR, it calls make_object and returns the corresponding object reference to the user. If it does want to influence the IOR, it calls make_profiles on the current_factory, adds its profiles to it and creates an object reference to return to the user. > > > >What's more we don't need IOR to ObjRef conversion at all >anymore. Because when the POA wants to influence the > >contents of the IOR, it just calls make_profiles on the >current_factory (if current factory was written to) and > >adds it to the list. (I.e. the factory does not need a way to >create Objects, because it doesn't create Objects). > > > > That's good if true: we could just close issue 4478. One nit however, based on the above scenario, we should not mandate that object references are created by calling make_object on the ORF. The text should be more like "when creating an object reference, the POA will either call at least one of make_object or make_profiles but not both." > > > Ken. Vijay -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Sun, 26 Aug 2001 21:58:42 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com MIME-Version: 1.0 Content-MD5: J8gmTSdlud9cDGGCqFLW/Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: J(I!!7Cmd9\EJe9O=@e9 >From: Vijaykumar Natarajan >Subject: Re: issue 4478 >To: Ken Cavanaugh >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, >kkchan@borland.com, interceptors-rtf@omg.org >MIME-version: 1.0 >X-Accept-Language: en > >Ken, > >Ken Cavanaugh wrote: > >> > >> >> But didn't we just do what you are suggesting for issue 4476? >> >> We added make_profiles to the ObjectReferenceFactory. We did >not call this get_profiles >> >> because the work involved in make_object and make_profiles is >essentially the same, in >> >> terms of what data is needed (but obviously not the same, in >terms of cost of creating >> >> the appropriate representation). >> > >> >The difference is as follows: In what we suggested for 4476, we >added make_profiles to the ORT, which means in >> >order for the POA to get its profiles into the IOR, we had to do >this LastInterceptor. What I'm suggesting is to >> >move that to the ORF. This allows the POA to just call >make_profiles and add the profiles to its list. Rather >> >> -------------------^ Did you mean POA here? > >Nope I meant ORF. > >> >than it installing an ORF to the end of the chain that wraps the >user ORF and its ORT. That would make this case >> >efficient and straightforward as well. >> >> make_profiles is on the ObjectReferenceFactory. In fact, there is >only a small difference >> between the Factory and the Template: the Template is_a Factory >which is identifiable. > >Ah! you are right. make_profiles is on ORF. For some reason, I had >the impression that it was on ORT. OK, so I think that is fine: no change required. > >> >> >> If your POA implementation is checking for equality on adapter_template and current_factory, >> it can do whatever it likes. It can effectively perform the logic I outlined earlier without >> using an IOR interceptor. It seems like you don't need make_profiles at all. > >The POA still needs the make_profiles. I think we are looking at it from two different angles. The way I see this >working is as follows: > >When a POA is ready to create an object and a current_factory has been set, the POA has two choices. >If it doesn't want to influence the profiles in the IOR, it calls >make_object and returns the corresponding object reference to the user. > >If it does want to influence the IOR, it calls make_profiles on the current_factory, adds its profiles to it and >creates an object reference to return to the user. To me, the motivation for make_profiles has disappeared: it was desirable when we needed the last interceptor, but if the POA acts directly on the result of a call to make_object, it has the object in whatever internal form that it uses. Why ever call make_profiles, when the POA itself has the objref (and presumably the additional profiles as well) in whatever form is most convenient and efficient? It seems that there is no need to expose the details of this through a standard API. > > >> >> >> >What's more we don't need IOR to ObjRef conversion at all >anymore. Because when the POA wants to influence the >> >contents of the IOR, it just calls make_profiles on the >current_factory (if current factory was written to) and >> >adds it to the list. (I.e. the factory does not need a way to >create Objects, because it doesn't create Objects). >> > >> >> That's good if true: we could just close issue 4478. > However, we have just effectively created a contract that any custom ObjectReferenceFactory must obey: it must implement both make_profiles and make_object. Perhaps this is always done simply by delegating to another ObjectReferenceFactory, in which case we still don't need the IOR<->objref converter. >One nit however, based on the above scenario, we should not mandate that object references are created by calling >make_object on the ORF. The text should be more like "when creating an object reference, the POA will either call at >least one of make_object or make_profiles but not both." True. We should raise a separate issue for this for the RTF (if you really need make_profiles). Ken. Date: Mon, 27 Aug 2001 10:32:28 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com Message-id: <3B8A842C.4C1F91F5@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108270458.VAA12897@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_CdTMpj2cbcssESNraD9Mbg)" X-UIDL: 3_@!!T7@e9V`Q!!A0+!! Hi Ken, Ken Cavanaugh wrote: > >From: Vijaykumar Natarajan > >Subject: Re: issue 4478 > >To: Ken Cavanaugh > >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, > >kkchan@borland.com, > interceptors-rtf@omg.org > >MIME-version: 1.0 > >X-Accept-Language: en > > > >Ken, > > > >Ken Cavanaugh wrote: > > > >> > > >> >> But didn't we just do what you are suggesting for issue 4476? > >> >> We added make_profiles to the ObjectReferenceFactory. We did > >not call this > get_profiles > >> >> because the work involved in make_object and make_profiles is > >essentially the same, in > >> >> terms of what data is needed (but obviously not the same, in > >terms of cost of creating > >> >> the appropriate representation). > >> > > >> >The difference is as follows: In what we suggested for 4476, we > >added make_profiles to > the ORT, which means in > >> >order for the POA to get its profiles into the IOR, we had to do > >this LastInterceptor. > What I'm suggesting is to > >> >move that to the ORF. This allows the POA to just call > >make_profiles and add the profiles > to its list. Rather > >> > >> -------------------^ Did you mean POA here? > > > >Nope I meant ORF. > > > >> >than it installing an ORF to the end of the chain that wraps the > >user ORF and its ORT. > That would make this case > >> >efficient and straightforward as well. > >> > >> make_profiles is on the ObjectReferenceFactory. In fact, there > >is only a small difference > >> between the Factory and the Template: the Template is_a Factory > >which is identifiable. > > > >Ah! you are right. make_profiles is on ORF. For some reason, I had > >the impression that it > was on ORT. > > OK, so I think that is fine: no change required. > > > > >> > >> > >> If your POA implementation is checking for equality on > >adapter_template and > current_factory, > >> it can do whatever it likes. It can effectively perform the > >logic I outlined earlier > without > >> using an IOR interceptor. It seems like you don't need > >make_profiles at all. > > > >The POA still needs the make_profiles. I think we are looking at it > >from two different > angles. The way I see this > >working is as follows: > > > >When a POA is ready to create an object and a current_factory has > >been set, the POA has two > choices. > >If it doesn't want to influence the profiles in the IOR, it calls > >make_object and returns the corresponding object reference to the > >user. > > > >If it does want to influence the IOR, it calls make_profiles on the > >current_factory, adds > its profiles to it and > >creates an object reference to return to the user. > > To me, the motivation for make_profiles has disappeared: it was > >desirable when > we needed the last interceptor, but if the POA acts directly on the > >result of a > call to make_object, it has the object in whatever internal form > >that it uses. > Why ever call make_profiles, when the POA itself has the objref (and > >presumably > the additional profiles as well) in whatever form is most convenient > >and efficient? > It seems that there is no need to expose the details of this through > >a standard API. Almost, but not quite. You see, if there's only make_object, then we go back to the assumption that the ORF has to delegate to an ORT to get the objref. having make_profiles allows the ORF to influence the IOR w/o delegating to an ORT (and importantly, w/o needing a IOR-ObjRef converter). Thanks, Vijay > > > > > > > >> > >> > >> >What's more we don't need IOR to ObjRef conversion at all >anymore. Because when the POA > wants to influence the > >> >contents of the IOR, it just calls make_profiles on the >current_factory (if current > factory was written to) and > >> >adds it to the list. (I.e. the factory does not need a way to >create Objects, because it > doesn't create Objects). > >> > > >> > >> That's good if true: we could just close issue 4478. > > > > However, we have just effectively created a contract that any custom >ObjectReferenceFactory > must obey: it must implement both make_profiles and make_object. >Perhaps this is always > done simply by delegating to another ObjectReferenceFactory, in >which case we still don't > need the IOR<->objref converter. > > >One nit however, based on the above scenario, we should not mandate >that object references > are created by calling > >make_object on the ORF. The text should be more like "when creating >an object reference, the > POA will either call at > >least one of make_object or make_profiles but not both." > > True. We should raise a separate issue for this for the RTF (if you >really need > make_profiles). > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Mon, 27 Aug 2001 12:39:38 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com MIME-Version: 1.0 Content-MD5: TjvXmkz5rznYDqwnSjrWMA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: =~P!!EB7!!#84e9/&@e9 >> To me, the motivation for make_profiles has disappeared: it was desirable when >> we needed the last interceptor, but if the POA acts directly on the result of a >> call to make_object, it has the object in whatever internal form that it uses. >> Why ever call make_profiles, when the POA itself has the objref (and presumably >> the additional profiles as well) in whatever form is most convenient and efficient? >> It seems that there is no need to expose the details of this through a standard API. > >Almost, but not quite. You see, if there's only make_object, then we go back to the assumption >that the ORF has to delegate to an ORT to get the objref. having make_profiles allows the ORF to >influence the IOR w/o delegating to an ORT (and importantly, w/o needing a IOR-ObjRef converter). > OK, so assume that we have written a custom ObjectReferenceFactory that runs last. I see two cases here: 1. (birth address optimization) As I outlined before, you have a custom make_profiles method that just delegates to the adapter_template and the current_factory ObjectReferenceFactory objects (note that the adapter_template is_a ObjectReferenceFactory) and concatenates the results into the resulting Profile sequence. However, implementing make_object to correspond to the make_profiles call requires converting IOR -> objref. 2. (selection of appropriate profiles based on protocol or security information) This seems to be just call make_profiles on the delegate and select only those profiles that are appropriate for the result, based on other information. Again, implementing make_object requires converting the results of the make_profiles call. In either case, make_object cannot be implemented so easily, if we want the results of calling make_profiles and make_object to be the same objref. Implementing make_object here would require calling the custom make_profiles method and converting the result to an objref. The other possible assumption is that the above is done in the POA instead of in the last IOR interceptor, in which case I don't see the need for make_profiles. Perhaps this is my point of confusion here. Thanks, Ken. Date: Mon, 27 Aug 2001 15:28:03 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com Message-id: <3B8AC972.48260031@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108271939.MAA09299@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_EgUhOqTqkSFzmE2XY5diqw)" X-UIDL: _I0e9V1^!!Q17e9oMUd9 Status: RO Hi Ken, Ken Cavanaugh wrote: > >> To me, the motivation for make_profiles has disappeared: it was desirable when > >> we needed the last interceptor, but if the POA acts directly on the result of a > >> call to make_object, it has the object in whatever internal form that it uses. > >> Why ever call make_profiles, when the POA itself has the objref (and presumably > >> the additional profiles as well) in whatever form is most convenient and efficient? > >> It seems that there is no need to expose the details of this through a standard API. > > > >Almost, but not quite. You see, if there's only make_object, then we go back to the assumption > >that the ORF has to delegate to an ORT to get the objref. having make_profiles allows the ORF to > >influence the IOR w/o delegating to an ORT (and importantly, w/o needing a IOR-ObjRef converter). > > > > OK, so assume that we have written a custom ObjectReferenceFactory that runs last. > I see two cases here: > > 1. (birth address optimization) > > As I outlined before, you have a custom make_profiles method that >just delegates to > the adapter_template and the current_factory ObjectReferenceFactory >objects (note > that the adapter_template is_a ObjectReferenceFactory) and >concatenates the results > into the resulting Profile sequence. However, implementing >make_object to correspond > to the make_profiles call requires converting IOR -> objref. > > 2. (selection of appropriate profiles based on protocol or security >information) > > This seems to be just call make_profiles on the delegate and select >only those > profiles that are appropriate for the result, based on other >information. > Again, implementing make_object requires converting the results of >the make_profiles > call. > > In either case, make_object cannot be implemented > so easily, if we want the results of calling make_profiles and >make_object to be the > same objref. Implementing make_object here would require calling >the custom make_profiles > method and converting the result to an objref. > > The other possible assumption is that the above is done in the POA >instead of in the > last IOR interceptor, in which case I don't see the need for >make_profiles. Perhaps > this is my point of confusion here. Question: Can a user write a custom ORF that influences IOR contents, but is not related to ImplReps etc. i.e does not have a handle to a remote ORT that it can call make_object on? You are right in that make_object (once we solve 4478) will be in internal form for the POA to use, which makes make_profiles questionable. The reason I think it is useful, is that my custom ORF (if it doesn't delegate to another adapter_template, such as the one it may receive from an impl rep) will have to build the profiles, to build the IOR before it converts to Object. If that's the case, then my custom ORF can stop at building profiles, and convert to Object only when(or if) make_object is called. > > > Thanks, > > Ken. Vijay -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Mon, 27 Aug 2001 15:48:39 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 4478 To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com MIME-Version: 1.0 Content-MD5: ubfBj5kYBEiGyM40b3VkyA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: >SQe9WlM!!];ed92Zk!! Status: RO >From: Vijaykumar Natarajan >Subject: Re: issue 4478 >To: Ken Cavanaugh >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com >MIME-version: 1.0 >X-Accept-Language: en > >Hi Ken, > >Ken Cavanaugh wrote: > >> >> To me, the motivation for make_profiles has disappeared: it was >desirable when >> >> we needed the last interceptor, but if the POA acts directly on >the result of a >> >> call to make_object, it has the object in whatever internal form >that it uses. >> >> Why ever call make_profiles, when the POA itself has the objref >(and presumably >> >> the additional profiles as well) in whatever form is most >convenient and efficient? >> >> It seems that there is no need to expose the details of this >through a standard API. >> > >> >Almost, but not quite. You see, if there's only make_object, then >we go back to the assumption >> >that the ORF has to delegate to an ORT to get the objref. having make_profiles allows the ORF to >> >influence the IOR w/o delegating to an ORT (and importantly, w/o >needing a IOR-ObjRef converter). >> > >> >> OK, so assume that we have written a custom ObjectReferenceFactory >that runs last. > >> I see two cases here: >> >> 1. (birth address optimization) >> >> As I outlined before, you have a custom make_profiles method that >just delegates to >> the adapter_template and the current_factory ObjectReferenceFactory >objects (note >> that the adapter_template is_a ObjectReferenceFactory) and >concatenates the results >> into the resulting Profile sequence. However, implementing >make_object to correspond >> to the make_profiles call requires converting IOR -> objref. >> >> 2. (selection of appropriate profiles based on protocol or security information) >> >> This seems to be just call make_profiles on the delegate and select >only those >> profiles that are appropriate for the result, based on other >information. >> Again, implementing make_object requires converting the results of >the make_profiles >> call. >> >> In either case, make_object cannot be implemented >> so easily, if we want the results of calling make_profiles and >make_object to be the >> same objref. Implementing make_object here would require calling >the custom make_profiles >> method and converting the result to an objref. >> >> The other possible assumption is that the above is done in the POA >instead of in the >> last IOR interceptor, in which case I don't see the need for >make_profiles. Perhaps >> this is my point of confusion here. > >Question: > >Can a user write a custom ORF that influences IOR contents, but is >not related to ImplReps etc. i.e >does not have a handle to a remote ORT that it can call make_object >on? > Not directly in the original spec. make_profiles allows something of this capability now. >You are right in that make_object (once we solve 4478) will be in internal form for the POA to use, >which makes make_profiles questionable. Yes. It really comes down to doing the optimization either in a last IORInterceptor that sets current_factory to a custom ObjectReferenceFactory vs. just doing it in the POA, in which case only the equals method is really needed. >The reason I think it is useful, is that my custom ORF (if it >doesn't delegate to another adapter_template, such as the one it may >receive from an impl rep) will >have to build the profiles, to build the IOR before it converts to >Object. In general I agree with this, but how does a portable application build a usable profile? Any profile that is complete (i.e. can be used by itself for an invocation) will necessarily contain the object key information, which includes the OA name, object ID, and other bits in some proprietary encoding. The only portable way we have now to create a complete Profile is through an ObjectReferenceFactory. Even so, both of you examples just expose Profiles so that they can look at the profile ID (and perhaps take apart a Profile to look at Components) and decide which Profiles are needed in the final result. This makes me somewhat tempted to create a more abstract Profile type, but I think this would take us too far for the RTF. >If that's the case, then my >custom ORF can stop at building profiles, and convert to Object only >when(or if) make_object is >called. > Yes, so we still need converters, at least for the IOR -> objref direction. Ken. Date: Mon, 27 Aug 2001 17:40:10 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4478 To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, kkchan@borland.com Message-id: <3B8AE86A.4FD11D@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108272248.PAA17393@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_xOZcOb136fydqIWWr69ueQ)" X-UIDL: L~d!!%S >From: Vijaykumar Natarajan > >Subject: Re: issue 4478 > >To: Ken Cavanaugh > >Cc: vnatarajan@borland.com, ort-ftf@omg.org, akhan@borland.com, > kkchan@borland.com > >MIME-version: 1.0 > >X-Accept-Language: en > > > >Hi Ken, > > > >Ken Cavanaugh wrote: > > > >> >> To me, the motivation for make_profiles has disappeared: it > >was desirable > when > >> >> we needed the last interceptor, but if the POA acts directly > >on the result > of a > >> >> call to make_object, it has the object in whatever internal > >form that it > uses. > >> >> Why ever call make_profiles, when the POA itself has the > >objref (and > presumably > >> >> the additional profiles as well) in whatever form is most > >convenient and > efficient? > >> >> It seems that there is no need to expose the details of this > >through a > standard API. > >> > > >> >Almost, but not quite. You see, if there's only make_object, > >then we go > back to the assumption > >> >that the ORF has to delegate to an ORT to get the objref. having > make_profiles allows the ORF to > >> >influence the IOR w/o delegating to an ORT (and importantly, w/o > >needing a > IOR-ObjRef converter). > >> > > >> > >> OK, so assume that we have written a custom > >ObjectReferenceFactory that runs > last. > > > >> I see two cases here: > >> > >> 1. (birth address optimization) > >> > >> As I outlined before, you have a custom make_profiles method that > >just > delegates to > >> the adapter_template and the current_factory > >ObjectReferenceFactory objects > (note > >> that the adapter_template is_a ObjectReferenceFactory) and > >concatenates the > results > >> into the resulting Profile sequence. However, implementing > >make_object to > correspond > >> to the make_profiles call requires converting IOR -> objref. > >> > >> 2. (selection of appropriate profiles based on protocol or > >security > information) > >> > >> This seems to be just call make_profiles on the delegate and > >select only > those > >> profiles that are appropriate for the result, based on other > >information. > >> Again, implementing make_object requires converting the results > >of the > make_profiles > >> call. > >> > >> In either case, make_object cannot be implemented > >> so easily, if we want the results of calling make_profiles and > >make_object to > be the > >> same objref. Implementing make_object here would require calling > >the custom > make_profiles > >> method and converting the result to an objref. > >> > >> The other possible assumption is that the above is done in the > >POA instead of > in the > >> last IOR interceptor, in which case I don't see the need for > >make_profiles. > Perhaps > >> this is my point of confusion here. > > > >Question: > > > >Can a user write a custom ORF that influences IOR contents, but is > >not related > to ImplReps etc. i.e > >does not have a handle to a remote ORT that it can call make_object > >on? > > > > Not directly in the original spec. make_profiles allows something > >of > this capability now. > > >You are right in that make_object (once we solve 4478) will be in > >internal form > for the POA to use, > >which makes make_profiles questionable. > > Yes. It really comes down to doing the optimization either in a > >last > IORInterceptor that sets current_factory to a custom > >ObjectReferenceFactory > vs. just doing it in the POA, in which case only the equals method > >is > really needed. > > >The reason I think it is useful, is that my custom ORF (if it > >doesn't delegate to another adapter_template, such as the one it > >may receive > from an impl rep) will > >have to build the profiles, to build the IOR before it converts to > >Object. > > In general I agree with this, but how does a portable application > >build a > usable profile? Any profile that is complete (i.e. can be used by > >itself > for an invocation) will necessarily contain the object key > >information, > which includes the OA name, object ID, and other bits in some > >proprietary > encoding. The only portable way we have now to create a complete > >Profile > is through an ObjectReferenceFactory. Yeah. I see the issue. However, there are multicomponent profiles that may be added and are not by this definition complete. Also, There does exist the mechanism akin to corbaloc, which is knowing the host port and the bunch of bytes that make the object key (or a well known object key, like "NameService"). Nevertheless, the standard structures exist and can be populated (except for the object key contents, which has to be known to the ORF) > Even so, both of you examples just expose Profiles so that they can look at > the profile ID (and perhaps take apart a Profile to look at Components) > and decide which Profiles are needed in the final result. If the POA creates the Obj ref (ie not using the last factory mechanism), then the POA doesn't have to look into the profiles, it can just add the profile to the IOR. > > > This makes me somewhat tempted to create a more abstract Profile >type, > but I think this would take us too far for the RTF. Isn't taggedProfile an abstract profile type. there's IIOP ProfileBody that allows you to look into an IIOP profile as well. > > > >If that's the case, then my > >custom ORF can stop at building profiles, and convert to Object >only when(or > if) make_object is > >called. > > > > Yes, so we still need converters, at least for the IOR -> objref >direction. :( appears so. > Vijay > > > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Wed, 3 Oct 2001 11:56:33 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Remaining issue(s) To: ort-ftf@omg.org Cc: ken.cavanaugh@sun.com, harold.carr@sun.com MIME-Version: 1.0 Content-MD5: TQKGqbDUH/uLnv3imQuI/w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: jWAe9Vg=e9:I6e9k_O!! At the last OMG meeting in Toronto, the AB raised objections to the status of issue 4478 (objref to IOR conversion). Consequently, the FTF deadline was extended to 12/3/01, with the report due 3 weeks before the Dublin meeting. Alhough 12/3 is a ways off yet, 3 weeks before the Dublin meeting works out to 10/22. We will need to get out at least one more vote between now and then to deal with issue 4478 (and possibly 4476 again as well: see below). Just as a reminder, because the FTF was continued, we still have the same FTF membership, not the newly proposed RTF membership. The voting members of the ORT FTF are: Sun (Ken Cavanaugh) chair Borland (Vijaykumar Natarajan) Iona (Bob Kukura) IBM (Randy Fox) Recap Vijay raised the questions in issue 4476 to allow more manipulation of the objref that is created in an ObjectReferenceTemplate. This led to the introduction of ObjectReferenceFactory.make_profiles, which returns a sequence, which can then be (rather painfully and slowly) manipulated as desired, using the PI codecs. The main use cases for this are: 1. Birth address optimization, in which the POA must add a profile to an IOR of a persistent objref that contains the address at which the object was created (and in many cases is still served at this address). 2. Complex security models, where the IMR wants to construct an IOR containing multiple profiles with different security models. Proposal for consideration Let's create an abstract representation of an IOR roughly as follows: module IOR { abstract valuetype ProfileIterator ; abstract valuetype Profile ; abstract valuetype ComponentIterator ; abstract valuetype Component ; abstract valuetype IOR { readonly attribute string type_id ; ProfileIterator profiles() ; void add_profile( in Profile profile ) ; Object make_object() ; } ; abstract valuetype ProfileIterator { boolean has_next_profile() ; Profile next_profile() ; } ; abstract valuetype Profile { readonly attribute IOP::ProfileId id ; } ; abstract valuetype IIOPProfile : Profile { typedef sequence ObjectKey ; readonly attribute IIOP::Version version ; readonly attribute string host ; readonly attribute unsigned short port ; readonly attribute ObjectKey key ; ComponentIterator components() ; void add_component( in Component component ) ; } ; abstract valuetype ComponentIterator{ boolean has_next_attribute() ; Component next_component() ; } ; abstract valuetype Component { readonly attribute IOP::ComponentId id ; } ; } ; then the ObjectReferenceFactory just needs IOR::IOR make_ior( in string repoid, in ObjectId oid ) instead of make_profiles. The IOR can be composed out of abstract profiles as needed, and converted to an objref using IOR.make_object. This handles the cases where objrefs are created out of pieces of IORs created by multiple ObjectReferenceFactory instances. If there is a need to start with a random objref outside of the ORT framework, then we need an additional method to create an IOR::IOR out of an objref somewhere. But I'm not presenting this as a finished proposal, rather I intend to use it to continue the discussion. Problems this solves: 1. No inefficient conversion: the abstract valuetypes can be efficiently mapped to whatever internal architecture an ORB supports for objrefs and IORs. 2. No committment to particular encodings: all of that is deferred until needed. 3. This avoids concerns about which version of GIOP is used to encode the IOR using a codec approach. Questions (mainly for Vijay): 1. Do you want to move in this direction? 2. Do you need the general objref to abstract IOR conversion in this framewor? Let's get the ball rolling again and finish this FTF. Thanks, Ken. Date: Tue, 9 Oct 2001 12:44:10 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Remaining issue(s) To: Ken.Cavanaugh@sun.com, kukura@iona.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, michi.henning@iona.com, matthew.newhook@iona.com MIME-Version: 1.0 Content-MD5: L3hA7MaJ5qTvfamVBGqhnA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: T`:e96,\d9*Y"!!O&hd9 >From: Bob Kukura >X-Accept-Language: en >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: vnatarajan@borland.com, ort-ftf@omg.org, Michi Henning >, Matthew Newhook >Subject: Re: Remaining issue(s) >Content-Transfer-Encoding: 7bit > >Hi Ken, > >I appreciate your effort in producing this proposal to stimulate >discussion, but I believe IONA >would vote against this sort of proposal. The abstract model of IORs >that is presented has >significant incompatabilities with the internal model of IORs used in >some of our products. >These aren't just representational issues, but are related to the >architecture by which IORs, >Profiles, and Components are created and managed in our ORBs. The >model we use internally would >not necessarily be appropriate for other ORBs, either. > >For example, the read accessors of the proposed valuetypes could be >mapped efficiently. But the >the add_profile and add_component operations on the specified >valuetypes just don't fit our >model, as our internal equivalent of IOR templates are created via a >different process tied to >our transport framework. > Actually, this is basically true for the Sun ORB as well. add_profile and add_component would basically require that we create a new IOR template for the additions and use the template just for the particular objref being created. However, this is still better than alternative models using the standard IOP::IOR, which require CDR encapsulation. Encapsulating information just for the purpose of satisfying an OMG standard API is a high performance price to pay. My efforts are aimed at producing the best specification that I can given Vijay's requirements. >Also, our model does not treat TAG_INTERNET_IOP profiles specially - components can be used >transparently in TAG_MULTIPLE_COMPONENTS profiles or other profile types, with ORB services >(even those implemented using Portable Interceptors) supported regardless of what profiles are >used to advertize the transports and protocols supported by the IOR. If someone really needs >this level of IOR access using our products, they would be much better off using our >proprietaty APIs. They'd get better performance, better scalability, and better compatibility >with the other components making up our ORB products. > >My general reaction is that this proposal is attempting to extend the reach of ORT into >territory not intended in the RFP submission. Specifically, IONA did not intend to expose >transport level details, such as specific profiles and the ability to manipulate their >contents, via ORT. Manipulating "birth addresses" or implementing "complex security models" >were not considered requirements. We feel that the mechanisms already present in the Portable >Interceptor specification for accessing IOR components are sufficient for portably >implementating transport-independent ORB services, and that providing access to >transport-specific IOR information should be considered out of scope. Even if these sorts of >APIs were provided, it would simply not be portable for an application to manipulate transport >information in IORs outside the context of a specific ORB's transport framework. > This of course is the problem with issue 4476, which arguably does move beyond the original RFP requirements, which I tried to target very carefully at the server activation issues. But 4476 is incomplete without 4478 (4478 calls for methods to convert CORBA::Object to/from IOP::IOR). One problem I have with 4478 is that IOP::IOR is too concrete a representation for everything that can be done with object references. In particular, it assumes CDR encapsulation, so IOP::IOR is protocol specific (and indeed which version of GIOP encoding for the encapsulation might matter). To finish this FTF, we need to either move forward with 4476/4478 and produce a complete solution for Vijay's concerns, or get rid of the mechanism altogether. >By the way, what were the specific objections of the AB on issue 4478? > >From Jeff's email of 9/5/01: Final status of the spec: (Unfortunately for the FTF, I'm on its mailing list so I got to watch the flurry of mail on issue 4478. :-) IMO the deferred issue 4478 is fairly serious, and should be resolved and implemented before the spec will be suitable for being considered to be finalised. Note: If I've misunderstood, I'm quite willing to be convinced otherwise. All of the other issues Jeff had with the earlier vcersion of the FTF report were minor and could easily be corrected. But given Jeff's feelings on this issue, I decided it was best to extend the FTF one meeting to address issue 4478. I was unable to attend the Toronto meeting (and I won't be in the Dublin meeting either; Sun's travel restrictions basically keep everyone home in nearly all cases except critical company business). From what Peter Walker said, we just proposed the extension and the board said OK. Ken. Date: Tue, 09 Oct 2001 18:07:57 -0700 From: Vijaykumar Natarajan Subject: Re: Remaining issue(s) To: Bob Kukura Cc: Ken Cavanaugh , vnatarajan@borland.com, ort-ftf@omg.org, Michi Henning , Matthew Newhook Message-id: <3BC39F6D.29661102@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200110090033.f990X2324331@ha1sca-mail1.SFBay.Sun.COM> <3BC34707.F298F03A@iona.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_gw6mVeIX5arpV8pTqnfPEA)" X-UIDL: !@Ee90,"e93R:!!Ma5e9 Bob, While I agree that this approach might not be the way to go, I disagree that fixing this is out of scope of this proposal. This specification's existence is primarily to support Server Activation. I don't see how that can be done and yet be oblivious of transport details (as ImplReps and servers are effectively exchanging transport details). Overall, I have only one issue that I need resolved and the issue must be resolved. My issue is that the IOR produced by my server has to be able to include things that my server (POA) wants to include. W/o 4476/4478, one could install a ObjectReferenceFactory that will have to be called by a POA when it is creating an IOR and whatever IOR is returned by that ObjectReferenceFactory is the IOR the POA returns to the user (w/o the POA having any way to add/change anything in the IOR returned). To get a sense of where we stand, do you even consider this an issue? Thanks, vijay Bob Kukura wrote: > Hi Ken, > > I appreciate your effort in producing this proposal to stimulate >discussion, but I believe IONA > would vote against this sort of proposal. The abstract model of IORs >that is presented has > significant incompatabilities with the internal model of IORs used >in some of our products. > These aren't just representational issues, but are related to the >architecture by which IORs, > Profiles, and Components are created and managed in our ORBs. The >model we use internally would > not necessarily be appropriate for other ORBs, either. > > For example, the read accessors of the proposed valuetypes could be >mapped efficiently. But the > the add_profile and add_component operations on the specified >valuetypes just don't fit our > model, as our internal equivalent of IOR templates are created via a >different process tied to > our transport framework. > > Also, our model does not treat TAG_INTERNET_IOP profiles specially - >components can be used > transparently in TAG_MULTIPLE_COMPONENTS profiles or other profile >types, with ORB services > (even those implemented using Portable Interceptors) supported >regardless of what profiles are > used to advertize the transports and protocols supported by the >IOR. If someone really needs > this level of IOR access using our products, they would be much >better off using our > proprietaty APIs. They'd get better performance, better scalability, >and better compatibility > with the other components making up our ORB products. > > My general reaction is that this proposal is attempting to extend >the reach of ORT into > territory not intended in the RFP submission. Specifically, IONA did >not intend to expose > transport level details, such as specific profiles and the ability >to manipulate their > contents, via ORT. Manipulating "birth addresses" or implementing >"complex security models" > were not considered requirements. We feel that the mechanisms >already present in the Portable > Interceptor specification for accessing IOR components are >sufficient for po