Issue 4624: support for local objects (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: The CORBA spec Section 3.7.6.1 includes the following: - The usage of client side language mappings for local types shall be identical to those of equivalent unconstrained types. - Language mappings shall specify server side mechanisms, including base classes and/or skeletons if necessary, for implementing local objects, so that invocation overhead is minimized. - Invocations on local objects are not ORB mediated. Specifically, parameter copy semantics are not honored, interceptors are not invoked, and the execution context of a local object does not have ORB service Current object contexts that are distinct from those of the caller. The IDL to Java spec section Section 1.12 Mapping for Interface, subsection Local Interfaces states that: - A local interface <typename> is mapped to interface <typename> which extends <typename>Operations, [... which an implementation can extend] - A holder class is generated as for non-local interfaces. - A helper class is also generated according to the normal rules, see Section 1.5, "Helpers", on page 1-13. No mention is made of Stubs, Ties or skeletons. Section 1.20.2.1 Mapping for Local Interface states: In the Java language mapping, the LocalObject class is used as a base class for implementations of a local interface. I take it from the above that, quite reasonably, since "invocations on local objects are not ORB mediated", skeletons/Ties are not required for Java. I can't see why Stubs should be required either, but Section 1.21.6.1 Stub/Skeleton Architecture states: Stubs support both local invocation and remote invocation, except in the following case: The stub is implementing an IDL interface that may only be invoked locally (e.g., PortableServer::POA). In this case, the stub may choose to implement only local invocation. which suggests that Stubs may be required (although the POA interface is constrained to be invoked locally, but not actually defined as local - is that the difference?) Resolution: Incorporate revised text and close issue Revised Text: In section 1.21.6.1 "Stub/skeleton architecture", first paragraph, remove the sentence that reads: Local invocation is also required for certain IDL types, which contain parameter types that cannot be marshalled remotely. In section 1.21.6.1 "Stub/skeleton architecture", add the following as a new second paragraph: Note that neither stubs nor skeletons are required for interfaces that are defined as local. In section 1.21.6.1 "Stub/skeleton architecture", subsection "Stub Design", remove the first bullet that reads The stub is implementing an IDL interface that may only be invoked locally (e.g. PortableServer::POA). In this case, the stub may choose to implement only local invocation. and also the preceding sentence: Stubs support both local invocation and remote invocation, except in the following case: It is clear from a careful reading that there should only have been one bullet here, not three, so change the last two bullets to single paragraphs: The stub class supports either the DII or the streaming style APIs. Stubs are not required to define any constructors. However, if they do define special constructors, a constructor with no arguments must also be supplied. Actions taken: October 22, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Importance: Normal Subject: Question re support for local objects To: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ann Dalton1" Date: Mon, 22 Oct 2001 17:21:51 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.8 |June 18, 2001) at 22/10/2001 17:20:24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: Regd9VT-e9,Cpd9Ofdd9 It's probably stated, or implied, in the spec but I'm having difficulty determining whether or not Stubs and Ties/Skeletons are required for a compliant implementation of local objects. The CORBA spec Section 3.7.6.1 includes the following: - The usage of client side language mappings for local types shall be identical to those of equivalent unconstrained types. - Language mappings shall specify server side mechanisms, including base classes and/or skeletons if necessary, for implementing local objects, so that invocation overhead is minimized. - Invocations on local objects are not ORB mediated. Specifically, parameter copy semantics are not honored, interceptors are not invoked, and the execution context of a local object does not have ORB service Current object contexts that are distinct from those of the caller. The IDL to Java spec section Section 1.12 Mapping for Interface, subsection Local Interfaces states that: - A local interface is mapped to interface which extends Operations, [... which an implementation can extend] - A holder class is generated as for non-local interfaces. - A helper class is also generated according to the normal rules, see Section 1.5, "Helpers", on page 1-13. No mention is made of Stubs, Ties or skeletons. Section 1.20.2.1 Mapping for Local Interface states: In the Java language mapping, the LocalObject class is used as a base class for implementations of a local interface. I take it from the above that, quite reasonably, since "invocations on local objects are not ORB mediated", skeletons/Ties are not required for Java. I can't see why Stubs should be required either, but Section 1.21.6.1 Stub/Skeleton Architecture states: Stubs support both local invocation and remote invocation, except in the following case: The stub is implementing an IDL interface that may only be invoked locally (e.g., PortableServer::POA). In this case, the stub may choose to implement only local invocation. which suggests that Stubs may be required (although the POA interface is constrained to be invoked locally, but not actually defined as local - is that the difference?) Any help with/thoughts about this would be much appreciated. Thanks, Ann A E Dalton Java Technology Centre MP 146, IBM UK Labs, Hursley Park, Winchester, Hants. SO21 2JN Tel: UK-1962-816791 Fax: UK-1962-815388 ann_dalton@uk.ibm.com Date: Mon, 22 Oct 2001 11:47:18 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Question re support for local objects To: java-rtf@omg.org, ann_dalton@uk.ibm.com MIME-Version: 1.0 Content-MD5: m+o8yoFRng0u58a1qc4oYQ== 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: A;F!!J/gd9Z9md9!\1!! >X-Authentication-Warning: engmail1.Eng.Sun.COM: noaccess owned process doing -bs >X-Authentication-Warning: engmail1.Eng.Sun.COM: noaccess@localhost didn't use HELO protocol >Importance: Normal >Subject: Question re support for local objects >To: java-rtf@omg.org >From: "Ann Dalton1" >X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.8 |June 18, 2001) at 22/10/2001 17:20:24 >MIME-Version: 1.0 > >It's probably stated, or implied, in the spec but I'm having difficulty >determining >whether or not Stubs and Ties/Skeletons are required for a compliant >implementation >of local objects. I beleive that there is no reason to create stubs or skeletons for local interfaces in Java. > >The IDL to Java spec section Section 1.12 Mapping for Interface, >subsection Local Interfaces states that: >- A local interface is mapped to interface >which >extends Operations, [... which an implementation can >extend] >- A holder class is generated as for non-local interfaces. >- A helper class is also generated according to the normal rules, see >Section 1.5, >"Helpers", on page 1-13. >No mention is made of Stubs, Ties or skeletons. > >Section 1.20.2.1 Mapping for Local Interface states: >In the Java language mapping, the LocalObject class is used as a base >class >for >implementations of a local interface. > Note that this implies that, while a local interface is an org.omg.CORBA.Object, it is not an org.omg.CORBA.portable.ObjectImpl, and therefore does not have a Delegate. This means that no stub is possible for a local interface. >I take it from the above that, quite reasonably, since "invocations on >local objects are >not ORB mediated", skeletons/Ties are not required for Java. > That's the way the Sun ORB local interface support works: no skeletons, ties, or stubs. >I can't see why Stubs should be required either, but >Section 1.21.6.1 Stub/Skeleton Architecture states: >Stubs support both local invocation and remote invocation, except in >the >following >case: The stub is implementing an IDL interface that may only be >invoked >locally (e.g., >PortableServer::POA). In this case, the stub may choose to implement >only >local >invocation. >which suggests that Stubs may be required (although the POA interface >is >constrained >to be invoked locally, but not actually defined as local - is that >the >difference?) > There is/has been a plan at some point (CORBA 3.0 perhaps?) to rewrite the POA interface to make all of the relevant interfaces local interfaces, but I am not sure what is happening with that plan. Concerns have been expressed about backwards compatibility in this case. However, at present the POA is a special case. First, for most of the interfaces, no stub or skeleton is required, since the ORB is free to implement the POA interfaces in any way desired. However, the user of the POA must be able to implement instances of ServantActivator and ServantLocator. Since the only portable way to create a CORBA Object is to use the POA (and all of the POA was written before local interfaces existed), ServantLocator and ServantActivator both require implementation using a POA. This means that these two interfaces do need stubs and skeletons. The normal portable pattern for implementing these is to create a servant simply by extending ServantPOA as usual. Then an instance of Servant is obtained by using implicit activation (that is, impl._this_object()). _this_object is implemented by an Orb's implementation of the PortableServer.Servant Delegate. Since the call to _this_object is normally not in an invocation context, the result of a call to _default_POA is used, which by default returns the root POA (it can be overriden in the Servant impl class if desired). This is one reason why the root POA must support implicit activation by default: it allows the user of the POA to bootstrap the necessary ServantManager objects. So, the net result is that a Stub is created of the appropriate type, and most ORBs should use the local optimization so that the ServantManager call is not too expensive. So, the only "local" stubs and skeletons that are required are for ServantActivator and ServantLocator. Note that they are required in this case even though the ServantManager and its subclasses are supposed to be locality constrained. Ken. Importance: Normal Subject: Re: Question re support for local objects To: Ken Cavanaugh Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ann Dalton1" Date: Tue, 23 Oct 2001 00:40:05 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.8 |June 18, 2001) at 23/10/2001 09:30:29 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: [NFe9g_ on 22/10/2001 19:47:18 Please respond to Ken Cavanaugh To: java-rtf@omg.org, Ann Dalton1/UK/IBM@IBMGB cc: Subject: Re: Question re support for local objects >X-Authentication-Warning: engmail1.Eng.Sun.COM: noaccess owned process doing -bs >X-Authentication-Warning: engmail1.Eng.Sun.COM: noaccess@localhost didn't use HELO protocol >Importance: Normal >Subject: Question re support for local objects >To: java-rtf@omg.org >From: "Ann Dalton1" >X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.8 |June 18, 2001) at 22/10/2001 17:20:24 >MIME-Version: 1.0 > >It's probably stated, or implied, in the spec but I'm having difficulty >determining >whether or not Stubs and Ties/Skeletons are required for a compliant >implementation >of local objects. I beleive that there is no reason to create stubs or skeletons for local interfaces in Java. > >The IDL to Java spec section Section 1.12 Mapping for Interface, >subsection Local Interfaces states that: >- A local interface is mapped to interface >which >extends Operations, [... which an implementation can >extend] >- A holder class is generated as for non-local interfaces. >- A helper class is also generated according to the normal rules, see >Section 1.5, >"Helpers", on page 1-13. >No mention is made of Stubs, Ties or skeletons. > >Section 1.20.2.1 Mapping for Local Interface states: >In the Java language mapping, the LocalObject class is used as a base class >for >implementations of a local interface. > Note that this implies that, while a local interface is an org.omg.CORBA.Object, it is not an org.omg.CORBA.portable.ObjectImpl, and therefore does not have a Delegate. This means that no stub is possible for a local interface. >I take it from the above that, quite reasonably, since "invocations on >local objects are >not ORB mediated", skeletons/Ties are not required for Java. > That's the way the Sun ORB local interface support works: no skeletons, ties, or stubs. >I can't see why Stubs should be required either, but >Section 1.21.6.1 Stub/Skeleton Architecture states: >Stubs support both local invocation and remote invocation, except in >the >following >case: The stub is implementing an IDL interface that may only be >invoked >locally (e.g., >PortableServer::POA). In this case, the stub may choose to implement >only >local >invocation. >which suggests that Stubs may be required (although the POA interface >is >constrained >to be invoked locally, but not actually defined as local - is that >the >difference?) > There is/has been a plan at some point (CORBA 3.0 perhaps?) to rewrite the POA interface to make all of the relevant interfaces local interfaces, but I am not sure what is happening with that plan. Concerns have been expressed about backwards compatibility in this case. However, at present the POA is a special case. First, for most of the interfaces, no stub or skeleton is required, since the ORB is free to implement the POA interfaces in any way desired. However, the user of the POA must be able to implement instances of ServantActivator and ServantLocator. Since the only portable way to create a CORBA Object is to use the POA (and all of the POA was written before local interfaces existed), ServantLocator and ServantActivator both require implementation using a POA. This means that these two interfaces do need stubs and skeletons. The normal portable pattern for implementing these is to create a servant simply by extending ServantPOA as usual. Then an instance of Servant is obtained by using implicit activation (that is, impl._this_object()). _this_object is implemented by an Orb's implementation of the PortableServer.Servant Delegate. Since the call to _this_object is normally not in an invocation context, the result of a call to _default_POA is used, which by default returns the root POA (it can be overriden in the Servant impl class if desired). This is one reason why the root POA must support implicit activation by default: it allows the user of the POA to bootstrap the necessary ServantManager objects. So, the net result is that a Stub is created of the appropriate type, and most ORBs should use the local optimization so that the ServantManager call is not too expensive. So, the only "local" stubs and skeletons that are required are for ServantActivator and ServantLocator. Note that they are required in this case even though the ServantManager and its subclasses are supposed to be locality constrained. Ken. Date: Tue, 23 Oct 2001 10:53:55 -0700 From: Vijaykumar Natarajan Subject: Re: Question re support for local objects To: Ann Dalton1 Cc: Ken Cavanaugh , java-rtf@omg.org Message-id: <3BD5AEB2.5FCB2798@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: Content-Type: multipart/mixed; boundary="Boundary_(ID_6HZjwWBEsoigznpQkdqkiw)" X-UIDL: \,'e9oAod9Q+7!![#Ld9 Ann, You are right, the text in the IDL-Java mapping must be updated to reflect the resolution for 4264. As of now, there is no need to treat ServantActivators, ServantLocators or POAs any differently. Vijay Ann Dalton1 wrote: > Ken, > Many thanks for your help; that's made things a lot clearer. > > Following your comment about POA changes in the pipeline, I've now > found > Core RTF issue 4264. If I've understood you correctly, since this > issue > has now closed, with both ServantActivator and ServantLocator being > defined as local, there is no longer a need to treat the POA as a > special case? So, do you think the IDL to Java spec should be > changed? > > Perhaps the first bullet in subsection Stub Design of section > 1.21.6.1 Stub/Skeleton Architecture, following the sentence "Stubs > support > both local invocation and remote invocation, except in the following > case:" > should be removed i.e remove > "- The stub is implementing an IDL interface that may only be > invoked > locally (e.g.PortableServer::POA). In this case, the stub may choose > to > implement only local invocation." > > And possibly the sentence in the first paragraph of section 1.21.6.1 > that reads "Local invocation is also required for certain IDL types, > which > contain parameter types that cannot be marshaled remotely." should > also be > removed, since such interfaces should now be defined as local (or is > this > not true in all cases?). > > I would have found it helpful but, with this slight confusion > removed, > perhaps not absolutely necessary, for the spec to have stated > explicitly, > earlier in the same section, that > "Neither stubs nor skeletons are required for interfaces that are > defined > as local". > > Ann > A E Dalton > Java Technology Centre > MP 146, IBM UK Labs, Hursley Park, Winchester, Hants. SO21 2JN > Tel: UK-1962-816791 Fax: UK-1962-815388 > ann_dalton@uk.ibm.com > > Ken Cavanaugh on 22/10/2001 19:47:18 > > Please respond to Ken Cavanaugh > > To: java-rtf@omg.org, Ann Dalton1/UK/IBM@IBMGB > cc: > Subject: Re: Question re support for local objects > > >X-Authentication-Warning: engmail1.Eng.Sun.COM: noaccess owned > process > doing -bs > >X-Authentication-Warning: engmail1.Eng.Sun.COM: noaccess@localhost > didn't > use HELO protocol > >Importance: Normal > >Subject: Question re support for local objects > >To: java-rtf@omg.org > >From: "Ann Dalton1" > >X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.8 > |June > 18, 2001) at > 22/10/2001 17:20:24 > >MIME-Version: 1.0 > > > >It's probably stated, or implied, in the spec but I'm having > difficulty > >determining > >whether or not Stubs and Ties/Skeletons are required for a > compliant > >implementation > >of local objects. > > I beleive that there is no reason to create stubs or skeletons for > local > interfaces in Java. > > > > >The IDL to Java spec section Section 1.12 Mapping for Interface, > >subsection Local Interfaces states that: > >- A local interface is mapped to interface > which > >extends Operations, [... which an implementation can > extend] > >- A holder class is generated as for non-local interfaces. > >- A helper class is also generated according to the normal rules, > see > >Section 1.5, > >"Helpers", on page 1-13. > >No mention is made of Stubs, Ties or skeletons. > > > >Section 1.20.2.1 Mapping for Local Interface states: > >In the Java language mapping, the LocalObject class is used as a > base > class > >for > >implementations of a local interface. > > > > Note that this implies that, while a local interface is an > org.omg.CORBA.Object, > it is not an org.omg.CORBA.portable.ObjectImpl, and therefore does > not have > a Delegate. This means that no stub is possible for a local > interface. > > >I take it from the above that, quite reasonably, since "invocations > on > >local objects are > >not ORB mediated", skeletons/Ties are not required for Java. > > > > That's the way the Sun ORB local interface support works: no > skeletons, > ties, or stubs. > > >I can't see why Stubs should be required either, but > >Section 1.21.6.1 Stub/Skeleton Architecture states: > >Stubs support both local invocation and remote invocation, except > in the > >following > >case: The stub is implementing an IDL interface that may only be > invoked > >locally (e.g., > >PortableServer::POA). In this case, the stub may choose to > implement only > >local > >invocation. > >which suggests that Stubs may be required (although the POA > interface is > >constrained > >to be invoked locally, but not actually defined as local - is that > the > >difference?) > > > > There is/has been a plan at some point (CORBA 3.0 perhaps?) to > rewrite the > POA interface to make all of the relevant interfaces local > interfaces, but > I am not sure what is happening with that plan. Concerns have been > expressed > about backwards compatibility in this case. > > However, at present the POA is a special case. First, for most of > the > interfaces, > no stub or skeleton is required, since the ORB is free to implement > the POA > interfaces > in any way desired. However, the user of the POA must be able > to implement instances of ServantActivator and ServantLocator. > Since the > only > portable way to create a CORBA Object is to use the POA (and all of > the POA > was written before local interfaces existed), ServantLocator and > ServantActivator > both require implementation using a POA. This means that these two > interfaces > do need stubs and skeletons. The normal portable pattern for > implementing > these > is to create a servant simply by extending ServantPOA as > usual. Then > an > instance of Servant is obtained by using implicit activation > (that is, > impl._this_object()). _this_object is implemented by an Orb's > implementation of > the PortableServer.Servant Delegate. Since the call to _this_object > is > normally > not in an invocation context, the result of a call to _default_POA > is used, > which by default returns the root POA (it can be overriden in the > Servant > impl class if desired). This is one reason why the root POA must > support > implicit > activation by default: it allows the user of the POA to bootstrap > the > necessary > ServantManager objects. So, the net result is that a Stub is > created of > the > appropriate type, and most ORBs should use the local optimization so > that > the > ServantManager call is not too expensive. > > So, the only "local" stubs and skeletons that are required are for > ServantActivator and > ServantLocator. Note that they are required in this case even > though the > ServantManager and its subclasses are supposed to be locality > constrained. > > 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. [] vnatarajan.vcf Date: Tue, 23 Oct 2001 14:06:47 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard SSO Staff, Florham Park NJ, USA X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan Cc: Ann Dalton1 , Ken Cavanaugh , java-rtf@omg.org Subject: Re: Question re support for local objects References: <3BD5AEB2.5FCB2798@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?bj!!g&'!!M9H!!L&=!! Vijaykumar Natarajan wrote: > > Ann, > > You are right, the text in the IDL-Java mapping must be updated to reflect the > resolution for 4264. As of now, there is no need to treat ServantActivators, > ServantLocators or POAs any differently. > > Vijay Could someone please register an issue for this one say that we can address this before the end of this RTF cycle, extended as planned? Thanks, Jishnu. Importance: Normal Subject: Re: Issue 4624 support for local objects To: java-rtf@omg.org Cc: Ken.Cavanaugh@Sun.COM, Vijaykumar Natarajan , jishnu_mukerji@hp.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ann Dalton1" Date: Thu, 25 Oct 2001 03:25:53 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 03:24:30 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: @aed9V'&!!l6id9aGgd9 Ok, here is a proposed resolution for issue 4624: The following revisions to the IDL to Java specification are required following closure of Core RTF issue 4264, which defines various POA interfaces as local. In section 1.21.6.1 Stub/Skeleton Architecture, first paragraph, remove the sentence that reads "Local invocation is also required for certain IDL types, which contain parameter types that cannot be marshaled remotely." In section 1.21.6.1 Stub/Skeleton Architecture, insert the following as a new third paragraph, "Note that neither stubs nor skeletons are required for interfaces that are defined as local". In section 1.21.6.1 Stub/Skeleton Architecture, subsection "Stub Design", remove the first bullet that reads "- The stub is implementing an IDL interface that may only be invoked locally (e.g.PortableServer::POA). In this case, the stub may choose to implement only local invocation." Ann