Issue 648: Server request and oneway operations (port-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Given it"s optional to call set_result operation of CORBA::ServerRequest, an ORB can"t determine whether operation supported is oneway or not Resolution: closed with no action Revised Text: Actions taken: August 4, 1997: received issue July 30, 1998: closed issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Return-Path: From: T.C.NASH@UK03.wins.icl.co.uk X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 4 Aug 1997 19:55:42 +0100 X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 4 Aug 1997 19:55:42 +0100 X400-Received: by mta hls03 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 4 Aug 1997 17:52:51 +0100 X400-Received: by mta MAN05C1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 4 Aug 1997 17:47:18 +0100 X400-Received: by mta man0507 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 4 Aug 1997 17:45:56 +0100 X400-Received: by mta " /UK03 /:POSTROOM" in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 4 Aug 1997 18:46:11 +0100 X400-Received: by /PRMD=ICL/ADMD=GOLD 400/C=GB/; converted (ia5-text); Relayed; Mon, 4 Aug 1997 18:46:11 +0100 Date: Mon, 4 Aug 1997 18:46:11 +0100 X400-Originator: T.C.NASH@UK03.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;UK03 TCNASH TCN-D-3874] X400-Content-Type: P2-1984 (2) Content-Identifier: 2 /Issue: Server Alternate-Recipient: Allowed To: * Start of list OMG-ISSUES:;@UK03.wins.icl.co.uk, issues@omg.org, * End of list OMG-ISSUES:;@UK03.wins.icl.co.uk Cc: R.HERBERT@UK03.wins.icl.co.uk, G.A.JONES@MAN0524.wins.icl.co.uk Subject: Issue: Server Request and oneway operations Issue: Server Request and oneway operations Regarding formal/96-08-04 (Corba 2.0) 5 (Dynamic Skeleton Interface) orbos/97-05-15 (Portability) 2.5.2 (ServerRequest pseudo-Object) Given that it is optional to call the set_result operation of CORBA::ServerRequest, an ORB cannot determine whether the operation supported is "oneway" or not, i.e. whether it is to send a reply consisting solely of CORBO_NO_EXCEPTION or no reply at all. I appreciate that the semantics of "oneway" are such that a reply is optional rather than forbidden, but since an ORB can choose to omit the reply for a statically compiled operation it seems reasonable for it to be able to do so when the implementation is dynamic. It may be for example that "oneway" is chosen for performance reasons, in which case the generation of replies by a bridge is certainly wrong. Trevor Nash ICL Return-Path: From: T.C.NASH@UK03.wins.icl.co.uk X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 5 Aug 1997 10:52:12 +0100 X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 5 Aug 1997 10:51:52 +0100 X400-Received: by mta hls03 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 5 Aug 1997 10:54:33 +0100 X400-Received: by mta MAN05C1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 5 Aug 1997 10:48:51 +0100 X400-Received: by mta man0507 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 5 Aug 1997 10:47:34 +0100 X400-Received: by mta " /UK03 /:POSTROOM" in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 5 Aug 1997 11:47:49 +0100 X400-Received: by /PRMD=ICL/ADMD=GOLD 400/C=GB/; converted (ia5-text); Relayed; Tue, 5 Aug 1997 10:47:34 +0100 Date: Tue, 5 Aug 1997 10:47:34 +0100 X400-Originator: T.C.NASH@UK03.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;UK03 TCNASH TCN-D-3875] X400-Content-Type: P2-1984 (2) Content-Identifier: 8 /Re:Issue: Ser Alternate-Recipient: Allowed To: * Start of list OMG-ISSUES:;@UK03.wins.icl.co.uk, issues@omg.org, * End of list OMG-ISSUES:;@UK03.wins.icl.co.uk Cc: R.HERBERT@UK03.wins.icl.co.uk, G.A.JONES@MAN0524.wins.icl.co.uk Subject: Re:Issue: Server Request and oneway operations sergior(a)ovdm38.cnd.hp.com wrote: >T.C.NASH@UK03.wins.icl.co.uk wrote: >> >> Issue: Server Request and oneway operations >> Regarding >> formal/96-08-04 (Corba 2.0) 5 (Dynamic Skeleton Interface) >> orbos/97-05-15 (Portability) 2.5.2 (ServerRequest pseudo-Object) >> >> Given that it is optional to call the set_result operation of >> CORBA::ServerRequest, an ORB cannot determine whether the operation >> supported is "oneway" or not, i.e. whether it is to send a reply >> consisting solely of CORBO_NO_EXCEPTION or no reply at all. >> >> I appreciate that the semantics of "oneway" are such that a reply >> is optional rather than forbidden, but since an ORB can choose to >> omit the reply for a statically compiled operation it seems >> reasonable for it to be able to do so when the implementation is >> dynamic. It may be for example that "oneway" is chosen for >> performance reasons, in which case the generation of replies by >> a bridge is certainly wrong. >> >> Trevor Nash >> ICL > >I am afraid this has nothing to do with your question, but >I think the request message should contain the information >about whether the operation is oneway (i.e. whether a >response is expected) as it does in IIOP. I had looked in IIOP for exactly that, but I'm afraid I missed it - thanks. A few more entries in the index for 'oneway' would be useful! Are there any ORBs which do not put this information in their proprietary protocols? If not then there is no problem - if we assume a dynamic implementation knows the oneway property from the interface repository or whatever. Trevor Nash ICL Return-Path: Date: Tue, 30 Jun 1998 07:22:12 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: port-rtf@omg.org Subject: Re: Suggestions for issues 614, 648, 676, 744, 958, 964, 1314: no action X-Sun-Charset: US-ASCII > > I suggest we close the following issues with no action. > > Some enhancement issues were discussed and said to be > impractical. Some met with opposition and will clearly never be > accepted. Some answers are my own replies for enhancement > requests that seem impractical. I think this shoots down a > suggestion from almost everybody who's made more than one. I > apologize if I've missed anybody. :-) > > Let me know if you disagree. We can take an email vote next week. > > Dan I vote yes to the proposed resolutions and also agree with Jeff's sugestion regarding inclusion of the create_policy proposal in this RTF. -- Juanjo > > Issue 614: Threading and shutdown interfaces > Nature: Enhancement > Summary: The ORB interface for shutdown is incomplete and > underspecified. work_pending and perform_work as > specified are inadequate. See suggested changes > in communicating archive file. > Resolution: Closed with no action. It's not clear that the > enhancements are useful. > > Issue 648: Server request and oneway operations > Nature: Enhancement > Summary: Given it's optional to call set_result operation of > CORBA::ServerRequest, an ORB can't determine whether > operation supported is oneway or not. > Resolution: Closed with no action. The information is available > in GIOP. > > Issue 676: Use of root POA to implement root POA and POAMAnager > impossible > Nature: Error > Summary: It's impossible to use root POA to implement the root > POA and its POAManager, due to a deadlock because > POAManager starts in the HOLDING state. > Resolution: Closed with no action. The POA and POAManager are > implemented by the ORB so they must be special-cased > already. > > Issue 744: get_servant_manager and set_servant_manager > Nature: Revision > Summary: get_servant_manager and set_servant_manager > operations should not require the USE_SERVANT_MANAGER > policy to work. > Resolution: Closed with no action. The change would be > incompatible with the current specification. A > proposal for different entity on which to hang the > seemingly requested feature might be in order, such > as Issue 1162. > > Issue 958: Separator character for POAs should be specified > Nature: Enhancement > Summary: The Portability submission should specify a separator > character for POAs that may not be used in a POA name. > We propose that "/" be the separator character in POA > name, and that a "/" is not valid if used in a POA > name. This provides for vendors to provide a more > compact on-the-wire encoding, rather than use > sequence, and also is a convenience for the user if we > allow compound POA names to be used anywhere an > adapter_name is currently used in the POA APIs. > Resolution: Close with no action. On-the-wire representation of > POA name is implementer-defined. Providing a "compound > POA" name is not a feature that is universally > acclaimed. > > Issue 964: No POA hook for future Policies > Nature: Enhancement > Summary: The POA spec currently provides no hook for adding > future POA Policies. Several submission currently in > the works will be adding new policies to the POA. We > propose a generic create_policy() method which can be > used to create any Policy. We are open for discussion > on the signature, but a current thought is something > like this: Policy create_policy(PolicyType policyType, > Any policyValue); > Resolution: Closed with no action. The joint messaging RFP > submission had already included the ORB::create_policy > operation as part of the submission. > > Issue 1314: Access to the Active Object Map > Nature: Enhancement > Summary: How about adding visibility to the Active Object Map. > This would be beneficial to a factory-type server > application that created and activated Servants and > also periodically reported status on what it is in its > AOM. Changes to the spec would look something like: > module PortableServer { > typedef sequenceObjectSequence; > interface POA { ObjectSequence > get_active_objects(); > }; > }; > Resolution: Closed with no action. It is not possible to generate > such a list given the information known to the POA > because an ID and servant (the information the AOM) > do not uniquely specify an object reference. > Return-Path: Date: Tue, 30 Jun 1998 19:01:02 -0400 From: Jonathan Biggar Organization: Floorboard Software To: "Daniel R. Frantz" CC: port-rtf@omg.org Subject: Re: Suggestions for issues 614, 648, 676, 744, 958, 964, > 1314: no action References: <005201bda3a2$53f81a80$3fc5bdce@idler.beasys.com> My comments on each one of these are included inline below: Daniel R. Frantz wrote: > I suggest we close the following issues with no action. > > Some enhancement issues were discussed and said to be > impractical. Some met with opposition and will clearly never be > accepted. Some answers are my own replies for enhancement > requests that seem impractical. I think this shoots down a > suggestion from almost everybody who's made more than one. I > apologize if I've missed anybody. :-) > > Let me know if you disagree. We can take an email vote next week. > > Dan > ======================================================== > > Issue 648: Server request and oneway operations > Nature: Enhancement > Summary: Given it's optional to call set_result operation of > CORBA::ServerRequest, an ORB can't determine whether > operation supported is oneway or not. > Resolution: Closed with no action. The information is available > in GIOP. Perhaps the text should state that calling set_result is only optional if the return type is void?