Sharing Subscriptions

2.6.1 Sharing Subscriptions Between Channels and Clients

The flow of events through a Notification channel depends on the events supplied to the channel and the subscriptions from event consumers which match them (or cause them to be discarded). In order to convey end-to-end the knowledge of what is required from suppliers, and what might be produced by them, we introduce two

complementary operations,offer_changeandsubscription_change. These operations are available on interfaces supported by channels and, due to the symmetry of design, also on the interfaces supported by the clients of channels.

2.6.2 Offer

Theoffer_changeoperation, provided by theNotifyPublishinterface is supported by all Proxy Consumer interfaces and theSupplierAdmininterface, and may be supported by consumers of events. It has two paramaters: one for event types that are newly offered, and one for event types no longer offered. This operation is used by suppliers of events to indicate to the channel the new event types that they will supply, and to indicate event types that they will no longer supply. Channels will then aggregate the offers from all their suppliers. If a new or removed offer by a supplier changes the aggregate list of event types offered to the channel, the channel will in turn invoke the same operation on its consumers, informing those consumers of new event types available to them, or events types no longer offered.

Consumers can use offer information to consult the Event Type Repository to discover what property names and types the event type contains, and thus write well-formed subscription expressions for these types.

Consumers may also discover the current set of event types that a channel has been offered by its suppliers by calling theobtain_offered_typesoperation on their

ProxySupplierinterface.

Consumers which are only interested in a fixed set of events may choose to supply a nil object reference to the channel at connect time if they pull events from the channel. They may also return aNO_IMPLEMENTexception from theoffer_change

operation if they must support the interface which allows the channel to push events to them.

2.6.3 Subscription Change

Thesubscription_changeoperation is provided by theNotifySubscribeinterface, which is supported by all Proxy Supplier interfaces and theConsumerAdmin

interface, and may be supported by suppliers of events. It is a means of relaying subscription information, in the form of required event types, back to the source of events. It has two parameters: one to specify event types that are required, and one to specify event types that are no longer required. Event Channels will aggregate the event types that their consumers require. If a new event type required by a consumer (or consumer group represented by aConsumerAdmin) changes the aggregate list then the channel will inform its suppliers by their callingsubscription_change

operation indicating that a new type is required. Likewise, if change from a consumer removes an event type from the aggregate list of event types in the channel it will call

subscription_changeon it suppliers indicating that the type is no longer required. Suppliers may also discover the current set of event types that consumers of a channel require by calling theobtain_subscription_typesoperation on the

ProxyConsumerinterface.

Suppliers that are not interested in the event types currently subscribed to will not invokeobtain_subscription_types, and will raise theNO_IMPLEMENT exception in their implementation of thesubscription_changeoperation.

2.6.4 Notifications on Demand

One consequence of suppliers being informed of the event types that clients require is that they know which notifications are being consumed and which are not. This knowledge can be used by end-suppliers to influence which notifications they will produce. For instance, an operating system process watcher connected to a channel as a supplier is informed that only notifications of certain process watching types are being consumed. It might therefore choose to produce notifications only about those kinds of processes rather than producing notifications for all processes. Another example is where suppliers only generate notifications while there is an interested party. For instance, a consumer indicates an interest in CPU load statistics by

subscribing to a particular event type. Intelligent suppliers would then begin to produce these statistics only for as long as a consumer was interested in the information. When no consumers are interested, the channel’s aggregate list of event types will change, and the supplier will be notified via thesubscription_changeoperation that these

notifications are no longer being consumed. The supplier could then stop generating its statistics until the relevant event type was received insubscription_changein the parameter which indicates added types.

In these examples the anonymity of event suppliers and consumers is maintained while enabling communication about notification requirements between them.

2.6.5 Obligations on Filter Objects

Filter objects support the operationsattach_callbackanddetach_callback, which are used by Proxy Suppliers and ConsumerAdmins to provide and remove object references to theirNotifySubscribeinterfaces. Filter objects must call the references that are currently attached when the set of event types that their constraints require changes. This means that they must use theEventTypeSeqassociated with their constraints as a parameter to an invocation ofsubscription_change.

Implementations of Filters may choose whether to convey the event types for a constraint as the added parameter tosubscription_changewhen the constraint is added and then as the removed parameter tosubscription_changewhen that constraint is removed, or whether to maintain an aggregate of the event types that all its constraints require, and only callsubscription_changewhen this changes. Note that a Proxy or Admin object that is evaluating the suitability of an event that is not of one of the types that the filter has indicated that it requires may assume that the filter does not require this event and never call a match operation at that filter. See Section 2.6.6, “Special Event Types,” on page 2-51 about special event types that force matching.

A consumer connected to a proxy supplier may use thesubscription_change

operation instead of a filter object if it requires all events of one or more event types. However, once it adds a filter to the proxy, it must then interact with the filter only, and allow the filter to invokesubscription_change. An event channel will create an aggregate list of all the event types required by its consumers, which it will return as the result ofobtain_subscription_types. It will also communicate any changes to the list to its suppliers by invoking theirsubscription_changeoperation.

2.6.6 Special Event Types

If a constraint expression potentially applies to any event type, then the special event type “%ALL” can be specified in a constraint’s event type sequence (with a domain name of “*” or the empty string). When the filter calls backsubscription_change

with this type it indicates to the channel that the filter wants to match on all event types.

Alternatively the event type and domain specified by any combination of empty strings or the “*” string is treated as the equivalent to “%ALL”, and upon receiving a requirement for this type the channel will send “%ALL” to its suppliers by calling theirsubscription_changeoperations.

The event type “%TYPED” is given by channels to the Structured Event representation of events that are supplied by a typed event supplier using an operation other then the push and pull operations (i.e., untyped) specified in this document. The domain field of these events must be set to the empty string. This event type allows a Structured Event supplier to create an event that is equivalent to the invocation of a typed operation using the mapping given in Table 2-2 on page 2-9. It also allows Structured Event consumers and event service style consumers to write filter constraints that match events which were delivered to the channel by a typed supplier.

Note – the leader characters ‘%’ and ‘*’ are not legal for type names stored in the Event Type Repository, and are chosen because they do not clash with any pre-existing event type naming schemes known to the authors.