Issue 4081: Problems with the Components Notification Event Interface (components-ftf) Source: Iconixx (Mr. Thomas S. Hawker, ) Nature: Uncategorized Issue Severity: Summary: The CCM standard indicates that all CCM Event functions will delegate to the container. Chapter 7 of the CCM Volume 1 further dictates the interface the container will provide to the component, called Components::Notification::Event, referred to as the "Event Interface" hereafter. This interface contains many problems and does not address all the required functionality. The problems are listed below:<p> * The create_channel() method returns an EventConsumerBase for the publisher to use to publish events to the channel. It is not possible for the Event Interface to construct a concrete EventConsumerBase, specifically the interface defined as &lt;publishing_component&gt;EventConsumers:: &lt;event_type&gt;Consumer (per section 5.6.6 and 5.6.7 giving the publisher and emitter IDL expansion). The Event::obtain_channel() method has the same problem * The subscribe() method implies that the container supplying events will hold the supplier proxy that will be used to send events to the subscriber’s EventConsumerBase. This is an inefficient model. Also, this model is in direct conflict with the listen() method, which supports a more efficient model (see next bullet). * The standard does not provide any documentation on when a consumer would call the listen() method. The standard also does not provide a means for the consumer’s component to realise the "csmr_name", the name used to find the ConsumerAdmin from the Naming Service [see possibly related issue #3940]. Nor does the standard indicate when the ConsumerAdmin would have ever been added to the Naming Service. It might be possible that this would work for emitters, but it does not work for publishers (the standard dictates that a consumer cannot distinguish between being connected to an emitter or a publisher). This method does imply that the consuming component will have a proxy local to its container, separate from the publishing component’s container (contradictory to the subscribe() method, see previous bullet). * The push() method does not provide a means to indicate which channel the event should be pushed to [see possibly related issue #3928].<p> The Event Interface is a local interface ­ that is, the client will never see this interface, and so it is possible to hide the use of this interface inside the generated code and thus replace the interface. Internally we have added a PortManager interface to be used in place of the Event Interface. This interface provides better management of the Event Channels and it also manages receptacle connections. Two interfaces will derive from the PortManager, a TransientPortManager and a PersistentPortManager. These two derived interfaces will permit connections between components to be managed as defined by the type of the container. Where meaningful, this permits the port connections to be made persistent as part of the overall state so that connections (specifically, notification channels) can be more reliably and robustly managed. The CCM2Context::get_event() operation is replaced by get_port_manager() Resolution: See issue 3937. rejected Revised Text: Actions taken: November 24, 2000: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== From: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Fri, 24 Nov 2000 16:47:36 -0600 Message-Id: Subject: Problems with the Components Notification Event Interface MIME-Version: 1.0 TO: issues@omg.org CC: jim.x.stickley@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-35a72edb-00000001" X-UIDL: 1QZ!!HGRd97~o!!E\2e9 See the CORBA Components Specification, orbos/99-07-01, section 5.6 et al and section 7.

The CCM standard indicates that all CCM Event functions will delegate to the container. Chapter 7 of the CCM Volume 1 further dictates the interface the container will provide to the component, called Components::Notification::Event, referred to as the "Event Interface" hereafter. This interface contains many problems and does not address all the required functionality. The problems are listed below:

* The create_channel() method returns an EventConsumerBase for the publisher to use to publish events to the channel. It is not possible for the Event Interface to construct a concrete EventConsumerBase, specifically the interface defined as <publishing_component>EventConsumers:: <event_type>Consumer (per section 5.6.6 and 5.6.7 giving the publisher and emitter IDL expansion). The Event::obtain_channel() method has the same problem * The subscribe() method implies that the container supplying events will hold the supplier proxy that will be used to send event this model is in direct conflict with the listen() method, which supports a more efficient model (see next bullet). * The standard does not provide any documentation on when a consumer would call the listen() method. The standard also does not provide a mean name used to find the ConsumerAdmin from the Naming Service [see possibly related issue #3940]. Nor does the standard indicate when the ConsumerAdmin would have ever been added to the Naming Service. It might be possible that this would work for emitters, but it does not work for publishers (the standard dictates that a consumer cannot distinguish between being connected to an emitter or a publisher). This method does imply that the consuming component will have a proxy local to its container, separate from the publi container (contradictory to the subscribe() method, see previous bullet). * The push() method does not provide a means to indicate which channel the event should be pushed to [see possibly related issue #3928].

The Event Interface is a local interface - that is, the client will never see this interface, and so it is possible to hide the use of this interface inside the generated code and thus replace the interface. Internally we have added a PortManager interface to be used in place of the Event Interface. This interface provides better management of the Event Channels and it also manages receptacle connections. Two interfaces will derive from the PortManager, a TransientPortManager and a PersistentPortManager. These two derived interfaces will permit connections between components to be managed as defined by the type of the container. Where meaningful, this permits the port connections to be made persistent as part of the overall state so that connections (specifically, notification channels) can be more reliably and robustly managed. The CCM2Context::get_event() operation is replaced by get_port_manager(). Tom Hawker, Iconixx thawker@iconixx.com shing components for the consumers to the subscriber