Collective Adaptation in Process-Based Systems - IEEE Xplore

2014 IEEE Eighth International Conference on Self-Adaptive and Self-Organizing Systems

Collective Adaptation in Process-Based Systems Antonio Bucchiarone, Claudio Antares Mezzina, Marco Pistore, Heorhi Raik, and Giuseppe Valetto Fondazione Bruno Kessler, Via Sommarive, 18, Trento, Italy {bucchiarone,mezzina,pistore,raik,valetto}@fbk.eu Abstract—A collective adaptive system is composed of a set of heterogeneous, autonomous and self-adaptive entities that come into a collaboration with one another in order to improve the effectiveness with which they can accomplish their individual goals. In this paper, we offer a characterization of ensembles, as the main concept around which systems that exhibit collective adaptability can be built. Our conceptualization of ensembles enables to define a collective adaptive system as an emergent aggregation of autonomous and self-adaptive process-based elements. To elucidate our approach to ensembles and collective adaptation, we draw an example from a scenario in the urban mobility domain, we describe an architecture that enables that approach, and we show how our approach can address the problems posed by the motivating scenario.

Throughout this paper, we emphasize that while collectiveness and adaptability are quite interesting when considered in isolation, they bring new challenges when combined together. To that end, we offer a conceptualization of ensembles as CAS, with several characterizing traits. First of all, the creation of an ensemble is spontaneous, and participants can decide to join and leave an Ensemble dynamically and autonomously. The dissolution of the ensemble is also spontaneous; it can occur because the participants have reached their goals, or because the collaboration has ceased to provide benefits. Furthermore, the collaboration is instrumental towards the fulfillment of individual, diverse goals, as opposed to a global and shared goal, which is instead the case, for example, of swarms [8].

Keywords—collective adaptive systems, self-adaptation, dynamic adaptation, process, composition

Our technical approach to realize the ensemble characteristics listed above is to construct collective adaptation as an emergent aggregation of autonomous and self-adaptive process-based elements. For that, we draw from our previous works [1], in which we described a design for dynamically adaptable service-based applications, in which, however, adaptation was carried out on each single process individually, and CAS aspects were not considered. In this paper, we begin to attack the problem of collective adaptability by extending the process adaptation approach presented in the aforementioned papers, and we propose a novel, decentralized architecture for the proposed ensemble conceptualization that supports those extended process-based techniques. To the best of our knowledge, this is the first work that explores the problem of collective adaptation in process-based systems in such detail.

I.

I NTRODUCTION

Many contemporary software-intensive systems, are approaching ultra-large scale, may operate with a high degree of autonomy in environments whose boundaries are openended, leading to so-called ”systems of systems” [5]. The term ensembles has been used for a few years in the literature to denote this class of very large scale systems, which may present substantial socio-technical embedding [11]. A key requirements for ensembles is the ability to selfadapt, in order to remain robust against the very high degree of unpredictability and variability of their operating environments. In an ensemble, each of the participating entities may be self-adaptive on its own, which may pose at the same time an opportunity and a challenge. The opportunity is that entities within an ensemble can try to achieve their individual goals more efficiently or effectively, by collaborating with other ensemble participants, that is, adapting their behavior to leverage each other’s resources and capabilities. The challenge is that the existence of a collaboration aspect makes adaptation of individuals much trickier. For example, the modification in the behavior of one entity as a result of its own self-adaptation may break the consistency of the whole collaboration, or otherwise negatively affect other participants; or, it may be the participation in an ensemble that creates the need for an entity to self-adapt, to better collaborate with other entities.

II. A. Scenario

We introduce a simple example of a CAS, which we will use throughout the paper to elucidate our approach. We draw our example from the domain of urban mobility. One of the main objectives for urban mobility administrations is the ”smart” integration of various public and private transportation facilities, in order to provide each citizen with options and opportunities to use this integrated mobility system most efficiently. We consider here the means of public transportation called “flexible bus”, or simply flexibus. A flexibus service mediates between trip requests from passengers and transportation offers from owners and operators or mini-buses. The service then organizes custom bus routes to cover the requested trips as efficiently as possible.

