Scope
Events are perceived changes in the world around, which means representations will always play a part. As far as systems are concerned, that part is defined at two levels, first when events are registered at entry points, and then by their representation as symbolic objects.
Actual vs Symbolic Events
Events happen all the time, which is to say that time is punctuated by events. That makes for a classical chicken-and-egg situation, and it can be said that time is made from events, or, speaking of business events, time is money. So, in order to describe when activities are to be executed, the first thing to do is to single out the subset of events worth of some business attention.
- Actual events are associated with changes in the state of external objects or activities, including agents’ expectations.
- Symbolic events are associated with changes in the state of symbolic objects or activities.
At this stage it must be noted that external events can be associated with symbolic objects (e.g contractual agreements) and symbolic events can be associated with actual objects (e.g change in agents’ expectations). What matters is the relationship with their system representations; to be defined by the synchronization of business activities.
Combined with source, that provides for a preliminary qualification of events:
Events associated with changes in actual contexts (objects state or execution status of non symbolic processes) can only be known when captured (or polled) through actual entry points. Moreover, since they cannot be directly interpreted before being translated into symbolic meaning, there is no guarantee that other events will happen during the interval. Time events are a special case as, despite being released by physical devices, they come with instant meaning.
Events associated with changes in symbolic representations of persistency or execution units can be known without delay and processed accordingly, i.e as if nothing relevant could happen between the event and its processing. User generated events are a special case as, despite being sourced from actual contexts, changes in expectations are necessarily symbolic and can therefore be instantly processed.
The introduction of the Internet of Things (IoT) puts a new light on physical events which can be captured by devices before being translated and transmitted across distributed systems as messages, i.e symbolic events.
Once the nature of events properly understood, and stereotyped events will help, the point is how they will appear within models.
Events Representation
As far as modeling is concerned, external events appear under three different guises: as they occur, as they are taken into account, as they are recorded as non mutable symbolic objects.
Unfortunately events don’t come flag-waving their credentials. So, if they must be dealt with “on arrival”, only two criteria are at hand for consideration: if their source is known, and how to proceed with their interpretation.
Regarding origin: actual (aka external) events are issued by objects and agents, internal (aka symbolic) ones mirror changes to symbolic representations. As far as the architecture is concerned, we need only to consider external events.
Regarding their consequences, one must distinguish between events bound to objects, active or passive, and events free of direct attachment.
- Signals are physical events which must be translated into logical ones before being processed. That should be done immediately lest the signal, once translated, could make the processing obsolete.
- Change events are signals bound to passive objects. Time events are a special case of change with instant meaning associated to dedicated devices.
- Messages dispatch and reception are logical events subject to interpretation. They change the information available to agents.
- Requests are a special case of message pertaining to changes into agent expectations.
Derived Events
Derived events are triggered by primary ones and are supposed to happen necessarily and simultaneously. They may be subject to business conditions as far as those conditions can be evaluated at the time and location of the primary event; hence, the occurrence of a derived event can be established with certainty whatever will occur in between. Derived events can be defined using logical operators, with or without qualifications: alternative events are meant to happen when one of a set of possible events occurs, join events are meant to happen when all necessary events have occurred.
It must be noted that join derivation rules can only apply to “live” events, i.e events whose actuality doesn’t expire instantly.
The characteristics of external events will determine the constraints on architectures and the kind of devices required on system boundaries.
Events & Contexts
Since events are defined by clocks and locations, their modeling is necessarily relative to systems: the same phenomenon may be perceived as different events by different systems. For instance, a robot on its own will only deal with actual event through its sensors. When other robots or supervisors are involved, other kind of events will have to be taken into account.
- Actual events are changes in context as perceived by sensors (visuals and sound).
- While actuator events (arm and motor) are local to the control unit and are not represented, their actual effect must be communicated to the handling system as a change in context (robot events). They must also appear explicitly when originated from the handling system (control events).
- The handling system records events and execution states, but the robot only keeps memory of execution states.
- Assignments of roles to robots appear as events as well as records.
