Issue 738: DSI servants should support an _is_a method which receives an ObjectId (port-rtf) Source: (, ) Nature: Enhancement Severity: Significant Summary: Summary: "DSI servants should support an _is_a method which receives a RepositoryId and is invoked by the ORB to support remote _is_a_requests. _is_a should be included in the list of operations that a DSI servant should support" Resolution: Revised Text: Actions taken: October 3, 1997: received issue July 30, 1998: closed issue Discussion: Revision: Section 9.3.1 "The Servant IDL type", page 9-14. Add End of Annotations:===== Return-Path: Date: Fri, 3 Oct 1997 21:00:14 -0600 From: Juan Hierro To: issues@omg.org Subject: Issues in the ORB, POA and DynAny specification Cc: juergen@omg.org, jhierro@ovdm36.cnd.hp.com Content-Md5: E67eiV73ezHPKuny2yIsxw== Hi all, Please add the following issues associated to the ORB, POA and the DynAny chapters of the CORBA spec. Best regards, Juanjo Title: DSI servants should support an _is_a method which receives an ObjectId and is invoked by the ORB to support remote _is_a requests Description: A CORBA server may receive an _is_a request for a given CORBA object. Is that request passed to the actual servant associated to the CORBA object ? What happens if the servant is member of the DynamicImplementation class ? In order to resolve an _is_a request in a dynamic servant, the ORB implementation may invoke _primary_interface and then use the CORBA Interface Repository to determine what value should be returned in response to the _is_a request. However, that would break a fundamental design principle of DSI, stated in page 5-3, section 5.3.1 of current CORBA specs: "Finally, note that these APIs have been specified to support a performance model whereby the ORB doesn't implictly consult an interface repository ... in order to handle an invocation." Therefore, we conclude that _is_a should be also included in the list of operations that a DSI servant should support. The operation should receive an ObjectId as parameter, since the servant may be incarnating different CORBA objects with different interfaces. Return-Path: Date: Fri, 30 Jan 1998 11:31:47 -0700 From: Juan Hierro To: juergen@omg.org Subject: Defect on issue 738 Cc: jhierro@ovdm36.cnd.hp.com Content-Md5: B6ch4O+aSlu1t7YaCjIAAg== Hi Juergen, Yesterday I was reviewing issues related to portability and found that one issue Telefonica I+D raised (issue 738) had an 'editorial' defect. I guess that we sent it wrong. The issue description currently says: "DSI servants should support an _is_a method which receives an ObjectId and is invoked by the ORB to support remote _is_a_requests. _is_a should be included in the list of operations that a DSI servant should support" The _is_a method in the DSI servant should receive an interface RepositoryId instead of an ObjectId. Note that the intent here is to be able to serve remote _is_a requests. The input argument in those remote _is_a requests is a RepositoryId, not an ObjectId. The proposed description is: "DSI servants should support an _is_a method which receives a RepositoryId and is invoked by the ORB to support remote _is_a_requests. _is_a should be included in the list of operations that a DSI servant should support" Sorry about sending the issue with the wrong description. Should we resend it to issues again or may you simply fix the current description ? Thanks, Juanjo Return-Path: Sender: jon@floorboard.com Date: Mon, 13 Apr 1998 12:30:16 -0700 From: Jonathan Biggar To: port-rtf@omg.org Subject: Re: Issue 738 proposal Problem: The specification is silent about whether the "standard" CORBA::Object operations [get_interface(), get_implementation(), non_existent(), is_a()] are passed through as invocations to an object implementation that uses the DSI, or whether the ORB handles the operations itself. Proposal: Add a new paragraph to Section 6.3.1 at the end of the section: "The standard CORBA::Object operations are handled as follows: an invocation of get_interface and non_existent are handled by the ORB and will not result in an invocation of the DIR; an invocation of is_a will result in an invocation of the DIR, so that the ORB does not need to consult the Interface Repository; an invocation of get_implementation may or may not result in an invocation of the DIR, this is an implementation specific matter. Discussion: The ORB has sufficient information to provide the proper result for the get_interface and non_existent operations without having to make an upcall to the object implementation. However, for the is_a operation, the ORB would have to consult with the IR in order to determine the proper result. Since a design goal of the DSI requires that the object implementation, not the ORB core access the IR, we need to make it clear that is_a must be passed through to the object implementation. This should not cause undue difficulty for the programmer, because a call to is_a can be implemented easily by calling CORBA::InterfaceDef::is_a(). I have left the option of whether get_implementation is passed through to the object implementation up to the ORB implementation since the implementation repository is undefined, and it is likely that different ORB implementations may have different requirements. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Tue, 14 Apr 1998 01:12:16 -0400 To: Jonathan Biggar From: Steve Vinoski Subject: Re: Issue 738 proposal Cc: port-rtf@omg.org At 12:30 PM 4/13/98 -0700, Jonathan Biggar wrote: >Proposal: > >Add a new paragraph to Section 6.3.1 at the end of the section: > >"The standard CORBA::Object operations are handled as follows: an >invocation of get_interface and non_existent are handled by the ORB and >will not result in an invocation of the DIR; an invocation of is_a will >result in an invocation of the DIR, so that the ORB does not need to >consult the Interface Repository; an invocation of get_implementation >may or may not result in an invocation of the DIR, this is an >implementation specific matter. I disagree on at least two counts: 1) Contrary to what the CORBA spec says elsewhere about non_existent not involving the object implementation (which is another bug that needs to be fixed, Paul R.), I believe that non_existent *must* invoke the DIR for DSI servants. With the use of some features of the POA, default servants for example, there really is no other way to see if the CORBA object still exists or not without asking the servant. This is precisely why the POA spec explicitly mentions in multiple places that servants are allowed to throw OBJECT_NOT_EXIST, and thus I believe their need to be involved in invocations of non_existent follows. 2) get_implementation is already deprecated, so nothing should be said or needs to be said about it. --steve Return-Path: Date: Tue, 14 Apr 1998 10:39:15 -0400 From: Bob Kukura Organization: IONA Technologies To: Steve Vinoski CC: Jonathan Biggar , port-rtf@omg.org Subject: Re: Issue 738 proposal References: <3.0.5.32.19980414011216.00921b50@mail.boston.iona.ie> Steve Vinoski wrote: > > At 12:30 PM 4/13/98 -0700, Jonathan Biggar wrote: > >Proposal: > > > >Add a new paragraph to Section 6.3.1 at the end of the section: > > > >"The standard CORBA::Object operations are handled as follows: an > >invocation of get_interface and non_existent are handled by the ORB > and > >will not result in an invocation of the DIR; an invocation of is_a > will > >result in an invocation of the DIR, so that the ORB does not need > to > >consult the Interface Repository; an invocation of > get_implementation > >may or may not result in an invocation of the DIR, this is an > >implementation specific matter. > > I disagree on at least two counts: > > 1) Contrary to what the CORBA spec says elsewhere about non_existent > not involving the object implementation (which is another bug that > needs to be fixed, Paul R.), I believe that non_existent *must* > invoke the DIR for DSI servants. With the use of some features of > the > POA, default servants for example, there really is no other way to > see if the CORBA object still exists or not without asking the > servant. This is precisely why the POA spec explicitly mentions in > multiple places that servants are allowed to throw OBJECT_NOT_EXIST, > and thus I believe their need to be involved in invocations of > non_existent follows. I see no reason that the exact same reasoning would not apply to static servants as well as DSI servants. Static servants can also serve as default servants, and therefore must be able to determine the non_existence of the object_id in question. In the C++ mapping of the POA, I think it would be make sense to require the ORB vendor to provide a default implementation of _non_existent() on PortableServer::ServantBase that returns FALSE. Then applications that need to determine non_existence themselves could override this implementation in either static or DSI servant implementations. The same approach could also be taken for _is_a() and _get_interface(), with default implementations that query the local interface repository. > > 2) get_implementation is already deprecated, so nothing should be > said or needs to be said about it. > > --steve -Bob Return-Path: Sender: "George M. Scott" Date: Tue, 14 Apr 1998 11:16:31 -0700 From: "George M. Scott" Organization: Borland International, Inc. To: port-rtf@omg.org Subject: Re: Issue 738 proposal References: <353267C8.82743BAC@floorboard.com> Jonathan Biggar wrote: > Add a new paragraph to Section 6.3.1 at the end of the section: > > "The standard CORBA::Object operations are handled as follows: an > invocation of get_interface and non_existent are handled by the ORB and > will not result in an invocation of the DIR; an invocation of is_a will > result in an invocation of the DIR, so that the ORB does not need to > consult the Interface Repository; an invocation of get_implementation > may or may not result in an invocation of the DIR, this is an > implementation specific matter. I disagree that is_a needs to be passed to the object implementation. The Java mapping of the POA already has an abstract method _all_interfaces() defined on the Servant base class which the ORB can use to implement is_a. DSI-based skeletons must provide an implementation of this method. I would prefer that the ORB handle almost all of the operations on CORBA Object itself, without having to invoke the servant. However, I can see some cases such as Steve pointed out where this will be problematic. Perhaps, the best solution is to do as Bob suggested and provide default implementations on the Servant base class and allow users to override them as necessary. This would work well for both static and dynamic skeletons. George Return-Path: Sender: jon@floorboard.com Date: Tue, 14 Apr 1998 11:31:20 -0700 From: Jonathan Biggar To: Steve Vinoski CC: port-rtf@omg.org Subject: Re: Issue 738 proposal References: <3.0.5.32.19980414011216.00921b50@mail.boston.iona.ie> Steve Vinoski wrote: > I disagree on at least two counts: The advantage of posting a proposal is that you get the discussion started. The disadvantage is that everyone else gets to take shots at you. :-) > 1) Contrary to what the CORBA spec says elsewhere about non_existent > not involving the object implementation (which is another bug that > needs to be fixed, Paul R.), I believe that non_existent *must* > invoke the DIR for DSI servants. With the use of some features of > the > POA, default servants for example, there really is no other way to > see if the CORBA object still exists or not without asking the > servant. This is precisely why the POA spec explicitly mentions in > multiple places that servants are allowed to throw OBJECT_NOT_EXIST, > and thus I believe their need to be involved in invocations of > non_existent follows. Your argument makes sense. I worried about this a little, but obviously not enough. I already have implemented objects which do explicitly throw OBJECT_NOT_EXIST, (for example, when some other thread calls their destroy() method, they set a flag that causes other threads to throw OBJECT_NOT_EXIST during the period before the servant is destroyed.) Perhaps it would be better to change my proposal to simply state that ALL of the standard Object operations are passed through to the DIR, even get_interface(). Even though get_interface() could be implemented easily by calling _primary_interface() (for C++), it is probably easier to just avoid all special cases. > 2) get_implementation is already deprecated, so nothing should be > said or needs to be said about it. I saw a message recently from one of the people on the original portability submitters team that stated that get_implementation() wasn't made obsolete by the POA specification because other object adapters might still find it useful. For the life of me, I can't find the message anymore or remember who said it, so whoever you are, you will have to speak up. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jon@floorboard.com Date: Tue, 14 Apr 1998 11:33:36 -0700 From: Jonathan Biggar To: Bob Kukura CC: Steve Vinoski , port-rtf@omg.org Subject: Re: Issue 738 proposal References: <3.0.5.32.19980414011216.00921b50@mail.boston.iona.ie> <35337513.AFB46E4B@iona.com> Bob Kukura wrote: > I see no reason that the exact same reasoning would not apply to > static > servants as well as DSI servants. Static servants can also serve as > default servants, and therefore must be able to determine the > non_existence of the object_id in question. > > In the C++ mapping of the POA, I think it would be make sense to > require > the ORB vendor to provide a default implementation of > _non_existent() on > PortableServer::ServantBase that returns FALSE. Then applications > that > need to determine non_existence themselves could override this > implementation in either static or DSI servant implementations. The > same approach could also be taken for _is_a() and _get_interface(), > with > default implementations that query the local interface repository. This is also a good idea. Since the the ServantBase (or equivalent in other languages) would provide a default implementation, this would be a compatible change that wouldn't obsolete old code. The difficulty is to get this type of change coordinated with all of the language mapping RTFs. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 4 May 1998 20:06:45 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: vinoski@iona.com, kukura@iona.com Subject: Re: Issue 738 proposal Cc: jon@floorboard.com, port-rtf@omg.org X-Sun-Charset: US-ASCII > From kukura@iona.com Tue Apr 14 16:55 WET 1998 > Date: Tue, 14 Apr 1998 10:39:15 -0400 > From: Bob Kukura > Mime-Version: 1.0 > To: Steve Vinoski > Cc: Jonathan Biggar , port-rtf@omg.org > Subject: Re: Issue 738 proposal > Content-Transfer-Encoding: 7bit > > Steve Vinoski wrote: > > > > At 12:30 PM 4/13/98 -0700, Jonathan Biggar wrote: > > >Proposal: > > > > > >Add a new paragraph to Section 6.3.1 at the end of the section: > > > > > >"The standard CORBA::Object operations are handled as follows: > an > > >invocation of get_interface and non_existent are handled by the > ORB and > > >will not result in an invocation of the DIR; an invocation of > is_a will > > >result in an invocation of the DIR, so that the ORB does not need > to > > >consult the Interface Repository; an invocation of > get_implementation > > >may or may not result in an invocation of the DIR, this is an > > >implementation specific matter. > > > > I disagree on at least two counts: > > > > 1) Contrary to what the CORBA spec says elsewhere about > non_existent > > not involving the object implementation (which is another bug that > > needs to be fixed, Paul R.), I believe that non_existent *must* > > invoke the DIR for DSI servants. With the use of some features of > the > > POA, default servants for example, there really is no other way to > > see if the CORBA object still exists or not without asking the > > servant. This is precisely why the POA spec explicitly mentions in > > multiple places that servants are allowed to throw > OBJECT_NOT_EXIST, > > and thus I believe their need to be involved in invocations of > > non_existent follows. > > I see no reason that the exact same reasoning would not apply to > static > servants as well as DSI servants. Static servants can also serve as > default servants, and therefore must be able to determine the > non_existence of the object_id in question. > > In the C++ mapping of the POA, I think it would be make sense to > require > the ORB vendor to provide a default implementation of > _non_existent() on > PortableServer::ServantBase that returns FALSE. Then applications > that > need to determine non_existence themselves could override this > implementation in either static or DSI servant implementations. The > same approach could also be taken for _is_a() and _get_interface(), > with > default implementations that query the local interface repository. > I agree with Bob here. _is_a(), _get_interface(), and _non_existence() are operations that should have corresponding methods defined in ServantBase. There may be default implementations for these methods but it should be possible to override them by the programmer (of course, when using DSI servants but also true for static servants). I disagree in one minor aspect: whether default implementations of these methods query the local interface repository or not, is an ORB implementation issue. Some ORBs may actually do that, but others may implement them in other ways (the IDL compiler may generate the contents of these methods based on knowledge acquired during the compilation, for example). A question which should be resolved though, is that of the parameters passed to these operations. The implementation of _is_a(), for example, must be able to obtain the ObjectId and POA which denote the CORBA object being incarnated in the context of the invocation. This is needed, for example, when you have a DSI servant which incarnates several CORBA objects with different interfaces. In this repect, I see two options: - assume that we may use a reference to the POACurrent in the context of the _is_a(), _get_interface() and _non_existence() methods. - pass the POA and the ObjectId as arguments to the _is_a(), get_interface(), and _non_existence() methods The first approach may seem to be more 'academic' but always require te programmer to get a reference to the POACurrent and, overall, seems to force the ORB to start a thread in order to serve the _is_a(), _get_interface() or _non_existence() operations (as with any other operation defined in IDL). The second option is more aligned with the approach followed when we defined the _primary_interface() method in the DynamicImplementation class. I would propose to adopt this approach. > > > > 2) get_implementation is already deprecated, so nothing should be > > said or needs to be said about it. > > I agree with Steve. Hope it helps, -- Juanjo Return-Path: Date: Mon, 04 May 1998 22:13:21 -0400 From: Bob Kukura Organization: IONA Technologies To: Juan Jose Hierro Sureda CC: vinoski@iona.com, jon@floorboard.com, port-rtf@omg.org Subject: Re: Issue 738 proposal References: <9805041906.AA09457@jam.tid.es> Juan Jose Hierro Sureda wrote: > > > From kukura@iona.com Tue Apr 14 16:55 WET 1998 > > Date: Tue, 14 Apr 1998 10:39:15 -0400 > > From: Bob Kukura > > Mime-Version: 1.0 > > To: Steve Vinoski > > Cc: Jonathan Biggar , port-rtf@omg.org > > Subject: Re: Issue 738 proposal > > Content-Transfer-Encoding: 7bit > > > > Steve Vinoski wrote: > > > > > > At 12:30 PM 4/13/98 -0700, Jonathan Biggar wrote: > > > >Proposal: > > > > > > > >Add a new paragraph to Section 6.3.1 at the end of the section: > > > > > > > >"The standard CORBA::Object operations are handled as follows: > an > > > >invocation of get_interface and non_existent are handled by the > ORB and > > > >will not result in an invocation of the DIR; an invocation of > is_a will > > > >result in an invocation of the DIR, so that the ORB does not > need to > > > >consult the Interface Repository; an invocation of > get_implementation > > > >may or may not result in an invocation of the DIR, this is an > > > >implementation specific matter. > > > > > > I disagree on at least two counts: > > > > > > 1) Contrary to what the CORBA spec says elsewhere about > non_existent > > > not involving the object implementation (which is another bug > that > > > needs to be fixed, Paul R.), I believe that non_existent *must* > > > invoke the DIR for DSI servants. With the use of some features > of the > > > POA, default servants for example, there really is no other way > to > > > see if the CORBA object still exists or not without asking the > > > servant. This is precisely why the POA spec explicitly mentions > in > > > multiple places that servants are allowed to throw > OBJECT_NOT_EXIST, > > > and thus I believe their need to be involved in invocations of > > > non_existent follows. > > > > I see no reason that the exact same reasoning would not apply to > static > > servants as well as DSI servants. Static servants can also serve > as > > default servants, and therefore must be able to determine the > > non_existence of the object_id in question. > > > > In the C++ mapping of the POA, I think it would be make sense to > require > > the ORB vendor to provide a default implementation of > _non_existent() on > > PortableServer::ServantBase that returns FALSE. Then applications > that > > need to determine non_existence themselves could override this > > implementation in either static or DSI servant implementations. > The > > same approach could also be taken for _is_a() and > _get_interface(), with > > default implementations that query the local interface repository. > > > > I agree with Bob here. _is_a(), _get_interface(), and > _non_existence() are > operations that should have corresponding methods defined in > ServantBase. > There may be default implementations for these methods but it should > be > possible to override them by the programmer (of course, when using > DSI > servants but also true for static servants). > > I disagree in one minor aspect: whether default implementations > of these > methods query the local interface repository or not, is an ORB > implementation > issue. Some ORBs may actually do that, but others may implement > them > in other ways (the IDL compiler may generate the contents of these > methods based on knowledge acquired during the compilation, for > example). You are absolutely right. I was thinking of the DSI when I suggested using the IFR, but other solutions may be available, for static skeletons at least. > > A question which should be resolved though, is that of the > parameters > passed to these operations. The implementation of _is_a(), for > example, > must be able to obtain the ObjectId and POA which denote the CORBA > object being incarnated in the context of the invocation. This is > needed, > for example, when you have a DSI servant which incarnates several > CORBA > objects with different interfaces. In this repect, I see two > options: > > - assume that we may use a reference to the POACurrent in the > context > of the _is_a(), _get_interface() and _non_existence() methods. > > - pass the POA and the ObjectId as arguments to the _is_a(), > get_interface(), > and _non_existence() methods > > The first approach may seem to be more 'academic' but always > require > te programmer to get a reference to the POACurrent and, overall, > seems > to force the ORB to start a thread in order to serve the _is_a(), > _get_interface() or _non_existence() operations (as with any other > operation defined in IDL). > > The second option is more aligned with the approach followed when > we > defined the _primary_interface() method in the DynamicImplementation > class. I would propose to adopt this approach. I could live with either approach. I don't see a big disadvantage in using the POA Current. But passing the POA and ObjectId does seem consistent with _primary_interface(), which I never thought needed those parameters either. Are we certain that a portable application should not be able to count on the POA Current reflecting the details of a call to these pseudo-operation implementations? I think I would prefer to treat them as similarly to real operations as possible. One other thing - lets not introduce yet another spelling of "_non_existent". > > > > > > > 2) get_implementation is already deprecated, so nothing should > be > > > said or needs to be said about it. > > > > > I agree with Steve. So do I. > > Hope it helps, > > -- Juanjo -Bob Return-Path: Sender: jon@floorboard.com Date: Mon, 04 May 1998 19:23:15 -0700 From: Jonathan Biggar To: Bob Kukura CC: Juan Jose Hierro Sureda , vinoski@iona.com, port-rtf@omg.org Subject: Re: Issue 738 proposal References: <9805041906.AA09457@jam.tid.es> <354E75C1.CD11459E@iona.com> Bob Kukura wrote: > I could live with either approach. I don't see a big disadvantage > in > using the POA Current. But passing the POA and ObjectId does seem > consistent with _primary_interface(), which I never thought needed > those > parameters either. Are we certain that a portable application > should > not be able to count on the POA Current reflecting the details of a > call > to these pseudo-operation implementations? I think I would prefer > to > treat them as similarly to real operations as possible. > > One other thing - lets not introduce yet another spelling of > "_non_existent". Ok, I agree that these operations should be added to ServantBase, with default implementations. Isn't this really a C++ RTF issue, rather than a core issue, however? On the point of whether to have parameters for POA & ObjectId rather than current, I don't see any particular reason to make these operation signatures any different than a normal one. Just one less exception to remember. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: "Daniel R. Frantz" To: "'Jonathan Biggar'" , Subject: RE: Proposal for Issue 752 -- or is it 738? Date: Mon, 6 Jul 1998 16:08:55 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 I believe this is really in response to Issue 738 instead of 752. Jon did another proposal a few minutes before this on 752 and probably just didn't change gears in time. Is that right Jon? Dan >-----Original Message----- >From: Jonathan Biggar [mailto:jon@floorboard.com] >Sent: Wednesday, July 01, 1998 4:41 PM >To: port-rtf@omg.org >Subject: Proposal for Issue 752 > > >[In a separate message, I will post an issue to the C++ RTF requesting >the addition of virtual functions to handle get_interface(), >is_a(), and >non_existent() in the PortableServer::ServantBase class.] > >In section 9.3.1, add the following after the second bullet item: > > o Values of type Servant provide default implementations of the >standard object reference operations get_interface(), is_a(), and >non_existent(). These operations can be overridden by the >programmer to >provide additional behavior needed by the object implementation. The >default implementations of get_interface() and is_a() operations will >use the most derived interface of a static servant or the most derived >interface retrieved from a dynamic servant to perform the operation. >The default implementation of the non_existent() operation will simply >return false. These operations are invoked by the POA just like any >other operation invocation, so the PortableServer::Current >interface and >any language mapping provided method of accessing the >invocation context >are available. ...