That is why we maintain that ensembles should be regarded as Collective Adaptive Systems (CAS in the remainder), that is, a collection of heterogeneous entities that have autonomous goals and behaviors, but, in order to accomplish their tasks and reach their individual goals effectively, must work together as a collective entity [7]. In a CAS, adaptation must be itself collective, that is, multiple participants must adapt simultaneously in a way that, on the one hand, properly addresses an unexpected or critical runtime condition, while, on the other hand, preserves the collaboration and its benefits. 978-1-4799-5367-7/14 $31.00 © 2014 IEEE DOI 10.1109/SASO.2014.28

M OTIVATION

A flexibus service can be designed as a CAS with a number of autonomous entities (such as passengers, buses, flexibus booking system, etc..). Each entity tries to fulfill its own goal (e.g. passengers want to arrive to the intended destination in time), by executing a specific behavior. To address the challenges of the dynamic urban mobility environment in which it is immersed, each entity may adapt its behaviour at run time. We emphasize that all entities in a CAS are 151

autonomous. This means that they execute and adapt their behavior independently from one other; however, an entity may decide/agree to collaborate with other entities with the purpose to accomplish its individual objectives more efficiently, even if that means it may temporarily give up some degree of autonomy. For example, a flexibus route represents a collaboration of several passengers and a bus operator service. When they decide to collaborate within the context of a flexibus route, both the passengers and the bus lose some of autonomy, since they take up some responsibilities towards the other entities; those responsiblities can be regarded as conditions, whose satisfaction ensures that the benefits of the collaboration for the various participants in the flexibus CAS can be preserved.

the “Flexibus Route Manager” entity, whose responsibility is to instantiate a number of flexibus route ensembles, based on trip requests from citizens and transportation offers from bus operators. After ensemble creation, entities may dynamically join the ensemble by choosing to take any of the roles specified. In our example, citizens join a flexibus ensemble with the role of a passenger, and drivers join the ensemble with the role of a bus (each ensemble may be reasonably restricted to have no more than one bus). Within the ensemble, participants remain largely autonomous, but they must respect the ensemble rules. Entities exit the ensemble when their objectives are achieved (for example, all participating citizens have been transported to their destinatin and the bus vehicle is ready for a new route), or when the participation in the ensemble is not anymore beneficial – and additional rules may be used to regulate such withdrawal. The ensemble is terminated when certain termination conditions are achieved (e.g., all participants have exited the ensemble).

Let’s assume now that, due to intensive traffic, the bus may fail to follow its original pick-up schedule, or may even need to change its itinerary. Even though this problem impacts in the first place the behavior of the bus, it ultimately affects all the passengers on the flexibus route. To resolve this situation correctly, it is thus not enough to adapt the behavior of the bus; the passengers’ behaviors need to adapt as well, so that the latter become consistent with the new schedule and itinerary of the bus, and the passengers still can reap some benefits by participating in the CAS.

The aforementioned concepts can be conveniently cast in of process-based terms: we can distringuish in the process specification of an entity some sections (or scopes) where the entity operates as a part of an ensemble. Outside these scopes the entity remains completely autonomous and can adapt without limitations; inside the scopes the entity is additionally constrained by the ensemble rules. By tracking the boundaries of ensemble scopes, an entity can easily discriminate whether it shouls at any time perform adaptation autonomously or collectively.

Generalizing from the example, a CAS participant cannot adapt its behaviour in complete isolation in case of extraordinary situations, because this may negatively affect the goals of other participants, or compromise the whole collaboration. Instead, every extraordinary situation that concerns at least one of the participating entities must be resolved at the scale of the whole ensemble, and changes may need to be simultaneously applied to the behavior multiple participants; those changes, moreover, must respect the specific conditions that participation to the CAS imposes. B. Ensembles In our approach, the behaviors of an entity are specified as business processes, and individual self-adaptation happens by dynamically changing those processes. This requires a process model that enables such dynamic changes. For this purpose, we adopt the modelling approach originally proposed in [1]. – which we will recap in Section Examples of process-driven entities found in our scenario are shown in Figure 2. We can see for example that the passenger’s process includes sequential execution of such activities as book seat, pay trip, go to stop, etc., while the bus’ process includes registration and itinerary request followed by a loop that encodes driving through the bus stops while picking up/dropping off the passengers.

Fig. 1: Ensemble LifeCycle.

