CORBA26 — Problems with the Components Notification Event Interface

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
  <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 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()

See issue 3937. rejected