Misleading Terminology Impedes Event Processing Adoption

22 January 2018

W.  Roy Schulte          This article represents my personal opinion, not necessarily that of my employer or anyone else.

If you want to succeed at event processing, I have two suggestions:

  1. Whenever you read or hear the word “event,” stop and figure out whether the author means an (event) happening, an (event) object, or an (event) notification. These are three different things, but they are all called “events.” When people talk or write about events, the word slides quickly from one meaning to another without warning. You are supposed to know from the context which meaning is intended, but it is rarely made explicit.
  2. Whenever you read or hear the words “event driven” or ”event based,” stop and figure out what the author is talking about. There are many variations and shades of event processing, and people do not apply these labels in a consistent manner. One expert will say that a system is event driven, while another will say it is not, because they’re using different criteria. To determine the appropriate architecture for any system that you are designing, you need to think through the details.

Background

For years, people in the IT community who study event processing have been puzzled about why it hasn’t been used more widely. Its advantages over alternative design concepts have been understood for decades. Yet, those new to the topic are bewildered by the vague and conflicting statements made by experts in the field. Even seasoned IT architects and developers often default to request/reply (such as remote procedure calls (RPCs)), database sharing, or other design patterns for situations where event-based design would do a better job. Confusing semantics play a major role in those unfortunate outcomes.

I see two problems:

Firstly, the term “event” is overloaded. As mentioned above, it has at least three common meanings. I will discuss these below.

Secondly, experts don’t agree on the characteristics of event processing design. I will cover this in a subsequent article.

Three Common Meanings of “Event”

  • “Event” means anything that happens, or a state change. There are interesting differences between happenings and state changes, and there are other definitions for event, but those issues can be overlooked for the purposes of this discussion. Whether happening or state change, an event may be real or imaginary, past or future. Movies and dreams have imaginary events. Systems can simulate imaginary or real events. When you post the time of tomorrow’s sunrise, or predict that a machine will break sometime in the next two hours, you are communicating about future events, not reporting past events.

 

  • Elsewhere “event” is short for “event object,” which is a report of an event happening. In IT, an event object is typically data – a string of bits, perhaps in the form of a JSON or XML message, an ASCII text file, or a row in a database table. The content of an event object is determined by the person who designed the system. It usually has one or more explicit time stamps, although it doesn’t have to. A time stamp may signify when the happening took place or will take place, when the event object was generated, when it was received or read, or, for events with a measurable duration, when the event began and when it ended. An event object may also include data about who or what did the activity that the object signifies, what caused it, the identity of the component that generated the object (e.g., a device identifier), or other data collected or computed from various sources. See David Luckham’s book, The Power of Events, Chapter 5, for a complete explanation of event objects’ form, significance and relativity.

 

  • “Event” can also mean (event) notification. A notification is a signal caused by an event happening. It is communication from one component (sender or producer) to another component (receiver or consumer). In some parts of the industry, a notification is literally called a “signal.” It is generally emitted shortly after the sender component detects the event happening. In programming, a notification is implemented as a transfer of data, transfer of control or both. If the notification is data (an event object, see above), it may have hundreds of data attributes or be a one-bit semaphore. If the notification is a transfer of control, it may be a procedure call (e.g., a callback to an event handler) with or without a parameter list.

The relationship of events and notifications is shown in Figure 1.

Figure 1. The Notification Sequence

  1. Notification or “event” producer software component (sender A) detects an event1 (happening/state change) inside the component or in its environment.
  2. The producer performs some computation to generate a notification, and sends the notification to one or more notification/“event” consumer components (receiver B). A communication intermediary is optional. For example, the notification message may be conveyed through a publish-and-subscribe (pub/sub) message-oriented middleware (MOM) product or some other MOM product with a message broker in the communication path.
  3. The arrival of a notification is an event2 (happening) in the consumer, and it causes a temporary or durable state change in the consumer (B). The consumer is said to be “event-driven,” which really should be called “notification driven.” If the notification is a procedure call, the consumer (B) component is activated. Or, if the notification is data, the consumer is already running, and it reads the event object, for example, by polling a section of memory or reading a file or database.
  4. The consumer (B) does some computation. Optionally, the consumer can discard the notification and return to its prior state without doing anything else.
  5. The consumer (B) may become a notification producer, sending a follow up notification to a downstream notification consumer C (not shown). This would be like a sequence of tumbling dominoes, event->notification->event->notification.

If a component produces an event object and puts it into a data store such as a data lake, data warehouse, database, file or in-memory data grid, without sending it to anyone, there is an event object but no notification. If another component later reads it from the data store, the event object becomes a notification, although it is no longer real-time notification.

Conclusion

Half of the confusion that surrounds event processing would be eliminated if people consistently used the term “event” to mean a happening (or state change); “event object” to mean a software object that documents a happening; and “event notification” or just “notification” to mean a signal that transfers information about an event.

Unfortunately, that is not going to happen.  People will continue to use the term “event” to refer to notifications because the habit is widely and deeply ingrained. So my advice is to stop every time you hear or see “event” and figure out if the person means happening, object, or notification. If you see “send an event” you can assume it means “send a notification.” If you see “event-driven,” you can assume it means notification–driven much of the time. Amusingly, the same people who write “send an event” and “event-driven” will generally define event as a state change, avoiding mention of notification. However, you can’t literally send a state change or a happening because they’re abstractions not messages.

This is pedantry, but helpful pedantry because people who are new to the discipline of event processing are put off by the confusion that results from unclear terminology. Moreover, the confusion spills over into the design of systems that process events.

That brings us the second problem mentioned in the introduction: experts don’t agree on the characteristics of “event-driven” (we call this notification-driven), “event based,” or other event processing design patterns.  I’ll summarize some of the key issues in a subsequent article.

Leave a Reply