Issue 2223: Local operations on CORBA::Object (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Basically, people get confused about which operations on CORBA::Object can go remote. It"s clear from the GIOP spec that only non_existent(), is_a(), get_interface(), and get_domain_managers() can go on the wire. It follows that things like nil(), hash(), and is_equivalent() must be local. However, as Owen Rees pointed out, this only applies to GIOP, not the core, but a compliant ORB need not provide GIOP. It seems that it would be a good idea to add some clarification to the core to state which operations on CORBA::Object must be local and which ones may (but need not) go remote. Resolution: Incorporate changes in 2.4 and close issue Revised Text: Provide clarifying text in Chapter 4 for each of the Object operations stating which ones may go remote and which are local only. Revised Text: Change text in Chapter 4 as follows: 1. In section 4.3.1 append the sentence: "The implementation of this operation may involve contacting the ORB that implements the target object." to the last paragraph of the section. 2. In section 4.3.9, append the sentence: "The implementation of this operation may involve contacting the ORB that implements the target object." to the first paragraph of the section. 3. In section 4.3.7, append the sentence: "The implementation of this operation may involve remote invocation of an operation (e.g. DomainManager::get_domain_policy for some security policies) for some policy types." to the first paragraph of the section. 4. Add the following paragraph at the end of section 4.3 (immediately preceding section 4.3.1: "Unless otherwise stated, the operations in the IDL above do not require access to remote information." Actions taken: November 19, 1998: received issue September 16, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Thu, 19 Nov 1998 10:48:11 +1000 (EST) From: Michi Henning To: issues@omg.org, orb_revision@omg.org Subject: Local operations on CORBA::Object Organization: Triodia Technologies Hi, this question comes up time and time again in comp.object.corba, which indicates the spec could do with some clarification. Basically, people get confused about which operations on CORBA::Object can go remote. It's clear from the GIOP spec that only non_existent(), is_a(), get_interface(), and get_domain_managers() can go on the wire. It follows that things like nil(), hash(), and is_equivalent() must be local. However, as Owen Rees pointed out, this only applies to GIOP, not the core, but a compliant ORB need not provide GIOP. It seems that it would be a good idea to add some clarification to the core to state which operations on CORBA::Object must be local and which ones may (but need not) go remote. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Fri, 19 Feb 1999 16:27:55 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: Jishnu Mukerji CC: Jeff Mischkinsky , Tom Rutt , Jonathan Biggar , Ken Fleming , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 3 References: <36C48D53.80DE0F33@fpk.hp.com> IONA's votes are as follows: YES on: 569, 665a, 667, 668, 743, 1150, 1653, 1893, 1970, 2200, 2202, 2321, 2327, 2372, 2377, 2378, 2435, 2444 YES with existing ammendment: 2230 NO on 993: Even in the case of colocated client and server, I don't think the language mapping RTFs have any business dealing with the semantics of ForwardRequest. This must be transparent to the application. Steve Vinoski says he'll send this right back to us. NO on 2223: I think the paranthisized part of bullet 4 is completely misleading, since GIOP 1.2 added a "_get_domain_managers" remote pseudo-op. I think the client should invoke this pseudo-op to get the DomainManager rather than invoke operations on a DomainManager. NO on 2340: Similar concents to those raised on email list recently. ABSTAIN on 2432: I haven't had a chance to see what IONA's products do here. -Bob Jishnu Mukerji wrote: > > Core RTF Vote 3 is posted at the URL: > > http://www.omg.org/pub/orbrev/votes/2_4vote3.html > > The most current list of open Core RTF issues including their > current > status can be seen at the URL: > > http://www.omg.org/pub/orbrev/drafts/orb_revision_2_4.html > > Core RTF 2.4 voters, the vote is due on Friday the 19th of Feb by > 17:00 > EST (GMT-5). > > Regards, > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 19 Feb 1999 16:27:55 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: Jishnu Mukerji CC: Jeff Mischkinsky , Tom Rutt , Jonathan Biggar , Ken Fleming , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 3 References: <36C48D53.80DE0F33@fpk.hp.com> IONA's votes are as follows: YES on: 569, 665a, 667, 668, 743, 1150, 1653, 1893, 1970, 2200, 2202, 2321, 2327, 2372, 2377, 2378, 2435, 2444 YES with existing ammendment: 2230 NO on 993: Even in the case of colocated client and server, I don't think the language mapping RTFs have any business dealing with the semantics of ForwardRequest. This must be transparent to the application. Steve Vinoski says he'll send this right back to us. NO on 2223: I think the paranthisized part of bullet 4 is completely misleading, since GIOP 1.2 added a "_get_domain_managers" remote pseudo-op. I think the client should invoke this pseudo-op to get the DomainManager rather than invoke operations on a DomainManager. NO on 2340: Similar concents to those raised on email list recently. ABSTAIN on 2432: I haven't had a chance to see what IONA's products do here. -Bob Jishnu Mukerji wrote: > > Core RTF Vote 3 is posted at the URL: > > http://www.omg.org/pub/orbrev/votes/2_4vote3.html > > The most current list of open Core RTF issues including their > current > status can be seen at the URL: > > http://www.omg.org/pub/orbrev/drafts/orb_revision_2_4.html > > Core RTF 2.4 voters, the vote is due on Friday the 19th of Feb by > 17:00 > EST (GMT-5). > > Regards, > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Fri, 19 Feb 1999 17:39:47 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Bob Kukura CC: Jeff Mischkinsky , Tom Rutt , Jonathan Biggar , Ken Fleming , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 3 References: <36C48D53.80DE0F33@fpk.hp.com> <36CDD75B.CA4F075B@iona.com> > NO on 2223: I think the paranthisized part of bullet 4 is completely > misleading, since GIOP 1.2 added a "_get_domain_managers" remote > pseudo-op. I think the client should invoke this pseudo-op to get > the > DomainManager rather than invoke operations on a DomainManager. I would just point out that the only way that Object::get_policy can be implemented for certain security policies that are held in the domain manager is to first use get_domain_manager to get the domain manager and then invoke the domain manager's get_domain_policy. You have to do it at least once. Then you can cache that value locally. So I am afraid you might have missed the point of that stuff in the parentheses entirely. However, the fact that you completely missed the point suggests that the parenthesized part did not serve its purpose, so I would be happy to entertain proposals for better wording capturing the gist of what I was attempting to say, as described above. Now whether this is broken or not is a separate discussion, but right now as things stand, that is the way it is. > NO on 993: Even in the case of colocated client and server, I don't > think the language mapping RTFs have any business dealing with the > semantics of ForwardRequest. This must be transparent to the > application. Steve Vinoski says he'll send this right back to us. My interpretation of what the resolution proposes is, if the language binding folks don't want to do anything with it then it is as good as closed 'cause the core folks by adopting this resolution are expressing that they don't want to do anything about it either.:-) However, we could keep bouncing it back and forth for entertainment purposes.:-) Personally I'd have been happier if the proposed resolution was to close this with no change, but then that is just one opinion, and I can live with fun and games for a while instead.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA.