Composed Events

One of the ideas in an event based architecture that I really like is the idea of composed events. A composed event is an event that is defined in terms of other events. For example, in my previous post I mentioned a ‘PossibleBruteForceAttack’ event. This event is defined as having occurred when 3 or more failed login attempts occur for the same username. One of the things I like most about this is how it mirrors reality. How many times have you been able to accurately describe a system failure based on correlated events? Its the kind of experience that the long timers can have for specific systems, but instead of it being a ‘gut feeling’ we make it explicit. By making it explicit we can test it for accuracy over time.

So what does this technique do for us? Well beyond being able to define these kinds of complex events it also lets us extend our systems without actually modifying the system, since we can simply compose these events by subscribing to them and then publishing a new event. You could take a system that produces events on the changing price of a financial instrument and then have a new component that watches this stream of events for large swings in price. This could then be announced as new CrazyMarket event. This is also another way you might look to use the blogjecting watchdog pattern to monitor system health by correlating fault messages to the server logs.

Anyways, I just think it is cool. :)

-d

About Dru Sellers

Sr. Software Engineer at Dovetail Software.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/members/drusellers/default.aspx drusellers

    I am currently playing with that idea. At the moment its just another message consumer.

    -d

  • Daniel Fernandes

    How would you configure the event broker to handle complex scenarios ?
    Would you create some kind of generic broker that you can configure say at startup time to compose those events ?