According to our conceptualization, an ensemble is a specification of how a certain type of collaboration occurs between several entities, in terms of a set of roles that can be taken by participating entities, and a set of rules regulating the operation of participating entities. Rules capture the potential need to trigger adaptations to multiple participants, whenever an ensemble participant in a given role self-adapts, and modifies its own behaviour in non-compliant ways. Roles and rules represent a layer on top of individual process-based self-adaptation, and support the collective adaptation of the ensemble. The life cycle of an ensemble is depicted in Figure 1. The creation of an ensemble is triggered by some entity (creator) which recognizes the emergence of a need for collaboration, or whose role is explicitly to facilitate such emergent collaborations. In our example, we assume such a role for

III.

R ELATED W ORK

Works that introduce the ensemble concept are very recent. With SCEL [10] it is possible to define ensembles as a set of components, and the choice of which components participates at runtime to a certain ensemble is based on the satisfaction of certain predicates. Adaptation has to be programmed at the level of each component, while our approach is more generative, thanks to the goal based/AI planning approach. [2] presents an ensemble based component model, based on the idea that the only way for components to bind and communicate is via an ensemble. Hence an ensemble embodies a dynamic binding among a set of components and

152

appear in process specification) for the following reasons. First of all, since a critical change can appear at any point of execution, alert senders and handlers would be likely to appear at numerous points in the process. Second, in processes with flexible structure every change in the process structure would be followed by a significant (and hard to automate) overhead of re-encoding signalling activities. Third, every change in the signalling model of the ensemble would require a lot of effort to re-design processes to reflect these changes. Finally, such approach would add a lot of process logic that has nothing to do with the process business goals, and distract the designer from modelling the business logic. As a result, we conclude that inter-process signalling must be processed as a part of process execution routine by the process engine.

thus determines their composition and interaction. As in [10] the membership to a particular ensemble is determined by predicates. Moreover, components belonging to an ensemble are not able to direct communicate with each other, there has to be a ensemble coordinator that is in charge of sharing the knowledge among all the participants. This last issue is in contrast with our idea, in which cells participating into an ensemble maintain their autonomicity and can interact each other directly. [6] gives a formal foundation for ensemble modelling. An ensemble is defined in terms of roles and role connectors. A role can be seen as a meta-component (or a type) that can be instantiated by components of different types. Role connectors specify the I/O operations among roles. A role is endowed with a cardinality, thus it is possible to control at runtime the number of component playing a particular role. Moreover the runtime behaviour of an ensemble is given by means of an automaton. Noteworthy, a component participating into an ensemble can adopt a role (either by entering into an ensemble or by playing an additional role) or can drop a role. The idea of role is close to ours, but in our approach instead of defining connections among roles in the ensemble, we specify consistency rules for the adaptation, by leaving to cell the freedom of interaction.

A. Context-Aware Adaptable Processes In this subsection we recap the idea of context-aware adaptable processes as it was introduced in [1]. Context-aware processes are accompanied by an explicit domain model (that represents the operational environment of a process) and are annotated over it. This architecture makes it possible to detect run-time violations and dynamically adapt process structure to new conditions. A domain model is a set of domain objects, each reflecting a relevant aspect of the environment. Formally, each domain object is a state transition system that is defined as follows:

The problem of collective adaptation has been studied in various domains like Swarm Intelligence, where entities that are essentially homogeneous, are able to adapt their behavior considering only local knowledge [3], [8], or Autonomic computing, where the entity types are typically limited and the adaptation is guided by predefined policies with the objective to optimize the management of the system, rather than evolve it [9]. Among these, our approach to ensembles is most similar to the latter; however, we do not aim at prescribing or prohibiting any actions specified within the processes defining the behavior of any ensemble participants, nor the dynamic changes to which those process are subject due to their adaptivity; we are rather interested in putting in place another adaptation loop that influences the collective entity of the ensemble as a whole, in order to preserve its correct operational semantics [4].

Definition 1: (Domain Object) A Domain Object is a tuple o = L, L0 , E, T , where: L is a set of object states and L0 ⊆ L is a set of initial states;

•

E is a set of object events;

•

T ⊆ L × E × L is a transition relation.

In general, the overall domain comprises a set of domain objects O, and hence, the domain state results from the combination of the states of its domain objects (i.e., L =  o∈O L(o)).

The results obtained in all of the previous approaches and domains tackle only some of the individual challenges defined in the motivation section. For example, while they focus of research on adaptation has not been put on adaptive behavior of the composite system yet, but is limited to the definition of adaptation solutions for individual entities, we want to move from individual-based applications to collective systems proposing also adaptation techniques that support adaptation of ensembles. IV.

