- The fifth example demonstrates the usage of an event server and an event client ports.
- The event pattern supports asynchronous notifications. An event activation provides a parameter set for the event condition. The event condition is checked at the server side. An event activation fires as soon as the event condition becomes true under its individual activation parameters.
- The returned communication object can contain any required information about what caused the event to fire. As with the push pattern, the server is the active part and the server decides on when to check the event condition. The event pattern, however, does not distribute the same data for every subscribed client, but provides individual answers for each firing activation.
- An event server can have multiple activations even from different clients each with their own parameters for the event predicate. Each activation is checked individually and fires only according to the individual activation parameters. A single event server can therefore be used to report on different event parameterizations. For example, an event that checks a value against a threshold can be activated multiple times with customized thresholds to report on different levels reached.
- Events are, for example, used for vertical communication between components. They are used to synchronize continuous task execution progress with a discrete description of task plots (for example based on state charts or task nets).
- Events are also used to monitor battery voltage, for example. The server side knows when to check the activated events. Each event activation is based on the same predicate (condition to be checked) but can comprise its individual parameterization. For instance, one activation can check whether voltage drops below a warning threshold, another activation of the same event can check whether the voltage level is below a critical threshold and another activation can be parameterized such that it reports when voltage is again in the expected range.
- The client side template of an event is instantiated by the communication object for the event activation parameters P and that one for reporting the fired event E. The server side additionally requires the state description S which is the basis for testing the event predicate (see testEvent method in figure above).
- Each activation can be individually set to either single or continuous mode. In single mode, it is the event pattern that makes sure that an activation fires only once irrespective of the results of the event predicate at further tests. In continuous mode, only the latest firing of an activation is kept to avoid boundless growing of buffers. The users either have to use the handler based interface at the client side in case no firing can be missed in continuous mode or they simply specify the returned event object such that it contains the state instead of reporting on state changes. Then the latest event contains all necessary information irrespective of previous firings.
Advanced Event Pattern characteristics
A crucial part of the Event Pattern is the testEvent(...) function on server side that controls whether events for a specific client are fired. Depending on the implementation of this function the events behave in a different way. In the following typical types for this function will be presented and the implications of them will be discussed.
Again an event can be activated in single or continuous modes. In addition the test-function can be implemented with or without state. This means that the state history is either taken into account or not (see table below). This implies some details that a user has to take into consideration.
|single||fire once as soon as a specific state is reached||fire as soon as a specific state change is performed|
|continuous||fire continuously as long as a specific state is true||fire each time the test-function detects a state change|
Although there are four combinations only two of them are reasonable in many cases. For the single mode the stateless test-function makes most sense. In this case, one typically wants to be informed of reaching a certain state (e.g. low voltage on the battery, or reaching a location). Whether this state was true before activating the event does not matter, the result is the same. The continuous mode on the other hand is most valuable if the test-function takes the previous state into account. In this case, one typically wants to be informed every time a state has changed (e.g. entering and leaving a region or value of interest). Continuous firing being in the same state often does not make sense, because there are hardly new information. This is different of course if in addition to the state for example a current position is transmitted within the event answer parameter.
Nevertheless all four cases are not conflicting and allow to implement flexible event servers.
A testEvent(...) function that takes former states into account can be implemented as follows. First the client has to activate the event with a predicate initially set to neutral state. This allows the server to signal every state change different to the neutral state. This is the case at the first event check (see figure below).
The event predicate additionally allows modifications of the activation parameters which is useful to implement a state based event by memorizing states in the parameter communication object (see IntervalTestHandler-example and PhD thesis on pages 110-111).
The event predicate is checked at the server side each time a new state description is provided via the put-method. It is important to note that the client-side activation of an event does not result in the check of the event condition! The reason is that only the server knows when it makes sense to invoke such a check by providing new state information via the put-method. Therefore, an already at activation time fulfilled event condition is reported the first time with the next call of testEvent(...).
The client side event pattern provides both, synchronous / asynchronous user called methods as well as a synchronous upcall interface. The handler based interface is particularly useful if one wants to implement a central event dispatcher or if the pattern is used to asynchronously report events and one does not want to wait for the next firing of the event. Once a handler is provided at the client side, each incoming event is forwarded to the handler. Individual activations can always be distinguished by the unique activation identifier which is also forwarded to the event handler.