Free High Performance CORBA Notification Service from AT&T Laboratories

omniORB Home AT&T Research

Back to Documentation Home Page

Underspecified Features

The CosNotification specification does not give complete semantics for all of the Notification Service features.  This section is under construction; it will cover the current behavior of omniNotify for these underspecified cases as we identify them.  So far we have documented the following:

• Admin and Proxy Nodes with No Filters and No Type Subscriptions
• Admin-Level Type Subscriptions
• Combining Type Subscriptions and Filters
• Type Change Mechanisms

If you believe the specification is clear (and we are confused), send us a note!

Admin and Proxy Nodes with No Filters and No Type Subscriptions

Suppose a consumer is connected to a proxy P obtained from an admin A.  If no filters and no type subscription have been added to either P or A, then it is clear from the specification that the consumer will get all events that are supplied to the channel.   In other words, the lack of any specification from the consumer about the events it wants results in all events. 

The specification is less clear on what should happen when filters or type subscriptions are placed at P but not at A, or vice versa.  Admin A is created with either AND or OR semantics for its InterFilterGroupOperator, but the specification only states the semantics of this operator for the case where filters have been added to both A and P.    What about the case where filters or subscriptions are only placed at A, but not P, or vice versa?  (The related case of filters at A and subscriptions at P, or vice versa, is discussed below.)

The main issue is whether, in the case of OR semantics, the lack of either a filter or type subscription should result in all events being consumed.  (For AND semantics, any reasonable interpretation requires matching of the specified types or filters.)  Recall that, if no filter and no type subscription is registered at P, this normally means "match everything."  If there are subscriptions or filters at A, what should happen?  One can take one of 2 stands on this case:

• (1) The Boolean OR of P's implicit subscription of "match everything" with whatever subscription or filter is added to A always results in "match everything."    With this interpretation, OR semantics will only result in a proper subset of all events being consumed if one places a subscription or a filter at both admin A and proxy P.
• (2) The lack of a specification at P should not have any weight, given that there is an explicit specification at A, and therefore the specification at A should be used to filter events on behalf of P.  In other words, the AND or OR InterFilterGroupOperator semantics is only applied when there are two sets of specifications to be combined, one from A and one from P.  When only A or only P has a specification, the InterFilterGroupOperator is simply ignored. 

The above scenario discussed consumer-side filtering.  There is a related issue with supplier-side filtering, where a supplier is connected to a proxy P derived from an admin A.  Supplier-side filtering can only be done using filters, so the only issue is what happens when there are filters at P but not A, or filters at A but not P?   Again, the question is only interesting for OR semantics, since for AND semantics any reasonable interpretation requires matching the specified filters.  Again, the two choices are (1) the result is "match everything" since Boolean OR of "match everything" and X is always "match everything"; (2) the result is to ignore the node that lacks filters, and to require matching against the filters at the other node.

Current omniNotify Semantics:   omniNotify currently implements option number 2 for both consumer-side subscriptions/filters and for supplier-side filters.  We are not big fans of the default "match everything" semantics.

Admin-Level Type Subscriptions

The specification states (section 2.6.5) that a consumer can use type subscriptions (via subscription_change) to control the event types that it consumes. The section only directly mentions using subscription_change on a proxy P, where it states that subscription_change cannot be used once a filter is added to P. However, it did not rule out using subscription_change at the admin level. The two choices here seem to be: (1) allow subcription_change on admin A, as long as no filters have been added to A, with the result being a sharing of the type subscriptions across the proxies of A; (2) do not allow subscription_change at the admin level.

Current omniNotify Semantics: omniNotify implements option number 1.

Combining Type Subscriptions and Filters

A related issue is the question of placing a filter at admin A and a type subscription at proxy P, or vice versa.  The specification states (section 2.6.5) that type subscriptions cannot be used at proxy P once a filter is added to P, but it says nothing about using type subscriptions at P once a filter is added to A, or vice versa.

Current omniNotify Semantics: omniNotify treats type subscriptions like simple filters, and applies A's InterFilterGroupOperator when there are filter(s) at  P and subscriptions at A or vice versa.

Type Change Mechanisms

The offer_change and subscription_change mechanisms both take 2 lists of event types: types to be added, and types to be deleted.  You are allowed to use wildcards in these types, but the meaning of wildcards in this context is underspecified.

For example, consider this sequence of offer_change messages from a supplier to its proxy:

1.   offer_change( [ Stock::Ticker,Weather::Report ],   [ ] )