•

We use the same model for both processes and process fragments (in definition, we use term fragment). Conceptual difference is that processes represent a behaviour of some entity (and are executed), and fragments are pieces of process knowledge indicating how to accomplish a certain task. Formally, fragments are state transition systems, where each transitions correspond to activities. We distinguish four kinds of activities: input and output activities model communications between processes; concrete activities model internal elaborations; and abstract activities correspond to abstract tasks in the process. Abstract activity makes process structure dynamic. It stands for a task whose implementation is not known a priori and must be derived at run time (e.g., through fragment discovery/composition). Fragments are linked to the domain model through domain annotations: each activity may have precondition (encompass domain states where execution is allowed), effect (domain events triggered), compensation (domain states where activity is considered to be compensated); abstract activities must have a goal (expresses domain states to be reached as an activity objective):

T ECHNICAL A PPROACH

Our approach to collective adaptation consists in organizing some sort of signalling between entities participating within ensemble. Processes can promptly notify each other of critical changes and proactively react to them altogether. In terms of ensemble scopes described in Section II-B, when a process is outside any ensemble scope, it acts completely autonomously, and when it is in some ensemble scope it takes responsibilities of 1) issuing certain alerts to other processes in case of critical events and 2) handling alerts coming from other processes. Such signalling and signal handling is far from trivial. It can hardly be realized as a part of processes themselves (i.e., where alert sending and handling explicitly

Definition 2: (Process Fragment) Process fragment defined over domain O is a tuple p = S, S0 , A, T, Ann, where: 153

Fig. 2: Collective adaptation in the urban mobility scenario.

•

S is a set of states and S0 ⊆ S is a set of initial states;

•

A = Ain ∪ Aout ∪ Acon ∪ Aabs is a set of activities, where Ain is a set of input activities, Aout is a set of output activities, Acon is a set of concrete activities, and Aabs is a set of abstract activities. Ain , Aout , Acon , and Aabs are disjoint sets;

•

T ⊆ S × A × S is a transition relation;

•

Ann = Pre, Eff, Goal, Comp is a process annotation, where Pre : A → L∗ is the precondition labeling function, Eff : Ain ∪ Aout ∪ Acon → L∗ is the effect labeling function, Goal : Aabs → L∗ is the goal labeling function, and Comp : A → L∗ is the compensation labeling function (L, L correspond to states and events of underlying domain O);

this technology is that concrete fragments can be composesd for abstract (implementation-independent) goals. The overall application is modelled as a set of entities (flexibus route manager, passengers, buses, etc..). Entities can join and exit the application dynamically. Each entity includes its domain model, a process encoding its behaviour, and a set of fragments advertising the functionality that the entity provides: Definition 3: (Entity) An entity  is a tuple  = p, F, C  where p is the entity behaviour (i.e., process), F is a set of process fragments provided by the entity and C is a set of domain objects that characterize the entity itself (i.e., Bus Status, etc..). An entity life cycle consists in executing its process over time and exploiting fragments of surrounding entities to adapt it. The domain model of an entity also evolves over time (changes its state), either due to process execution or due to exogenous events that are external to process execution.

In our previous works, we generally distinguish three types of execution violations: 1) the precondition of the next action is violated; 2) the partner communicated by the next action is not available; 3) the next action is an abstract action that is not yet refined. There are also several types of adaptation mechanisms proposed. For instance, an abstract activity is replaced (or refined) at run time with a fragment composition achieving the abstract goal of the activity. Domain annotations and domain model are used to perform such composition. In brief, knowing 1) the current domain state and goal domain states, and 2) the set of dynamically discovered fragments (which are properly annotated), we can produce a fragment composition that brings the domain to the goal state. The advantage of

B. Domain-based signalling Domain model can be seen as a layer of abstraction on top of processes and fragments that is used to express their functional properties in implementation-independent (abstract) way. We believe that such abstraction layer can be efficiently exploited for the purpose of inter-process signalling. The way our adaptable processes work suggests that process adaptation is efficient only when the critical changes are promptly 154

adaptation, in the result of which, the itinerary is updated using another fragment of the Flexibus Route Manager (7) and the execution is resumed. As we can see, a single problem was resolved by adaptation in multiple processes/entities. In addition to the rule 1 used in Figure 2, we can introduce some other useful collective adaptation rules:

