What is an event?

My colleague Peter Abrahams wrote an article last year about event-driven architecture (EDA) in which he defined the environment as being one that “begins with a business event, which is anything that changes the status of the business in some way. The events can be of varying importance ranging from a major event, such as a customer placing an order, to a more trivial event, such as a product with an RFID tag passing a sensor or it could even be a clock tick that signals the start of a new price list.”

Now, I can’t argue with that. Literally, a transaction is a type of event. However, it is not very useful to treat it as such because the things that you need to do to process a transaction are very different from the things that you need to do process what we might call a non-transactional event. In particular, transactions are susceptible to change. A customer may place an order for 50 blue widgets today but call up tomorrow and change that to 15 green widgets and 35 red ones. Provided that that change is accepted then the business no longer has any interest in the original version of this order, only the current one. Another point is that a transaction may be incomplete. For example, you might accept an order with delivery address to be confirmed at a later date.

Now think about an RFID tag passing a sensor. You may or may not be interested in that fact but one thing is sure: you can’t change it. In other words, the data is static. Other examples of static (a better term, I think, than non-transactional) events are stock ticks, call data records, and the arrival times of trains, amongst others.

So we could refer to transactional events and static events but since we are all used to discussing transactions as such, my view is that we simply use the term event to refer to any static event. Note that, in this view, a transaction may still be an event but only if each version of the customer order (say) is viewed as being important in its own right—each change being viewed as a new event.

There is a corollary to trying to fit both conventional transactions and events into the same pot. As Peter went on to say in his article “all of the business events can be represented in the IT world by a message, and in the EDA world that will be an XML message.”

Well, this may be true in the EDA world but it certainly isn’t when it comes to event processing. To begin with nobody talks about messages and most events do not come in XML format. Even more so, once you start to talk about buses and queues. This is not the sort of language you want to use when you are processing tens or hundreds of thousands of events per second. When you queue up for something, does that imply waiting? I think so. And we all know that you have to wait ages for the first bus and then get several all at once. That’s why event processing vendors talk about streams and even waterfalls.

However, perhaps the most interesting thing is why event processing doesn’t talk about messages. This is because event processing is essentially about treating an event as data to be processed, whereas messages are more application oriented. This suggests that while EDA and event processing are nominally operating within the same environment, in practice they are some way apart and may even compete with one another in some circumstances. I confess to not having looked at EDA in any detail up until now but it is clear that I will need to do so in the future, in order to understand how this is positioned with respect to event processing, and vice versa.