Back to the less global issues, I continue the previous posting that follows chapter 4 of the book "Event Processing in Action" that Peter Niblett and myself are writing.
This time, I'll get one level deeper into the information we have found useful in describing events.
This is a figure taken from the book, showing different information that an event may contain. We partition the information into three types: header, payload, and event to event relations.
The header concept, taken from the messaging world (but used also in file systems) contains information that answers the following questions:
- What is the event type of this particular event ?
- Is it a composite event (i.e. composed of another event) or not.
- What is the temporal granularity (chronon) of all time stamps in this event. For some applications the granularity of time stamps should be 1MS, in others a granularity of 1 minute is sufficient, and surplus of information is not helpful. This may be an application default which can be overridden in the level of the particular event type.
- What is the occurrence time of the event (when did it happen in reality) ?
- What is the certainty that this event has occurred ?
- Is there an annotation associated with this event ?
- What is the unique event identity generated by the system ?
- When did the system detect that this event has occurred (note that the actual semantics of this information is implementation dependent, it may be when the event hits the system's API, when the event has been put into the engine's execution queue, or any other interpretation).
- Who emitted this event ?
The payload part of the information consists of attributes that provide additional information about the event, each attributes has a data type, and may have a semantic role (e.g. reference to some entity).
The event to event relations information enable to define event types as specializations or generalization of other event types, and classify a particular event to a super-type (possibly when some condition is satisfied). Also an event can have retraction relationship to another event, i.e. it is a logical cancellation of a previous event (I have referred to it in the past as converse event, but my co-author Peter Niblett, who is a very keen on terminology precision convince me that "converse" is a symmetric relation, while we mean here anti-symmetric relation).
In the book we show how these events are defined in a use case, using our definition elements language. We intend also to add to the book code samples from various products.