Creación del Museo y actividades de la etapa inicial

The core of our architecture is an extension to the MOM shown in Figure 5.2 called ExpectationController. It consists of platform-independent components to negotiate expecta- tions with capabilities and a few platform-specific components to enable reactions, e.g., filtering notifications. MOM and participants communicate with platform-specific messages.

An ExpectationController consists of five key components:

• ResourceMonitor: monitors the system state and reports changes to the Registry.

• Registry: stores all necessary state information including expectations and capabilities as well as metadata about participants. Changes trigger runtime negotiation at the Balancer. • Balancer: matches expectations to capabilities and decides on satisfiable expectations. Trig-

gers the ReactionCoordinator upon completion to execute the adaptation plan. • MechanismsRepository stores all applicable actions to manipulate generic properties. • ReactionCoordinator: applies actions from the MechanismsRepository and coordinates

Message-oriented Middleware Interface: ExpectationController Registry

ResourceMonitor _CoordinatorReaction

Balancer Mechanisms Repository ExpectationController negotiate execute adaptation plan update access

broker state broker stateadapt

Figure 5.4.: Design of the MOM extension to enable runtime support for QoI.

The components encapsulated in the ExpectationController require access to the state of the MOM for monitoring the system and to apply reactions like filtering messages or routing adap- tation [172]. The access is provided through an Application Programming Interface (API) by the MOM implementing the ExpectationController interface (cf., Figure A.1a in the appendix ). The methods to be provided by each broker implementing the ExpectationController interface can be categorized into three types: first, forward updates about the lifecycle of expectations and capabilities (e.g., register, update, revoke) to the Registry in a platform-independent format; second, enable the access between different components of the ExpectationController; third, allow for manipulating the routing tables to adapt the routing of notifications.

In the next sections, we are going to present the internal design of each key component in the ExpectationController. We will describe their generic, platform- and application-specific parts as well as their interfaces to each other in more detail.

ResourceMonitor: Montoring the System State

The ResourceMonitor encapsulates the functionality to monitor the system state as described in Section 4.5, report changes to the Registry, and trigger the Balancer whenever necessary.

The ResourceMonitor consists of a set of active monitorlets and watchdogs as shown in Fig- ure 5.5. The lifecylce of each monitorlet is managed by a MonitorletsRepository while a WatchdogsRepositorydoes the same for watchdogs. Each repository stores a set of prototypes. A factory creates, updates or deletes instances of appropriate prototypes whenever necessary. Each instance of a monitorlet keeps a specific capability in the Registry up-to-date by monitoring the state of the broker or the system as described in Section 4.5.1. Thus, monitorlet prototypes are assumed to be platform- or application-specific, e.g., using AdvisoryMessages1on ActiveMQ or ASIA aggregations as described in Section 4.5.2.

