directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cetin Karakus <cetin.kara...@gmail.com>
Subject Re: [seda] event notifier pattern clarification
Date Wed, 22 Sep 2004 09:00:28 GMT
Hi Alex,
I think that  Advices are a kind of meta-filters with message
transformation capabilities.
In order for Advices to  transform EventObjects in interesting ways
they need to access
the context  provided by EventRouter. So, perhaps we need to introduce
this into the Advice
contract.





On Wed, 22 Sep 2004 01:35:02 -0400, Alex Karasulu <aok123@bellsouth.net> wrote:
> This is in reference to the Event Notifier pattern described here:
> 
> http://www.dralasoft.com/products/eventbroker/whitepaper/
> 
> 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 {
> ...
>     apply(Advice);
> }
> 
> 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.
> 
> WDYT?
> 
> Alex
> 
>

Mime
View raw message