org.omg.CosNotifyFilter
Interface Filter

All Superinterfaces:

FilterOperations, IDLEntity, Object, java.io.Serializable

public interface Filter
extends Object, FilterOperations, 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 (i.e., a BNF). Implementations may support other constraint grammars, and/or users of this service may implement their own filter objects which allow constraints to be expressed in terms of an alternative 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.

The operations supported by the Filter interface are described in more detail within the following subsections.

Method Summary

Methods inherited from interface org.omg.CORBA.Object

_create_request, _create_request, _duplicate, _get_domain_managers, _get_interface_def, _get_policy, _hash, _is_a, _is_equivalent, _non_existent, _release, _request, _set_policy_override

Methods inherited from interface org.omg.CosNotifyFilter.FilterOperations

add_constraints, attach_callback, constraint_grammar, destroy, detach_callback, get_all_constraints, get_callbacks, get_constraints, match_structured, match_typed, match, modify_constraints, remove_all_constraints