reflected in the domain models of the relevant entities. Otherwise, a process may continue its execution under wrong assumptions about the state of the world. To enable proactive adaptation, we introduce a mechanism for sharing critical changes between the domain models of various entities to spread the awareness. We implement this mechanism as a set of collective adaptation rules that encode causal relations between different domain events. These rules must be considered as an integral part of ensemble and are provided by the ensemble designer. In simple words, when an event happens in the domain model of some entity, the rules indicate which other events in the domain models of other entities have to be triggered. Once the rules are applied, all the entities in the system end up with up-to-date domain models and continue operating autonomously (this includes adaptation to domain changes). As it will become clearer from the example, the two important points of our approach is that the 1) collective adaptation rules are detached from process logic and can be modified with minimal effort and 2) entities remain autonomous in how they react to critical situations. The syntax of the language to express collective adaptation rules is shown in Figure 3. We can see that a rule cr contains two parts: crl specifies the triggering, and crr specifies the events that are triggered. Both parts can operate multiple entities by using quantifiers and include conjunctions (disjunctions are prohibited since they would do rules ambiguous). For that purpose we introduce entity roles and universal and existential constructs. Roles r are used to distinguish different types of entities to refer to them in quantifier constructs. Universal construct (∀r.e) stands for event e happening for all entities with role r, while existential construct (∃ r qn .e) limits event occurrence to limited number of role representatives. The universal construct may appear both in the left and right part of a rule, and the existential construct may appear only in the left part. We use the dot notation to identify an event by a domain object, to which it belongs (e.g., o.e means event e belonging to object o). cr crl crr qn

::= ::= ::= ::=

crl → crr ∃ r qn .e | ∀r.e | n|

∀r.e | crr ∧ crr n|

= n

Fig. 3: Syntax for collective adaptation rules. Example. Fig. 2 shows an example of how the collective adaptation works. Each entity has its own domain model and a process annotated over this model (annotation legend is attached). Moreover, each of them runs its process and adapts it in case inconsistencies are detected (e.g., abstract activity pay trip is refined with a fragment of Credit Card Payment entity). A conflict situation occurs when the bus gets the delay of 10 minutes in a traffic-jam. The delay is reflected in the Itinerary Status domain object (1). Being in the middle of the “go to next stop” activity (2), the process engine detects that the original precondition P 3 is now violated and adaptation is needed. The adaptation consists in i) abandoning the current refinement, ii) composing and executing a process that satisfies the precondition (3) (the adaptation process consists in committing delay to the flexibus system). As an effect of executing adaptation procedure, the event update in the Itinerary Status object is triggered (4). At the same time, one of the collective adaptation rules indicates that any update event must trigger change event for all passengers (5). Consequently, the passenger detects the violation of its precondition P 7 (6), and applies a similar

Fig. 4: Citizen process with ensemble activity. In order to enable ensembles in our process model, we extend it with a new type of activity called ensemble activity. It is semantically close to abstract tasks but additionally places entity in the scope of some ensemble. To be executed, ensemble activity is first refined, and second is executed in compliance with the ensemble rules. We remark that in this paper we mainly focused on how collective adaptation occurs within the scope of ensemble. The further developments of such aspects as ensemble activity, ensemble creation and desctruction are considered as principal steps in the future work.

155

V.

I MPLEMENTATION

VI.

C ONCLUSIONS

We have presented a conceptualization that enables the collective adaptation of ensembles composed of process-based entities. We have also outlined an architecture that supports the enactment of such collective adaptation.

Figure 5 depicts the internal architecture of an entity that is part of a CAS. Entity Model corresponds to Definition 3. When an entity becomes part of an ensemble, it contributes its fragments to the whole ensemble by storing them in the Fragments Repository. Each entity includes a Process Engine that runs its process. The Process Engine is also in charge of monitoring various types of runtime process violations that may occur, and is capable to enact the adaptation mechanisms we have described in Section IV-A . Once the Process Engine detects an inconsistency, an adaptation goal is derived, and passed to the Adaptation Manager together with the current context configuration. The Adaptation Manager is responsible for finding a solution to the adaptation problem of an entity by automatically composing the set of available fragments. The Adaptation Manager transforms an adaptation problem into a planning problem and applies to it advanced planning techniques capable of dealing with asynchronous nondeterministic domains and complex goals.

