instance, which created a given TypedProxyPushConsumer

instance. In addition, this inheritance implies that aTypedProxyPushConsumer

instance supports an operation which will return the list of event types which

consumers connected to the same channel are interested in receiving, and an operation which can return information about the instance’s ability to accept a per-event QoS request.

TheTypedProxyPushConsumerinterface also inherits from the

TypedPushConsumerinterface defined within theCosTypedNotifyComm

module. This interface supports the event type specific operation(s), which the supplier connected to aTypedProxyPushConsumerinstance will invoke to send events to the channel in the form of typed events. And, since theTypedPushConsumer

interface inherits from thePushConsumerinterface defined in the

1.In this case, the reference is really to a TypedSupplierAdmin instance, which is valid since TypedSupplierAdmin inherits from CosNotifyChannelAdmin::SupplierAdmin.

CosEventCommmodule, an instance supporting theTypedProxyPushConsumer

interface supports the standardpushoperation with which it can be supplied untyped events, and the operation required to disconnect theTypedProxyPushConsumer

from its associated supplier. In addition, since the inheritedTypedPushConsumer

interface inherits theCosNotifyComm::NotifyPublishinterface, a supplier connected to an instance supporting theTypedProxyPushConsumerinterface can inform it whenever the list of event types the supplier plans to supply changes. Finally, theTypedProxyPushConsumerinterface defines the operation, which can be invoked by a push supplier to establish the connection over which the push supplier will send events to the channel. Note that this can be either a pure event service style, or a notification service style push supplier.

3.6.1.1 connect_typed_push_supplier

Theconnect_typed_push_supplieroperation accepts as an input parameter the reference to an object supporting thePushSupplierinterface defined within the

CosEventCommmodule. This reference is that of a supplier that plans to push typed events to the channel with which the target object is associated. This operation is thus invoked in order to establish a connection between a push-style supplier of typed events, and the notification channel. Once established, the supplier can proceed to send events to the channel by invoking the event type specific operation(s) supported by the targetTypedProxyPushConsumerinstance. If the target object of this operation is already connected to a push supplier object, theAlreadyConnectedexception will be raised.

Note that since there is no difference between the interfaces of suppliers of untyped and typed events, it would have sufficed to have theTypedProxyPushConsumer

interface to inherit from theProxyPushConsumerinterface defined in the

CosNotifyChannelAdminmodule, and to not define a separate “connect” method for push-style suppliers of typed events. It was felt, however, that explicitly defining this operation makes the usage model of theTypedProxyPushConsumerinterface more intuitive.

Note also that because thePushSupplierinterface defined in theCosNotifyComm

module inherits from thePushSupplierinterface defined in theCosEventComm

module, the input parameter to this operation could be either a pure event service style, or a notification service style push supplier. The only difference between the two are that the latter also supports theNotifySubscribeinterface, and thus can be the target ofsubscription_changeinvocations. The implementation of the

TypedProxyPushConsumerinterface should attempt to narrow the input parameter toCosNotifyComm::PushSupplierin order to determine which style of push supplier is connecting to it.

3.6.2 The TypedProxyPullSupplier Interface

TheTypedProxyPullSupplierinterface supports connections to the channel by consumers who will pull OMG Event Service style typed events from the channel.

Through inheritance of theProxySupplierinterface, theTypedProxyPullSupplier

interface supports administration of various QoS properties, administration of a list of associated filter objects, mapping filters for event priority and lifetime, and a readonly attribute containing the object reference of theConsumerAdmin2instance, which created a givenTypedProxyPullSupplierinstance. In addition, this inheritance implies that aTypedProxyPullSupplierinstance supports an operation that will return the list of event types, which the proxy supplier will potentially be supplying, and an operation that can return information about the instance’s ability to accept a per-event QoS request.

TheTypedProxyPullSupplierinterface also inherits from theTypedPullSupplier

interface defined within theCosTypedNotifyCommmodule. This interface supports the event type specific operation(s), which the consumer connected to a

TypedProxyPullSupplierinstance will invoke to receive events from the channel in the form of typed events. And, since theTypedPullSupplierinterface inherits from thePullSupplierinterface defined in theCosEventCommmodule, an instance supporting theTypedProxyPullSupplierinterface supports the standardpulland

try_pulloperations with which it can supply untyped events, and the operation required to disconnect theTypedProxyPullSupplierfrom its associated consumer. In addition, since the inheritedTypedPullSupplierinterface inherits the

CosNotifyComm::NotifySubscribeinterface, an instance supporting the

TypedProxyPullSupplierinterface can be informed whenever the list of event types that the consumer connected to it is interested in receiving changes.

Finally, theTypedProxyPullSupplierinterface defines the operation which can be invoked by a pull consumer to establish the connection over which the pull consumer will receive events from the channel. Note that this can be either a pure event service style, or a notification service style pull consumer.

3.6.2.1 connect_typed_pull_consumer

Theconnect_typed_pull_consumeroperation accepts as an input parameter the reference to an object supporting thePullConsumerinterface defined within the

CosEventCommmodule. This reference is that of a consumer, which plans to pull typed events from the channel with which the target object is associated. This operation is thus invoked in order to establish a connection between a pull-style consumer of typed events, and the notification channel. Once established, the consumer can proceed to receive events from the channel by invoking the event type specific operation(s) supported by the targetTypedProxyPullSupplierinstance. If the target object of this operation is already connected to a pull consumer object, the

AlreadyConnectedexception will be raised.

2.In this case, the reference is really to a TypedConsumerAdmin instance, which is valid since TypedConsumerAdmin inherits from CosNotifyChannelAdmin::ConsumerAdmin.

Note that since there is no difference between the interfaces of consumers of untyped and typed events, it would have sufficed to have theTypedProxyPullSupplier

interface to inherit from theProxyPullSupplierinterface defined in the

CosNotifyChannelAdminmodule, and to not define a separate “connect” method for pull-style consumers of typed events. It was felt, however, that explicitly defining this operation makes the usage model of theTypedProxyPullSupplierinterface more intuitive.

Note also that because thePullConsumerinterface defined in theCosNotifyComm

module inherits from thePullConsumerinterface defined in theCosEventComm

module, the input parameter to this operation could be either a pure event service style, or a notification service style pull consumer. The only difference between the two are that the latter also supports theNotifyPublishinterface, and thus can be the target of

offer_changeinvocations. The implementation of theTypedProxyPullSupplier

interface should attempt to narrow the input parameter to

CosNotifyComm::PullConsumerin order to determine which style of pull consumer is connecting to it.

3.6.3 The TypedProxyPullConsumer Interface

TheTypedProxyPullConsumerinterface supports connections to the channel by suppliers who will make OMG Event Service style typed events available for pulling to the channel.

Through inheritance of theProxyConsumerinterface, theProxyPullConsumer

interface supports administration of various QoS properties, administration of a list of associated filter objects, and a readonly attribute containing the object reference of the