directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [seda] event notifier pattern clarification
Date Wed, 22 Sep 2004 05:35:02 GMT
This is in reference to the Event Notifier pattern described here:

Trustin, Enrique, Noel and I were discussing this on IRC.  Actually we
were discussing how to handle situations were we need to change the way
we route in complex ways sometimes based on:

 o event type (normal for pattern)
 o event filters 
 o event properties/attributes 
 o extraneous logic

Any combination of the above can be used.  There were comments made
about the weaknesses of this pattern specifically where EventType is
used to determine how to route an event to Subscribers.  I agreed but
soon realized that I'm very wrong and this email will tell you why.

The most important point to make is there are two dimensions to
controlling routing in the standard pattern.

(i)  event type
(ii) filters

The event type can totally be turned of by making subscribing for the
root event type EventObject.  So one can subscribe Subscribers for all
events and use logic within Filters to determine whether or not to
inform() the Subscriber.  The logic in the filter can be as dynamic as
you want it to be.  It can check EventObject properties or use
extraneous parameters to determine if the Subscriber should be
notified.  We can check the time of day, type of service event is
associated with, and client specific information if that's what we want
to use in making the routing decision.

So at the end of the day we have all the expressivity we need in this
pattern which as stood the test of time.  However Trustin brought some
interesting ideas to the table.  He spoke about transformations of
Events before informing a Subscriber.  This got me thinking; this is
another dimension for controling routing decisions.

I also had an idea of my own.  I thought about adding routing advice. 
Advice would prune, and/or augment the Subscribers consulted, it would
also transform the event if necessary before delivering it to
Subscribers.  This would extend the routing control of the pattern
further than it has gone before (I think).  Perhaps this has already
been done.

Here's how routing Advice could be administered to the router:

interface EventRouter {

Here's how Advice would look:

interface Advice {
    Subscription[] getSubscriptions(Event, Subscriptions[]);
    Event getEvent(Event);

Advice can be registered on the basis of event type too.  It does not
hurt to do this at all if we just take the root of the event heirarchy
then all events will be checked for advice.

Basically if there is advice for routing then the standard set of
Subscriptions are ignored.  Only the ones returned by the Advice are
used to inform.  Secondly the EventObject used to inform is transformed
before the inform().  The EventObject may not have changed, it can just
be returned as is if transformation via 'cloning' is not in effect.



View raw message