In the table above (taken from a recent presentation I am working on) I have summarized some of the main differences between request driven thinking and event driven thinking. It is interesting to note that many of the activities we are doing in life are event driven, however, we are programmed to think that computer should be approached in request driven way, and I have noticed that even if the application itself is event driven by nature, people will tend to convert it to request driven. Event driven action is being activated not due to explicit request but since an event has occurred, or a derived event was concluded. This may happen in unknown time and unknown frequency. Furthermore, a request getting into a system should always entail response (which can be error message), an event getting into the system may be ignored, since it is out of context, just increment internal state, or close the circle of detecting derived event which can be either internal to the system, or trigger external action or notification, Note that only the last case has visible response to the outside. One of the challenges is to educate people to think in event driven way rather than request driven. I'll write more on event driven thinking in the sequel.