CORBA 2.6 NO IDEA Avatar
  1. OMG Issue

CORBA26 — Problems with the Components Notification Event Interface

  • Key: CORBA26-62
  • Legacy Issue Number: 4081
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • 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
      <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
    • 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

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3937. rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT