Mapping Filter Objects

The Notification Service recognizes two special properties of each event that could influence the delivery policy applied to the event: its priority and its expiration time (referred to here as its lifetime). While these properties are often populated by the supplier as fields of the event, there are many scenarios in which a consumer’s opinion of the relative importance of the event may differ from that of the supplier. In order to enable consumers to affect the priority and lifetime properties of events, the

Notification Service introduces the concept of mapping filter objects.

Mapping filter objects support theCosNotifyFilter::MappingFilterinterface. The specification of this interface looks very similar to that of the interface for regular filter objects. The main difference, however, is that mapping filters also associate a value with each constraint they encapsulate.

Each proxy supplier within a Notification Service event channel can have associated with it a mapping filter object which can affect the priority property of the events it receives, and another mapping filter object which can affect the lifetime property of the events it receives. The value associated with each constraint encapsulated by a mapping filter which affects events’ priority property is of type short, and represents an event priority. The value associated with each constraint encapsulated by a mapping filter which affects events’ lifetime property is of typeTimeBase::TimeT, and represents a relative event lifetime.

Each mapping filter object can encapsulate one or more constraint-value pairs, and also has a default value associated with it. Upon receipt of an event by a proxy supplier with an associated mapping filter for the priority4property, the proxy supplier invokes the appropriate match operation on the mapping filter. The mapping filter proceeds to apply its encapsulated constraints in the order of highest to lowest with respect to the value associated with each constraint, until either the event satisfies a constraint or else does not satisfy all constraints. Upon encountering the first constraint which the event satisfies, the operation returns a result of TRUE, and an output parameter set to the value associated with the constraint. If the event satisfies none of the constraints associated with the mapping filter object, the result of thematchoperation will be set to FALSE, and the default value associated with the mapping filter object will be returned as the output parameter. Upon return from the operation, if the output parameter is TRUE, the proxy supplier treats the event with respect to its priority according to the return value, as opposed to a priority setting contained within the event. If the output parameter is FALSE, the proxy supplier will apply the following rules in order to determine the priority that should be associated with the event: 1. If there is a priority property set in the header of the event, that value will be used. 2. If there is no priority property set in the header of the event, but the event has

inherited an associated priority by virtue of being processed by a proxy object (either the current proxy supplier or the proxy consumer which first received the event) that has an assoicated priority QoS property, that value will be used. 3. Otherwise, the output parameter returned by thematchoperation, which in this

case is the default value of the mapping filter object, will be used.

Proxy suppliers with an associated mapping filter for the lifetime property proceed similarly to invoke thematchoperation on such a mapping filter. The behavior of the

matchoperation for a mapping filter related to event lifetime is identical to that for a mapping filter related to priority; the only difference is in the type of the output parameter returned when a constraint is encountered which the event satisfies. In this case, the proxy supplier uses the output parameter as the lifetime property of the event. Note that the results of applying a mapping filter to an event are used to modify the way in which a proxy supplier treats its copy of the event with respect to priority and lifetime, but not to modify the contents of the event itself. Even if the event contains priority and lifetime fields, these should not be modified as the result of applying a mapping filter to the event.

Notification Service styleConsumerAdmininterfaces can also have associated mapping filter objects. The semantics in this case are identical to those with regular filter objects: the mapping filters associated with aConsumerAdminobject are

4.Note that the priority property is used as an example here to explain how mapping filters are applied. Similarly, the lifetime property could have been used in the example. All mapping filter processing rules that apply to priority mapping filters as explained in this paragraph also apply to lifetime mapping filters.

shared by all proxy suppliers being managed by thatConsumerAdminobject. Note, however, if a particular proxy supplier has a mapping filter associated with it, this overrides any mapping filter set for the same proxy on theConsumerAdminthat manages that proxy supplier.

Finally, note that this specification uses mapping filters to affect the priority and lifetime properties of events. TheCosNotifyFilter::MappingFilterinterface, however, is generic enough to be applied to any property of an event. Implementations of the Notification Service can thus support as a value-added extension the application of mapping filters to other event properties besides priority and lifetime.