On event-driven, request-driven,stateful and stateless

This slide is taken from our DEBS 2013 tutorial, explaining what are the differences in thinking between the traditional request-driven way and the event-driven way.   It shows the differences by answering three questions.     This goes back to the differences between business rules and event processing, and old topic, on which I have written first time around 6 years ago!    One of the claims that I've heard several times is that the distinction between them is that business rules are stateless and event processing is stateful.     I think that the main difference is that business rules are treated as request driven,  the rule is activated on request and provides a response, while event driven logic is driven by event occurrence as shown in the slide above.

While it is true that there is correlation between event based/request based and stateful/stateless,  these are really orthogonal issues.

Event-driven logic can be stateless.  If we only wish to filter an event and trigger some action,  this can be stateless (most filters are indeed stateless), but it has all the characteristics of event-driven, including the fact that if the event is filtered out - no response is given.   

On the other hand -- a request-driven logic may be stateful, there are many instances of session oriented and other stateful request-response protocols.    One can also implement stateful rule engine in a request-response way, where invocation of rule is based on result of previous rules that are retained by the system.  

Bottom line:  stateful vs. stateless is not equivalent to event-driven vs. request-driven.   

Event model - the next frontier

I am writing this time from Falls Church, Virginia.  Where I arrived yesterday for a business trip in the Washington DC area, and then in Toronto.   So far I was not affected by the weather, but we'll see what happens later in the week.     

The slides above is an old slide which I used seven years ago to show the relationships of events and the rest of the universe.   I was reminded on that when reading a new article by David Luckham and Roy Schulte entitled "Why companies should develop event models?".    In this article they explain the motivation and provide a high level methodology to build event model.     Following what I recently written about "event oriented thinking",  it seems that the major obstacle to adoption of event-driven systems is the ability of people to think in event-driven way and not in the traditional request-driven way.   Being able to create event model and relate it to enterprise computing modeling is an essential step.    This is the direction I am working on these days (very much in the direction that Luckham and Schulte indicate), and will surely write more about it in the sequel.