El cooperativismo en Entre Ríos

In our approach, we separate the detection of significant changes from the reaction to them. We encapsulate the functionality to monitor specific aspects of the local or global system state in

monitorlets while watchdogs encapsulate reactivity. Their design is the same for centralized or

distributed setups and inspired by the concept of eventlets introduced by Appel et al. [18, 19, 20]. As shown in Figure 4.12, watchdogs and monitorlets are complementary. The local state refers to a single broker while the global state refers to a network of brokers in a DEBS, where we use a novel approach to monitor the global state of the system and implement monitorlets.

Watchdog Monitorlet Monitorlet Capability Capability Watchdog observe simple condition update update query query observe complex condition

Renegotiation Local_state Global _state

trigger update

Single broker Broker network

Expectation Expectation

initialize condition initialize condition

Figure 4.12.: Runtime monitoring using watchdogs and monitorlets.

A watchdog is bound to at least one expectation and observes the current value of one or more capabilities. Each watchdog is initialized with a simple or complex condition to check; it triggers a renegotiation of its associated expectation(s) or updates the global system state if that condition is met. Simple conditions refer to only a single capability, e.g.,Ce

k.C V < x ∨ C e

k.C V > y, while

complex conditions do also include multiple capabilities. The capabilities to observe and the condition to check are based on the associated expectation(s). The lifecycle of a watchdog is tied to the lifecycle of its initializing expectation(s) and a watchdog is destroyed by the MOM as soon as all of its initializing expectations are revoked. While each expectation is active, however, the conditions the watchdog has to observe can change with updates to the expectation.

For example, a watchdog for a satisfiable expectation triggers a negotiation of this expectation as soon as the current values of capabilities are within the range of allowed values; conversely, a

watchdog triggers the renegotiation of a satisfied expectation if it observes that the current value of a capability exceeds or falls below the range of allowed values defined for a requirement.

Monitorlets, in turn, act independently of expectations and do not trigger reactions. A monitorlet

is responsible for updating the current state of a capability so that it can be observed by watch- dogs and used by the MOM during the runtime negotiation phase. For this, monitorlets either query the local state of the broker or the global state of a DEBS. Examples are: the current forwarding and publication latency of notifications provided by a given publisher; the sampling rate of a single publisher for a given type of notification; the number of publishers currently providing notifications of a certain type; or the number of subscribers currently subscribed for a certain type of notification and set of requirements. Monitorlets are instantiated by the MOM at runtime when necessary. For example, they can be initiated upon pre-defined events by the MOM, e.g., subscribers or publishers joining the system for the first time. All monitorlets directly associated with capabilities of a publisher are destroyed when this publisher disconnects.

The way watchdogs work is illustrated in Figure 4.13 with an example containing one pub- lisher and three expectationsXe

a,X e

b, andX e

c. A single publisher is providing notifications that fit

the other requirements defined in these three expectations; its sampling rate is monitored by a dedicated monitorlet, which has been initialized by the publisher sending a new advertisement. In our example, each expectation defines a requirement about the sampling rate over a closed interval of allowed values (shown on the right hand side of Figure 4.13). Thus, three watchdogs – w_a, w_b, w_c– are associated with these expectations and this publisher. Each watchdog observes the current value of the capability sampling rate of this publisher and triggers a re-evaluation of its associated expectation if the monitored sampling rate enters or leaves the range of allowed values defined in the associated expectation.

Sampling rate Time 10 20 30 40 50 Condition satisfied Xea: [30; 35] Xeb: [30; 50] Ranges required Xec: [20; 40] wa wb wc Watchdogs t1 t2 t3 t4 t5

Figure 4.13.: Example for watchdogs detecting satisfied or unsatisfied conditions.

In our example, the sampling rate increases and decreases over time. At starting time, the sam- pling rate is too low to satisfy the requirements of any expectation, rendering them all unsatisfied. Thus, each watchdog is initialized to trigger a renegotation if the sampling rate is equal or greater than the lower bound defined in each expectation.

The first watchdog to trigger a renegotiation of its expectation is w_c at t₁. As the sampling rate requirement defined inXe

c is now satisfied, wc is changed to trigger a renegotiation of Xec

as soon as the sampling rate becomes greater than the upper bound or lower than the lower bound. While this event is not detected for w_c it is for the other watchdogs. Watchdogs w_a and wb trigger renegotiation at t2 to satisfy Xea and X

e

b respectively. The necessity to change

their triggering conditions becomes apparent at t₃ for w_a as the still increasing sampling rate exceeds the range of allowed values defined inXe

a but not that defined inX e

b (watched over by w_b). Now, the condition for w_a is changed again so that the watchdog can detect the sampling rate entering the range of allowed values again at t4. Both watchdogs wa and wb now have to

trigger a renegotiation of their expectations again at t5 as the sampling rate drops below the

lower bounds defined in the associated expectations.