La inmigración como rasgo de la identidad provincial

In the runtime negotiation phase, a single expectation is negotiated at a time. This negotiation results in a preliminary adaptation plan for the expectation. The adaptation plan contains all actions that have to be executed for a set of capability profiles to satisfy the expectation: changes to the routing table for those publishers that have capability profiles which already satisfy the expectation; other actions for those capability profiles that require adaptation. The set of actions is empty if the expectation is declined or cannot be satisfied even with adaptation as described in Sections 4.1 and 4.2.

The last step of the runtime negotiation phase takes care that executing actions does not violate constraints. Constraints stem from requirements defined in expectations as well as local or global constraints imposed by the MOM due to budgets or load-balancing considerations. We refer to this process as safeguarding.

Three examples illustrate such constraints:

• Advising one publisher to increase the sampling rate to satisfy the expectation currently un- der negotiation might violate requirements about sampling rate defined in already satisfied expectation.

• Advising several publishers to increase their sampling rate in order to satisfy a requirement about alternatives might saturate a network link or broker and violate requirements about latency and completeness [173].

• While the MOM can apply content aggregation or traffic shaping to satisfy requirements about the latency of notifications, effectively reducing the number of processed notifications can violate requirements about the sampling rate [138].

During the safeguarding process, we try to detect such violations of constraints and adjust the adaptation plan accordingly. We decline the expectation as unsatisfiable if severe violations cannot be avoided without emptying the adaptation plan. The feasibility and complexity of the whole process depends on the custom decision strategy that is used.

In general, simulating the effect of adaptations before actually executing them or predicting their impact on local or global constraints should be part of this process. However, this requires complex performance and system models for EBSs and Distributed Event-based Systems (DEBSs) to capture cause-effect relationships and make proper predictions. This actively pursued field of research is out of scope of this dissertation and we refer the interested reader to [72, 202, 258, 305, 311, 367, 388, 410] for further information.

General Safeguarding Approach

In the remainder of this section, we describe the general safeguarding approach and show where custom performance models and load-balancing approaches can be integrated. The sequence of operations in our safeguarding algorithm is shown in Figure 4.8.

Safeguarding starts with parsing the initial adaptation plan that has been compiled during the range-matching step described in Section 4.1.2 and the decision step in Section 4.2.

We rank all capability profiles affected by the adaptation plan according to a custom ranking function. Starting with the top-ranked capability profile, we iteratively check whether the actions defined for each capability profile would violate any global or local constraints.

Runtime negotiation Matching expectations to capabilities Safeguarding decision Decide on satisfiable expectations 4.1 4.2 4.3 Safeguarding decision

Final adaptation plan

rank affected CPs check for violations return adaptation plan no violations adjust adaptation plan violations {a1, . . . , am}

initial adaptation plan

{a1, . . . , am} resolved decline as unsatisfied unsolvable LB = Load-balancing LB LB LB

Figure 4.8.: Steps to safeguard the adaptation plan.

If we detect such violations, we try to adapt the adaptation plan. For example, we could try to use alternative actions as those currently defined or we could exclude the current capability profile from the list. Finally, we end with a safe adaptation plan that we proceed with as the final adaptation plan. The safeguarding algorithm rejects the expectation as unsatisfied if the violations cannot be resolved. In this case, the final adaptation plan would be empty.

Integrating Load-balancing

Custom algorithms for load-balancing can be integrated in all steps of the safeguarding process to distribute the load between different publishers or brokers. The ranking function allows for encapsulating load-balancing aspects first and foremost. For example, the capability profiles could be ranked based on their adaptation costs in ascending order to avoid expensive publishers to be chosen first. Alternatively, ranking could be based on the utilization of the publishers associated with each capability profile the action is targeting. Using the FIT-score [169], ranking could be done in ascending order to choose less critical publishers first (as a high FIT score indicates a high criticality) while ranking in descending order would start with more critical publishers. Another possibility would be to rank publishers based on their trustworthiness score in descending order. Alternatively, load-balancing can be included when checking for violations or it can be used during the purging step in a similar way as during the initial ranking step. Please note the difference between load-balancing in this section and load-balancing as part of the decision mechanism discussed in Section 4.2. There, we sketched out how load-balancing considerations can be included into the decision process of deciding whether the system should adapt to enforce satisfiable requirements or not. By contrast, including load-balancing here aims at how the expectation is going to be satisfied.

Example: Detecting and Resolving Violations for Alternatives

We illustrate the safeguarding process by describing how we avoid violations of the alternatives requirement when assuming the simple decision strategy we describe in Section 4.2.2.

When defined over a closed interval, the alternatives requirement can be violated by routing notifications from too many publishers to a subscriber i. This can be avoided by checking the size of|CANDXe

i| and |CANDX e

i|: if the size of CANDX e

i already exceeds the range of allowed values,

we do not have to adapt any further capability profiles from this list. Rather, we have to limit the number of satisfying publishers that i receives notifications from. Conversely, if the sum of satisfying and capable publishers exceeds the upper bound of the requirement, we have to limit the number of capability profiles in C_ANDXe

i to adapt 5_.

In both cases, all required information is available in the preliminary adaptation plan: routing actions for satisfying capability profiles and other actions for capable capability profiles.

Thus, the basic algorithm we use for this is as follows:

1. Rank all capability profiles in the adaptation plan according to a ranking function

2. Iteratively check and resolve violations for requirements about generic properties other than alternatives

3. Keep only the top-k capability profiles, delete all other from the adaptation plan

Here, k defines the upper bound defined for the requirement about alternatives if defined over a closed interval. This way, we keep only the maximum number of capability profiles allowed by the subscriber.

5 _{Please note that for load-balancing reasons we could also decide to adapt capable publishers first and deactivate}