Issue 3071: messaging issue: pollable sets broken (messaging-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: I would like to raise the following issue with Messaging: The specification of pollable sets is broken because there is no direct way to widen a poller to a pollable and to narrow a pollable to a poller. Goal of pollable sets: A client holds pollers to outstanding replies. He registers these pollers in a pollable set. The set can be queried if one of the pollers is ready, ie. if a corresponding reply can be retrieved by means of this poller. The client uses the ready poller to retrieve the available reply. The problem: Poller is a valuetype, Pollable an interface type. In general, valuetypes are not object references nor CORBA objects. This is true even if a valuetype supports an interface. -> (a) How is it possible to obtain a pollable object reference from a poller instance? -> (b) How is it possible to obtain a poller instance from a pollable object reference? Why has Pollable be defined as an interface type in the first place? I think the original Messaging spec designers were not aware of the fundamental difference between valuetypes and object references. Probably, the original design intention just was that every poller "is a" pollable. They probably thought if the poller supported the interface Pollable, each poller instance could be widened to a pollable and then narrowed back again to a poller. Thus, a possible correction would be to define Pollable as an abstract valuetype instead of an interface. Resolution: resolved, see below Revised Text: Proposed resolution: 1. In section 6.6, the following words <<start>> The generic base Poller value can be queried to obtain the status of a potentially outstanding request. So that it can be registered in a CORBA::PollableSet, it derives from the interface CORBA::Pollable. The inherited Pollable is_ready returns the value TRUE if and only if a reply is currently available for the outstanding request. If it returns the value FALSE, the reply has not yet been returned from the target. This operation raises the system exception OBJECT_NOT_EXIST if the reply has already been obtained by some client at the time of the query. The Poller has the following definition: module Messaging { value Poller supports CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; }; <<end>> should be replaced with <<start>> The generic base Poller value can be queried to obtain the status of a potentially outstanding request. So that it can be registered in a CORBA::PollableSet, it derives from the abstract valuetype CORBA::Pollable. The inherited Pollable is_ready returns the value TRUE if and only if a reply is currently available for the outstanding request. If it returns the value FALSE, the reply has not yet been returned from the target. This operation raises the system exception OBJECT_NOT_EXIST if the reply has already been obtained by some client at the time of the query. The Poller has the following definition: module Messaging { valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; }; <<end>> 2. In section 9.3.4.1, the following words 9.3.4.1 interface Pollable are replaced with 9.3.4.1 abstract valuetype Pollable 3. In section 10.2, the following IDL interface Pollable { boolean is_ready(in unsigned long timeout); PollableSet create_pollable_set(); }; is replaced with abstract valuetype Pollable { boolean is_ready(in unsigned long timeout); PollableSet create_pollable_set(); }; Actions taken: November 30, 1999: received issue October 4, 2000: closed issue Discussion: Pollable is now an abstract valuetype, so this is fixed. Close this issue. End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 30 Nov 1999 09:21:29 +0100 Message-Id: Subject: messaging issue: pollable sets broken MIME-Version: 1.0 TO: issues@omg.org, messaging-rtf@omg.org CC: sgw@adnovum.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 30 Nov 1999 09:21:29 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 30 Nov 1999 09:21:29 +0100" X-UIDL: d:'e9\dTd92NQd997Pd9 Hello I would like to raise the following issue with Messaging: The specification of pollable sets is broken because there is no direct way to widen a poller to a pollable and to narrow a pollable to a poller. Goal of pollable sets: A client holds pollers to outstanding replies. He registers these pollers in a pollable set. The set can be queried if one of the pollers is ready, ie. if a corresponding reply can be retrieved by means of this poller. The client uses the ready poller to retrieve the available reply. The problem: Poller is a valuetype, Pollable an interface type. In general, valuetypes are not object references nor CORBA objects. This is true even if a valuetype supports an interface. -> (a) How is it possible to obtain a pollable object reference from a poller instance? -> (b) How is it possible to obtain a poller instance from a pollable object reference? Why has Pollable be defined as an interface type in the first place? I think the original Messaging spec designers were not aware of the fundamental difference between valuetypes and object references. Probably, the original design intention just was that every poller "is a" pollable. They probably thought if the poller supported the interface Pollable, each poller instance could be widened to a pollable and then narrowed back again to a poller. Thus, a possible correction would be to define Pollable as an abstract valuetype instead of an interface. Regards Hans From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Mon, 6 Dec 1999 10:22:53 +0100 Message-Id: Subject: proposed resolution for "pollable sets broken" MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 6 Dec 1999 10:22:53 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Mon, 6 Dec 1999 10:22:53 +0100" X-UIDL: Bnb!!UBgd9co\!!(aKe9 Chris, I propose the following resolution for the messaging issue "pollable sets broken": http://www.omg.org/archives/messaging-rtf/msg00193.html proposed resolution: -------------------- 1. In section 6.6, the following words <> The generic base Poller value can be queried to obtain the status of a potentially outstanding request. So that it can be registered in a CORBA::PollableSet, it derives from the interface CORBA::Pollable. The inherited Pollable is_ready returns the value TRUE if and only if a reply is currently available for the outstanding request. If it returns the value FALSE, the reply has not yet been returned from the target. This operation raises the system exception OBJECT_NOT_EXIST if the reply has already been obtained by some client at the time of the query. The Poller has the following definition: module Messaging { value Poller supports CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; }; <> should be replaced with <> The generic base Poller value can be queried to obtain the status of a potentially outstanding request. So that it can be registered in a CORBA::PollableSet, it derives from the abstract valuetype CORBA::Pollable. The inherited Pollable is_ready returns the value TRUE if and only if a reply is currently available for the outstanding request. If it returns the value FALSE, the reply has not yet been returned from the target. This operation raises the system exception OBJECT_NOT_EXIST if the reply has already been obtained by some client at the time of the query. The Poller has the following definition: module Messaging { valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; }; <> 2. In section 9.3.4.1, the following words 9.3.4.1 interface Pollable are replaced with 9.3.4.1 abstract valuetype Pollable 3. In section 10.2, the following IDL interface Pollable { boolean is_ready(in unsigned long timeout); PollableSet create_pollable_set(); }; is replaced with abstract valuetype Pollable { boolean is_ready(in unsigned long timeout); PollableSet create_pollable_set(); }; rationale: --------- The purpose of PollableSet is to offer operations on a set of pollers, ie. to provide a container of valuetype instances. - no widening from poller to pollable In some language mappings like C++ and Java, a valuetype cannot be widened to an interface. Although valuetypes can support an interface, a valuetype is never a subtype of an interface. The common abstraction from valuetype and interface is abstract interface. (see http://www.omg.org/archives/messaging-rtf/msg00194.html ) At creation time of the messaging spec, the objects by value spec defined a _this method in C++ that provided a sort of widening from a valuetype to a supported interface. There is no such method today (for good reasons!). Pollable should therefore not be defined as an interface, as there is no direct way to get from a poller valuetype instance to a Pollable object reference. Does anyone agree to give this a chance on vote 2? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11