Issue 1660: No way to "quench" to event style supplier (notif_service-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: In the CosNotifyComm module, we define new client interfaces for clients that supply and consumer structured events and sequence of structured events. In the CosNotifyChannelAdmin module, we define different proxy interfaces for clients that deal with Anys, structured events, and sequences of structured events. For the proxies that deal with Anys, we rely on Event tyle clients to connect to them. In other words, the input parameter to the "connect_*" operations defined on the proxies provided for clients that deal with Anys are of a type defined in the CosEventComm module. This is because we don"t redefine Notification-specific interfaces for clients that deal with Anys. It has just occurred to us that this makes it impossible to propagate "subscription_change" requests to clients that deal with Anys. This is because such clients are defined in CosEventComm, and do not support the NotifySubscribe or NotifyPublish interfaces. Resolution: Revised Text: Actions taken: July 10, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: "Michael J. Greenberg" Subject: New Issue: No way to "quench" to event style supplier... To: notif_service-rtf@omg.org Date: Thu, 9 Jul 1998 16:30:37 -0400 (EDT) Cc: issues@omg.org, dsm@syl.nj.nec.com Hello, My development team has encountered what I feel is a fairly significant hole in the current spec. In the CosNotifyComm module, we define new client interfaces for clients that supply and consumer structured events and sequence of structured events. In the CosNotifyChannelAdmin module, we define different proxy interfaces for clients that deal with Anys, structured events, and sequences of structured events. For the proxies that deal with Anys, we rely on Event tyle clients to connect to them. In other words, the input parameter to the "connect_*" operations defined on the proxies provided for clients that deal with Anys are of a type defined in the CosEventComm module. This is because we don't redefine Notification-specific interfaces for clients that deal with Anys. It has just occurred to us that this makes it impossible to propagate "subscription_change" requests to clients that deal with Anys. This is because such clients are defined in CosEventComm, and do not support the NotifySubscribe or NotifyPublish interfaces. As a specific example, suppose a push supplier of Anys wants to connect to a Notification Service channel. The supplier creates an object of type CosEventComm::PushSupplier, which is passed as input to the connect_any_push_supplier operation defined by CosNotifyChannelAdmin::ProxyPushConsumer. Now, this ProxyPushConsumer cannot propagate subscription change requests to the supplier, because the supplier does not support the NotifySubscribe interface. Likewise, the converse problem is true for consumers of Any events. These do not support the NotifyPublish interface, and thus cannot be the target of "offer_change" requests. My proposal would be to define new PushConsumer, PushSupplier, PullConsumer, and PullSupplier interfaces within CosNotifyChannelAdmin that multiple inherit from their CosEventComm equivalent, and either NotifyPublish (for the Consumer interfaces) or NotifySubscribe (for the Supplier interfaces). Then, these new interfaces could be passed as input to the appropriate connect_* operations supported by their corresponding proxy. I'm interested in comments. -Mike -- 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