Issue 1422: Does the DII support the standard object operations? (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: There are two types of standard operations: ones that are transmitted over the wire, and ones that are not. Now it seems reasonable to support the over-the-wire operations via the DII, such as "is_a", "non_existent", "get_interface" and "get_implementation" (obsolete), but what about the ones that don"t go over the wire: hash is_equivalent get_policy get_domain_managers I would guess that the DII should not support these operations, but the spec does not explicitly say that. So, should we add a statement to the DII part of the spec that an attempt to invoke these non-over-the-wire operations should raise BAD_OPERATION? Resolution: Revised Text: Actions taken: June 2, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Mon, 01 Jun 1998 19:17:33 -0700 From: Jonathan Biggar To: issues@omg.org, orb_revision@omg.org Subject: What standard object operations are supported by DII? Here is a question I haven't seen an answer to: Does the DII support the standard object operations? There are two types of standard operations: ones that are transmitted over the wire, and ones that are not. Now it seems reasonable to support the over-the-wire operations via the DII, such as "is_a", "non_existent", "get_interface" and "get_implementation" (obsolete), but what about the ones that don't go over the wire: hash is_equivalent get_policy get_domain_managers I would guess that the DII should not support these operations, but the spec does not explicitly say that. So, should we add a statement to the DII part of the spec that an attempt to invoke these non-over-the-wire operations should raise BAD_OPERATION? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Wed, 03 Jun 1998 11:18:31 -0400 From: Bob Kukura Organization: IONA Technologies To: Jonathan Biggar CC: issues@omg.org, orb_revision@omg.org Subject: Re: What standard object operations are supported by DII? References: <357360BD.FF7948CC@floorboard.com> I don't see any point in using the DII to invoke any of the Object pseudo-operations that can be invoked using the functions provided by the mapping of CORBA::Object. These include all the ones mentioned in both messages below. I recommend clarifying that none of these pseudo-operations are available via the DII, and passing their names to the DII should result in BAD_OPERATION unless the IDL definition of the target object's interface really has operations with these names (without a prepended underscores, of course). I would not recommend requiring an ORB to raise BAD_OPERATION if any of the legal GIOP on-the-wire remote pseudo-op names (with the prepended underscore) are passed to the DII, since these might be implemented in some ORBs via the DII. -Bob Jonathan Biggar wrote: > > Here is a question I haven't seen an answer to: > > Does the DII support the standard object operations? > > There are two types of standard operations: ones that are > transmitted > over the wire, and ones that are not. Now it seems reasonable to > support the over-the-wire operations via the DII, such as "is_a", > "non_existent", "get_interface" and "get_implementation" (obsolete), > but > what about the ones that don't go over the wire: > > hash > is_equivalent > get_policy > get_domain_managers > > I would guess that the DII should not support these operations, but > the > spec does not explicitly say that. So, should we add a statement to > the > DII part of the spec that an attempt to invoke these > non-over-the-wire > operations should raise BAD_OPERATION? > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Return-Path: Date: Wed, 3 Jun 1998 08:33:22 -0700 From: jon@floorboard.com (Jon Biggar) To: orb_revision@omg.org Subject: Re: What standard object operations are supported by DII? Bob Kukura wrote: > > I don't see any point in using the DII to invoke any of the Object > pseudo-operations that can be invoked using the functions provided > by > the mapping of CORBA::Object. These include all the ones mentioned > in > both messages below. > > I recommend clarifying that none of these pseudo-operations are > available via the DII, and passing their names to the DII should > result > in BAD_OPERATION unless the IDL definition of the target object's > interface really has operations with these names (without a > prepended > underscores, of course). I would not recommend requiring an ORB to > raise BAD_OPERATION if any of the legal GIOP on-the-wire remote > pseudo-op names (with the prepended underscore) are passed to the > DII, > since these might be implemented in some ORBs via the DII. I'm not trying to pick on you Bob, but doesn't anyone out there think that optionally allowing things like this in an ORB implementation is a bad idea? Any optional functionality can't be used by portable clients anyway, so ORB implementations may as well not bother to implement optional features. Then, all we are left with is confusion and imperfect institutional knowledge that certain "features" need to be avoided. There are still several such "features" in the ORB core right now. One of the more egregious that comes to mind is the statement in the DII chapter that ORBs "may" allow the parameters in NVLists to be in arbitrary order, but don't "have" to. I would never bother to implement this feature in an ORB, and no one in their right mind would write an application that used it either! So, to get back to the point, since the 4 (or 3?) "over-the-wire" operations need to be parsed on the server side, which is a DSI-like process already (and in many implmentation IS the DSI!), I propose the following: The object operations is_a, non_existent, get_interface and get_implementation (obsolete) can be invoked via the DII, but must (of course) have the initial underscore just like the wire protocol. The object operations hash, is_equivalent, get_policy, and get_domain_managers may NOT be called via the DII. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Wed, 3 Jun 1998 17:54:28 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: orb_revision@omg.org, jon@floorboard.co Subject: Re: What standard object operations are supported by DII? X-Sun-Charset: US-ASCII > > So, to get back to the point, since the 4 (or 3?) "over-the-wire" > operations need to be parsed on the server side, which is a DSI-like > process already (and in many implmentation IS the DSI!), I propose > the > following: > > The object operations is_a, non_existent, get_interface and > get_implementation (obsolete) can be invoked via the DII, but must > (of > course) have the initial underscore just like the wire protocol. > > The object operations hash, is_equivalent, get_policy, and > get_domain_managers may NOT be called via the DII. > I agree with Jon here and support his proposal. -- Juanjo Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 4 Jun 1998 05:44:23 +1000 (EST) From: Michi Henning To: Jon Biggar cc: orb_revision@omg.org Subject: Re: What standard object operations are supported by DII? On Wed, 3 Jun 1998, Jon Biggar wrote: > So, to get back to the point, since the 4 (or 3?) "over-the-wire" > operations need to be parsed on the server side, which is a DSI-like > process already (and in many implmentation IS the DSI!), I propose > the > following: > > The object operations is_a, non_existent, get_interface and > get_implementation (obsolete) can be invoked via the DII, but must > (of > course) have the initial underscore just like the wire protocol. > > The object operations hash, is_equivalent, get_policy, and > get_domain_managers may NOT be called via the DII. I agree with this -- it makes sense. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Sat, 06 Jun 1998 11:27:53 -0700 From: Jon Goldberg To: Michi Henning CC: jon@floorboard.com, orb_revision@omg.org Subject: Re: What standard object operations are supported by DII? References: Seems more appropriate for *all* operations on CORBA::Object to not be supported through the DII. There's no real reason for them, since they can be statically invoked even without stubs through CORBA::Object. I would prefer a simple clarification in the spec that no CORBA::Object pseudo-op names can be passed to create_request. BAD_PARAM seems like the appropriate exception to me. take care, Jon Michi Henning wrote: > > On Wed, 3 Jun 1998, Jon Biggar wrote: > > > So, to get back to the point, since the 4 (or 3?) "over-the-wire" > > operations need to be parsed on the server side, which is a > DSI-like > > process already (and in many implmentation IS the DSI!), I propose > the > > following: > > > > The object operations is_a, non_existent, get_interface and > > get_implementation (obsolete) can be invoked via the DII, but must > (of > > course) have the initial underscore just like the wire protocol. > > > > The object operations hash, is_equivalent, get_policy, and > > get_domain_managers may NOT be called via the DII. > > I agree with this -- it makes sense. > ] Return-Path: Sender: jon@floorboard.com Date: Sat, 06 Jun 1998 12:33:44 -0700 From: Jonathan Biggar To: Jon Goldberg CC: Michi Henning , orb_revision@omg.org Subject: Re: What standard object operations are supported by DII? References: <35798A29.F0C20A47@inprise.com> Jon Goldberg wrote: > > Seems more appropriate for *all* operations on CORBA::Object > to not be supported through the DII. There's no real > reason for them, since they can be statically invoked > even without stubs through CORBA::Object. > > I would prefer a simple clarification in the spec that > no CORBA::Object pseudo-op names can be passed to > create_request. BAD_PARAM seems like the appropriate > exception to me. The reasoning for allowing the "over-the-wire" operations via DII are two fold: 1. Since they have to be received from GIOP and parsed in a process that is very similar to DSI, the mechanism to support DII invocation of these operations already exists in a similar form in an ORB implementation. 2. These operations need to pass through to dynamic servants via the DSI already, so again, the mechanism probably already exists in the ORB implementation. Given these two reasons, there isn't really any good reason to disallow them. And by the way, BAD_OPERATION would be a better exception, anyway. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 08 Jun 1998 08:32:11 -0700 From: Jon Goldberg To: Jonathan Biggar CC: michi@dstc.edu.au, orb_revision@omg.org Subject: Re: What standard object operations are supported by DII? References: <35798A29.F0C20A47@inprise.com> Jonathan Biggar wrote: > > Jon Goldberg wrote: > > > > Seems more appropriate for *all* operations on CORBA::Object > > to not be supported through the DII. There's no real > > reason for them, since they can be statically invoked > > even without stubs through CORBA::Object. > > > > I would prefer a simple clarification in the spec that > > no CORBA::Object pseudo-op names can be passed to > > create_request. BAD_PARAM seems like the appropriate > > exception to me. > > The reasoning for allowing the "over-the-wire" operations via DII > are > two fold: > > 1. Since they have to be received from GIOP and parsed in a process > that is very similar to DSI, the mechanism to support DII invocation > of > these operations already exists in a similar form in an ORB > implementation. > > 2. These operations need to pass through to dynamic servants via > the > DSI already, so again, the mechanism probably already exists in the > ORB > implementation. > > Given these two reasons, there isn't really any good reason to > disallow > them. > > And by the way, BAD_OPERATION would be a better exception, anyway. This issue should have nothing to do with being able to receive and handle the invocation. Regardless of whether invoked via DII or synchronously through CORBA::Object, the request looks the same to the dynamic servant or target. The only question is whether I can call create_request (or equivalents) passing in is_a, non_existent, hash, etc. Since there is no reason to need to pass these to a create_request (because the static CORBA::Object stub is always available), I still don't see any motivation for having these be supported. -Jon Return-Path: Sender: jon@floorboard.com Date: Mon, 08 Jun 1998 09:24:41 -0700 From: Jonathan Biggar To: Jon Goldberg CC: michi@dstc.edu.au, orb_revision@omg.org Subject: Re: What standard object operations are supported by DII? References: <35798A29.F0C20A47@inprise.com> <357C03FB.7C1BCFD8@inprise.com> Jon Goldberg wrote: > This issue should have nothing to do with being able to receive > and handle the invocation. Regardless of whether invoked via > DII or synchronously through CORBA::Object, the request looks > the same to the dynamic servant or target. > > The only question is whether I can call create_request (or > equivalents) passing in is_a, non_existent, hash, etc. Since > there is no reason to need to pass these to a create_request > (because the static CORBA::Object stub is always available), > I still don't see any motivation for having these be supported. Actually, I just thought of a better motivation. You can't call them with deferred synchronous semantics without using the DII. So forbidding using the DII for these operations means that applications must always use the blocking interface, which restricts application flexibility. Again, the operations in question are is_a, non_existent, get_interface and get_implementation (obsolete). The hash, is_equivalent, get_policy and get_domain_managers operations would not be allowed via DII. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 08 Jun 1998 20:11:57 -0700 From: Jon Goldberg To: Jonathan Biggar CC: michi@dstc.edu.au, orb_revision@omg.org Subject: Re: What standard object operations are supported by DII? References: <35798A29.F0C20A47@inprise.com> <357C03FB.7C1BCFD8@inprise.com> Jonathan Biggar wrote: > > Jon Goldberg wrote: > > This issue should have nothing to do with being able to receive > > and handle the invocation. Regardless of whether invoked via > > DII or synchronously through CORBA::Object, the request looks > > the same to the dynamic servant or target. > > > > The only question is whether I can call create_request (or > > equivalents) passing in is_a, non_existent, hash, etc. Since > > there is no reason to need to pass these to a create_request > > (because the static CORBA::Object stub is always available), > > I still don't see any motivation for having these be supported. > > Actually, I just thought of a better motivation. You can't call > them > with deferred synchronous semantics without using the DII. So > forbidding using the DII for these operations means that > applications > must always use the blocking interface, which restricts application > flexibility. yeah, I thought of that possibility, too. I don't know if it is a particularly good bit of flexibility to hand out, but have no real problem with it. > > Again, the operations in question are is_a, non_existent, > get_interface > and get_implementation (obsolete). The hash, is_equivalent, > get_policy > and get_domain_managers operations would not be allowed via DII. that's fine with me. Just to reiterate, it is create_request (and its equivalents) that must raise an exception when passed the strings "_hash", "_is_equivalent", "_get_policy" and "_get_domain_managers". Since it is not the invocation itself that raises the exception, I think the appropriate exception could either be BAD_PARAM or BAD_OPERATION. Technically, the parameter being passed to create_request is not valid (BAD_PARAM), but "create_request" is a valid operation (BAD_OPERATION is not really the case). However, I don't really care either way and would be happy with either choice. take care, Jon