Issue 2933: ots-rtf: OTS and location transparency (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: Page 10-67 of the spec says: The ORB will invoke the sender callbacks only when a transactional operation is issued for an object in a different process. Objects within the same process implicitly share the same transaction context. The receiver callbacks are invoked when the ORB receives a transactional request from a different process. There are a number of problems with this paragraph: 1) "Different process" is a rather ill-defined idea. Some environments have no such thing as a process. 2) The requirement breaks location transparency big-time, and it appears to be unimplementable in the general case: Resolution: This problem is made mute by text changes made by Messaging. Revised Text: Actions taken: October 11, 1999: received issue January 16, 2001: closed issue Discussion: The text mentioned in the summary will be removed by the Messaging changes, so this issue can be closed without action. End of Annotations:===== Date: Mon, 11 Oct 1999 14:59:02 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: OTS and location transparency Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Page 10-67 of the spec says: The ORB will invoke the sender callbacks only when a transactional operation is issued for an object in a different process. Objects within the same process implicitly share the same transaction context. The receiver callbacks are invoked when the ORB receives a transactional request from a different process. There are a number of problems with this paragraph: 1) "Different process" is a rather ill-defined idea. Some environments have no such thing as a process. 2) The requirement breaks location transparency big-time, and it appears to be unimplementable in the general case: - It imposes a restriction on the ORB to implement a collocation optimization. There may be good reasons not have such an optimization. - Guaranteeing that the callbacks will be invoked only for requests to another process (whatever that means) may be difficult. In particular, the ultimate target of a request is not determined until after the actual request is dispatched, by which time it is too late. What if the receiving process uses a servant locator and issues a location forward reply? - An ORB may run on a machine with multiple network interfaces (possibly for different protocols). Conceivably, a call could be made via one network interface to an object implemented using a different protocol. If no previous binding has happened to an object on that second interface, the ORB may not be able to recognize that a call is actually collocated and incorrectly invoke a callback. - A call may actually be collocated via a bridge. In other words, an IOR can point at a bridge which then ends up forwarding the request back to the original caller (if client and server happen to be collocated by communicate via the bridge). I'm having great problems with the above paragraph. In particular, the fact that the receiving address space for an invocation can vary on a call-by-call basis, using the location forward mechanism, I don't see how this can be implementable. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com Date: Wed, 9 Feb 2000 10:36:33 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: Issue 2933 In-Reply-To: <20000208161557.F439@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: bN9!!3Wh!!;kKe92nGe9 On Tue, 8 Feb 2000, Blake Biesecker wrote: > Michi, > > Did you have any specific changes in mind? Well, as far as I can tell, the requirement in the spec is unimplementable, pure and simple. So, either we drop the callbacks entirely, or we make them always. Only making callbacks in the collocated case appears to be impossible. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 8 Feb 2000 17:05:31 -0800 From: Blake Biesecker To: Michi Henning Cc: ots-rtf@omg.org Subject: Re: Issue 2933 Message-ID: <20000208170530.A430@gemstone.com> References: <20000208161557.F439@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Wed, Feb 09, 2000 at 10:36:33AM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: fYNd9J;=e9Uoi!!~'T!! Michi, It looks like the text you are concerned about has been removed by the Messaging spec. If the current Messaging work is part of the CORBA 2.3, I think we can defer this issue to Messaging. The section replacing the text you mention - 10.5.2.1 - make no mention of processes. Do you agree? (I'm looking at ptc/99-10-07.pdf.) Blake On Wed, Feb 09, 2000 at 10:36:33AM +1000, Michi Henning wrote: > On Tue, 8 Feb 2000, Blake Biesecker wrote: > > > Michi, > > > > Did you have any specific changes in mind? > > Well, as far as I can tell, the requirement in the spec is > unimplementable, > pure and simple. So, either we drop the callbacks entirely, or we > make > them always. Only making callbacks in the collocated case appears to > be impossible. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Date: Wed, 9 Feb 2000 11:16:32 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org, Jishnu Mukerji Subject: Re: Issue 2933 In-Reply-To: <20000208170530.A430@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ;C?e9_P?!!Y^@!!+N2!! On Tue, 8 Feb 2000, Blake Biesecker wrote: > Michi, > > It looks like the text you are concerned about has been > removed by the Messaging spec. If the current Messaging > work is part of the CORBA 2.3, I think we can defer > this issue to Messaging. The section replacing the text > you mention - 10.5.2.1 - make no mention of processes. > > Do you agree? (I'm looking at ptc/99-10-07.pdf.) Looks like this has been fixed, yes. Certainly, the requirement to only invoke the callbacks in the collocated case is no longer there, and there is no mention of "process" anymore. (Both changes are for the better, IMO :-) I don't think that messaging is part of CORBA 2.3. Jishnu, can we just vote to adopt the text the messaging people came up with for this RTF? Seeing that messaging has been voted on already, can we do this"? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 8 Feb 2000 17:27:57 -0800 From: Blake Biesecker To: Michi Henning Cc: ots-rtf@omg.org, Jishnu Mukerji Subject: Re: Issue 2933 Message-ID: <20000208172757.F430@gemstone.com> References: <20000208170530.A430@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Wed, Feb 09, 2000 at 11:16:32AM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 0%H!!n[T!!mF;e9jk2e9 On Wed, Feb 09, 2000 at 11:16:32AM +1000, Michi Henning wrote: > On Tue, 8 Feb 2000, Blake Biesecker wrote: > > > Michi, > > > > It looks like the text you are concerned about has been > > removed by the Messaging spec. If the current Messaging > > work is part of the CORBA 2.3, I think we can defer > > this issue to Messaging. The section replacing the text > > you mention - 10.5.2.1 - make no mention of processes. > > > > Do you agree? (I'm looking at ptc/99-10-07.pdf.) > > Looks like this has been fixed, yes. Certainly, the requirement to > only > invoke the callbacks in the collocated case is no longer there, and > there > is no mention of "process" anymore. (Both changes are for the > better, IMO :-) > Do you mean only invoke callbacks in the non-collocated case? The original spec says: "The receiver callbacks are invoked when the ORB receives a transactional request from a different process." Anyway, I agree that it is best to avoid talk of processes, but I'm confused about the requirement to only invoke the callbacks in the collocated case .... Blake > > I don't think that messaging is part of CORBA 2.3. Jishnu, can we > just > vote to adopt the text the messaging people came up with for this > RTF? > Seeing that messaging has been voted on already, can we do this"? > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Date: Wed, 9 Feb 2000 12:03:14 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org, Jishnu Mukerji Subject: Re: Issue 2933 In-Reply-To: <20000208172757.F430@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: RCDe9NT4!!NB"!!H_ad9 On Tue, 8 Feb 2000, Blake Biesecker wrote: > Do you mean only invoke callbacks in the non-collocated case? Oops, yes. > The original spec says: > > "The receiver callbacks are invoked when the ORB receives a > transactional > request from a different process." > > Anyway, I agree that it is best to avoid talk of processes, but I'm > confused about the requirement to only invoke the callbacks in > the collocated case .... My point was that it doesn't make sense to invoke a callback in either the collocated case or the non-collocated case only because, in general, there is no way to find out whether something is collocated or not. As far as I can see, the callbacks are now invoked always and unconditionally, which means the thing is at least implementable. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jis@fpk.hp.com Message-ID: <38A18DCA.79A2E7B6@fpk.hp.com> Date: Wed, 09 Feb 2000 10:54:50 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: Michi Henning Cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 2933 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: X@Xd9K-Sd9kAJ!!QQ1e9 Michi Henning wrote: > > On Tue, 8 Feb 2000, Blake Biesecker wrote: > > > Michi, > > > > It looks like the text you are concerned about has been > > removed by the Messaging spec. If the current Messaging > > work is part of the CORBA 2.3, I think we can defer > > this issue to Messaging. The section replacing the text > > you mention - 10.5.2.1 - make no mention of processes. > > > > Do you agree? (I'm looking at ptc/99-10-07.pdf.) > > Looks like this has been fixed, yes. Certainly, the requirement to > only > invoke the callbacks in the collocated case is no longer there, and > there > is no mention of "process" anymore. (Both changes are for the > better, IMO :-) > > I don't think that messaging is part of CORBA 2.3. Jishnu, can we > just > vote to adopt the text the messaging people came up with for this > RTF? > Seeing that messaging has been voted on already, can we do this"? Yes, that would be the right thing to do to cover the small window between when this RTF report gets adopted, and when Messaging gets published as part of a mainline version. This works as long as the proposed resolution does not depend on any Core features that are not in Core 2.3, but is in Core 2.3 + Messaging. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" , Subject: RE: Issue 2933 Date: Wed, 9 Feb 2000 13:19:30 -0500 Message-ID: <003201bf732a$3615eb10$b185413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20000208161557.F439@gemstone.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: pMl!!b#^!!c_ed9)+"e9 The definition of "process" is problematic. Is the issue on callbacks that it isn't clear whether or not these must go via the ORB? -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Tuesday, February 08, 2000 7:16 PM To: ots-rtf@omg.org Subject: Issue 2933 Michi, Did you have any specific changes in mind? Any one else have any comments? Blake issue archive: -------------------------------- Issue 2933: ots-rtf: OTS and location transparency (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 10-67 of the spec says: The ORB will invoke the sender callbacks only when a transactional operation is issued for an object in a different process. Objects within the same process implicitly share the same transaction context. The receiver callbacks are invoked when the ORB receives a transactional request from a different process. There are a number of problems with this paragraph: 1) "Different process" is a rather ill-defined idea. Some environments have no such thing as a process. 2) The requirement breaks location transparency big-time, and it appears to be unimplementable in the general case: Resolution: Revised Text: Actions taken: October 11, 1999: received issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 14:59:02 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: OTS and location transparency Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Page 10-67 of the spec says: The ORB will invoke the sender callbacks only when a transactional operation is issued for an object in a different process. Objects within the same process implicitly share the same transaction context. The receiver callbacks are invoked when the ORB receives a transactional request from a different process. There are a number of problems with this paragraph: 1) "Different process" is a rather ill-defined idea. Some environments have no such thing as a process. 2) The requirement breaks location transparency big-time, and it appears to be unimplementable in the general case: - It imposes a restriction on the ORB to implement a collocation optimization. There may be good reasons not have such an optimization. - Guaranteeing that the callbacks will be invoked only for requests to another process (whatever that means) may be difficult. In particular, the ultimate target of a request is not determined until after the actual request is dispatched, by which time it is too late. What if the receiving process uses a servant locator and issues a location forward reply? - An ORB may run on a machine with multiple network interfaces (possibly for different protocols). Conceivably, a call could be made via one network interface to an object implemented using a different protocol. If no previous binding has happened to an object on that second interface, the ORB may not be able to recognize that a call is actually collocated and incorrectly invoke a callback. - A call may actually be collocated via a bridge. In other words, an IOR can point at a bridge which then ends up forwarding the request back to the original caller (if client and server happen to be collocated by communicate via the bridge). I'm having great problems with the above paragraph. In particular, the fact that the receiving address space for an invocation can vary on a call-by-call basis, using the location forward mechanism, I don't see how this can be implementable. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" , "'Michi Henning'" Cc: , "'Jishnu Mukerji'" Subject: RE: Issue 2933 Date: Wed, 9 Feb 2000 13:21:08 -0500 Message-ID: <003301bf732a$6ffaa0a0$b185413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20000208172757.F430@gemstone.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]0-!!W%Me9f?j!!['Wd9 Ok, if this is fixed, never mind! I got my emails out of order (boy there were a lot today) -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Tuesday, February 08, 2000 8:28 PM To: Michi Henning Cc: ots-rtf@omg.org; Jishnu Mukerji Subject: Re: Issue 2933 On Wed, Feb 09, 2000 at 11:16:32AM +1000, Michi Henning wrote: > On Tue, 8 Feb 2000, Blake Biesecker wrote: > > > Michi, > > > > It looks like the text you are concerned about has been > > removed by the Messaging spec. If the current Messaging > > work is part of the CORBA 2.3, I think we can defer > > this issue to Messaging. The section replacing the text > > you mention - 10.5.2.1 - make no mention of processes. > > > > Do you agree? (I'm looking at ptc/99-10-07.pdf.) > > Looks like this has been fixed, yes. Certainly, the requirement to > only > invoke the callbacks in the collocated case is no longer there, and > there > is no mention of "process" anymore. (Both changes are for the > better, IMO :-) > Do you mean only invoke callbacks in the non-collocated case? The original spec says: "The receiver callbacks are invoked when the ORB receives a transactional request from a different process." Anyway, I agree that it is best to avoid talk of processes, but I'm confused about the requirement to only invoke the callbacks in the collocated case .... Blake > > I don't think that messaging is part of CORBA 2.3. Jishnu, can we > just > vote to adopt the text the messaging people came up with for this > RTF? > Seeing that messaging has been voted on already, can we do this"? > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Date: Wed, 9 Feb 2000 19:10:50 -0800 From: Blake Biesecker To: Jishnu Mukerji Cc: Michi Henning , ots-rtf@omg.org Subject: Re: Issue 2933 Message-ID: <20000209191050.A2922@gemstone.com> References: <38A18DCA.79A2E7B6@fpk.hp.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <38A18DCA.79A2E7B6@fpk.hp.com>; from jis@fpk.hp.com on Wed, Feb 09, 2000 at 10:54:50AM -0500 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: JH/e9gD-!!ke0e9b1N!! On Wed, Feb 09, 2000 at 10:54:50AM -0500, Jishnu Mukerji wrote: > Michi Henning wrote: > > > > On Tue, 8 Feb 2000, Blake Biesecker wrote: > > > > > Michi, > > > > > > It looks like the text you are concerned about has been > > > removed by the Messaging spec. If the current Messaging > > > work is part of the CORBA 2.3, I think we can defer > > > this issue to Messaging. The section replacing the text > > > you mention - 10.5.2.1 - make no mention of processes. > > > > > > Do you agree? (I'm looking at ptc/99-10-07.pdf.) > > > > Looks like this has been fixed, yes. Certainly, the requirement to > only > > invoke the callbacks in the collocated case is no longer there, > and there > > is no mention of "process" anymore. (Both changes are for the > better, IMO :-) > > > > I don't think that messaging is part of CORBA 2.3. Jishnu, can we > just > > vote to adopt the text the messaging people came up with for this > RTF? > > Seeing that messaging has been voted on already, can we do this"? > > Yes, that would be the right thing to do to cover the small window > between > when this RTF report gets adopted, and when Messaging gets published > as part > of a mainline version. This works as long as the proposed resolution > does not > depend on any Core features that are not in Core 2.3, but is in Core > 2.3 + Messaging. > > Jishnu. > I'd like to just remove the sections "Behavior of the Callbacks", "Requirements on the ORB" and "Requirements on the Transaction Service" and then just add 10.5.2.1 as proposed in Messaging to the 2.3 level of the OTS. The only problem is that there is at least one reference to 3.x sources (at least I think there is, I haven't been keeping track of what was introduced for which version until recently). 10.5.2.1 has one reference to the exception TRANSACTION_UNAVAILABLE. I can't find a reference to this exception in the 2.3 specs. Can someone confirm when TRANSACTION_UNAVAILABLE was introduced? Also, when was NO_REPLY introduced? If these were introduced for 3.x, then we'll either need to make 10.5.2.1 2.3 friendly or we'll need to edit sections "Requirements on the ORB" and "Requirements on the Transaction Service" in the 2.3 level. comments? Blake