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.
5 comments:
It is interesting to note: a request is an event. Because applications start actions by request: request thinking about sowtware still dominates. Request thinkins is equivalent to client-server aproach.
Opher, thanks for very helpful blog!
Hi Igor.
There are attempts to emulate event-driven in a request-driven by stating that event = request. One can look at this statement as when event occurs send a request, or treat request as an event. I'll write more about this issue
Cheers,
Opher
Hi Opher,
Request is an event as Igor notes, so it depends on class of problem you want to solve. Also, a reactionary architecture could handle events listeners just as readily as a request.
I think the issue lies deeper in architecture and the tradeoff you make in an earlier post re: latency and cost.
Was curious whether you checked out the links I had sent. Wondered if I had prompted this post.
In any case, as always, I enjoyed it.
Happy New Years.
Dave
I still can't see how event processing can resolve the issue where a component has to synchronously query another component before proceeding.
Here's an example. A user logs into an application using his/her credentials. The UI component sends an authentication request to the UserAuthentication component. The UI component has to wait for a response before it can route the user to a 'login success' or 'login failure' page.
It appears to me that systems like these need both event-driven and request-driven architectures.
Opher, what are your thoughts on this?
Thanks
Event processing indeed does not replace request-driven programming, such as cases that synchronous response is needed. The point is not that event processing can become the only programming paradigm, the point is that it is not natural to express event-driven with request-driven programming, when event-driven is more natural
Opher
Post a Comment