This chapter is from the book
This chapter is from the book
This chapter is from the book
8.4 Attributes of Events
Rapide-EPL events have a set of predefined attributes that are common to all events. Not all attributes need to have defined values in an event.
Attributes give basic information about events. This includes, for example, their timestamps, their origin (the system component that generated them), their destinations (the components that received them), and information about what events caused them. Attributes give us an ability to write patterns that more precisely match the events we want to match, and to trace through event hierarchies.
There are public and private attributes. Public attributes can be named and used in patterns just like the declared parameters of actions (examples come later). Private attributes cannot be named in patterns—at least, not explicitly. They are used by tools such as the semantic checker to do type
Table 8.1 shows a complete list of the predefined attributes. The ones that are starred (*) are private and cannot be used to write patterns.
Table 8.1: Predefined Attributes
|
Attribute Name |
Meaning |
|
Name |
Action name of the event |
|
Origin |
Object in the target system whose execution created the event |
|
Thread |
Thread in the target system that created the event |
|
Countervalue |
Counter value of the thread that created the event |
|
archstamp* |
Target architecture information related to the event, such as destinations and connections to destinations traveled by the event |
|
timestamp start, end |
Start and end times of the event according to clocks in the target system |
|
causality |
References to immediate predecessors in the causal history of the event |
|
point-of-creation* |
Method call in the target system that created the event |
|
declaration* |
Reference to the action declaration defining the subtype of the event |
|
trigger set* |
References to events that were aggregated to create this event checking or the pattern matcher to compute causal history, or animation tools to display event movements on architectural diagrams. |
The meaning or interpretation of event attributes must be defined for each target system. Interpretations of most attributes are defined in adapters, whose job is to monitor the target system and translate the target system's events into Rapide-EPL events (we will discuss adapters in detail later).2 In some cases, an attribute may not be meaningful for a particular system. Attributes all have default initial values. So, if an attribute isn't defined for some target system, its value in all the events will be its default value.
The interpretation of attributes such as origin and archstamp can vary greatly in different target systems. For example, an origin could be a module in one system, an application in another, and a thread in a third. The timestamp attribute can give an interval consisting of the start and end times of an event with respect to a clock. If there is more than one clock, there may be multiple timestamps, one for each clock, giving a time interval from the reading of one of the clocks together with a reference to the clock.
The causality attribute refers to the events that had to happen in the system for this event to happen. It is often a vector of event Ids. The interpretation of "had to happen" is system dependent and will be incorporated into the adapter for events in that system. The trigger set is a set of references to events that triggered an aggregation rule to create this event. A trigger set encodes hierarchical aggregation (or vertical causality, Section 1.3.2) and is available to tools that make drill-down tracking possible.
The interpretation of event attributes may depend upon the programming language in which the target system is written, its components (such as the networking middleware), and its architecture.