Event Processing in Action review, part 2

Per my previous post, I’m currently reading a preview copy of Event Processing in Action (EPIA) from Manning. I’ll write a short summary mixed with review, composed of several posts.

Unfortunately, the name of Manning’s “In Action” series was ruined for me by a book from another publisher; I just can’t read In Action without thinking Inaction. I will try to put this prejudice aside.

I only have time to go into Chapter 1 right now. I doubt that I’ll have time for one post per chapter, but this one turned out longer than I thought.

The book starts slow, because the authors are very thorough about capturing the basics. Chapter 1 is mostly an introduction to terminology. It also goes into many examples of Event Processing in use today. Finally, it introduces an example Event Processing application (a flower delivery service) that will be used throughout the book.

As I’m already familiar with event driven systems, some of the pages on terminology were a little boring. At the same time, the level of detail and the real world examples are great for a less experienced reader. This book has an academic flavor, and I’m the type to read through the boring introductory chapter of a textbook before getting started on the subject. That’s because I do learn a little (maybe more than I realize at the time) and it gets me on the same page (so to speak) as the author for the rest of the book.

So from Chapter 1, I see that Event Processing in Action is about events and the processing thereof. These “events” are the same ones that drive an Event Driven Architecture (EDA). The point of the book is to look beyond the basic pattern of EDA logic that says “send an event and interested parties will eventually receive it”. Beyond this simple pattern lie many patterns of processing logic that are common to most or all event driven systems.

For example (and I’m extrapolating a little here), as an Event Driven Architecture implementation grows and matures, there’s a natural desire to extract more and more information and value from the event flow. Where each event type may have started with just one interested consumer, others find uses for existing events.  Architects start devising applications that combine and rehash events in new ways. Often an EDA is adopted with grand visions of squeezing ever increasing value from events.

Over time, we see common patterns in the logic used to extract information from events in the EDA. We can use those patterns to design the logic at a higher level than code and code-level design patterns. We can use our logic designs to compare the goals and the logic of our EDA to another EDA, and to learn lessons and develop best practices for exactly how we will extract more value from events. Those logic patterns and their use is the core of … Event Processing.

One might not be interested in an EDA per-se, but still want to extract information and value from events. The most common example seems to be automatic (electronic) trading (other examples are listed in Chapter 1). Trading systems get events (mostly feeds of quotes, news and order executions) and extract information from them. While the media seems to focus on the mathematics, the fact is that most of the logic of trading is exactly the same as logic that extracts information from events in any EDA. The former deals with feeds and trading connectivity, the latter with message buses and shared event definitions. Trading may require maximum performance, an EDA may require guaranteed delivery. But mostly they share patterns in the logic, because they are both doing Event Processing.