org.omg.CosNotifyFilter
Interface Filter
public
interface
Filter
extends FilterOperations, Object, IDLEntity
The Filter interface defines the behaviors supported by objects which encapsulate
constraints used by the proxy objects associated with an event channel in order to
determine which events they receive will be forwarded, and which will be discarded.
Each object supporting the Filter interface can encapsulate a sequence of any number
of constraints. Each event received by a proxy object which has one or more objects
supporting the Filter interface associated with it must satisfy at least one of the
constraints associated with one of its associated Filter objects in order to be forwarded
(either to another proxy object or to the consumer, depending on the type of proxy the
filter is associated with), otherwise it will be discarded.
Each constraint encapsulated by a filter object is a structure comprised of two main
components. The first component is a sequence of data structures, each of which
indicates an event type comprised of a domain and a type name. The second
component is a boolean expression over the properties of an event, expressed in some
constraint grammar (more on this below). For a given constraint, the sequence of event
type structures in the first component nominates a set of event types to which the
constraint expression in the second component applies. Each element of the sequence
can contain strings which will be matched for equality against the domain_name and
type_name fields of each event being evaluated by the filter object, or it could contain
strings with wildcard symbols (), indicating a pattern match should be performed
against the type contained in each event, rather than a comparison for equality when
determining if the boolean expression should be applied to the event, or the event
should simply be discarded without even attempting to apply the boolean expression.
Note that an empty sequence included as the first component of a constraint implies
that the associated expression applies to all types of events, as does a sequence
comprised of a single element whose domain and type name are both set to either the
empty string or else the wildcard symbol alone contained in quotes.
The constraint expressions associated with a particular object supporting the Filter
interface are expressed as strings which obey the syntax of a particular constraint
grammar.
As long as such user-defined filter objects support the Filter interface, they can be
attached to Proxy or Admin objects in the same fashion as the default Filter objects
supported by the implementation of the service are, and the channel should be able to
use them to filter events in the same fashion.
The Filter interface supports the operations required to manage the constraints
associated with an object instance which supports the interface, along with a readonly
attribute which identifies the particular constraint grammar in which the constraints
encapsulated by this object have meaning. In addition, the Filter interface supports
three variants of the match operation which can be invoked by an associated proxy
object upon receipt of an event (the specific variant selected depends upon whether the
event is received in the form of an Any, a Structured Event, or a Typed Event), to
determine if the event should be forwarded or discarded, based on whether or not the
event satisfies at least one criteria encapsulated by the filter object.
The Filter interface also supports operations which enable a client to associate with
the target filter object any number of callbacks which are notified each time there is
a change to the list of event types which the constraints encapsulated by the filter
object could potentially cause proxies to which the filter is attached to receive.
Operations are also defined to support administration of this callback list by unique
identifier.