Scott's Workblog

scott.bradley.wilson@gmail.com


attention!
This blog has moved! Go to my new blog!


November 29, 2006

Fowler on event collaboration and event cascades

Martin Fowler is working on a very good article on event collaboration - the style of architecture where internal state changes are propagated by firing events to anyone wanting to listen. As well as being the style of several IT architectures, such as the Schools Interoperability Framework (SIF), its also pretty close to the behaviour of neurons and neurotransmitters in the brain, which use a combination of specific and undifferentiated signal diffusion to create cascade effects.

Event collaboration is interesting as a style of system as you don't need to know, a priori, who you are going to collaborate with.

Typically in an enterprise scenario a piece of middleware listens for your events, and forwards them to any interested parties. Likewise, you use the same 'postroom' to listen for any useful messages. This piece of middleware is also where you register new applications so they can join the network.

In a distributed web environment you can also see event collaboration at work. As websites change their states they emit an event in the form of changes to their feeds, which 'subscribers' periodically collect, cascading changes in response to new items. This style of implementation avoids the need for a specialized 'postroom' by using the general internet technologies of DNS and URI, combined with the use of local, application-specific event source lists (feed URIs for sources of interest) rather than central distribution lists.

In either case there is the likelihood of unintended effects caused by chains of events cascding across systems with different concerns and loci. This can be good, creative chaos, or it can be a complete pain depending on what you're trying to achieve. In practice both enterprise and distributed event architectures need to prevent 'hunting' (rapid oscillation between a pair of states - essentially the networked equivalent of an infinite loop).

In the distributed case another example of a fault is the site which messes up its feed algorithm and always marks items as being published at the current date and time with new identifiers. This triggers aggregators to constantly fire their 'new event' behaviour such as notifying the user or pushing the item to the top of the page. In enterprise systems a common situation to avoid is one whereby an update in 'A is propagated to 'B' which tells 'C' which then changes the data that 'A' uses, creating a loop.

However, event cascades also have some productive potential in the form of self-modulating cycles - event chains which have the effect of dampening or amplifying an originating event based on feedback. This operates at both the machine and human level and is potentially very powerful and productive, although difficult to predict across a large number of nodes in the event chain.

main archive