Various interesting and challenging aspects are not covered in this paper: (i) Ensemble Life Cycle: in our approach, one way to anchor the formation of a CAS is the ability to exchange process fragments, through which entities ”recruit” one another as needed to complement the behaviors specified in their own processes. That allows to identify and enumerate the set of entities that may aggregate into a CA; however, other details of the mecahnics of the ensemble life cycle, e.g., how that aggregation is triggered, or under what conditions it should be maintained or dissolved, have remained out of the scope of this paper. (ii) Collective Adaptation Rules: linked to the issue above is how collective adaptation rules are created and applied when a CAS is formed. Since these rules capture the semantics of the collaboration to be instantiated, it is reasonable to consider that in many cases the rules are specified explicitily by a domain expert, to enable a given application. The rules define a scope for the execution of the processes of the participant entities, specify how entities enter and exit that scope, and how they retrieve their copy of the collective adaptation rules. (iii) Hierarchical Ensembles: There may be more advanced scenarios in which multiple CAS come into a collaboration in a larger ensemble. We intend to pursue all of the aspects above, as part of our continuing research on Collective Adaptive Systems. ACKNOWLEDGMENT This work is partially funded by the 7th Framework EUFET project 600792 ALLOW Ensembles. R EFERENCES [1]

Fig. 5: CAS architecture.

[2]

The Domain Manager maintains the domain model and current state of the entity, and also receives and applies context events triggered through process execution or received through interprocess signalling mechanism. It also checks if any rules in the Collective Adaptive Rules of the ensemble must be applied. If it is the case, the necessary alerts are propagated to all the entities that are affected by that rule. The latter further apply the changes accordingly, so that all entities end up with up-to-date domain models. After servicing the Collective Adaptation signal, each entity continues operating autonomously in accord with its own resident process.

[3] [4]

[5] [6]

[7]

The signal propagation occurs through a publish/subscribe bus (the Communication Manager in the Figure), which is dynamically instantiated among the entities taking part in the ensemble. The Communication Manager transports any other events that may be significant for the context of one or more entities, such as events generated from the environment around the entities. For all its communication needs, each entity has a Communication Module, which manages its Port and governs all exchanges with the Communication Manager bus (interprocess message exchange and signalling), as well as the decentralized Fragments Repository.

[8] [9] [10]

[11]

156

A. Bucchiarone, A. Marconi, M. Pistore, and H. Raik. Dynamic adaptation of fragment-based and context-aware business processes. In ICWS, pages 33–41, 2012. T. Bures, I. Gerostathopoulos, P. Hnetynka, J. Keznikl, M. Kit, and F. Plasil. Deeco: An ensemble-based component system. In CBSE 2013, CBSE ’13, pages 81–90. ACM, 2013. C. Pinciroli et al. Argos: A modular, multi-engine simulator for heterogeneous swarm robotics. In IROS, pages 5027–5034, 2011. G. Cabri, M. Puviani, and F. Zambonelli. Towards a taxonomy of adaptive agent-based collaboration patterns for autonomic service ensembles. In CTS, pages 508–515, 2011. Sharon A. Henson et al. Towards a systems of systems engineering eu strategic research agenda. In SoSE, pages 99–104, 2013. R. Hennicker and A. Klarl. Foundations for ensemble modeling the helena approach. In Specification, Algebra, and Software, volume 8373 of Lecture Notes in Computer Science, pages 359–381. 2014. S. Kernbach, T. Schmickl, and J. Timmis. Collective adaptive systems: Challenges beyond evolvability. ACM Computing Research Repository (CoRR), August 2011. P. Levi and S. Kernbach. Symbiotic-Robot Organisms: Reliability, Adaptability, Evolution, volume 7. Springer Verlag, 2010. P. Lewis, M. Platzner, and X. Yao. An outlook for self-awareness in computing systems. Awareness Magazine, 2012. R. De Nicola, M. Loreti, R. Pugliese, and F. Tiezzi. A formal approach to autonomic systems programming: The scel language. ACM Trans. Auton. Adapt. Syst., 9(2):7:1–7:29, 2014. F. Zambonelli, N. Bicocchi, G. Cabri, L. Leonardi, and M. Puviani. On self-adaptation, self-expression, and self-awareness in autonomic service component ensembles. In SASOW, pages 108–113, 2011.