Thursday, December 13, 2007

On Event processing and Event Driven Architecture


As those who read this blog can notice, I use the term - "event processing" as the name of the discipline that this blog deals with. Other people are using the term EDA - "event driven architecture" as their key terms? one of the questions I was recently asked - are they the same, or similar like the two Arizona Moths that you can see in the picture above ? this, of course, depends on the exact meaning, and people do use them interchangeably.
In my opinions these terms are different.
EDA deals with the way components communicate, and in this case, unlike the request/response style, EDA is loosely coupled, asynchronous, and delivered via push.
Event Processing deals with the end-to-end processing of events, it may or may not be based on EDA. There are some cases that are EP, and are not EDA, examples:
  • Event can be obtained in pull (periodically or on demand)
  • Event can be part of transaction -and thus there is a dependency
  • Event can be communicated to an event processor using request/response protocol, but the actual functionality is event processing.

(may be other reason).

So EP and EDA are not really identical...

1 comment:

Anonymous said...

Dear Opher,

I'm fully compliant with your current post and I think that it hits the nerve of the current event processing terminology.

I noticed that people tend to mix up EDA and Event Processing (as well as CEP/ESP) quite often for some reason.

EDA is an architecture while an event-based solution (e.g. event processing realm) is a component that *can* be applied within an event-driven architecture both as a consumer or producer - which is actually not a bad idea to do so. If someone attaches an event processing solution to a SOA-based concept it is still event processing, but it is not very efficient to do so and it breaks with the concept of creating a really loosely coupled environment and hangs into request/reply patterns a little bit.

Furthermore I noticed that people who grew out of the pub/sub field tend to treat the communication middleware/infrastructure as an essential part of an event-based system which is again not true from my point of view as the communication infrastructure can follow some paradigms, but basically it can implement arbitrarily different strategies for handling event notifications.