2.   offer_change( [ *::Ticker ],                       [ ] )

3.   offer_change( [ ],                                 [ *::Ticker ] )

In each case the first argument is a list of event types to be added and the second argument is a list of event types to be deleted.  The first call indicates that the supplier will supply events of type Stock::Ticker and of type Weather::Report.  The second call indicates that the supplier will also supply events of type *::Ticker.  This indicates that it supplies a class of event types, all of them having type name Ticker.  The third call indicates that the supplier will no longer supply *::Ticker events. 

The specification does not give the semantics for the second or third calls:

• For the second call, what is the resulting set of event types offered by the supplier?   Should there be three types (Stock::Ticker, Weather::Report, and *::Ticker) or just two types (Weather::Report and *::Ticker)?    The latter case recognizes the fact that *::Ticker dominates Stock::Ticker, and therefore it is no longer necessary to keep Stock::Ticker in the list of types offered by the supplier.  However, the fact that the supplier has explicitly indicated that it supplies Stock::Ticker events might be useful to a consumer even if *::Ticker is also specified.
• For the third call, what is the resulting set of event types offered by the supplier?    If we leave Stock::Ticker in the offer list during the second call, should it be removed due to this third call?  The result will either be a list with just Weather::Report, or  a list with both Stock::Ticker and Weather::Report.

The same issues arise for subscription_change messages.  If the above 3 calls were subscription_change calls used by a consumer, should the consumer's final subscription list be just Weather::Report, or a list with both Stock::Ticker and Weather::Report?

Current omniNotify Semantics: omniNotify does not take event type domination into account when computing changes to offer lists or subscription lists.  This was done to preserve the maximum amount of information about the types that have been specified.  What this means:  In the example above, the only way to remove Stock::Ticker is to explicitly place type Stock::Ticker in the deleted list.  A supplier or consumer should remember the set of types that it has added to its offer list or subscription list if it plans to remove them at a later time, since it cannot simply use *::* in the deleted list to remove all its types.

Further Complications

When the connecting Boolean operator between a consumer proxy and its admin object is CosNotifyChannelAdmin::AND_OP, then a proxy only receives events that pass both its own subscription and the subscription of its admin object.  Suppose a channel has only one admin, and this admin has only one proxy.  If there are 2 subscriptions,   *::Ticker and Stock::Ticker, with one each at the admin and proxy, the net effect is that only Stock::Ticker events are sent to the consumer.   Suppose the *::Ticker subscription is added second.  Should the notification channel announce a subscription_change message containing *::Ticker, even though the consumer will only receive Stock::Ticker events?  What should be announced if one of the subscriptions is removed? 

Current omniNotify Semantics: At present, omniNotify ignores the distinction between AND_OP and OR_OP semantics when computing the global subscriptions list.   For the example above, this means the global list will contain both *::Ticker and Stock::Ticker. 

Star-Star Semantics

When specifying an event type in an offer_change, subscription_change, or filter constraint, all of the following event types are equivalent and match any type:

• Empty domain name and empty type name.
• Empty domain name and "*" type name.
• "*" domain name and empty type name.
• "*" domain name and "*" type name.

We refer to these cases as star-star forms.  What the specification does say is that if a star-star form is explicitly added by a consumer via subscription_change or a filter constraint, and this type is new to the global set of subscriptions  (no other consumer has explicitly registered using a star-star form) then the special type with an empty domain name and a " %ALL" type name must be sent out in subscription_change messages.

It is also the case that when both an admin and a proxy have no filters and no subscribed types the consumer connected to the proxy will receive all events supplied to the channel.  The specification does not say whether the special "%ALL" type name should be sent as an addition in a subscription_change message due to an empty subscription list, or whether this type should be sent as a removal when an empty subscription list is changed to be non-empty.

Current omniNotify Semantics: omniNotify does not send out the special" %ALL" event type as an addition due to a new proxy with an empty subscription list or due to a proxy whose subscription list changes from non-empty to empty.  It also does not send a corresponding removal when an empty list becomes non-empty.  If you want the "%ALL" type to appear in subscription_change messages, you must explicitly add a star-star form to a proxy or admin, either using subscription_change or by adding a filter with a constraint that includes a star-star form.  You must explicitly remove the filter or the star-star subscription for a corresponding "%ALL" removal to be sent out.  Our reasoning:  Our approach differentiates between a consumer that is getting all events due to the degenerate case of failing to specify anything and a consumer that explicitly asks for all event types.