Each instance of a watchdog monitors a capability or a set of capabilities based on conditions and triggers a renegotiation of an expectation at the Balancer whenever its condition is satisfied 1 _{http://activemq.apache.org/advisory-message.html}

Monitorlet Prototypes Factory Active Monitorlets MonitorletsRepository ResourceMonitor Monitorlet access state WachdogsRepository instantiate update remove Balancer Registry MOM update capabilities Monitorlet Prototypes Factory Active Watchdogs Watchdog negotiate expectation Monitorlet

Figure 5.5.: Design of the ResourceMonitor.

as described in Section 4.5.1. As watchdogs only operate within the ExpectationController, prototypes for watchdogs do not have to be platform- or application-specific necessarily.

Monitorlets and watchdogs can trigger implicitly or explicitly: implicitly, they run in the back- ground and constantly pull data; explicitly, they are called when some significant event takes place, e.g., an ASIA aggregation update is received.

The granularity of watchdogs can be single or cumulative. Single refers to each expectation maintaining its own watchdog instance; cumulative refers to all satisfied expectations for a certain type of notification defining a single watchdog while also all satisfiable expectations per type of notification share a single watchdog. Single watchdogs reduce the negotiation overhead as they allow for each expectation to be (re)negotiated only if its specific conditions are met or violated. However, depending on the number of active expectations and their size (in terms of the number of generic properties they are defined over), having multiple threads of watchdogs running in the background can increase the resource utilization overhead. Cumulative watchdogs reduce resource utilization as fewer watchdogs are to be maintained. However, the number of unnecessary renegotiations might be higher than for single watchdogs if the ranges defined for the different expectations are not close together.

In our prototypes, and the example described in Figure 4.13, we have used single watchdogs that trigger implicitly by running as daemon threads. Please note that monitorlets and watchdogs could be implemented using eventlets [18] in principle.

Registry: Manage All Necessary State Information

The Registry stores all necessary state information and metadata about the system in one place and independently of the MOM platform or application running on it. As shown in Figure 5.6, this information is not restricted to metadata about subscribers, publishers and neighboring brokers but also includes the definitions of generic properties, expectations and capabilities.

The storage, state and lifecycle management of expectations is encapsulated in an Expectations- Repository. The CapabilitiesRepository is similarly designed for encapsulating the storage

Registry Unsatisfied Satisfiable Population CapabilitiesRepository ExpectationsRepository Satisfied Property Definitions _{Relationships} Prop./Cap. Capability Profiles Expectations BrokerHandlerExpectations BrokerHandlerCapabilities Balancer update capabilities update expectation Resource Monitor Reaction Coordinator

Figure 5.6.: Design of the broker component Registry.

and lifecycle management of capabilities together with the relationships/mappings/transforma- tions between capabilities provided by publishers and generic properties required by subscribers (cf., Section 3.2.2 and fig. 3.8). Access to each repository is provided through broker handlers that offer an API to query and update expectations or capabilities.

The Registry can be accessed by every other component of the ExpectationController. In our reference architecture, the ResourceMonitor is the main contributor to the Registry as it monitors the system state and reports every change to the Registry. The state of expecta- tions is also updated by the Balancer upon completing the runtime negotiation process as de- scribed in Sections 4.1 and 4.2. The state of capabilities, in turn, can also be changed by the ReactionCoordinatorto enforce coordinated adaptation as described in Section 4.4.3.

Balancer: Decide on Expectations and Safeguard Decision

While ResourceMonitor and Registry provide up-to-date information about the system state, the Balancerencapsulates all functionality needed during the runtime negotiation phase: matching expectations to capabilities, deciding on satisfiable expectations, safeguarding the decision, and finally triggering ReactionCoordinator to pass on to the runtime adaptation phase.

The Balancer consists of three components as shown in Figure 5.7.

Decision Strategies Balancer execute adaptation plan ResourceMonitor ReactionCoordinator negotiate expectation Matcher Adaptation plans Solver Guard query actions Registry query CPs decide safeguard

Figure 5.7.: Design of the Balancer which implements the runtime negotiation phase.

The Matcher is triggered by the ResourceMonitor to negotiate a dedicated expectation. For this, it queries the Registry for available capability profiles with a matching set of capabilities to perform the set and range matching steps of the runtime negotiation phase as described in detail in Section 4.1.

The Solver is triggered by the Matcher if the expectation is not yet satisfied but satisfiable. Using predefined decision strategies and custom approaches, the Solver decides whether to satisfy the expectation or decline it as unsatisfied (cf., Section 4.2). The result is reported back to the Matcher, which proceeds with safeguarding the decision by triggering the Guard component. The Guard checks the preliminary adaptation plan for inconsistencies or violations of constraints as described in Section 4.3. It tries to solve violations or inconsistencies by adjusting the actions listed in the adaptation plan. If the Guard cannot resolve the violation of constraints, the expec- tation is declined as unsatisfied. The Matcher is informed about the result in any case, as it has to trigger the ReactionCoordinator to execute the adaptation plan.

ReactionCoordinator and MechanimsRepository: Runtime Adaptation

The ReactionCoordinator is responsible for executing the adaptation plan provided by the Bal- ancer. For this, it relies on the MechanismsRepository as shown in Figure 5.8.

The adaptation plan contains a list of actions that have to be executed to adapt a set of capabili- ties. Each action is associated with at least one capability (cf., Section 3.2.2) in a mapping table. The MechanismsRepository provides generic prototypes of actions to the Balancer for runtime negotiation while it provides executable instances for the ReactionCoordinator to deploy and execute. The interface to implement by each prototype is shown in Figure A.2 in the appendix.

Log Executed Actions ReactionCoordinator ExecutableAction instance MechanismsRepository Action Prototypes Mapping actions to capabilities Balancer

get executable instance

rateController adaptPublisher adjustRouting adjustLatency … … deploy & execute action instance MOM Balancer execute adaptation plan query

Figure 5.8.: Design of the ReactionCoordinator and attached MechanismsRepository. Depending on the type of action, prototypes of actions can be agnostic or specific in regard to the MOM platform or application using the MOM as shown in Figure 5.8. Examples for generic actions are routing adaptation (adjustRouting) or publisher adaptation (adaptPublisher). The former action is generic as its execution is implemented by the MOM itself when implementing the ExpectationController interface; the latter action is generic as well as advising publishers to adapt is independent of the MOM platform or application (cf., Section 3.5.1).

Actions that require an adaptation of the MOM, however, have to be platform-specific at least. In some cases, they also have to be application-specific. For example, sampling rate reduction

(rateController) and forwarding latency minimization (adjustLatency) can be implemented to apply traffic shaping algorithms as described in Section 4.4.1. The way that notifications can be intercepted is platform-specific and has to be implemented in the prototype of the action. The rateController prototype must be application-specific if traffic shaping should be done by aggregating the content of multiple notifications instead of discarding notifications: the se- mantics of the notifications exchanged by the application over the MOM have to be known to the rateController to be able to aggregate the content correctly. The general design of a rateController is shown in Figure 5.9: a rateController instance is deployed for a dedi- cated receiver and intercepts the notifications of a given type before the broker dispatches them. Intercepted notifications are aggregated or decimated.

Notification e1 r1 Type (eg., topic +filter) Receiver … … rateController

Dispatching process broker

Figure 5.9.: Realizing the rateController per receiver and type.

The ReactionCoordinator sequentially executes the instances of the generic actions defined in the adaptation plan and keeps a log of all successfully executed actions for rollback operations. The ReactionCoordinator also handles individual feedback to subscribers about the state of their expectations. As described in Section 3.5.1, this feedback can contain an acknowledgement about the expectation being already satisfied, a list of reasons why it is declined as unsatisfied, or a temporary state (pending), which indicates that the MOM is currently adapting to satisfy a satisfiable expectation.

Executing the adaptation plan and giving feedback to subscriber completes an iteration of the runtime support cycle for QoI requirements we have described in Chapter 4.