Issue 3068: Messaging sendc and sendp missing from portability interfaces (java-rtf) Source: Ericsson (Mr. Chris Smith, nobody) Nature: Uncategorized Issue Severity: Summary: The Messaging Specification was adopted before Java Portability layer was really in place. In order to make portability work with the asynchronous stubs which will in future be generated, some things may be added to the portability interface. Each stub has a sendc_<op> and sendp_<op> operation which will need to call on the portable stub layer. A first glance at the requirements to make a portable implementation suggest that a sendc_invoke and sendp_invoke operation will probably need to be added to ObjectImpl and Delegate. I dont know if this is viewed as a "compatible" class change for JDK, or whether we will need to put derived classes in CORBA_3_0 package.... Resolution: Revised Text: Actions taken: November 23, 1999: received issue April 3, 2001: moved from the Messaging RTF to the Java RTF Discussion: Move to Java RTF? Clearly an IDL Java mapping issue. Send to IDL-Java RTF End of Annotations:===== Sender: Chris.Smith@uab.ericsson.se Message-ID: <383AD826.3C297683@uab.ericsson.se> Date: Tue, 23 Nov 1999 19:08:38 +0100 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: messaging-rtf@omg.org, issues@omg.org, java-rtf@omg.org Subject: Messaging sendc and sendp missing from portability interfaces Content-Type: multipart/mixed; boundary="------------76023014B6E86C609048E795" X-UIDL: 8V^d9IL4e9h~;e9+)X!! The Messaging Specification was adopted before Java Portability layer was really in place. In order to make portability work with the asynchronous stubs which will in future be generated, some things may be added to the portability interface. Each stub has a sendc_ and sendp_ operation which will need to call on the portable stub layer. A first glance at the requirements to make a portable implementation suggest that a sendc_invoke and sendp_invoke operation will probably need to be added to ObjectImpl and Delegate. I dont know if this is viewed as a "compatible" class change for JDK, or whether we will need to put derived classes in CORBA_3_0 package.... [] Chris.Smith1.vcf Date: Tue, 20 Mar 2001 19:21:12 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Cc: java-rtf@omg.org Subject: Issue 3068 over to Java RTF? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -/fd9"b'!!O(Fe9X4X!! Issue 3068: Messaging sendc and sendp missing from portability interfaces (messaging-rtf) Click here for this issue's archive. Source: Ericsson (Mr. Chris Smith, chris.smith@uab.ericsson.se) Nature: Uncategorized Issue Severity: Summary: The Messaging Specification was adopted before Java Portability layer was really in place. In order to make portability work with the asynchronous stubs which will in future be generated, some things may be added to the portability interface. Each stub has a sendc_ and sendp_ operation which will need to call on the portable stub layer. A first glance at the requirements to make a portable implementation suggest that a sendc_invoke and sendp_invoke operation will probably need to be added to ObjectImpl and Delegate. I dont know if this is viewed as a "compatible" class change for JDK, or whether we will need to put derived classes in CORBA_3_0 package.... Resolution: Clearly an IDL Java mapping issue. Send to IDL-Java RTF Revised Text: Actions taken: Over to Java RTF. _________________________________________________________________ Unless there is signficant objection this proposal to move this issue over to the Java RTF will appear in the next Core RTF vote. Thanks, Jishnu. Date: Fri, 7 Dec 2001 17:22:54 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Issue 3068 To: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: b3zQZ4yYyZ/YimF+MsPlRw== 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: Z44e9%m)!!0Cp!!:o""! Status: RO Issue 3068 calls for support for sendp_ and sendc_ operations in Java. This is essential to completing the CORBA 3.0 specification for Java, although it's not clear to me whether anyone has implemented messaging in Java. The messaging spec calls for the generation of implied idl for the callback and polling variants of the AMI. However, the implied IDL only defines the signatures and operations. Different code must be generated for the Stubs (although Skeletons are unaffacted by this) for the sendc_/sendp_ methods. There are several issues: 1. The basic pattern is a bit different here, since the Stub never handles the result. Instead, the IDL compiler must generate the code to handle the result in another class, perhaps some kind of AMI helper. The ORB would then need to invoke a method on the AMI helper to unmarshal the result and either place the results in the poller, or invoke the result method on the callback object. This needs to be defined. 2. New methods similar to invoke need to be defined on org.omg.CORBA.portable.Delegate. Something along the lines of public void sendc( org.omg.CORBA.Object.self, OutputStream os, rh, ah ) and something similar for sendp is needed, but the details need a lot of work. 3. The ExceptionHandler needs more definition. This is defined as a valuetype, but what do the methods do? The ORB needs to allocate an appropriate ExceptionHandler when a reply is received that contains an exception. This again calls for some kind of Helper that supports creating the ExceptionHandler. The AMI Helper perhaps could be simply used by the ORB as amiHelper.handleResult( OutputStream, replyHandler ) amiHelper.handleException( OutputStream, java.lang.Exception, replyHandler ) 4. What about co-located calls? Should the standard address an optimization just as in the normal invocation case where servant_preinvoke/servant_postinvoke provide the needed support? As it stands, we will not have a coherent and complete CORBA 3.0 in Java without addressing these issues, but there has been almost no discussion at all on messaging support in Java. I do not have time (nor do I have a messaging implementation) to do all of this. Ken. Date: Wed, 2 Jan 2002 13:32:41 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: sendc/sendp java mapping (Re: issue 3068) To: jishnu_mukerji@hp.com, Chris.Smith@uab.ericsson.se Cc: Ken.Cavanaugh@sun.com, java-rtf@omg.org MIME-Version: 1.0 Content-MD5: hmcBxeCoJl1Mr53OuJsc0Q== 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: G$:!!BoNd9eVk!!6>>e9 >X-Unix-From: Chris.Smith@uab.ericsson.se Wed Jan 2 08:10:26 2002 >From: Chris Smith >X-Accept-Language: sv, en-US >MIME-Version: 1.0 >To: Jishnu Mukerji >CC: Ken Cavanaugh >Subject: Re: sendc/sendp java mapping > > >> > The biggest hole that I see at this point is a lack of responses >to issue >> > 3068, which asks for a portable Java mapping for sendc/sendp in >support >> > of messaging. I took a quick look at this, and a solution >requires a >> > fair bit of work by someone with a messaging implementation. >However, >> > there have been no responses to a couple of emails I sent to the >> > Java RTF for input on this. >> >> Chris, >> >> Would it be possible for you to help Ken resolve this one? > >Sure. To start with, the resolution that we have >now proposed to 2929 will simplify things a lot, since there are no >type specific exception holders. > >So, my belief is that the sendc mode can very easily be done by >adding >the sendc operation that is already specified in the DII chapter to >org.omg.CORBA.Request. I cant see that this has been added in any >IDL-To-Java >RTFs yet. It has not. There are issues with the signature of sendc and the implementation of the stub methods that need to be resolved. > >So, it would work like this. The IDL to java compiler would generate >the "extra" >operations sendc_ on the Stub class. This implies that the >sendc >operations >are NOT part of the "operations" Java interface - they are just >present on the >Stub class. Users of the IDL to Java mapping do not currently need to program to the stub, which is a generated class. All client code is programmed directly against the generated interface, not the stub. For example, the current code generation for IDL interface Foo generates: Java interface FooOperations Java interface Foo (which extends FooOperations) Java class _Foo_Stub (which implements Foo) Currently users of the Foo IDL type just use Java type Foo for all operations. Are you proposing that users of AMI on Foo would need to first narrow a org.omg.CORBA.Object to _FooStub instead of just Foo? This is particularly awkward when invoking operations on a typed object reference that was obtained from another invocation, in which case a narrow would be required for AMI, but not for SII. > The idl to java compiler would also generate the operations, stub >and >Impl Base classes/interfaces for the AMI Call back handler class. The >user >makes an implementation of the Handler which he connects to some POA, >and then >passes to the sendc_ on the Stub class. The generated code >then uses >DII to create a Request object with the appropriate in params (the >out params >and >return are ignored), and then uses sendc on the Request object, >passing the >Handler >as the extra parameter. The underlying ORBs implementation of Request >would then >handle all the rest. Since type specific exception holders have been >removed, >(hopefully) in 2929, then are no needs for registering valuetype >factories. > > This is a good point: the DII request should be extended to include sendc/sendp support. This is a core issue, as well as a language mapping issue. Using DII is one way to handle AMI, but it is typically much less efficient than the portable stream approach that is also supported. In analogy with normal SII calls, there should be 3 mechanisms supported: - DII - Portable Streams - Co-located call optimization (no marshalling of data). Admittedly - this is less efficient in some ways with AMI, since the server side work - would need to be handled by a separate thread, but we should consider - this. The portable stream mechanism would require extending org.omg.CORBA.portable.Delegate with a sendc operation along the lines of: public void sendc( org.omg.CORBA.Object.self, OutputStream os, rh, ah ) where the reply handler is the usual AMI reply handler, and the AMI helper is a new type that is generated by the IDL compiler. This AMI helper would need to unmarshal the results and invoke the reply handler method. For example, it could support operations something like handleResult( OutputStream, replyHandler ) handleException( OutputStream, java.lang.Exception, replyHandler ) The actual implementation of these methods is type specific and generated by the IDL compiler. The type of replyHandler would need to be a common base class for all generated AMI reply handler types (even org.omg.CORBA.Object could work here). >For the sendp stuff, I am much less an expert, since we have only played >around with implementing it. However, I have done a cursory investigation, >and it is my belief that the generated stub code probably also just needs the >sendp and prepare operations from PIDL Request to be added to >org.omg.CORBA.Request. > >However, the sendp bit is a bit more of a mess, since the DII Request operations >for sendp are a bit wooly. Firstly they involve creating a second Request which >is >used to talk to the MessageRouting::PersistentRequest object that you get back >from sendp, and furthermore, the marshalling code then gets back the message >body >rather than nice objects. > >In my view, the mess in sendp on the DII is caused by two factors - firstly the >TII stuff (time independant invocations) which should be sunsetted IMO, and Purely from a Java centric view, this makes a lot of sense. The real interest in Java messaging is in JMS and JAXM, not in the CORBA side. On the other hand, AMI provides useful functionality to the core CORBA model that is missing today. >also by the fact that it is possible to turn a sendp invocation into a sendc >invocation after sending it (although not vice versa). This complication is >not worth the trouble in my opinion - it is not a typical use case that one >sends a request in polling mode, and then "changes ones mind" half way through. > >If one could remove TII and this "change of mode", then the send_deferred that >is already there, could be used by the Stub code to send the sendp request, >and a new variant of get_response (with a timeout) could be used by the >stub code polling for the answer. Again, this addresses the question from the DII side, but I think there needs to be a portable stream answer as well. > >Hope this helps - PLEASE try and get the sendc bit added to the Java >mapping at >least. This is an immensely useful primitive to many of our >customers, and >we have had this implemented for over 2 years now. I think we should do this, but it won't make it in time for CORBA 3.0 on the current schedule. I do not plan to issue another vote in this RTF since the 3 week deadline is January 7, 2002. It may be able to make an interim Java RTF report later, and possibly also JDK 1.5. > >I am willing to try and help out with tidying up the sendp bit, but >there are >probably people at Iona and Borland who have implemented this as well >who >can help as well. > I'd love to here from the other ORB vendors here too: Eoghan? Vijay? Thanks, Ken. Sender: Chris.Smith@uab.ericsson.se Message-ID: <3C34165F.D42FBB0@uab.ericsson.se> Date: Thu, 03 Jan 2002 09:29:19 +0100 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.77C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv, en-US MIME-Version: 1.0 To: Ken Cavanaugh CC: jishnu_mukerji@hp.com, java-rtf@omg.org Subject: Re: sendc/sendp java mapping (Re: issue 3068) References: <200201022132.g02LWgM17016@ha1sca-mail1.SFBay.Sun.COM> Content-Type: multipart/mixed; boundary="------------FD911CC04F3F4D08AC80282C" X-UIDL: >Dfd9X1Be9'5]!!DI5!! > >> Chris, > >> > >> Would it be possible for you to help Ken resolve this one? > > > >Sure. To start with, the resolution that we have > >now proposed to 2929 will simplify things a lot, since there are no > >type specific exception holders. > > > >So, my belief is that the sendc mode can very easily be done by > >>adding > >the sendc operation that is already specified in the DII chapter to > >org.omg.CORBA.Request. I cant see that this has been added in any > >>IDL-To-Java > >RTFs yet. > > It has not. There are issues with the signature of sendc and the > >>implementation > of the stub methods that need to be resolved. > > > > >So, it would work like this. The IDL to java compiler would > >>generate the "extra" > >operations sendc_ on the Stub class. This implies that the > >>sendc > >operations > >are NOT part of the "operations" Java interface - they are just > >>present on the > >Stub class. > > Users of the IDL to Java mapping do not currently need to program to > >>the > stub, which is a generated class. All client code is programmed > >>directly > against the generated interface, not the stub. > > For example, the current code generation for IDL interface Foo > >>generates: > > Java interface FooOperations > Java interface Foo (which extends FooOperations) > Java class _Foo_Stub (which implements Foo) > > Currently users of the Foo IDL type just use Java type Foo for all > >>operations. > Are you proposing that users of AMI on Foo would need to first > >>narrow > a org.omg.CORBA.Object to _FooStub instead of just Foo? This is > >>particularly > awkward when invoking operations on a typed object reference that > >>was > obtained from another invocation, in which case a narrow would be > >>required > for AMI, but not for SII. True - I had forgotten that the Stub class is not seen by the programmers. Well I guess the alternative is to put the sendc_ and sendp_ stuff in the operations interface, and to define sensible "non working" implementations in the POA class. This is probably more "pleasant" (although a bit dirty). > > > The idl to java compiler would also generate the operations, stub > >and > >Impl Base classes/interfaces for the AMI Call back handler class. The user > >makes an implementation of the Handler which he connects to some POA, and then > >passes to the sendc_ on the Stub class. The generated code then uses > >DII to create a Request object with the appropriate in params (the out params > >and > >return are ignored), and then uses sendc on the Request object, passing the > >Handler > >as the extra parameter. The underlying ORBs implementation of Request would then > >handle all the rest. Since type specific exception holders have been removed, > >(hopefully) in 2929, then are no needs for registering valuetype factories. > > > > > > This is a good point: the DII request should be extended to include sendc/sendp > support. This is a core issue, as well as a language mapping issue. This stuff was added to the DII Request PIDL a long time ago in core. > > Using DII is one way to handle AMI, but it is typically much less > efficient than > the portable stream approach that is also supported. In analogy > with normal > SII calls, there should be 3 mechanisms supported: > > - DII > - Portable Streams > - Co-located call optimization (no marshalling of data). Admittedly > this > is less efficient in some ways with AMI, since the server side > work would > need to be handled by a separate thread, but we should consider > this. Sure. I was just concentrating on clarifying on how the DII mode would work. You "language mapping experts" can extrapolate better than me how the portable streams and colocation should look given how the DII method should look. > > The portable stream mechanism would require extending > org.omg.CORBA.portable.Delegate > with a sendc operation along the lines of: > > public void sendc( org.omg.CORBA.Object.self, OutputStream os, > rh, ah ) > > where the reply handler is the usual AMI reply handler, and the > AMI helper is a new type that is generated by the IDL compiler. > This > AMI helper would need to unmarshal the results and invoke the reply > handler > method. For example, it could support operations something like > > handleResult( OutputStream, replyHandler ) > > handleException( OutputStream, java.lang.Exception, replyHandler > ) > > The actual implementation of these methods is type specific and > generated by > the IDL compiler. The type of replyHandler would need to be a > common base > class for all generated AMI reply handler types (even > org.omg.CORBA.Object > could work here). I could be wrong here, but I think you have made this more difficult than it needs to be! I dont believe the unmarshalling of the reply and invoking the reply handled NEEDS to be operation specific, and so I dont think there is any need for the "AMI helper". Given the resolution to 2929 where type specific exception holders are taken away, the only thing that the Delegate would need in order to construct the request to the handler are a) The object reference of the handler (which he gets from the call to Delegate.sendc) b) The operation name (which he can mangle to the operation name on the handler), and which he gets from the original call to Delegate.Request. c) The marshalling reply body, which in the case of NO_EXCEPTION, can be just turned around and reused as the body for the request to the handler, or in the case of USER or SYSTEM EXCEPTION, can be wrapped in a generic ExceptionHolder valuetype, and send in the request to the handler. This is why I think the sendc stuff is reasonably trivial to add. > > >For the sendp stuff, I am much less an expert, since we have only played > >around with implementing it. However, I have done a cursory investigation, > >and it is my belief that the generated stub code probably also just needs the > >sendp and prepare operations from PIDL Request to be added to > >org.omg.CORBA.Request. > > > >However, the sendp bit is a bit more of a mess, since the DII Request operations > >for sendp are a bit wooly. Firstly they involve creating a second Request which > >is > >used to talk to the MessageRouting::PersistentRequest object that you get back > >from sendp, and furthermore, the marshalling code then gets back the message > >body > >rather than nice objects. > > > >In my view, the mess in sendp on the DII is caused by two factors - firstly the > >TII stuff (time independant invocations) which should be sunsetted IMO, and > > Purely from a Java centric view, this makes a lot of sense. The real interest > in Java messaging is in JMS and JAXM, not in the CORBA side. On the other > hand, AMI provides useful functionality to the core CORBA model that is missing > today. > > >also by the fact that it is possible to turn a sendp invocation into a sendc > >invocation after sending it (although not vice versa). This complication is > >not worth the trouble in my opinion - it is not a typical use case that one > >sends a request in polling mode, and then "changes ones mind" half way through. > > > >If one could remove TII and this "change of mode", then the send_deferred that > >is already there, could be used by the Stub code to send the sendp request, > >and a new variant of get_response (with a timeout) could be used by the > >stub code polling for the answer. > > Again, this addresses the question from the DII side, but I think there needs > to be a portable stream answer as well. Sure > > > > >Hope this helps - PLEASE try and get the sendc bit added to the Java mapping at > >least. This is an immensely useful primitive to many of our customers, and > >we have had this implemented for over 2 years now. > > I think we should do this, but it won't make it in time for CORBA 3.0 on > the current schedule. I do not plan to issue another vote in this RTF > since the 3 week deadline is January 7, 2002. It may > be able to make an interim Java RTF report later, and possibly also JDK 1.5. > > > > >I am willing to try and help out with tidying up the sendp bit, but there are > >probably people at Iona and Borland who have implemented this as well who > >can help as well. > > > > I'd love to here from the other ORB vendors here too: Eoghan? Vijay? > > Thanks, > > Ken. [] Chris.Smith1.vcf Date: Fri, 04 Jan 2002 08:45:59 +0000 From: Eoghan Glynn X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Cavanaugh CC: jishnu_mukerji@hp.com, Chris.Smith@uab.ericsson.se, java-rtf@omg.org Subject: Re: sendc/sendp java mapping (Re: issue 3068) References: <200201022132.g02LWgM17016@ha1sca-mail1.SFBay.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6l*!!%:od91Ged9gSm!! Ken Cavanaugh wrote: > > >I am willing to try and help out with tidying up the sendp bit, but there are > >probably people at Iona and Borland who have implemented this as well who > >can help as well. > > > > I'd love to here from the other ORB vendors here too: Eoghan? Vijay? As it happens, IONA have only implemented AMI support in our C++ ORB and not in the Java ORB as yet. However, this is coming on the radar in the medium term so we would be eager that the remaining specification issues are resolved, especially the IDL-Java mapping extensions required to support generated snedc/sendp methods in the streams-based invocation model. Cheers, Eoghan. -- Eoghan Glynn, Principal Engineer, IONA Technologies. "END 2 ANYWHERE" http://www.iona.com The IONA Building mailto:eglynn@iona.com Shelbourne Road tel :+353-1-6372439 Ballsbridge cell:+353-86-8175024 Dublin 4 Ireland Date: Fri, 4 Jan 2002 13:24:57 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: sendc/sendp java mapping (Re: issue 3068) To: Ken.Cavanaugh@sun.com, Chris.Smith@uab.ericsson.se Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: ZQJCE/OnvmiF3m1ITQLhLQ== 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: 9M!e9?JJe90+*!!NnTd9 >X-Unix-From: Chris.Smith@uab.ericsson.se Thu Jan 3 00:29:24 2002 >From: Chris Smith >X-Accept-Language: sv, en-US >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: jishnu_mukerji@hp.com, java-rtf@omg.org >Subject: Re: sendc/sendp java mapping (Re: issue 3068) > > >> >> Chris, >> >> >> >> Would it be possible for you to help Ken resolve this one? >> > >> >Sure. To start with, the resolution that we have >> >now proposed to 2929 will simplify things a lot, since there are >no >> >type specific exception holders. >> > >> >So, my belief is that the sendc mode can very easily be done by >adding >> >the sendc operation that is already specified in the DII chapter >to >> >org.omg.CORBA.Request. I cant see that this has been added in any >IDL-To-Java >> >RTFs yet. >> >> It has not. There are issues with the signature of sendc and the >implementation >> of the stub methods that need to be resolved. >> >> > >> >So, it would work like this. The IDL to java compiler would >generate the "extra" >> >operations sendc_ on the Stub class. This implies that >the sendc >> >operations >> >are NOT part of the "operations" Java interface - they are just >present on the >> >Stub class. >> >> Users of the IDL to Java mapping do not currently need to program >to the >> stub, which is a generated class. All client code is programmed >directly >> against the generated interface, not the stub. >> >> For example, the current code generation for IDL interface Foo >generates: >> >> Java interface FooOperations >> Java interface Foo (which extends FooOperations) >> Java class _Foo_Stub (which implements Foo) >> >> Currently users of the Foo IDL type just use Java type Foo for all >operations. >> Are you proposing that users of AMI on Foo would need to first >narrow >> a org.omg.CORBA.Object to _FooStub instead of just Foo? This is >particularly >> awkward when invoking operations on a typed object reference that >was >> obtained from another invocation, in which case a narrow would be >required >> for AMI, but not for SII. > >True - I had forgotten that the Stub class is not seen by the >programmers. >Well I guess the alternative is to put the sendc_ and sendp_ stuff in >the >operations >interface, and to define sensible "non working" implementations in >the >POA >class. This is probably more "pleasant" (although a bit dirty). > I do not really like the idea of putting this in the Operations interface, since the purpose of the Operations interface is to contain the methods that are common to the stub and the skeleton. We could consider: 1. Adding the AMI methods to the java interface directly (this is stub side only) 2. Defining a new AMIOperations (or something like that) interface that is extended by the java interface. We need to be careful here about how we do this. AMI introduces the possibility of defining different java interfaces/stubs for the same IDL interface (i.e. which combination of SII/sendc/sendp operations do we include in the generated code? Do we mandate that we always generate sendc and sendp? Or can a particular IDL compiler choose which ones to emit?). I think this may not be too bad in general, if the stub and java interface for an IDL interface are always loaded from the same ClassLoader. However, if some environment loads these two classes from different ClassLoaders, the possibility could exist for a type mismatch. Another possibility would be something like the following: >From IDL interface foo, generate: Foo FooOperations _FooStub as usual, then add a new interface and class: FooAMI which extends Foo with all of the AMI sendc/sendp operations _FooAMIStub which implements all of the AMI sendc/sendp operations The _FooAMIStub class would need to use an extended version of the org.omg.CORBA.portable.Delegate class (in the streaming model) which supports the necessary sendc/sendp primitives, or just uses the similar primives on Request for the DII case. Also, in the FooHelper class, generate appropriate AMINarrow methods that return a FooAMI type insteaf of Foo. Something like this could provide a graceful migration path, while not making life for the AMI programmer too difficult. > >> >> > The idl to java compiler would also generate the operations, stub >> >and >> >Impl Base classes/interfaces for the AMI Call back handler class. The user >> >makes an implementation of the Handler which he connects to some POA, and then >> >passes to the sendc_ on the Stub class. The generated code then uses >> >DII to create a Request object with the appropriate in params (the out params >> >and >> >return are ignored), and then uses sendc on the Request object, passing the >> >Handler >> >as the extra parameter. The underlying ORBs implementation of Request would then >> >handle all the rest. Since type specific exception holders have been removed, >> >(hopefully) in 2929, then are no needs for registering valuetype factories. >> > >> > >> >> This is a good point: the DII request should be extended to include sendc/sendp >> support. This is a core issue, as well as a language mapping issue. > >This stuff was added to the DII Request PIDL a long time ago in core. > > While the core RTF has added AMI support to Request (at least in 2.5 or 2.6), the Java RTF has not, so an issue needs to be rainsed to update the mapping of the Request pseudo-object. >> >> Using DII is one way to handle AMI, but it is typically much less >> efficient than >> the portable stream approach that is also supported. In analogy >> with normal >> SII calls, there should be 3 mechanisms supported: >> >> - DII >> - Portable Streams >> - Co-located call optimization (no marshalling of data). >> Admittedly this >> is less efficient in some ways with AMI, since the server side >> work would >> need to be handled by a separate thread, but we should consider >> this. > >Sure. I was just concentrating on clarifying on how the DII mode >> would work. You >"language mapping experts" can extrapolate better than me how the >> portable >streams >and colocation should look given how the DII method should look. > >> >> The portable stream mechanism would require extending org.omg.CORBA.portable.Delegate >> with a sendc operation along the lines of: >> >> public void sendc( org.omg.CORBA.Object.self, OutputStream os, >> rh, ah ) >> >> where the reply handler is the usual AMI reply handler, and the >> AMI helper is a new type that is generated by the IDL compiler. >> This >> AMI helper would need to unmarshal the results and invoke the reply >> handler >> method. For example, it could support operations something like >> >> handleResult( OutputStream, replyHandler ) >> >> handleException( OutputStream, java.lang.Exception, replyHandler >> ) >> >> The actual implementation of these methods is type specific and >> generated by >> the IDL compiler. The type of replyHandler would need to be a >> common base >> class for all generated AMI reply handler types (even >> org.omg.CORBA.Object >> could work here). > >I could be wrong here, but I think you have made this more difficult >> than it >needs >to be! I dont believe the unmarshalling of the reply and invoking the >reply handled NEEDS to be operation specific, and so I dont think >> there is any >need >for the "AMI helper". Given the resolution to 2929 where type >> specific exception >holders are taken away, the only thing that the Delegate would need >> in order to >construct the request to the handler are > >a) The object reference of the handler (which he gets from the call >> to >Delegate.sendc) Agreed. >b) The operation name (which he can mangle to the operation name on the >handler), and > which he gets from the original call to Delegate.Request. Agreed. >c) The marshalling reply body, which in the case of NO_EXCEPTION, can be just >turned >around and reused as the body for the request to the handler, or in the case of >USER >or SYSTEM EXCEPTION, can be wrapped in a generic ExceptionHolder valuetype, and >send >in the request to the handler. > Here's the problem: where is the marshalling reply body in the current mapping? It's sitting inline in the middle of the code that is generated for the SII case, and cannot be reused in any way without doing the full SII invocation. The AMI reply handler that I have sketched above is nothing more than an IDL type independent wrapper around the IDL type specific code that is needed to unmarshal the reply. > >This is why I think the sendc stuff is reasonably trivial to add. > There can be a long way between "reasonably trivial" and "getting the details correct in a standard, portable mapping" :-). > >> >> >For the sendp stuff, I am much less an expert, since we have only played >> >around with implementing it. However, I have done a cursory investigation, >> >and it is my belief that the generated stub code probably also just needs the >> >sendp and prepare operations from PIDL Request to be added to >> >org.omg.CORBA.Request. >> > For the DII case, yes; but more work is needed here for the portable stream case. >> >However, the sendp bit is a bit more of a mess, since the DII Request operations >> >for sendp are a bit wooly. Firstly they involve creating a second Request which >> >is >> >used to talk to the MessageRouting::PersistentRequest object that you get back >> >from sendp, and furthermore, the marshalling code then gets back the message >> >body >> >rather than nice objects. >> > >> >In my view, the mess in sendp on the DII is caused by two factors - firstly the >> >TII stuff (time independant invocations) which should be sunsetted IMO, and >> Can't we decouple sendp as a programming model from TII? I think that the Java mapping should only need to concern itself with the programming model. Ken. Date: Sat, 05 Jan 2002 15:05:02 +0100 From: Chris Smith X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Cavanaugh CC: java-rtf@omg.org Subject: Re: sendc/sendp java mapping (Re: issue 3068) References: <200201042124.g04LOvM00722@ha1sca-mail1.SFBay.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %<1!!TM0e9E8U!!/Nmd9 Status: RO > > >> > >> Java interface FooOperations > >> Java interface Foo (which extends FooOperations) > >> Java class _Foo_Stub (which implements Foo) > >> > >> Currently users of the Foo IDL type just use Java type Foo for all operations. > >> Are you proposing that users of AMI on Foo would need to first narrow > >> a org.omg.CORBA.Object to _FooStub instead of just Foo? This is particularly > >> awkward when invoking operations on a typed object reference that was > >> obtained from another invocation, in which case a narrow would be required > >> for AMI, but not for SII. > > > >True - I had forgotten that the Stub class is not seen by the programmers. > >Well I guess the alternative is to put the sendc_ and sendp_ stuff in the > >operations > >interface, and to define sensible "non working" implementations in the > >POA > >class. This is probably more "pleasant" (although a bit dirty). > > > > I do not really like the idea of putting this in the Operations interface, > since the purpose of the Operations interface is to contain the methods > that are common to the stub and the skeleton. We could consider: > > 1. Adding the AMI methods to the java interface directly (this is stub side > only) > > 2. Defining a new AMIOperations (or something like that) > interface that is extended by the java interface. > > We need to be careful here about how we do this. AMI introduces the possibility > of defining different java interfaces/stubs for the same IDL interface > (i.e. which combination of SII/sendc/sendp operations do we include in the > generated code? Do we mandate that we always generate sendc and sendp? Or > can a particular IDL compiler choose which ones to emit?). > I think this may not be too bad in general, if the stub and java interface for > an IDL interface are always loaded from the same ClassLoader. However, > if some environment loads these two classes from different ClassLoaders, > the possibility could exist for a type mismatch > > > Another possibility would be something like the following: > > From IDL interface foo, generate: > > Foo > FooOperations > _FooStub > > as usual, then add a new interface and class: > > FooAMI which extends Foo with all of the AMI sendc/sendp operations > _FooAMIStub which implements all of the AMI sendc/sendp operations > > The _FooAMIStub class would need to use an extended version of the > org.omg.CORBA.portable.Delegate class (in the streaming model) > which supports the necessary sendc/sendp primitives, or just uses > the similar primives on Request for the DII case. > > Also, in the FooHelper class, generate appropriate AMINarrow methods > that return a FooAMI type insteaf of Foo. Something like this could > provide a graceful migration path, while not making life for the AMI > programmer too difficult. I understand your comments about the difficulty of having stub classes and interfaces with or without the sendc. However, the need to do a separate narrow isnt so pleasant from a programming point of view.... > > Snip.... > > >I could be wrong here, but I think you have made this more difficult than it > >needs > >to be! I dont believe the unmarshalling of the reply and invoking the > >reply handled NEEDS to be operation specific, and so I dont think there is any > >need > >for the "AMI helper". Given the resolution to 2929 where type specific exception > >holders are taken away, the only thing that the Delegate would need in order to > >construct the request to the handler are > > > >a) The object reference of the handler (which he gets from the call to > >Delegate.sendc) > > Agreed. > > >b) The operation name (which he can mangle to the operation name on the > >handler), and > > which he gets from the original call to Delegate.Request. > > Agreed. > > >c) The marshalling reply body, which in the case of NO_EXCEPTION, can be just > >turned > >around and reused as the body for the request to the handler, or in the case of > >USER > >or SYSTEM EXCEPTION, can be wrapped in a generic ExceptionHolder valuetype, and > >send > >in the request to the handler. > > > > Here's the problem: where is the marshalling reply body in the current mapping? > It's sitting inline in the middle of the code that is generated for the SII > case, and cannot be reused in any way without doing the full SII invocation. > The AMI reply handler that I have sketched above is nothing more than an > IDL type independent wrapper around the IDL type specific code that is needed > to unmarshal the reply. > I could be rather dumn here, but I still dont get the problem. The whole thing about the resolution to 2929 is that the reply doesnt need to be unmarshalled by the ORB, and there is nothing even type specific about the remarshalling of it as a request to the handler - this is all generic. In the non exception case, the request body to the handler IS the reply body from the original request, and in the exception case, the request body to the handler is a generic exception holder containing the reply body from the original request. Of course portability is the prime concern here, but I dont see the problem - all of this can be done inside the ORB itself, so there is no need to go up to stub or skeleton code. Sorry if I'm missing the point... > > > >This is why I think the sendc stuff is reasonably trivial to add. > > > > There can be a long way between "reasonably trivial" and "getting > >the details > correct in a standard, portable mapping" :-). Of course. > > > > > >> > >> >For the sendp stuff, I am much less an expert, since we have >only played > >> >around with implementing it. However, I have done a cursory >investigation, > >> >and it is my belief that the generated stub code probably also >just needs the > >> >sendp and prepare operations from PIDL Request to be added to > >> >org.omg.CORBA.Request. > >> > > > For the DII case, yes; but more work is needed here for the portable >stream case. > > >> >However, the sendp bit is a bit more of a mess, since the DII >Request operations > >> >for sendp are a bit wooly. Firstly they involve creating a >second Request which > >> >is > >> >used to talk to the MessageRouting::PersistentRequest object >that you get back > >> >from sendp, and furthermore, the marshalling code then gets back >the message > >> >body > >> >rather than nice objects. > >> > > >> >In my view, the mess in sendp on the DII is caused by two >factors - firstly the > >> >TII stuff (time independant invocations) which should be >sunsetted IMO, and > >> > > Can't we decouple sendp as a programming model from TII? I think >that the > Java mapping should only need to concern itself with the programming >model. That would be nice. The only place where this gets difficult is in the mapping of sendp in the DII, which is why I think it would be nice to clean that up. I believe it is possible to clean up and remove a lot of complexity there if one takes away the requirement to change from sendp to sendc in mid-request. > > > Ken. Date: Sat, 5 Jan 2002 12:06:15 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: sendc/sendp java mapping (Re: issue 3068) To: Ken.Cavanaugh@sun.com, chris.smith@uab.ericsson.se Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: adTJe3IyVJbwPs9kABtnEw== 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: \3`!!(4R!!73,e94_K!! Status: RO >From: Chris Smith >X-Accept-Language: en >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: java-rtf@omg.org >Subject: Re: sendc/sendp java mapping (Re: issue 3068) >Content-Transfer-Encoding: 7bit > >> >> >> >> >> Java interface FooOperations >> >> Java interface Foo (which extends FooOperations) >> >> Java class _Foo_Stub (which implements Foo) >> >> >> >> Currently users of the Foo IDL type just use Java type Foo for >all operations. >> >> Are you proposing that users of AMI on Foo would need to first >narrow >> >> a org.omg.CORBA.Object to _FooStub instead of just Foo? This is particularly >> >> awkward when invoking operations on a typed object reference >that was >> >> obtained from another invocation, in which case a narrow would >be required >> >> for AMI, but not for SII. >> > >> >True - I had forgotten that the Stub class is not seen by the >programmers. >> >Well I guess the alternative is to put the sendc_ and sendp_ stuff >in the >> >operations >> >interface, and to define sensible "non working" implementations in >the >> >POA >> >class. This is probably more "pleasant" (although a bit dirty). >> > >> >> I do not really like the idea of putting this in the Operations >interface, >> since the purpose of the Operations interface is to contain the >methods >> that are common to the stub and the skeleton. We could consider: >> >> 1. Adding the AMI methods to the java interface directly (this is >stub side >> only) >> >> 2. Defining a new AMIOperations (or something like that) >> interface that is extended by the java interface. >> >> We need to be careful here about how we do this. AMI introduces >the possibility >> of defining different java interfaces/stubs for the same IDL >interface >> (i.e. which combination of SII/sendc/sendp operations do we include >in the >> generated code? Do we mandate that we always generate sendc and >sendp? Or >> can a particular IDL compiler choose which ones to emit?). >> I think this may not be too bad in general, if the stub and java >interface for >> an IDL interface are always loaded from the same ClassLoader. >However, >> if some environment loads these two classes from different >ClassLoaders, >> the possibility could exist for a type mismatch > >> >> >> Another possibility would be something like the following: >> >> From IDL interface foo, generate: >> >> Foo >> FooOperations >> _FooStub >> >> as usual, then add a new interface and class: >> >> FooAMI which extends Foo with all of the AMI sendc/sendp operations >> _FooAMIStub which implements all of the AMI sendc/sendp operations >> >> The _FooAMIStub class would need to use an extended version of the >> org.omg.CORBA.portable.Delegate class (in the streaming model) >> which supports the necessary sendc/sendp primitives, or just uses >> the similar primives on Request for the DII case. >> >> Also, in the FooHelper class, generate appropriate AMINarrow >methods >> that return a FooAMI type insteaf of Foo. Something like this >could >> provide a graceful migration path, while not making life for the >AMI >> programmer too difficult. > >I understand your comments about the difficulty of having stub >classes and >interfaces with or without the sendc. However, the need to do a >separate >narrow isnt so pleasant from a programming point of view.... >> > Neither is the need to do a cast on the result of the narrow. I think we all (on the Java RTF) need to give this some more consideration. >> > >Snip.... > >> >> >I could be wrong here, but I think you have made this more difficult than it >> >needs >> >to be! I dont believe the unmarshalling of the reply and invoking the >> >reply handled NEEDS to be operation specific, and so I dont think there is any >> >need >> >for the "AMI helper". Given the resolution to 2929 where type specific exception >> >holders are taken away, the only thing that the Delegate would need in order to >> >construct the request to the handler are >> > >> >a) The object reference of the handler (which he gets from the call to >> >Delegate.sendc) >> >> Agreed. >> >> >b) The operation name (which he can mangle to the operation name on the >> >handler), and >> > which he gets from the original call to Delegate.Request. >> >> Agreed. >> >> >c) The marshalling reply body, which in the case of NO_EXCEPTION, can be just >> >turned >> >around and reused as the body for the request to the handler, or in the case of >> >USER >> >or SYSTEM EXCEPTION, can be wrapped in a generic ExceptionHolder valuetype, and >> >send >> >in the request to the handler. >> > >> >> Here's the problem: where is the marshalling reply body in the current mapping? >> It's sitting inline in the middle of the code that is generated for the SII >> case, and cannot be reused in any way without doing the full SII invocation. >> The AMI reply handler that I have sketched above is nothing more than an >> IDL type independent wrapper around the IDL type specific code that is needed >> to unmarshal the reply. >> > >I could be rather dumn here, but I still dont get the problem. The whole thing >about the resolution to 2929 is that the reply doesnt need to be unmarshalled >by the ORB, and there is nothing even type specific about the remarshalling >of it as a request to the handler - this is all generic. In the non exception case, >the request body to the handler IS the reply body from the original request, >and in the exception case, the request body to the handler is a generic >exception holder containing the reply body from the original request. Of >course portability is the prime concern here, but I dont see the problem - all >of this can be done inside the ORB itself, so there is no need to go up to >stub or skeleton code. Sorry if I'm missing the point... > I think you are correct IF the sendc stub method is implemented with DII. In this case, the ORB has all of the type information when the sendc call is made in the anys that were passed into the request. The problem is that the portable stream approach does not work that way. When the Delegate.request/invoke methods are called, the ORB has no information readily available (without invoking an IR, which is not a good solution) about the types of the arguments. All type information in this case lives in the stub. This is why I believe that an AMI response handler is needed. >> > >> >This is why I think the sendc stuff is reasonably trivial to add. >> > >> >> There can be a long way between "reasonably trivial" and "getting >> >the details >> correct in a standard, portable mapping" :-). > >Of course. > >> >> >> > >> >> >> >> >For the sendp stuff, I am much less an expert, since we have >> >only played >> >> >around with implementing it. However, I have done a cursory investigation, >> >> >and it is my belief that the generated stub code probably also >> >just needs the >> >> >sendp and prepare operations from PIDL Request to be added to >> >> >org.omg.CORBA.Request. >> >> > >> >> For the DII case, yes; but more work is needed here for the >> >portable stream case. >> >> >> >However, the sendp bit is a bit more of a mess, since the DII >> >Request operations >> >> >for sendp are a bit wooly. Firstly they involve creating a >> >second Request which >> >> >is >> >> >used to talk to the MessageRouting::PersistentRequest object >> >that you get back >> >> >from sendp, and furthermore, the marshalling code then gets >> >back the message >> >> >body >> >> >rather than nice objects. >> >> > >> >> >In my view, the mess in sendp on the DII is caused by two >> >factors - firstly the >> >> >TII stuff (time independant invocations) which should be >> >sunsetted IMO, and >> >> >> >> Can't we decouple sendp as a programming model from TII? I think >> >that the >> Java mapping should only need to concern itself with the >> >programming model. > >That would be nice. The only place where this gets difficult is in >> >the mapping of sendp >in the DII, which is why I think it would be nice to clean that up. I >> >believe it is >possible to clean up and remove a lot of complexity there if one >> >takes away the >requirement to change from sendp to sendc in mid-request. > I did not realize that it was possible to make the change. Could you describe how this currently works, and/or point to the discission in the spec? In any case, I agree that it seems to be an unreasonable use case. Thanks, Ken. Date: Sun, 06 Jan 2002 21:17:47 +0100 From: Chris Smith X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Cavanaugh CC: java-rtf@omg.org Subject: Re: sendc/sendp java mapping (Re: issue 3068) References: <200201052006.g05K6FM22397@ha1sca-mail1.SFBay.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >/V!!InBe9IALd9il4!! > > >I understand your comments about the difficulty of having stub classes and > >interfaces with or without the sendc. However, the need to do a separate > >narrow isnt so pleasant from a programming point of view.... > >> > > > > Neither is the need to do a cast on the result of the narrow. I think we > all (on the Java RTF) need to give this some more consideration. Sure. > > >I could be rather dumn here, but I still dont get the problem. The whole thing > >about the resolution to 2929 is that the reply doesnt need to be unmarshalled > >by the ORB, and there is nothing even type specific about the remarshalling > >of it as a request to the handler - this is all generic. In the non exception > case, > >the request body to the handler IS the reply body from the original request, > >and in the exception case, the request body to the handler is a generic > >exception holder containing the reply body from the original request. Of > >course portability is the prime concern here, but I dont see the problem - all > >of this can be done inside the ORB itself, so there is no need to go up to > >stub or skeleton code. Sorry if I'm missing the point... > > > > I think you are correct IF the sendc stub method is implemented with DII. > In this case, the ORB has all of the type information when the sendc call > is made in the anys that were passed into the request. > > The problem is that the portable stream approach does not work that way. > When the Delegate.request/invoke methods are called, the ORB has no information > readily available (without invoking an IR, which is not a good solution) > about the types of the arguments. All type information in this case lives in > the stub. This is why I believe that an AMI response handler is needed. I must still be missing something, but I'll leave the discussion at this point. Our implementation doesnt need any information about the types at all - in our C++ implementation for example, the type info is not available at the point we turn around the reply from the server and turn it into a request on the callback object - no type info is needed. But maybe there is some extra requirement for type info in the Java mapping that I havnt understood. Anyway - it would be great if the Java RTF could look at these issues soon. I'm very happy to help in any way that I can. Cheers Chris > > > >> > > >> >This is why I think the sendc stuff is reasonably trivial to >add. > >> > > >> > >> There can be a long way between "reasonably trivial" and "getting >the details > >> correct in a standard, portable mapping" :-). > > > >Of course. > > > >> > >> > >> > > >> >> > >> >> >For the sendp stuff, I am much less an expert, since we have >only played > >> >> >around with implementing it. However, I have done a cursory > investigation, > >> >> >and it is my belief that the generated stub code probably >also just needs > the > >> >> >sendp and prepare operations from PIDL Request to be added to > >> >> >org.omg.CORBA.Request. > >> >> > > >> > >> For the DII case, yes; but more work is needed here for the >portable stream > case. > >> > >> >> >However, the sendp bit is a bit more of a mess, since the DII >Request > operations > >> >> >for sendp are a bit wooly. Firstly they involve creating a >second Request > which > >> >> >is > >> >> >used to talk to the MessageRouting::PersistentRequest object >that you get > back > >> >> >from sendp, and furthermore, the marshalling code then gets >back the > message > >> >> >body > >> >> >rather than nice objects. > >> >> > > >> >> >In my view, the mess in sendp on the DII is caused by two >factors - > firstly the > >> >> >TII stuff (time independant invocations) which should be >sunsetted IMO, > and > >> >> > >> > >> Can't we decouple sendp as a programming model from TII? I think >that the > >> Java mapping should only need to concern itself with the >programming model. > > > >That would be nice. The only place where this gets difficult is in >the mapping > of sendp > >in the DII, which is why I think it would be nice to clean that >up. I believe > it is > >possible to clean up and remove a lot of complexity there if one >takes away the > >requirement to change from sendp to sendc in mid-request. > > > > I did not realize that it was possible to make the change. Could >you describe > how this currently works, and/or point to the discission in the >spec? In any > case, I agree that it seems to be an unreasonable use case. > > Thanks, > > Ken.