Issue 4269: IDL out parameters can't map to EJB? (components-ftf) Source: Progress Software (Mr. Alan Conway, nobody) Nature: Uncategorized Issue Severity: Summary: Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules." As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec. Someone please tell me I've missed something! Resolution: see below Revised Text: In section 64.4, page 64-183, first bullet, add: Notice that "The home and remote interfaces of the enterprise bean's client view are defined as Java RMI interfaces. This allows the Container to implement the home and remote interfaces as distributed objects." One implication of this is that the signatures on methods on an EJB's remote interface can only include parameters with "in" semantics. That is, "out" and "inout" semantics for parameters is not allowed. As a consequence, the out and inout qualifiers for parameters in IDL interface method definitions are not included in the portion of Component IDL that can be mapped to an EJB definition. Note however that a Java client does not have to use an EJB view in order to access a CCM. Any Java client can access a CCM directly via its IDL interface using a standard Java ORB, such as the one built in to the JDK. This provides full access to all aspects of the CCM. Since the EJB view is derived using the IDL to Java mapping rules, the Java IDL interface is identical to the EJB view for all business operations. The only differences are in the operations mentioned in [##reference to the table of re-mapped functions for the EJB view] have slightly different names and signatures. In section 64.4.1, page 64-185, Mapping the component definition, fourth bullet, add: Only signatures whose parameters have an in qualifier are allowed. Signatures that include parameters with out or inout qualifiers shall be signaled as an error. Actions taken: April 12, 2001: received issue May 13, 2002: closed issue Discussion: The fundamental problem appears to be that EJB/RMI is not able to express the mapping of a Component IDL signature with out or inout parameters (given RMI's pass by value semantics). Restrict the set of Component IDL signatures to be included in the portion of Component IDL that is to be considered by the specification to those that do not include out or inout parameters. End of Annotations:===== X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 12 Apr 2001 09:36:53 -0400 To: components-ftf@omg.org From: Alan Conway Subject: IDL out parameters can't map to EJB? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: EM1!!"#(e9"?D!!T6dd9 Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules." As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec. Someone please tell me I've missed something! Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: Re: IDL out parameters can't map to EJB? To: Alan Conway Cc: components-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Fri, 27 Apr 2001 15:47:47 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/27/2001 03:48:24 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: D`=!!:aOd9%'P!!"OAe9 Hi Alan, After thinking about this and talking about it with Jeff Mischkinsky and Michi Henning, I don't think we have much room to maneuver. Just to reiterate, the fundamental problem seems to be that EJB/RMI is not able to express the mapping of a Component IDL signature with out or inout parameters (given RMI's pass by value semantics). Possible solutions to this problem then are: 1- Disallow mapping (and thus bridging) of Component IDL signatures with out or inout parameters. This is a simple but drastic solution that may turn out to be too restrictive. On the up side, given that users of RMI and EJB interfaces are not used to out or inout parameters, they would not look for such a mapping. But then, the mapping and bridging of outs and inouts is not necessarily aimed at pure EJB/RMI users. 2- Use the return value as a vehicle for outs and inouts. In this case, the mapping of an out or inout parameter would not be onto a parameter at all, but rather into a composite return value that consists of the original return value plus the out or inout in question. This can actually work at an operational level, but it denotes a completely different meaning than that of the original signature, resulting in an obscure mapping at best. 3- Map outs and inouts into remote objects. In this case, we use the only kind of by-reference mechanism we can use in RMI for outs and inouts (which is closer to their meaning than by-value). The client is then passing a remote reference to the outs and inouts it wants to use. This option is less obscure than 2 but probably more inefficient and with more impact to the client, which now has to mantain a remote object for each out or inout. I don't think there is a clear winner out of these three options (there may be other options but so far these are the ones I have thought of). In my mind 2 is not really acceptable (even if it may be the more efficient or provide the most coverage) if for no better reason than the big semantic departure from the original signature that it implies. Option 1 is the most semantically clean but it may impose too high a cost in terms of expressibility. Option 3 may provide good enough coverage but it's not quite semantically clean. What's your opinion of these options? Do you see any other options? -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 04/12/2001 09:36:53 AM To: components-ftf@omg.org cc: Subject: IDL out parameters can't map to EJB? Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules." As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec. Someone please tell me I've missed something! Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Reply-To: From: "Tom Hawker" To: "'Ignacio Silva-Lepe'" , "'Alan Conway'" Cc: Subject: RE: IDL out parameters can't map to EJB? Date: Fri, 27 Apr 2001 17:06:51 -0500 Message-ID: <000101c0cf66$5d995e80$1600a8c0@wtest.dynu.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIMETrack: Itemize by SMTP Server on Bethesda1/Iconixx(Release 5.0.5 |September 22, 2000) at 04/27/2001 06:06:02 PM, Serialize by Router on Bethesda1/Iconixx(Release 5.0.5 |September 22, 2000) at 04/27/2001 06:06:06 PM, Serialize complete at 04/27/2001 06:06:06 PM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id f3RM5wa08559 Content-Type: text/plain; charset="us-ascii" X-UIDL: f-hd9nc$e9VN]d9mbn!! All, Please forgive me for tossing my opinion in here, but for my own peace of mind, I need some clarification. I'm not sure I understand the rationale behind Ignacio's stated preferences, especially why some options are more or less undesirable conpared to other alternatives. 1 - Disallow mapping. I do not understand why this is "drastic". It is not CCM that is imposing the limitation, it is EJB/RMI. CORBA is and has always been more flexible than other ROI/RMI middleware solutions. If EJB/RMI won't do it, why should we undertake the task of overcoming the restriction? We should probably state how the map would work with EJB/RMI as is, and then give guidelines for how the map would work if EJB/RMI changes to somethign more reasonable. (No, it won't be exact, but it would give us time to accommodate such a change.) Since Sun has always been diligent to control the semantics of Java in all its aspects, I don't understand the last sentence. How can one have an "impure" variant of EJB/RMI? Even if you could, won't the regular language mappings handle such cases? 2 - Use a composite return. This could work, although the actual programming might be messy. I suspect its true feasibility would depend on how much could be automated. I do not fully understand why this approach would have a different meaning than the intention. After all, in parameters by definition have copy semantics. Out/inout parameters merely copy the other direction. All this mapping does is move where the copy occurs. I don't really care that the bean might have a complex reply object to generate or consume to satisfy the signature. In fact, all it does is make one aware of what the marshalling algorithm normally does quietly. I also don't understand why the mapping is "obscure" - it looks straightforward to me. I can at least imagine how to build code to handle it. 3 - Map to object references. If this were to follow Java's use of holders (container objects), then the remote object references could be for the containers. Copy semantics are maintained by supplying value retrieval and replacement methods in the remote object's interface. This is a case where automated bridges (instead of a client or server programming hack) could actually handle the containers automatically, inserting or removing depending on the direction of the request. I am not sure I fully agree with the claims on the client. While transferring data through object references will be slower, I don't think it will be significant. The marshalling of the data in either direction will have the same basic cost. All we've added is some object lookup and message overhead, both of which are minimal and highly efficient with modern implementations. IMHO, I really don't have a problem with (1). Since EJB/RMI has locked itself into a box, I don't feel any need to aid them in prying open the lock. I would prefer (2) because it doesn't suffer from the potential synchronization issues of (3) in case you get or put the value several times. I don't have a problem with (3) and don't think that we'll encounter a big performance hit. I don't really mind that the signatures change in (2) and (3), because to implement them I've volunteered to engineer a solution to a problem not of my making. I don't feel that the semantics are particularly different, either, but I would point out that (3) is much more at variance than (2). Both could work transparently if done on-the-fly through an intermediate bridge (or transformation wrapper). Alan's original complaint was that the holder classes need not be Serializable. Would it be easier to require that behavior? If we did, would or wouldn't that get around the difficulties? Would it need to be in the language map? Tom Hawker, Iconixx thawker@iconixx.com > -----Original Message----- > From: Ignacio Silva-Lepe [mailto:isilval@us.ibm.com] > Sent: Friday, April 27, 2001 2:48 PM > To: Alan Conway > Cc: components-ftf@omg.org > Subject: Re: IDL out parameters can't map to EJB? > > > > Hi Alan, > > After thinking about this and talking about it with Jeff Mischkinsky and > Michi Henning, I don't think we have much room to maneuver. Just to > reiterate, the fundamental problem seems to be that EJB/RMI is not able to > express the mapping of a Component IDL signature with out or inout > parameters (given RMI's pass by value semantics). Possible solutions to > this problem then are: > > 1- Disallow mapping (and thus bridging) of Component IDL signatures with > out or inout parameters. This is a simple but drastic solution that may > turn out to be too restrictive. On the up side, given that users of RMI and > EJB interfaces are not used to out or inout parameters, they would not look > for such a mapping. But then, the mapping and bridging of outs and inouts > is not necessarily aimed at pure EJB/RMI users. > > 2- Use the return value as a vehicle for outs and inouts. In this case, the > mapping of an out or inout parameter would not be onto a parameter at all, > but rather into a composite return value that consists of the original > return value plus the out or inout in question. This can actually work at > an operational level, but it denotes a completely different meaning than > that of the original signature, resulting in an obscure mapping at best. > > 3- Map outs and inouts into remote objects. In this case, we use the only > kind of by-reference mechanism we can use in RMI for outs and inouts (which > is closer to their meaning than by-value). The client is then passing a > remote reference to the outs and inouts it wants to use. This option is > less obscure than 2 but probably more inefficient and with more impact to > the client, which now has to mantain a remote object for each out or inout. > > I don't think there is a clear winner out of these three options (there may > be other options but so far these are the ones I have thought of). In my > mind 2 is not really acceptable (even if it may be the more efficient or > provide the most coverage) if for no better reason than the big semantic > departure from the original signature that it implies. Option 1 is the most > semantically clean but it may impose too high a cost in terms of > expressibility. Option 3 may provide good enough coverage but it's not > quite semantically clean. > > What's your opinion of these options? Do you see any other options? > > -- Ignacio > > Ignacio Silva-Lepe > IBM T. J. Watson Research Center > P.O. Box 704 Yorktown Heights, NY 10598, USA > INTERNET: isilval@us.ibm.com > WWW: http://www.zgnews.com/silva > Phone: (914) 784 7003 Fax: (914) 784 6040 > > > Alan Conway on 04/12/2001 09:36:53 AM > > To: components-ftf@omg.org > cc: > Subject: IDL out parameters can't map to EJB? > > > > Section 8.3.1 says "The signatures of the CORBA component operations are > mapped to signatures of EJB remote interface methods following the IDL to > Java mapping rules." > > As far as I can see, this only works if the IDL signature has no out or > inout parameters. The Holder classes for out and inout parameters cannot be > used in an EJB interface signature because they need not be Serializable, > which breaks the rules for an RMI compliant class. Even if they could the > EJB stubs and skeletons would not implement their special return value > behavior without modifications to the EJB spec. > > Someone please tell me I've missed something! > > Cheers, > Alan. > > > Alan Conway, Senior Engineer, IONA Technologies. > E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. > > > > From: Jeffrey Mischkinsky Message-Id: <200104280540.WAA14176@wheel.dcn.davis.ca.us> Subject: Re: IDL out parameters can't map to EJB? To: thawker@iconixx.com Date: Fri, 27 Apr 2001 22:40:26 -0700 (PDT) Cc: isilval@us.ibm.com ('Ignacio Silva-Lepe'), alan.conway@iona.com ('Alan Conway'), components-ftf@omg.org In-Reply-To: <000101c0cf66$5d995e80$1600a8c0@wtest.dynu.com> from "Tom Hawker" at Apr 27, 2001 05:06:51 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m4Td9QcBe9oIQ!!65,e9 'Tom Hawker' writes: > > All, > > Please forgive me for tossing my opinion in here, but for my own peace of mind, I need some clarification. I'm not sure I understand the rationale behind Ignacio's stated preferences, especially why some options are more or less undesirable conpared to other alternatives. > > 1 - Disallow mapping. I do not understand why this is "drastic". It is not CCM that is imposing the limitation, it is EJB/RMI. CORBA is and has always been more flexible than other ROI/RMI middleware solutions. If EJB/RMI won't do it, why should we undertake the task of overcoming the restriction? We should probably state how the map would work with EJB/RMI as is, and then give guidelines for how the map would work if EJB/RMI changes to somethign more reasonable. (No, it won't be exact, but it would give us time to accommodate such a change.) Since Sun has always been diligent to control the semantics of Java in all its aspects, I don't understand the last sentence. How can one have an "impure" variant of EJB/RMI? Even if you could, won't the regular language mappings handle such cases? It's drastic only in that this approach there is some stuff that can't be mapped. But i agree, it's an EJB/RMI limitation, so be it. My other reason for preferring it, is that at this point I suspect this more of the nature of an "edge condition". When and if we have lots of people taking advantage of the mapping, and it becomes a significant issue that CCM supports outs and EJB doesn't, then we can come up with more complete solutions. I think we have bigger fish to fry right now, and restricting the mapping right now, won't prevent us from removing the restriction in the future. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 30 Apr 2001 05:13:55 -0700 To: , "'Ignacio Silva-Lepe'" From: Alan Conway Subject: RE: IDL out parameters can't map to EJB? Cc: In-Reply-To: <000101c0cf66$5d995e80$1600a8c0@wtest.dynu.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: *BV!!*N#e9%a=!!@$e!! Here's my take on Ignacio's 3 options (which I agree are the only 3) plus answer to a question Tom raised about why we can't just make Holder's serializable: The options: 1 - Disallow mapping out/inout: This is probably the best first cut. Any later solution to support out/inouts will certainly be backwards compatible with this. It is only drastic in the sense that a potentially broad class of CORBA components (those designed by CORBA programmers who are used to out/inout) will not be accessible to EJB clients *as EJBs*. Don't forget that they are always available to Java code *as CORBA objects via a Java ORB*. There's no conflict with being bot an EJB and CORBA client, and the JVM includes a built-in ORB. 2 - Use a composite return: essentially this amounts to writing a variant on the IDL to Java mapping that maps out/inout's to automatically generated return values (generated by a variant IDL compiler.) It's perfectly feasible, but now may not be the right time to bring it into CCM. 3 - Use remote references for out/inout: I'm strongly against this one. Who hosts these "remote holders"? We don't want to force the client to host them, since we can't require the client to be capable of being a server. If we put them on the server, we must put in place a whole bunch of factory/lookup machinery so the client can create holders remotely and attendent garbage collection on the server to clean them up. Also the performance *is* an issue - multiple out parameters are often used *specifically* to avoid multiple remote client calls by providing multiple results in a single call. Finally Tom's question: "Alan's original complaint was that the holder classes need not be Serializable. Would it be easier to require that behavior? If we did, would or wouldn't that get around the difficulties? Would it need to be in the language map?" That does not solve the problem. Even if Holders were serializable, when used as EJB parameters they would still only be passed "in" from client to server. EJB does not provide any mechanism whereby the client-side content of the Holder would be updated after the call. Underlying all this is the asymmetry of the IDL/Java and Java/IDL mappings. Running and IDL compiler followed by rmic does not bring you even close to the original IDL (try it some time on your favourite IDL file - it's an instructive lesson on the usability of the Java to IDL mapping!) Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: RE: IDL out parameters can't map to EJB? To: Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Mon, 30 Apr 2001 16:02:57 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/30/2001 04:03:17 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 4"Ie9)Mj!!%)ed9[TJe9 Hi Tom, Just to clarify the rationale for my preferences. The semantic departure that option (2) implies in my mind is from the point of view of the functionality of the signatures being mapped. That is, if a method with signature "double foo( in int x,inout float y )" is mapped to something like "fooRetVal foo( in int x )", where fooRetVal is a valuetype aggregating a double and a float, then, from the point of view of a client of foo, it is not apparently obvious that they represent the same function any more. Of course there are operational rules that can be used to determine the equivalence of the meanings, but this seems to me to obscure an application-specific specification for an implementation-specific reason. As for option (3), I agree with Alan that it does imply a performance degradation at best. Even option (1), which we seem to be forced into by EJB/RMI's limitations, poses a restriction on users that are not necessarily exclusively focused on EJB/RMI. But I think that it is the most acceptable of the three, in my opinion. -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 "Tom Hawker" on 04/27/2001 06:06:51 PM Please respond to To: Ignacio Silva-Lepe/Watson/IBM@IBMUS, "'Alan Conway'" cc: Subject: RE: IDL out parameters can't map to EJB? All, Please forgive me for tossing my opinion in here, but for my own peace of mind, I need some clarification. I'm not sure I understand the rationale behind Ignacio's stated preferences, especially why some options are more or less undesirable conpared to other alternatives. 1 - Disallow mapping. I do not understand why this is "drastic". It is not CCM that is imposing the limitation, it is EJB/RMI. CORBA is and has always been more flexible than other ROI/RMI middleware solutions. If EJB/RMI won't do it, why should we undertake the task of overcoming the restriction? We should probably state how the map would work with EJB/RMI as is, and then give guidelines for how the map would work if EJB/RMI changes to somethign more reasonable. (No, it won't be exact, but it would give us time to accommodate such a change.) Since Sun has always been diligent to control the semantics of Java in all its aspects, I don't understand the last sentence. How can one have an "impure" variant of EJB/RMI? Even if you could, won't the regular language mappings handle such cases? 2 - Use a composite return. This could work, although the actual programming might be messy. I suspect its true feasibility would depend on how much could be automated. I do not fully understand why this approach would have a different meaning than the intention. After all, in parameters by definition have copy semantics. Out/inout parameters merely copy the other direction. All this mapping does is move where the copy occurs. I don't really care that the bean might have a complex reply object to generate or consume to satisfy the signature. In fact, all it does is make one aware of what the marshalling algorithm normally does quietly. I also don't understand why the mapping is "obscure" - it looks straightforward to me. I can at least imagine how to build code to handle it. 3 - Map to object references. If this were to follow Java's use of holders (container objects), then the remote object references could be for the containers. Copy semantics are maintained by supplying value retrieval and replacement methods in the remote object's interface. This is a case where automated bridges (instead of a client or server programming hack) could actually handle the containers automatically, inserting or removing depending on the direction of the request. I am not sure I fully agree with the claims on the client. While transferring data through object references will be slower, I don't think it will be significant. The marshalling of the data in either direction will have the same basic cost. All we've added is some object lookup and message overhead, both of which are minimal and highly efficient with modern implementations. IMHO, I really don't have a problem with (1). Since EJB/RMI has locked itself into a box, I don't feel any need to aid them in prying open the lock. I would prefer (2) because it doesn't suffer from the potential synchronization issues of (3) in case you get or put the value several times. I don't have a problem with (3) and don't think that we'll encounter a big performance hit. I don't really mind that the signatures change in (2) and (3), because to implement them I've volunteered to engineer a solution to a problem not of my making. I don't feel that the semantics are particularly different, either, but I would point out that (3) is much more at variance than (2). Both could work transparently if done on-the-fly through an intermediate bridge (or transformation wrapper). Alan's original complaint was that the holder classes need not be Serializable. Would it be easier to require that behavior? If we did, would or wouldn't that get around the difficulties? Would it need to be in the language map? Tom Hawker, Iconixx thawker@iconixx.com > -----Original Message----- > From: Ignacio Silva-Lepe [mailto:isilval@us.ibm.com] > Sent: Friday, April 27, 2001 2:48 PM > To: Alan Conway > Cc: components-ftf@omg.org > Subject: Re: IDL out parameters can't map to EJB? > > > > Hi Alan, > > After thinking about this and talking about it with Jeff Mischkinsky and > Michi Henning, I don't think we have much room to maneuver. Just to > reiterate, the fundamental problem seems to be that EJB/RMI is not able to > express the mapping of a Component IDL signature with out or inout > parameters (given RMI's pass by value semantics). Possible solutions to > this problem then are: > > 1- Disallow mapping (and thus bridging) of Component IDL signatures with > out or inout parameters. This is a simple but drastic solution that may > turn out to be too restrictive. On the up side, given that users of RMI and > EJB interfaces are not used to out or inout parameters, they would not look > for such a mapping. But then, the mapping and bridging of outs and inouts > is not necessarily aimed at pure EJB/RMI users. > > 2- Use the return value as a vehicle for outs and inouts. In this case, the > mapping of an out or inout parameter would not be onto a parameter at all, > but rather into a composite return value that consists of the original > return value plus the out or inout in question. This can actually work at > an operational level, but it denotes a completely different meaning than > that of the original signature, resulting in an obscure mapping at best. > > 3- Map outs and inouts into remote objects. In this case, we use the only > kind of by-reference mechanism we can use in RMI for outs and inouts (which > is closer to their meaning than by-value). The client is then passing a > remote reference to the outs and inouts it wants to use. This option is > less obscure than 2 but probably more inefficient and with more impact to > the client, which now has to mantain a remote object for each out or inout. > > I don't think there is a clear winner out of these three options (there may > be other options but so far these are the ones I have thought of). In my > mind 2 is not really acceptable (even if it may be the more efficient or > provide the most coverage) if for no better reason than the big semantic > departure from the original signature that it implies. Option 1 is the most > semantically clean but it may impose too high a cost in terms of > expressibility. Option 3 may provide good enough coverage but it's not > quite semantically clean. > > What's your opinion of these options? Do you see any other options? > > -- Ignacio > > Ignacio Silva-Lepe > IBM T. J. Watson Research Center > P.O. Box 704 Yorktown Heights, NY 10598, USA > INTERNET: isilval@us.ibm.com > WWW: http://www.zgnews.com/silva > Phone: (914) 784 7003 Fax: (914) 784 6040 > > > Alan Conway on 04/12/2001 09:36:53 AM > > To: components-ftf@omg.org > cc: > Subject: IDL out parameters can't map to EJB? > > > > Section 8.3.1 says "The signatures of the CORBA component operations are > mapped to signatures of EJB remote interface methods following the IDL to > Java mapping rules." > > As far as I can see, this only works if the IDL signature has no out or > inout parameters. The Holder classes for out and inout parameters cannot be > used in an EJB interface signature because they need not be Serializable, > which breaks the rules for an RMI compliant class. Even if they could the > EJB stubs and skeletons would not implement their special return value > behavior without modifications to the EJB spec. > > Someone please tell me I've missed something! > > Cheers, > Alan. > > > Alan Conway, Senior Engineer, IONA Technologies. > E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. > > > > Importance: Normal Subject: RE: IDL out parameters can't map to EJB? To: Alan Conway Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Mon, 30 Apr 2001 16:12:37 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/30/2001 04:12:48 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: *Nhd9TCp!!~*g!!,NEe9 So, we seem to be reaching agreement that we should follow option 1 to resolve this issue. If everyone agrees, here's some text we could use to include in the resolution, feel free to modify it as you see fit and let me know. 64.4 - first bullet, add Notice that "The home and remote interfaces of the enterprise bean's client view are defined as Java RMI interfaces. This allows the Container to implement the home and remote interfaces as distributed objects." One implication of this is that the signatures on methods on an EJB's remote interface can only include parameters with "in" semantics. That is, "out" and "inout" semantics for parameters is not allowed. As a consequence, the out and inout qualifiers for parameters in IDL interface method defintions are not included in the portion of Component IDL that can be mapped to an EJB definition. 64.4.1 Mapping the component definition - fourth bullet, add Only signatures whose parameters have an in qualifier are allowed. Signatures that include parameters with out or inout qualifiers shall be signalled as an error. -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 04/30/2001 08:13:55 AM To: , Ignacio Silva-Lepe/Watson/IBM@IBMUS cc: Subject: RE: IDL out parameters can't map to EJB? Here's my take on Ignacio's 3 options (which I agree are the only 3) plus answer to a question Tom raised about why we can't just make Holder's serializable: The options: 1 - Disallow mapping out/inout: This is probably the best first cut. Any later solution to support out/inouts will certainly be backwards compatible with this. It is only drastic in the sense that a potentially broad class of CORBA components (those designed by CORBA programmers who are used to out/inout) will not be accessible to EJB clients *as EJBs*. Don't forget that they are always available to Java code *as CORBA objects via a Java ORB*. There's no conflict with being bot an EJB and CORBA client, and the JVM includes a built-in ORB. 2 - Use a composite return: essentially this amounts to writing a variant on the IDL to Java mapping that maps out/inout's to automatically generated return values (generated by a variant IDL compiler.) It's perfectly feasible, but now may not be the right time to bring it into CCM. 3 - Use remote references for out/inout: I'm strongly against this one. Who hosts these "remote holders"? We don't want to force the client to host them, since we can't require the client to be capable of being a server. If we put them on the server, we must put in place a whole bunch of factory/lookup machinery so the client can create holders remotely and attendent garbage collection on the server to clean them up. Also the performance *is* an issue - multiple out parameters are often used *specifically* to avoid multiple remote client calls by providing multiple results in a single call. Finally Tom's question: "Alan's original complaint was that the holder classes need not be Serializable. Would it be easier to require that behavior? If we did, would or wouldn't that get around the difficulties? Would it need to be in the language map?" That does not solve the problem. Even if Holders were serializable, when used as EJB parameters they would still only be passed "in" from client to server. EJB does not provide any mechanism whereby the client-side content of the Holder would be updated after the call. Underlying all this is the asymmetry of the IDL/Java and Java/IDL mappings. Running and IDL compiler followed by rmic does not bring you even close to the original IDL (try it some time on your favourite IDL file - it's an instructive lesson on the usability of the Java to IDL mapping!) Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 May 2001 07:51:53 -0400 To: "Ignacio Silva-Lepe" From: Alan Conway Subject: RE: IDL out parameters can't map to EJB? Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: =k*!!;0Ne9]Old9Z-o!! That's a reasonable first cut. Any attempt to solve the problem later will certainly be backwards compatible with this - it'll simply be expanding the range of IDL that can be mapped to EJB without changing any existing mappings. At 04:12 PM 4/30/2001 -0400, Ignacio Silva-Lepe wrote: So, we seem to be reaching agreement that we should follow option 1 to resolve this issue. If everyone agrees, here's some text we could use to include in the resolution, feel free to modify it as you see fit and let me know. 64.4 - first bullet, add Notice that "The home and remote interfaces of the enterprise bean's client view are defined as Java RMI interfaces. This allows the Container to implement the home and remote interfaces as distributed objects." One implication of this is that the signatures on methods on an EJB's remote interface can only include parameters with "in" semantics. That is, "out" and "inout" semantics for parameters is not allowed. As a consequence, the out and inout qualifiers for parameters in IDL interface method defintions are not included in the portion of Component IDL that can be mapped to an EJB definition. 64.4.1 Mapping the component definition - fourth bullet, add Only signatures whose parameters have an in qualifier are allowed. Signatures that include parameters with out or inout qualifiers shall be signalled as an error. -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 04/30/2001 08:13:55 AM To: , Ignacio Silva-Lepe/Watson/IBM@IBMUS cc: Subject: RE: IDL out parameters can't map to EJB? Here's my take on Ignacio's 3 options (which I agree are the only 3) plus answer to a question Tom raised about why we can't just make Holder's serializable: The options: 1 - Disallow mapping out/inout: This is probably the best first cut. Any later solution to support out/inouts will certainly be backwards compatible with this. It is only drastic in the sense that a potentially broad class of CORBA components (those designed by CORBA programmers who are used to out/inout) will not be accessible to EJB clients *as EJBs*. Don't forget that they are always available to Java code *as CORBA objects via a Java ORB*. There's no conflict with being bot an EJB and CORBA client, and the JVM includes a built-in ORB. 2 - Use a composite return: essentially this amounts to writing a variant on the IDL to Java mapping that maps out/inout's to automatically generated return values (generated by a variant IDL compiler.) It's perfectly feasible, but now may not be the right time to bring it into CCM. 3 - Use remote references for out/inout: I'm strongly against this one. Who hosts these "remote holders"? We don't want to force the client to host them, since we can't require the client to be capable of being a server. If we put them on the server, we must put in place a whole bunch of factory/lookup machinery so the client can create holders remotely and attendent garbage collection on the server to clean them up. Also the performance *is* an issue - multiple out parameters are often used *specifically* to avoid multiple remote client calls by providing multiple results in a single call. Finally Tom's question: "Alan's original complaint was that the holder classes need not be Serializable. Would it be easier to require that behavior? If we did, would or wouldn't that get around the difficulties? Would it need to be in the language map?" That does not solve the problem. Even if Holders were serializable, when used as EJB parameters they would still only be passed "in" from client to server. EJB does not provide any mechanism whereby the client-side content of the Holder would be updated after the call. Underlying all this is the asymmetry of the IDL/Java and Java/IDL mappings. Running and IDL compiler followed by rmic does not bring you even close to the original IDL (try it some time on your favourite IDL file - it's an instructive lesson on the usability of the Java to IDL mapping!) Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Date: Wed, 02 May 2001 17:00:26 +0530 From: Jacob Organization: Internet Component Management Group X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alan Conway CC: Ignacio Silva-Lepe , components-ftf@omg.org Subject: Re: IDL out parameters can't map to EJB? References: <5.1.0.14.2.20010501075059.01e8ed30@mail.boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *:B!!&dN!!W[%e9:1;e9 Hello World, Sorry to interrupt your interesting conversation. Could there be a fourth option. This relies on the fact that there is a bridge between the CCM Component and the EJB Client, which any way has to be there. If the Holders cannot be simulated with RMI constrains, why not map the holder be a Remote Object residing in the EJB Client Side. All that the client( be is a EJB Bean itself, or a simple application ) will have to do is create these objects and send them as arguments to the bridge and the bridge receiving the inout and out arguments and internally making calls to them( remote objects simulating the holder ) within the context of the request, thus avoiding synchronization problems. This assumes that the remote object is created for each request. The possible disadvantages are runtime cost of an extra invocation to set the fields of the remote object, this is just one operation which takes as values the simple and complex data types. As for complex data types, you could have similar mappings as well. Say for example -> enum SeatKind { Window, Aisle, Middle }; ConfirmationNumber make_reservations ( in string passenger_name, in unsigned long frequesnt_flyer_number, inout SeatKind seat_kind ) raises( BadFrequentFlyerNumber, SeatNotAvailable ); SeatKind is mapped to a RMI RemoteInterface and the required implementation is mapped to an Impl class extending from PortableRemoteObject which contains a set operation which takes an integer. The implementation has to be generated completely. public interface SeatKind { int get(); void set( int value ); } final public class SeatKindImpl extends PortableRemoteObject implements SeatKind { int get(); void set( int value ); // blah... } I must admit, I am no expert in RMI, but CORBA is kind of comfortable. So if I am making some mistakes please clarify. So long, Jacob. Alan Conway wrote: > > That's a reasonable first cut. Any attempt to solve the problem later will > certainly be backwards compatible with this - it'll simply be expanding the > range of IDL that can be mapped to EJB without changing any existing mappings. > > At 04:12 PM 4/30/2001 -0400, Ignacio Silva-Lepe wrote: > > >So, we seem to be reaching agreement that we should follow option 1 to > >resolve this issue. If everyone agrees, here's some text we could use to > >include in the resolution, feel free to modify it as you see fit and let me > >know. > > > >64.4 - first bullet, add > > > >Notice that "The home and remote interfaces of the enterprise bean's > >client view are defined as Java RMI interfaces. This allows the > >Container to implement the home and remote interfaces as distributed > >objects." One implication of this is that the signatures on methods on > >an EJB's remote interface can only include parameters with "in" > >semantics. That is, "out" and "inout" semantics for parameters is not > >allowed. As a consequence, the out and inout qualifiers for parameters > >in IDL interface method defintions are not included in the portion of > >Component IDL that can be mapped to an EJB definition. > > > > > >64.4.1 > > > >Mapping the component definition - fourth bullet, add > > > >Only signatures whose parameters have an in qualifier are > >allowed. Signatures that include parameters with out or inout > >qualifiers shall be signalled as an error. > > > >-- Ignacio > > > >Ignacio Silva-Lepe > >IBM T. J. Watson Research Center > >P.O. Box 704 Yorktown Heights, NY 10598, USA > >INTERNET: isilval@us.ibm.com > >WWW: http://www.zgnews.com/silva > >Phone: (914) 784 7003 Fax: (914) 784 6040 > > > > > >Alan Conway on 04/30/2001 08:13:55 AM > > > >To: , Ignacio Silva-Lepe/Watson/IBM@IBMUS > >cc: > >Subject: RE: IDL out parameters can't map to EJB? > > > > > > > >Here's my take on Ignacio's 3 options (which I agree are the only 3) plus > >answer to a question Tom raised about why we can't just make Holder's > >serializable: > > > >The options: > > > >1 - Disallow mapping out/inout: This is probably the best first cut. Any > >later solution to support out/inouts will certainly be backwards compatible > >with this. It is only drastic in the sense that a potentially broad class > >of CORBA components (those designed by CORBA programmers who are used to > >out/inout) will not be accessible to EJB clients *as EJBs*. Don't forget > >that they are always available to Java code *as CORBA objects via a Java > >ORB*. There's no conflict with being bot an EJB and CORBA client, and the > >JVM includes a built-in ORB. > > > >2 - Use a composite return: essentially this amounts to writing a variant > >on the IDL to Java mapping that maps out/inout's to automatically generated > >return values (generated by a variant IDL compiler.) It's perfectly > >feasible, but now may not be the right time to bring it into CCM. > > > >3 - Use remote references for out/inout: I'm strongly against this one. Who > >hosts these "remote holders"? We don't want to force the client to host > >them, since we can't require the client to be capable of being a server. If > >we put them on the server, we must put in place a whole bunch of > >factory/lookup machinery so the client can create holders remotely and > >attendent garbage collection on the server to clean them up. Also the > >performance *is* an issue - multiple out parameters are often used > >*specifically* to avoid multiple remote client calls by providing multiple > >results in a single call. > > > >Finally Tom's question: > >"Alan's original complaint was that the holder classes need not be > >Serializable. Would it be easier to require that behavior? If we did, > >would or wouldn't that get around the difficulties? Would it need to be in > >the language map?" > > > >That does not solve the problem. Even if Holders were serializable, when > >used as EJB parameters they would still only be passed "in" from client to > >server. EJB does not provide any mechanism whereby the client-side content > >of the Holder would be updated after the call. Underlying all this is the > >asymmetry of the IDL/Java and Java/IDL mappings. Running and IDL compiler > >followed by rmic does not bring you even close to the original IDL (try it > >some time on your favourite IDL file - it's an instructive lesson on the > >usability of the Java to IDL mapping!) > > > >Cheers, > >Alan. > > > > > >Alan Conway, Senior Engineer, IONA Technologies. > >E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > >Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. > > Alan Conway, Senior Engineer, IONA Technologies. > E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Date: Wed, 02 May 2001 17:04:55 +0530 From: Jacob Organization: Internet Component Management Group X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alan Conway , Ignacio Silva-Lepe , components-ftf@omg.org Subject: Re: IDL out parameters can't map to EJB? References: <5.1.0.14.2.20010501075059.01e8ed30@mail.boston.amer.iona.com> <3AEFEFD2.9AAB8BD4@icmg.nu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: cg$!!+N=!!OF-!!3:Vd9 There needs to be some corrections... Jacob wrote: > > Hello World, > > Sorry to interrupt your interesting conversation. Could there be a > fourth option. This relies on the fact that there is a bridge between > the CCM Component and the EJB Client, which any way has to be there. > > If the Holders cannot be simulated with RMI constrains, why not map the > holder be a Remote Object residing in the EJB Client Side. All that the > client( be is a EJB Bean itself, or a simple application ) will have to > do is create these objects and send them as arguments to the bridge and > the bridge receiving the inout and out arguments and internally making > calls to them( remote objects simulating the holder ) within the context > of the request, thus avoiding synchronization problems. This assumes > that the remote object is created for each request. > > The possible disadvantages are runtime cost of an extra invocation to > set the fields of the remote object, this is just one operation which > takes as values the simple and complex data types. As for complex data > types, you could have similar mappings as well. > > Say for example -> > > enum SeatKind { Window, Aisle, Middle }; > > ConfirmationNumber make_reservations ( > in string passenger_name, > in unsigned long frequesnt_flyer_number, > inout SeatKind seat_kind ) > raises( BadFrequentFlyerNumber, > SeatNotAvailable ); > > SeatKind is mapped to a RMI RemoteInterface and the required > implementation is mapped to an Impl class extending from > PortableRemoteObject which contains a set operation which takes an > integer. The implementation has to be generated completely. > > public interface SeatKind { ^^^ extends RemoteObject and all the methods throw RemoteExceptions both in the interface and the implementation... > > int get(); > void set( int value ); > } > > final public class SeatKindImpl extends PortableRemoteObject implements > SeatKind { > > int get(); > void set( int value ); > > // blah... > } > > I must admit, I am no expert in RMI, but CORBA is kind of comfortable. > So if I am making some mistakes please clarify. > > So long, > > Jacob. > > Alan Conway wrote: > > > > That's a reasonable first cut. Any attempt to solve the problem later will > > certainly be backwards compatible with this - it'll simply be expanding the > > range of IDL that can be mapped to EJB without changing any existing mappings. > > > > At 04:12 PM 4/30/2001 -0400, Ignacio Silva-Lepe wrote: > > > > >So, we seem to be reaching agreement that we should follow option 1 to > > >resolve this issue. If everyone agrees, here's some text we could use to > > >include in the resolution, feel free to modify it as you see fit and let me > > >know. > > > > > >64.4 - first bullet, add > > > > > >Notice that "The home and remote interfaces of the enterprise bean's > > >client view are defined as Java RMI interfaces. This allows the > > >Container to implement the home and remote interfaces as distributed > > >objects." One implication of this is that the signatures on methods on > > >an EJB's remote interface can only include parameters with "in" > > >semantics. That is, "out" and "inout" semantics for parameters is not > > >allowed. As a consequence, the out and inout qualifiers for parameters > > >in IDL interface method defintions are not included in the portion of > > >Component IDL that can be mapped to an EJB definition. > > > > > > > > >64.4.1 > > > > > >Mapping the component definition - fourth bullet, add > > > > > >Only signatures whose parameters have an in qualifier are > > >allowed. Signatures that include parameters with out or inout > > >qualifiers shall be signalled as an error. > > > > > >-- Ignacio > > > > > >Ignacio Silva-Lepe > > >IBM T. J. Watson Research Center > > >P.O. Box 704 Yorktown Heights, NY 10598, USA > > >INTERNET: isilval@us.ibm.com > > >WWW: http://www.zgnews.com/silva > > >Phone: (914) 784 7003 Fax: (914) 784 6040 > > > > > > > > >Alan Conway on 04/30/2001 08:13:55 AM > > > > > >To: , Ignacio Silva-Lepe/Watson/IBM@IBMUS > > >cc: > > >Subject: RE: IDL out parameters can't map to EJB? > > > > > > > > > > > >Here's my take on Ignacio's 3 options (which I agree are the only 3) plus > > >answer to a question Tom raised about why we can't just make Holder's > > >serializable: > > > > > >The options: > > > > > >1 - Disallow mapping out/inout: This is probably the best first cut. Any > > >later solution to support out/inouts will certainly be backwards compatible > > >with this. It is only drastic in the sense that a potentially broad class > > >of CORBA components (those designed by CORBA programmers who are used to > > >out/inout) will not be accessible to EJB clients *as EJBs*. Don't forget > > >that they are always available to Java code *as CORBA objects via a Java > > >ORB*. There's no conflict with being bot an EJB and CORBA client, and the > > >JVM includes a built-in ORB. > > > > > >2 - Use a composite return: essentially this amounts to writing a variant > > >on the IDL to Java mapping that maps out/inout's to automatically generated > > >return values (generated by a variant IDL compiler.) It's perfectly > > >feasible, but now may not be the right time to bring it into CCM. > > > > > >3 - Use remote references for out/inout: I'm strongly against this one. Who > > >hosts these "remote holders"? We don't want to force the client to host > > >them, since we can't require the client to be capable of being a server. If > > >we put them on the server, we must put in place a whole bunch of > > >factory/lookup machinery so the client can create holders remotely and > > >attendent garbage collection on the server to clean them up. Also the > > >performance *is* an issue - multiple out parameters are often used > > >*specifically* to avoid multiple remote client calls by providing multiple > > >results in a single call. > > > > > >Finally Tom's question: > > >"Alan's original complaint was that the holder classes need not be > > >Serializable. Would it be easier to require that behavior? If we did, > > >would or wouldn't that get around the difficulties? Would it need to be in > > >the language map?" > > > > > >That does not solve the problem. Even if Holders were serializable, when > > >used as EJB parameters they would still only be passed "in" from client to > > >server. EJB does not provide any mechanism whereby the client-side content > > >of the Holder would be updated after the call. Underlying all this is the > > >asymmetry of the IDL/Java and Java/IDL mappings. Running and IDL compiler > > >followed by rmic does not bring you even close to the original IDL (try it > > >some time on your favourite IDL file - it's an instructive lesson on the > > >usability of the Java to IDL mapping!) > > > > > >Cheers, > > >Alan. > > > > > > > > >Alan Conway, Senior Engineer, IONA Technologies. > > >E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > > >Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. > > > > Alan Conway, Senior Engineer, IONA Technologies. > > E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > > Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 02 May 2001 08:19:44 -0400 To: Jacob , Ignacio Silva-Lepe , components-ftf@omg.org From: Alan Conway Subject: Re: IDL out parameters can't map to EJB? In-Reply-To: <3AEFF0DF.4052BD8D@icmg.nu> References: <5.1.0.14.2.20010501075059.01e8ed30@mail.boston.amer.iona.com> <3AEFEFD2.9AAB8BD4@icmg.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 9CE!!Nk%e9Nm2!!Q^A!! This option was suggested in Silva's original list. I've got several concerns: Client must also be a server - not safe to assume that all EJB clients are capable of being servers, or that EJB client programmers are willing to code servers. We could generate code, but we're talking about introducing a whole new client-side server framework into the EJB model which is unlikely to be well received. Client programmig complexity - How does the client know when the server is done updating it's holder objects? The client needs a way to block or poll for the results to be updated after the call to the EJB (remember we have *no* scope to change what happens inside EJB stubs) This is yet more non-EJB machinery to force on the EJB client programmer. Performance - a typical use for multiple out parameters is exactly to avoid multiple network round-trips to retrieve several data values. By introducing this under the covers we will create much unhapiness. I think if we do address this, the best way is with generated return values (I admit it's a little ugly, but I think it's the only solution that will work.) However I also think it is an issue that could/should be left till the spec is out there and we have some idea of how important it really is. At 05:04 PM 5/2/2001 +0530, Jacob wrote: There needs to be some corrections... Jacob wrote: > > Hello World, > > Sorry to interrupt your interesting conversation. Could there be a > fourth option. This relies on the fact that there is a bridge between > the CCM Component and the EJB Client, which any way has to be there. > > If the Holders cannot be simulated with RMI constrains, why not map the > holder be a Remote Object residing in the EJB Client Side. All that the > client( be is a EJB Bean itself, or a simple application ) will have to > do is create these objects and send them as arguments to the bridge and > the bridge receiving the inout and out arguments and internally making > calls to them( remote objects simulating the holder ) within the context > of the request, thus avoiding synchronization problems. This assumes > that the remote object is created for each request. > > The possible disadvantages are runtime cost of an extra invocation to > set the fields of the remote object, this is just one operation which > takes as values the simple and complex data types. As for complex data > types, you could have similar mappings as well. > > Say for example -> > > enum SeatKind { Window, Aisle, Middle }; > > ConfirmationNumber make_reservations ( > in string passenger_name, > in unsigned long frequesnt_flyer_number, > inout SeatKind seat_kind ) > raises( BadFrequentFlyerNumber, > SeatNotAvailable ); > > SeatKind is mapped to a RMI RemoteInterface and the required > implementation is mapped to an Impl class extending from > PortableRemoteObject which contains a set operation which takes an > integer. The implementation has to be generated completely. > > public interface SeatKind { ^^^ extends RemoteObject and all the methods throw RemoteExceptions both in the interface and the implementation... > > int get(); > void set( int value ); > } > > final public class SeatKindImpl extends PortableRemoteObject implements > SeatKind { > > int get(); > void set( int value ); > > // blah... > } > > I must admit, I am no expert in RMI, but CORBA is kind of comfortable. > So if I am making some mistakes please clarify. > > So long, > > Jacob. > > Alan Conway wrote: > > > > That's a reasonable first cut. Any attempt to solve the problem later will > > certainly be backwards compatible with this - it'll simply be expanding the > > range of IDL that can be mapped to EJB without changing any existing mappings. > > > > At 04:12 PM 4/30/2001 -0400, Ignacio Silva-Lepe wrote: > > > > >So, we seem to be reaching agreement that we should follow option 1 to > > >resolve this issue. If everyone agrees, here's some text we could use to > > >include in the resolution, feel free to modify it as you see fit and let me > > >know. > > > > > >64.4 - first bullet, add > > > > > >Notice that "The home and remote interfaces of the enterprise bean's > > >client view are defined as Java RMI interfaces. This allows the > > >Container to implement the home and remote interfaces as distributed > > >objects." One implication of this is that the signatures on methods on > > >an EJB's remote interface can only include parameters with "in" > > >semantics. That is, "out" and "inout" semantics for parameters is not > > >allowed. As a consequence, the out and inout qualifiers for parameters > > >in IDL interface method defintions are not included in the portion of > > >Component IDL that can be mapped to an EJB definition. > > > > > > > > >64.4.1 > > > > > >Mapping the component definition - fourth bullet, add > > > > > >Only signatures whose parameters have an in qualifier are > > >allowed. Signatures that include parameters with out or inout > > >qualifiers shall be signalled as an error. > > > > > >-- Ignacio > > > > > >Ignacio Silva-Lepe > > >IBM T. J. Watson Research Center > > >P.O. Box 704 Yorktown Heights, NY 10598, USA > > >INTERNET: isilval@us.ibm.com > > >WWW: http://www.zgnews.com/silva > > >Phone: (914) 784 7003 Fax: (914) 784 6040 > > > > > > > > >Alan Conway on 04/30/2001 08:13:55 AM > > > > > >To: , Ignacio Silva-Lepe/Watson/IBM@IBMUS > > >cc: > > >Subject: RE: IDL out parameters can't map to EJB? > > > > > > > > > > > >Here's my take on Ignacio's 3 options (which I agree are the only 3) plus > > >answer to a question Tom raised about why we can't just make Holder's > > >serializable: > > > > > >The options: > > > > > >1 - Disallow mapping out/inout: This is probably the best first cut. Any > > >later solution to support out/inouts will certainly be backwards compatible > > >with this. It is only drastic in the sense that a potentially broad class > > >of CORBA components (those designed by CORBA programmers who are used to > > >out/inout) will not be accessible to EJB clients *as EJBs*. Don't forget > > >that they are always available to Java code *as CORBA objects via a Java > > >ORB*. There's no conflict with being bot an EJB and CORBA client, and the > > >JVM includes a built-in ORB. > > > > > >2 - Use a composite return: essentially this amounts to writing a variant > > >on the IDL to Java mapping that maps out/inout's to automatically generated > > >return values (generated by a variant IDL compiler.) It's perfectly > > >feasible, but now may not be the right time to bring it into CCM. > > > > > >3 - Use remote references for out/inout: I'm strongly against this one. Who > > >hosts these "remote holders"? We don't want to force the client to host > > >them, since we can't require the client to be capable of being a server. If > > >we put them on the server, we must put in place a whole bunch of > > >factory/lookup machinery so the client can create holders remotely and > > >attendent garbage collection on the server to clean them up. Also the > > >performance *is* an issue - multiple out parameters are often used > > >*specifically* to avoid multiple remote client calls by providing multiple > > >results in a single call. > > > > > >Finally Tom's question: > > >"Alan's original complaint was that the holder classes need not be > > >Serializable. Would it be easier to require that behavior? If we did, > > >would or wouldn't that get around the difficulties? Would it need to be in > > >the language map?" > > > > > >That does not solve the problem. Even if Holders were serializable, when > > >used as EJB parameters they would still only be passed "in" from client to > > >server. EJB does not provide any mechanism whereby the client-side content > > >of the Holder would be updated after the call. Underlying all this is the > > >asymmetry of the IDL/Java and Java/IDL mappings. Running and IDL compiler > > >followed by rmic does not bring you even close to the original IDL (try it > > >some time on your favourite IDL file - it's an instructive lesson on the > > >usability of the Java to IDL mapping!) > > > > > >Cheers, > > >Alan. > > > > > > > > >Alan Conway, Senior Engineer, IONA Technologies. > > >E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > > >Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. > > > > Alan Conway, Senior Engineer, IONA Technologies. > > E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > > Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Date: Wed, 02 May 2001 20:00:57 +0530 From: Jacob Organization: Internet Component Management Group X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alan Conway CC: Ignacio Silva-Lepe , components-ftf@omg.org Subject: Re: IDL out parameters can't map to EJB? References: <5.1.0.14.2.20010501075059.01e8ed30@mail.boston.amer.iona.com> <3AEFEFD2.9AAB8BD4@icmg.nu> <5.1.0.14.2.20010502080911.023ef3e8@mail.boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b2$e9708!!K1a!!J![!! Hello World, Alan Conway wrote: > > This option was suggested in Silva's original list. I've got several concerns: Oops, I missed it totally. > > Client must also be a server - not safe to assume that all EJB clients are > capable of being servers, or that EJB client programmers are willing to > code servers. We could generate code, but we're talking about introducing a > whole new client-side server framework into the EJB model which is unlikely > to be well received. You are right that it would not be received properly. But inout and out are indeed helpful and eventually might make it into the EJB Specs which would be a better solution. Still, the idea of leaving out inout and out semantics seems to be too restrictive, as it would lead to making not being able to adopt a few components, well the number would be pretty minimal if the chain is small. I guess currently we have no options. Sorry for the repetition of opinions, I shall be careful next time... So long, Jacob. > > Client programmig complexity - How does the client know when the > server is > done updating it's holder objects? The client needs a way to block > or poll > for the results to be updated after the call to the EJB (remember we > have > *no* scope to change what happens inside EJB stubs) This is yet more > non-EJB machinery to force on the EJB client programmer. > > Performance - a typical use for multiple out parameters is exactly > to avoid > multiple network round-trips to retrieve several data values. By > introducing this under the covers we will create much unhapiness. > > I think if we do address this, the best way is with generated return > values > (I admit it's a little ugly, but I think it's the only solution that > will > work.) However I also think it is an issue that could/should be left > till > the spec is out there and we have some idea of how important it > really is. > > At 05:04 PM 5/2/2001 +0530, Jacob wrote: > >There needs to be some corrections... > > > >Jacob wrote: > > > > > > Hello World, > > > > > > Sorry to interrupt your interesting conversation. Could > there be a > > > fourth option. This relies on the fact that there is a bridge > between > > > the CCM Component and the EJB Client, which any way has to be > there. > > > > > > If the Holders cannot be simulated with RMI constrains, > why not > > map the > > > holder be a Remote Object residing in the EJB Client Side. All > that the > > > client( be is a EJB Bean itself, or a simple application ) will > have to > > > do is create these objects and send them as arguments to the > bridge and > > > the bridge receiving the inout and out arguments and internally > making > > > calls to them( remote objects simulating the holder ) within the > context > > > of the request, thus avoiding synchronization problems. This > assumes > > > that the remote object is created for each request. > > > > > > The possible disadvantages are runtime cost of an extra > > invocation to > > > set the fields of the remote object, this is just one operation > which > > > takes as values the simple and complex data types. As for > complex data > > > types, you could have similar mappings as well. > > > > > > Say for example -> > > > > > > enum SeatKind { Window, Aisle, Middle }; > > > > > > ConfirmationNumber make_reservations ( > > > in string passenger_name, > > > in unsigned long frequesnt_flyer_number, > > > inout SeatKind seat_kind ) > > > raises( BadFrequentFlyerNumber, > > > SeatNotAvailable ); > > > > > > SeatKind is mapped to a RMI RemoteInterface and the > required > > > implementation is mapped to an Impl class extending from > > > PortableRemoteObject which contains a set operation which takes > an > > > integer. The implementation has to be generated completely. > > > > > > public interface SeatKind { > > ^^^ > > extends RemoteObject > >and all the methods throw RemoteExceptions both in the interface > and the > >implementation... > > > > > > int get(); > > > void set( int value ); > > > } > > > > > > final public class SeatKindImpl extends PortableRemoteObject > implements > > > SeatKind { > > > > > > int get(); > > > void set( int value ); > > > > > > // blah... > > > } > > > > > > I must admit, I am no expert in RMI, but CORBA is kind > of > > comfortable. > > > So if I am making some mistakes please clarify. > > > > > > So long, > > > > > > Jacob. > > > > > > Alan Conway wrote: > > > > > > > > That's a reasonable first cut. Any attempt to solve the > problem later > > will > > > > certainly be backwards compatible with this - it'll simply be > > expanding the > > > > range of IDL that can be mapped to EJB without changing any > existing > > mappings. > > > > > > > > At 04:12 PM 4/30/2001 -0400, Ignacio Silva-Lepe wrote: > > > > > > > > >So, we seem to be reaching agreement that we should follow > option 1 to > > > > >resolve this issue. If everyone agrees, here's some text we > could use to > > > > >include in the resolution, feel free to modify it as you see > fit and > > let me > > > > >know. > > > > > > > > > >64.4 - first bullet, add > > > > > > > > > >Notice that "The home and remote interfaces of the enterprise > bean's > > > > >client view are defined as Java RMI interfaces. This allows > the > > > > >Container to implement the home and remote interfaces as > distributed > > > > >objects." One implication of this is that the signatures on > methods on > > > > >an EJB's remote interface can only include parameters with > "in" > > > > >semantics. That is, "out" and "inout" semantics for > parameters is not > > > > >allowed. As a consequence, the out and inout qualifiers for > parameters > > > > >in IDL interface method defintions are not included in the > portion of > > > > >Component IDL that can be mapped to an EJB definition. > > > > > > > > > > > > > > >64.4.1 > > > > > > > > > >Mapping the component definition - fourth bullet, add > > > > > > > > > >Only signatures whose parameters have an in qualifier are > > > > >allowed. Signatures that include parameters with out or inout > > > > >qualifiers shall be signalled as an error. > > > > > > > > > >-- Ignacio > > > > > > > > > >Ignacio Silva-Lepe > > > > >IBM T. J. Watson Research Center > > > > >P.O. Box 704 Yorktown Heights, NY 10598, USA > > > > >INTERNET: isilval@us.ibm.com > > > > >WWW: http://www.zgnews.com/silva > > > > >Phone: (914) 784 7003 Fax: (914) 784 6040 > > > > > > > > > > > > > > >Alan Conway on 04/30/2001 08:13:55 AM > > > > > > > > > >To: , Ignacio > Silva-Lepe/Watson/IBM@IBMUS > > > > >cc: > > > > >Subject: RE: IDL out parameters can't map to EJB? > > > > > > > > > > > > > > > > > > > >Here's my take on Ignacio's 3 options (which I agree are the > only 3) > > plus > > > > >answer to a question Tom raised about why we can't just make > Holder's > > > > >serializable: > > > > > > > > > >The options: > > > > > > > > > >1 - Disallow mapping out/inout: This is probably the best > first cut. Any > > > > >later solution to support out/inouts will certainly be > backwards > > compatible > > > > >with this. It is only drastic in the sense that a potentially > broad > > class > > > > >of CORBA components (those designed by CORBA programmers who > are used to > > > > >out/inout) will not be accessible to EJB clients *as > EJBs*. Don't forget > > > > >that they are always available to Java code *as CORBA objects > via a Java > > > > >ORB*. There's no conflict with being bot an EJB and CORBA > client, > > and the > > > > >JVM includes a built-in ORB. > > > > > > > > > >2 - Use a composite return: essentially this amounts to > writing a > > variant > > > > >on the IDL to Java mapping that maps out/inout's to > automatically > > generated > > > > >return values (generated by a variant IDL compiler.) It's > perfectly > > > > >feasible, but now may not be the right time to bring it into > CCM. > > > > > > > > > >3 - Use remote references for out/inout: I'm strongly against > this > > one. Who > > > > >hosts these "remote holders"? We don't want to force the > client to host > > > > >them, since we can't require the client to be capable of > being a > > server. If > > > > >we put them on the server, we must put in place a whole bunch > of > > > > >factory/lookup machinery so the client can create holders > remotely and > > > > >attendent garbage collection on the server to clean them > up. Also the > > > > >performance *is* an issue - multiple out parameters are often > used > > > > >*specifically* to avoid multiple remote client calls by > providing > > multiple > > > > >results in a single call. > > > > > > > > > >Finally Tom's question: > > > > >"Alan's original complaint was that the holder classes need > not be > > > > >Serializable. Would it be easier to require that behavior? > If we did, > > > > >would or wouldn't that get around the difficulties? Would it > need > > to be in > > > > >the language map?" > > > > > > > > > >That does not solve the problem. Even if Holders were > serializable, when > > > > >used as EJB parameters they would still only be passed "in" > from > > client to > > > > >server. EJB does not provide any mechanism whereby the > client-side > > content > > > > >of the Holder would be updated after the call. Underlying all > this > > is the > > > > >asymmetry of the IDL/Java and Java/IDL mappings. Running and > IDL > > compiler > > > > >followed by rmic does not bring you even close to the > original IDL > > (try it > > > > >some time on your favourite IDL file - it's an instructive > lesson on the > > > > >usability of the Java to IDL mapping!) > > > > > > > > > >Cheers, > > > > >Alan. > > > > > > > > > > > > > > >Alan Conway, Senior Engineer, IONA Technologies. > > > > >E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > > > > >Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. > > > > > > > > Alan Conway, Senior Engineer, IONA Technologies. > > > > E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > > > > Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. > > Alan Conway, Senior Engineer, IONA Technologies. > E-mail: alan.conway@iona.com Tel: +1(819)843-5859 > Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: RE: IDL out parameters can't map to EJB? To: Alan Conway Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Thu, 3 May 2001 11:16:49 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.7 |March 21, 2001) at 05/03/2001 11:17:05 AM MIME-Version: 1.0 Content-Disposition: inline Content-Type: multipart/mixed; Boundary="0__=85256A410053A2118f9e8a93df938690918c85256A410053A211" X-UIDL: `Do!!_Y*!!BM:e9"TL!! Ok, here's a proposed resolution and revised text for issue 4269. If anyone has any objections please speak your mind asap. I intend to include this resolution in the next vote provided there are no objections. -- Ignacio (See attached file: components-ftf - Issue 4269.html) Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 05/01/2001 07:51:53 AM To: Ignacio Silva-Lepe/Watson/IBM@IBMUS cc: Subject: RE: IDL out parameters can't map to EJB? That's a reasonable first cut. Any attempt to solve the problem later will certainly be backwards compatible with this - it'll simply be expanding the range of IDL that can be mapped to EJB without changing any existing mappings. At 04:12 PM 4/30/2001 -0400, Ignacio Silva-Lepe wrote: >So, we seem to be reaching agreement that we should follow option 1 to >resolve this issue. If everyone agrees, here's some text we could use to >include in the resolution, feel free to modify it as you see fit and let me >know. > >64.4 - first bullet, add > >Notice that "The home and remote interfaces of the enterprise bean's >client view are defined as Java RMI interfaces. This allows the >Container to implement the home and remote interfaces as distributed >objects." One implication of this is that the signatures on methods on >an EJB's remote interface can only include parameters with "in" >semantics. That is, "out" and "inout" semantics for parameters is not >allowed. As a consequence, the out and inout qualifiers for parameters >in IDL interface method defintions are not included in the portion of >Component IDL that can be mapped to an EJB definition. > > >64.4.1 > >Mapping the component definition - fourth bullet, add > >Only signatures whose parameters have an in qualifier are >allowed. Signatures that include parameters with out or inout >qualifiers shall be signalled as an error. > >-- Ignacio > >Ignacio Silva-Lepe >IBM T. J. Watson Research Center >P.O. Box 704 Yorktown Heights, NY 10598, USA >INTERNET: isilval@us.ibm.com >WWW: http://www.zgnews.com/silva >Phone: (914) 784 7003 Fax: (914) 784 6040 > > >Alan Conway on 04/30/2001 08:13:55 AM > >To: , Ignacio Silva-Lepe/Watson/IBM@IBMUS >cc: >Subject: RE: IDL out parameters can't map to EJB? > > > >Here's my take on Ignacio's 3 options (which I agree are the only 3) plus >answer to a question Tom raised about why we can't just make Holder's >serializable: > >The options: > >1 - Disallow mapping out/inout: This is probably the best first cut. Any >later solution to support out/inouts will certainly be backwards compatible >with this. It is only drastic in the sense that a potentially broad class >of CORBA components (those designed by CORBA programmers who are used to >out/inout) will not be accessible to EJB clients *as EJBs*. Don't forget >that they are always available to Java code *as CORBA objects via a Java >ORB*. There's no conflict with being bot an EJB and CORBA client, and the >JVM includes a built-in ORB. > >2 - Use a composite return: essentially this amounts to writing a variant >on the IDL to Java mapping that maps out/inout's to automatically generated >return values (generated by a variant IDL compiler.) It's perfectly >feasible, but now may not be the right time to bring it into CCM. > >3 - Use remote references for out/inout: I'm strongly against this one. Who >hosts these "remote holders"? We don't want to force the client to host >them, since we can't require the client to be capable of being a server. If >we put them on the server, we must put in place a whole bunch of >factory/lookup machinery so the client can create holders remotely and >attendent garbage collection on the server to clean them up. Also the >performance *is* an issue - multiple out parameters are often used >*specifically* to avoid multiple remote client calls by providing multiple >results in a single call. > >Finally Tom's question: >"Alan's original complaint was that the holder classes need not be >Serializable. Would it be easier to require that behavior? If we did, >would or wouldn't that get around the difficulties? Would it need to be in >the language map?" > >That does not solve the problem. Even if Holders were serializable, when >used as EJB parameters they would still only be passed "in" from client to >server. EJB does not provide any mechanism whereby the client-side content >of the Holder would be updated after the call. Underlying all this is the >asymmetry of the IDL/Java and Java/IDL mappings. Running and IDL compiler >followed by rmic does not bring you even close to the original IDL (try it >some time on your favourite IDL file - it's an instructive lesson on the >usability of the Java to IDL mapping!) > >Cheers, >Alan. > > >Alan Conway, Senior Engineer, IONA Technologies. >E-mail: alan.conway@iona.com Tel: +1(819)843-5859 >Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. [] components-ftf - Issue 4269.htm X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 May 2001 14:20:46 -0400 To: "Ignacio Silva-Lepe" From: Alan Conway Subject: RE: IDL out parameters can't map to EJB? Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: mo~e9LXGe9"had9%P8e9 To reduce the shock-factor of this statement I suggest we add the following note to the text: "Note however that a Java client does not have to use an EJB view in order to access a CCM. Any Java client can access a CCM directly via its IDL interface using a standard Java ORB, such as the one built in to the JDK. This provides full access to all aspects of the CCM. Since the EJB view is derived using the IDL to Java mapping rules, the Java IDL interface is identical to the EJB view for all business operations. The only differences are in the operations mentioned in [##reference to the table of re-mapped functions for the EJB view] have slightly different names and signatures." At 11:16 AM 5/3/2001 -0400, Ignacio Silva-Lepe wrote: Ok, here's a proposed resolution and revised text for issue 4269. If anyone has any objections please speak your mind asap. I intend to include this resolution in the next vote provided there are no objections. -- Ignacio (See attached file: components-ftf - Issue 4269.html) Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 05/01/2001 07:51:53 AM To: Ignacio Silva-Lepe/Watson/IBM@IBMUS cc: Subject: RE: IDL out parameters can't map to EJB? That's a reasonable first cut. Any attempt to solve the problem later will certainly be backwards compatible with this - it'll simply be expanding the range of IDL that can be mapped to EJB without changing any existing mappings. At 04:12 PM 4/30/2001 -0400, Ignacio Silva-Lepe wrote: >So, we seem to be reaching agreement that we should follow option 1 to >resolve this issue. If everyone agrees, here's some text we could use to >include in the resolution, feel free to modify it as you see fit and let me >know. > >64.4 - first bullet, add > >Notice that "The home and remote interfaces of the enterprise bean's >client view are defined as Java RMI interfaces. This allows the >Container to implement the home and remote interfaces as distributed >objects." One implication of this is that the signatures on methods on >an EJB's remote interface can only include parameters with "in" >semantics. That is, "out" and "inout" semantics for parameters is not >allowed. As a consequence, the out and inout qualifiers for parameters >in IDL interface method defintions are not included in the portion of >Component IDL that can be mapped to an EJB definition. > > >64.4.1 > >Mapping the component definition - fourth bullet, add > >Only signatures whose parameters have an in qualifier are >allowed. Signatures that include parameters with out or inout >qualifiers shall be signalled as an error. > >-- Ignacio > >Ignacio Silva-Lepe >IBM T. J. Watson Research Center >P.O. Box 704 Yorktown Heights, NY 10598, USA >INTERNET: isilval@us.ibm.com >WWW: http://www.zgnews.com/silva >Phone: (914) 784 7003 Fax: (914) 784 6040 > > >Alan Conway on 04/30/2001 08:13:55 AM > >To: , Ignacio Silva-Lepe/Watson/IBM@IBMUS >cc: >Subject: RE: IDL out parameters can't map to EJB? > > > >Here's my take on Ignacio's 3 options (which I agree are the only 3) plus >answer to a question Tom raised about why we can't just make Holder's >serializable: > >The options: > >1 - Disallow mapping out/inout: This is probably the best first cut. Any >later solution to support out/inouts will certainly be backwards compatible >with this. It is only drastic in the sense that a potentially broad class >of CORBA components (those designed by CORBA programmers who are used to >out/inout) will not be accessible to EJB clients *as EJBs*. Don't forget >that they are always available to Java code *as CORBA objects via a Java >ORB*. There's no conflict with being bot an EJB and CORBA client, and the >JVM includes a built-in ORB. > >2 - Use a composite return: essentially this amounts to writing a variant >on the IDL to Java mapping that maps out/inout's to automatically generated >return values (generated by a variant IDL compiler.) It's perfectly >feasible, but now may not be the right time to bring it into CCM. > >3 - Use remote references for out/inout: I'm strongly against this one. Who >hosts these "remote holders"? We don't want to force the client to host >them, since we can't require the client to be capable of being a server. If >we put them on the server, we must put in place a whole bunch of >factory/lookup machinery so the client can create holders remotely and >attendent garbage collection on the server to clean them up. Also the >performance *is* an issue - multiple out parameters are often used >*specifically* to avoid multiple remote client calls by providing multiple >results in a single call. > >Finally Tom's question: >"Alan's original complaint was that the holder classes need not be >Serializable. Would it be easier to require that behavior? If we did, >would or wouldn't that get around the difficulties? Would it need to be in >the language map?" > >That does not solve the problem. Even if Holders were serializable, when >used as EJB parameters they would still only be passed "in" from client to >server. EJB does not provide any mechanism whereby the client-side content >of the Holder would be updated after the call. Underlying all this is the >asymmetry of the IDL/Java and Java/IDL mappings. Running and IDL compiler >followed by rmic does not bring you even close to the original IDL (try it >some time on your favourite IDL file - it's an instructive lesson on the >usability of the Java to IDL mapping!) > >Cheers, >Alan. > > >Alan Conway, Senior Engineer, IONA Technologies. >E-mail: alan.conway@iona.com Tel: +1(819)843-5859 >Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada.