Issue 2153: CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier oper (notif_service-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier operation, when asked for a proxy for a ClientType of ANY_EVENT, returns a proxy that is unuasable by event service clients. The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface returned inherits only from CosEventChannelAdmin::XSupplier, and then redefines the connect operation that was available in CosEventChannelAdmin:: ProxyXSupplier as connect_any_x_supplier. The interface can never be narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is unusable by the Event Service style client. Resolution: Revised Text: Actions taken: October 30, 1998: received issue Discussion: : End of Annotations:===== Return-Path: To: notif_service-rtf@omg.org Cc: issues@omg.org Subject: Just to make life difficult X-face: *A\_v+D,~Jx_g]`m,s61-x|*;H4hgZeE= Here's another Notification issue: The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier operation, when asked for a proxy for a ClientType of ANY_EVENT, returns a proxy that is unuasable by event service clients. The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface returned inherits only from CosEventChannelAdmin::XSupplier, and then redefines the connect operation that was available in CosEventChannelAdmin:: ProxyXSupplier as connect_any_x_supplier. The interface can never be narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is unusable by the Event Service style client. Proposed Solution: The interfaces defined in CosNotifyChannelAdmin that inherit from the CosEventChanelAdmin::[Push|Pull][Supplier|Consumer] interfaces and support the new connect operations connect_any_x_y() should be redefined to inerit from the appropriate CosEventChanelAdmin::Proxy[Push|Pull][Supplier|Consumer] interface, and the connect operations connect_any_x_y() should be deleted. e.g. interface ProxyPushConsumer : ProxyConsumer, CosNotifyComm::NotifyPublish, CosEventComm::PushConsumer { void connect_any_push_supplier ( in CosEventComm::PushSupplier push_supplier) raises(CosEventChannelAdmin::AlreadyConnected); }; // ProxyPushConsumer should become: interface ProxyPushConsumer : ProxyConsumer, CosNotifyComm::NotifyPublish, CosEventComm::ProxyPushConsumer { }; // ProxyPushConsumer -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) General Purpose South, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: From: "Michael J. Greenberg" Subject: Re: Just to make life difficult To: dud@dstc.edu.au (Keith Duddy) Date: Fri, 30 Oct 1998 09:13:36 -0500 (EST) Cc: notif_service-rtf@omg.org, issues@omg.org Hi Keith, Two comments on this one: 1) At this point, I have secured enough votes to also include the previous two issues in the output that we submit at the Burlingame meeting as the final output of this RTF. At this point, I'm quite content to close off the issues list (which was supposed to be closed over a month ago), and try to get the currently agreed upon set of issues adopted by the OMG. In addition, I plan to make a motion to recharter the RTF, so we can continue to resolve new issues (such as the one you raise). 2) I'm not sure I entirely agree with you this time that the proposed change is necessary. A pure Event Service style client would never invoke "obtain_notification_X_supplier" anyway...the name alone of this operation implies that it's a notification service style client! In addition, CosNotifyChannelAdmin::ConsumerAdmin inherits from CosEventChannelAdmin::ConsumerAdmin, so if the client really wants a pure Event service style proxy, it can always obtain one that way. Please provide further rationale for this proposed change. Thanks, Mike >>Here's another Notification issue: >> >>The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier >>operation, when asked for a proxy for a ClientType of ANY_EVENT, >>returns a proxy that is unuasable by event service clients. >> >>The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface >>returned inherits only from CosEventChannelAdmin::XSupplier, and then >>redefines the connect operation that was available in CosEventChannelAdmin:: >>ProxyXSupplier as connect_any_x_supplier. The interface can never be >>narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is >>unusable by the Event Service style client. >> >>Proposed Solution: >> >>The interfaces defined in CosNotifyChannelAdmin that inherit from the >>CosEventChanelAdmin::[Push|Pull][Supplier|Consumer] interfaces and >>support the new connect operations connect_any_x_y() should be >>redefined to inerit from the appropriate >>CosEventChanelAdmin::Proxy[Push|Pull][Supplier|Consumer] interface, >>and the connect operations connect_any_x_y() should be deleted. >> >>e.g. >> >> interface ProxyPushConsumer : >> ProxyConsumer, >> CosNotifyComm::NotifyPublish, >> CosEventComm::PushConsumer { >> >> void connect_any_push_supplier ( >> in CosEventComm::PushSupplier push_supplier) >> raises(CosEventChannelAdmin::AlreadyConnected); >> >> }; // ProxyPushConsumer >> >>should become: >> >> interface ProxyPushConsumer : >> ProxyConsumer, >> CosNotifyComm::NotifyPublish, >> CosEventComm::ProxyPushConsumer { >> >> }; // ProxyPushConsumer >> >>-- >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >>Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud >> CRC for Distributed Systems Technology (DSTC) >> General Purpose South, University of Queensland, 4072, Australia >> ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >> 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >> >>> http://www.wiley.com/compbooks/vogel <<< >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >> -- Michael J. Greenberg NEC Systems Lab. 4 Independence Way Tel. 609-734-6142 Princeton, NJ 08540 Fax. 609-734-6001 mjg@syl.nj.nec.com Return-Path: To: "Michael J. Greenberg" cc: notif_service-rtf@omg.org, issues@omg.org, dud@dstc.edu.au (Keith Duddy) Subject: Re: Just to make life difficult Date: Sat, 31 Oct 1998 14:32:54 +1000 From: Julian Boot Hi Mike, I came accross this issue while implementing SuplierAdmin::obtain_push_consumer. Because the Notification ProxyPushConsumer extends the Event PushConsumer rather then the Event ProxyPushConsumer, the Admin cannot return an instance of the same impl it would when obtain_notification_push_consumer was called. This means a Notifcation service can never be used as an event service without implementing event service style proxies as well as notifcation style proxies. Further, in the general case, a Notification ProxyPushConsumer can never be used as an Event ProxyPushConsumer, because is does not have a connect_push_supplier method (rather it has connect_any_push_supplier). We think this is far from the spirit of much of the current spec. -Julian > 2) I'm not sure I entirely agree with you this time that the proposed > change is necessary. A pure Event Service style client would > never invoke "obtain_notification_X_supplier" anyway...the name > alone of this operation implies that it's a notification service > style client! In addition, CosNotifyChannelAdmin::ConsumerAdmin > inherits from CosEventChannelAdmin::ConsumerAdmin, so if the > client really wants a pure Event service style proxy, it can > always obtain one that way. Please provide further rationale for > this proposed change. > > >>Here's another Notification issue: > >> > >>The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier > >>operation, when asked for a proxy for a ClientType of ANY_EVENT, > >>returns a proxy that is unuasable by event service clients. > >> > >>The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface > >>returned inherits only from CosEventChannelAdmin::XSupplier, and then > >>redefines the connect operation that was available in CosEventChannelAdmin:: > >>ProxyXSupplier as connect_any_x_supplier. The interface can never be > >>narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is > >>unusable by the Event Service style client. > >> > >>Proposed Solution: > >> > >>The interfaces defined in CosNotifyChannelAdmin that inherit from the > >>CosEventChanelAdmin::[Push|Pull][Supplier|Consumer] interfaces and > >>support the new connect operations connect_any_x_y() should be > >>redefined to inerit from the appropriate > >>CosEventChanelAdmin::Proxy[Push|Pull][Supplier|Consumer] interface, > >>and the connect operations connect_any_x_y() should be deleted. > >> > >>e.g. > >> > >> interface ProxyPushConsumer : > >> ProxyConsumer, > >> CosNotifyComm::NotifyPublish, > >> CosEventComm::PushConsumer { > >> > >> void connect_any_push_supplier ( > >> in CosEventComm::PushSupplier push_supplier) > >> raises(CosEventChannelAdmin::AlreadyConnected); > >> > >> }; // ProxyPushConsumer > >> > >>should become: > >> > >> interface ProxyPushConsumer : > >> ProxyConsumer, > >> CosNotifyComm::NotifyPublish, > >> CosEventComm::ProxyPushConsumer { > >> > >> }; // ProxyPushConsumer > >> > >>-- > >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > >>Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud > >> CRC for Distributed Systems Technology (DSTC) > >> General Purpose South, University of Queensland, 4072, Australia > >> ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 > >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > >> 2nd edition of my book ``Java Programming with CORBA'' now in bookshops > >> >>> http://www.wiley.com/compbooks/vogel <<< > >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > >> > > > -- > > Michael J. Greenberg > NEC Systems Lab. > 4 Independence Way Tel. 609-734-6142 > Princeton, NJ 08540 Fax. 609-734-6001 > mjg@syl.nj.nec.com > > -Julian ----- julian boot software engineer distributed systems technology centre http://www.dstc.edu.au/~julian/ Return-Path: From: "Michael J. Greenberg" Subject: Re: Just to make life difficult To: julian@dstc.edu.au (Julian Boot) Date: Sun, 1 Nov 1998 22:33:34 -0500 (EST) Cc: mjg@syl.nj.nec.com, notif_service-rtf@omg.org, issues@omg.org, dud@dstc.edu.au Hi Julian, I have a couple of comments about this. First, I now understand your point a little better about this. But, I'm still not entirely convinced the change you propose is necessary, nor do I feel it's worth stopping the wheels that are now in motion to get the current set of changes adopted as the final output of this RTF in Burlingame (the issue you raise could be the first one we consider for the next RTF). The reason I'm not convinced that the change is necessary is that although you are correct in saying that due to the IDL arrangement you are trying to change, you cannot implement just a Notification Service style Proxy which deals with Anys, and treat it like an Event style proxy, with just a small amount of wrapper code you can share most of the implementation. This is what we have done in our implementation, and it's really not such a big deal. Also, defining Any-styl proxies as they are is completely consistent with the way Structured and Sequence Proxies are defined. Again, I do understand your point, and would be willing to put this to a vote. But, I'm personally not sure this change is necessary. Regards, Mike >>Hi Mike, >> >>I came accross this issue while implementing SuplierAdmin::obtain_push_consumer. >> >>Because the Notification ProxyPushConsumer extends the Event PushConsumer rather >>then the Event ProxyPushConsumer, the Admin cannot return an instance of the >>same impl it would when obtain_notification_push_consumer was called. This means >>a Notifcation service can never be used as an event service without implementing >>event service style proxies as well as notifcation style proxies. >> >>Further, in the general case, a Notification ProxyPushConsumer can never be >>used as an Event ProxyPushConsumer, because is does not have a connect_push_supplier >>method (rather it has connect_any_push_supplier). >> >>We think this is far from the spirit of much of the current spec. >> >>-Julian >> >>> 2) I'm not sure I entirely agree with you this time that the proposed >>> change is necessary. A pure Event Service style client would >>> never invoke "obtain_notification_X_supplier" anyway...the name >>> alone of this operation implies that it's a notification service >>> style client! In addition, CosNotifyChannelAdmin::ConsumerAdmin >>> inherits from CosEventChannelAdmin::ConsumerAdmin, so if the >>> client really wants a pure Event service style proxy, it can >>> always obtain one that way. Please provide further rationale for >>> this proposed change. >>> >>> >>Here's another Notification issue: >>> >> >>> >>The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier >>> >>operation, when asked for a proxy for a ClientType of ANY_EVENT, >>> >>returns a proxy that is unuasable by event service clients. >>> >> >>> >>The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface >>> >>returned inherits only from CosEventChannelAdmin::XSupplier, and then >>> >>redefines the connect operation that was available in CosEventChannelAdmin:: >>> >>ProxyXSupplier as connect_any_x_supplier. The interface can never be >>> >>narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is >>> >>unusable by the Event Service style client. >>> >> >>> >>Proposed Solution: >>> >> >>> >>The interfaces defined in CosNotifyChannelAdmin that inherit from the >>> >>CosEventChanelAdmin::[Push|Pull][Supplier|Consumer] interfaces and >>> >>support the new connect operations connect_any_x_y() should be >>> >>redefined to inerit from the appropriate >>> >>CosEventChanelAdmin::Proxy[Push|Pull][Supplier|Consumer] interface, >>> >>and the connect operations connect_any_x_y() should be deleted. >>> >> >>> >>e.g. >>> >> >>> >> interface ProxyPushConsumer : >>> >> ProxyConsumer, >>> >> CosNotifyComm::NotifyPublish, >>> >> CosEventComm::PushConsumer { >>> >> >>> >> void connect_any_push_supplier ( >>> >> in CosEventComm::PushSupplier push_supplier) >>> >> raises(CosEventChannelAdmin::AlreadyConnected); >>> >> >>> >> }; // ProxyPushConsumer >>> >> >>> >>should become: >>> >> >>> >> interface ProxyPushConsumer : >>> >> ProxyConsumer, >>> >> CosNotifyComm::NotifyPublish, >>> >> CosEventComm::ProxyPushConsumer { >>> >> >>> >> }; // ProxyPushConsumer >>> >> >>> >>-- >>> >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >>> >>Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud >>> >> CRC for Distributed Systems Technology (DSTC) >>> >> General Purpose South, University of Queensland, 4072, Australia >>> >> ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 >>> >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >>> >> 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> >> >>> http://www.wiley.com/compbooks/vogel <<< >>> >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >>> >> >>> >>> >>> -- >>> >>> Michael J. Greenberg >>> NEC Systems Lab. >>> 4 Independence Way Tel. 609-734-6142 >>> Princeton, NJ 08540 Fax. 609-734-6001 >>> mjg@syl.nj.nec.com >>> >>> >> >> -Julian >> >>----- >>julian boot >>software engineer >>distributed systems technology centre >>http://www.dstc.edu.au/~julian/ >> -- Michael J. Greenberg NEC Systems Lab. 4 Independence Way Tel. 609-734-6142 Princeton, NJ 08540 Fax. 609-734-6001 mjg@syl.nj.nec.com