Issue 3955: push() versus push_event() (components-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: See the CORBA Components Model specification, orbos/99-07-01, section 5.6, pages 5-84 through 5-89, approximately. Could someone clarify the push() and push_event() operations, their purposes, and their interaction, if any. There is no description whatsoever of the relationship between the push() and push_event() operations, even though push_event() is declared in the inherited Components::EventConsumerBase. The producing component invokes its push() operation, which then performs any peculiar formatting to the event before transmission to the underlying channel through its container. It is unclear when, if ever, the push_event() operation will be invoked. A text search of the document reveals the operation appears only in the interface definition and its immediate descriptive paragraphs. Would a better model be to use push_event() as the interface to and from the container? (Perhaps this should be independent operations, produce_event() and consume_event()?) On the producer side, let push() perform any component specific formatting of the event before passing the [now modified] event on to push_event(). This latter interacts with the container to send the event to the event channel, as described. (Most push() implementations will do nothing to the event. This could be provided as a default generated implementation.) On the consumer side, push_event() will be invoked by the container as part of event delivery. The push_event() operation performs type checks, as described, before it invokes the consumer agent’s push() operation. This process correctly handles the semantics and permits suitable places to intercept or override event processing. Resolution: rejected Revised Text: Actions taken: October 16, 2000: received issue May 13, 2002: closed issue Discussion: EventConsumerBase is part of the client-side interface of a component. Clients can equivalently use either the push_event() operation on the EventConsumerBase interface or the push() operation on the consumer interface associated to the used eventtype. The push_event() operation is described on page 61-46 and must be used by clients having no static knowledge of the concrete consumer interface associated to the used eventtype. The push() operation is described in the text for equivalent eventtype consumer interfaces and could be used by clients having static knowledge of the concrete consumer interface associated to the used eventtype. Neither interface is used on the server side. No further clarification is necessary. End of Annotations:===== From: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Mon, 16 Oct 2000 10:48:29 -0500 Message-Id: Subject: New Components Issue: push() versus push_event() MIME-Version: 1.0 TO: issues@omg.org CC: jim.x.stickley@openmail.mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-32b4b6e8-00000001" X-UIDL: SeWd9Aggd9)MC!!I?W!! See the CORBA Components Model specification, orbos/99-07-01, section 5.6, pages 5-84 through 5-89, approximately. Could someone clarify the push() and push_event() operations, their purposes, and their interaction, if any. There is no description whatsoever of the relationship between the push() and push_event() operations, even though push_event() is declared in the inherited Components::EventConsumerBase. The producing component invokes itprocess correctly handles the semantics and permits suitable places to intercept or override event processing. Tom Hawker s push() operation, which then performs any peculiar formatting to the event before transmission to the underlying channel through its container. It is unclear when, if ever, the push_event() operation will be invoked. A text search of the document reveals the operation appears only in the interface definition and its immediate descriptive paragraphs. Would a better model be to use push_event() as the interface to and from the container? (Perhaps this should be independent operations, produce_event() and consume_event()?) On the producer side, let push() perform any component specific formatting of the event before passing the [now modified] event on to push_event(). This latter interacts with the container to send the event to the event channel, as described. (Most push() implementations will do nothing to the event. This could be provided as a default generated implementation.) On the consumer side, push_event() will be invoked by the container as part of event delivery. The push_event() operation performs type checks, as described, before it invokes the consumer agent X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>>61.6.1 Event types CORBA IDL contains event type declarations, which are a restricted form of value type declarations. They are for the use in the CORBA Component event model. Since the underlying implementation of the component event mechanism provided by the container is the CORBA notification service, event values shall be inserted into instances of the any type. The resulting any values shall be inserted into a CORBA notification structured event. The mapping between a component event and a notification event is implemented by the container and is described in Section 66.4, "Event Management Integration," on page 66-252. 61.6.1.1 Equivalent IDL For the declaration of event types of the following form: module { valuetype A { }; eventtype B : A { }; eventtype C : B { }; }; The following equivalent IDL is implied: module { valuetype A { }; valuetype B : A, ::Components::EventBase { }; interface BConsumer : ::Components::EventConsumerBase { void push_B ( in B the_b ); }; valuetype C : B { }; interface CConsumer : BConsumer { void push_C ( in C the_c ); }; }; As shown above the first event type in the inheritance chain introduces the inheritance from Components::EventBase into the inheritance chain for the equivalent value types. The same rule applies for the equivalent consumer interfaces and Components::EventConsumerBase. Consumer interfaces are in the same inheritance relation as the event types, where they origin. HERE THE NOTE WAS REMOVED. 61.6.1.2 EventBase The module Components contains the following abstract value type definition: module Components { abstract valuetype EventBase { }; }; It serves as base type for value types derived via the Equivalent IDL mapping for event types. 61.6.6 Publisher 61.6.6.1 Equivalent IDL For an event source declaration of the following form: module { component { publishes ; }; }; The following equivalent IDL is implied: module { interface : Components::CCMObject { Components::Cookie subscribe_( in Consumer consumer) raises (Components::ExceededConnectionLimit); Consumer unsubscribe_( in Components::Cookie ck) raises (Components::InvalidConnection); }; }; 61.6.6.2 Event publisher operations subscribe_ The subscribe_ operation connects the consumer parameter to an event channel provided to the component implementation by the container. The component shall be the only publisher to that channel. If the implementation of the component or the channel places an arbitrary limit on the number of subscriptions that can be supported simultaneously, and the invocation of the subscribe operation would cause that limit to be exceeded, the operation raises the ExceededConnectionLimit exception. The Cookie value returned by the operation identifies the subscription formed by the association of the subscriber with the publisher event source. This value can be used subsequently in an invocation of unsubscribe_ to disassociate the subscriber from the publisher. unsubscribe_ The unsubscribe_ operation destroys the subscription identified by the ck parameter value, returning the reference to the subscriber. If the ck parameter value does not identify an existing subscription to the publisher event source, the operation shall raise an InvalidConnection exception. 61.6.7 Emitters 61.6.7.1 Equivalent IDL For an event source declaration of the following form: module { component { emits ; }; }; The following equivalent IDL is implied: module { interface : Components::CCMObject { void connect_( in Consumer consumer ) raises (Components::AlreadyConnected); Consumer disconnect_() raises (Components::NoConnection); }; }; 61.6.7.2 Event emitter operations connect_ The connect_ operation connects the event consumer denoted by the consumer parameter to the event emitter. If the emitter is already connected to a consumer, the operation shall raise the AlreadyConnected exception. disconnect_source_name> The disconnect_ operation destroys any existing connection by disassociating the consumer from the emitter. The reference to the previously connected consumer is returned. If there was no existing connection, the operation raises the NoConnection exception. 61.6.9 Event Sinks An event sink embodies the potential for the component to receive events of a specified type. An event sink is, in essence, a special-purpose facet whose type is an event consumer. External entities, such as clients or configuration services, can obtain the reference for the consumer interface associated with the sink. Unlike event sources, event sinks do not distinguish between connection and subscription. The consumer interface may be associated with an arbitrary number of event sources, unbeknownst to the component that supplies the event sink. 61.6.9.1 Equivalent IDL For an event sink declaration of the following form: module { component { consumes ; }; }; The following equivalent IDL is implied: module { interface : Components::CCMObject { Consumer get_consumer_(); }; }; 61.6.9.2 Event sink operations The get_consumer_ operation returns a reference that supports the consumer interface specific to the declared event type. hme X-Mailer: Mozilla 4.73 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en, de MIME-Version: 1.0 To: components-ftf@omg.org Subject: Proposal for a event type solution Content-Type: multipart/mixed; boundary="------------41C0F4AC5C441C79D6B21DD9" X-UIDL: M&a!!M>/!!VoS!!]@I!! Hi After a long discussion on the implementors meeting in Berlin we found that event types should be a syntax construct from IDL-3, similarly to value types. For this two major changes are needed: 1. change CORBA core (syntax,semantic) to contain event types 2. change chapter 66.6 of the new CCM CORBA chapters. You will find attached the changed text for 66.6. Regards, Harald -- <<<< Harald BReceived: from unknown (141.20.20.50) by hobbit.omg.org asmtp(1.0) id 1632; Thu, 05 Jul 2001 07:43:53 -0400 (EDT) Received: from informatik.hu-berlin.de (pandora [141.20.23.176]) by mail.informatik.hu-berlin.de (8.9.1/8.9.1/INF-2.0-MA-UNIX-4.0E) with ESMTP id NAA02131 for ; Thu, 5 Jul 2001 13:38:40 +0200 (MET DST) Sender: boehme@informatik.hu-berlin.de Message-ID: <3B4451C1.F36FFE7F@informatik.hu-berlin.de> Date: Thu, 05 Jul 2001 13:38:41 +0200 From: Harald B