6 Introduction to Eventing

 

This chapter covers

  • The nature, purpose, and anatomy of CloudEvents
  • A basic walkthrough of creating CloudEvents and using triggers
  • The major subcomponents of Eventing

Here comes the next big section. I approach it with some trepidation.

In some sense, Serving is simple: do a thing. Eventing is: say a thing, hear a thing. In Serving, the intention to do and thing done have a relatively predictable temporal coupling. But in Eventing, I can be saying things long before these are heard. I can listen for things that will never be heard. I can hear things long since said. The shoe store point-of-sale system can emit events for sales before the sales forecasting system exists to process events. The inventory system can listen for stock shrinkage alerts that might not occur. And so on.

The underlying model of Eventing is this: things happen in the world. Some of these happenings are observed. Some of these observations are transmitted from place to place. Receivers of the transmission read the observation, deduce some state of the world, then perhaps take actions. These actions perhaps cause still other observations to arise.

6.1 The road to CloudEvents

6.2 The anatomy of CloudEvents

6.2.1 Required attributes

6.2.2 Optional attributes

6.2.3 Extension attributes

6.3 A word about event formats and protocol bindings

6.3.1 Structured content mode

6.3.2 Binary content mode

6.3.3 Batched content mode

6.4 A walkthrough

6.5 The basic architecture of Eventing

6.5.1 Messaging

6.5.2 Eventing

6.5.3 Sources

6.5.4 Flows

6.5.5 Duck types

Summary

References

sitemap