MuScA: A Multiscale Distributed SystemsScale-Awareness Framework

Sam Rottenberg1, Sebastien Leriche2, Chantal Taconet1, Claire Lecocq1, andThierry Desprats3

1 Institut Mines Telecom/Telecom SudParis, CNRS UMR 5157 SAMOVARfirstname.lastname@telecom-sudparis.eu

2 Toulouse University, ENAC firstname.lastname@enac.fr3 Toulouse University, CNRS UMR 5505 IRIT firstname.lastname@irit.fr

Abstract. Nowadays, complex systems are distributed over several lev-els of Information and Communications Technology (ICT) infrastruc-tures. They may involve very small devices such as sensors and RFID,but also powerful systems such as Cloud computers and knowledge bases,as well as intermediate devices such as smartphones and personal com-puters. These systems are sometimes referred to as multiscale systems.The word “multiscale” may qualify various distributed systems accordingto different viewpoints such as their geographic dispersion, the networksthey are deployed on, or their users’ organizations. For one entity ofthe multiscale system, communication technologies, non-functional com-ponents (for persistence or security purpose) or architectures to be fa-vored may vary from one scale to another. Ad hoc development andmanagement of such complex systems are costly and non-sustainable.In this paper, we propose a scale-awareness framework, called MuScA.This framework includes a characterization process that is based on theconcepts of viewpoints, dimensions and scales. These concepts consti-tute the core of a dedicated metamodel. The proposed framework allowsmultiscale software designers to share a vocabulary for qualifying theirown system. At system design time, the result of such a qualification isa model from which the framework produces scale-awareness artifacts.At runtime, those artifacts provide scale-awareness capabilities for au-tonomous management of the components of the multiscale system. Asan illustration of this model-driven approach, we show how multiscaleprobes are generated to provide multiscale components with an embed-ded scale-awareness ability.

Keywords: Multiscale, Distributed systems, Middleware, IoT, Cloud.

1 Introduction

Several recent research works [16, 19, 4] consider distributed systems that in-clude both very small systems such as objects from the Internet of Things (IoT)paradigm, and powerful systems such as those that may be found in the Cloud.

This collaboration enables each system to benefit from the capabilities of theothers. Some of these systems also involve intermediate computers such as mo-bile devices or proximity servers. These collaborating systems are sometimescalled multiscale distributed system.

The term multiscale system appears in several research papers [4, 9, 19], andin recent research groups such as the FCRP MUSYC research group (The Multi-scale Systems Center4). The multiscale concept is also present in other scientificdomains. In physics, laws vary according to the studied scales —i.e., microscopicscale for atoms, mesoscopic scale for nanotechnology, and macroscopic scale forbody. For example, at the microscopic scale, quantum mechanics applies, whereasat the macroscopic scale classical mechanic applies. In the traffic simulation do-main as well, the applied models vary according to the examined scale. We arguethat communication protocols, system behaviors, and architectures of systemsalso vary according to the scale of their entities.

Multiscale distribution is a different concept from large-scale distribution.Large scale has a quantitative meaning, whereas multiscale has an hetorogene-ity meaning. Multiscale distributed systems refer to a wide range of distributedsystems. The system heterogeneity may come from differences of latency or pro-tocols of involved networks, from differences of storage capacity or nature ofdevices, or from dispersion variations between entities. Each heterogeneity char-acteristic may lead to specific communication, performance, behavior, architec-ture choices. For this purpose, the system entities may benefit from the knowl-edge of their multiscale nature in terms of networks, devices, and geographicaldispersion.

In this paper, our contribution is a scale-awareness framework, called MuScA(Multiscale distributed systems Scale-Awareness framework). The aim of thisframework is to provide multiscale systems with scale-awareness capabilities.The first contribution is a multiscale characterization process. It is based onthe concepts of viewpoints, dimensions and scales. We follow a model-drivenapproach to produce an editor to qualify multiscale systems. Thus, multiscalesoftware designers share a vocabulary to qualify their systems. As a second con-tribution, multiscale probe artifacts are generated for scale-awareness purpose.With those artifacts, system entities become aware of the scales they are runningon. System entities may then choose the components, the behavior, the architec-ture, the design pattern, and the communication means, the most appropriatesto their current scales.

The organization of the paper is the following. In Section 2, we present themotivations for a scale-awareness framework. In Section 3, we present relatedwork. Then, in Section 4, we propose a generic characterization process for mul-tiscale systems. Finally, we present the MuScA framework in Section 5, and weconclude in Section 6.

4 http://www.musyc.org

2

2 Motivations for a scale-awareness framework

This section presents our motivations for a scale-awareness framework. In Sec-tion 2.1, we distinguish multiscale systems from large scale systems. Afterwards,we discuss in Section 2.2 the heterogeneity of the distributed systems from theICT infrastructure viewpoint. Then, we highlight some issues of multiscale sys-tems in Section 2.3.

2.1 Multiscale vs large-scale

First of all, it is important to differentiate multiscale from large-scale distribu-tion. The concept of large-scale distributed systems appeared in the 90s [14, 13].In the field of large-scale distributed systems, the term scale has a quantitativemeaning. In other words, a large-scale distributed system is highly distributedin terms of numbers of involved tiers, or geographical distance between tiers.Likewise, the term “scalability” designates the ability of a system to go from alow distribution (few tiers, close tiers, etc.) to a higher distribution (many tiers,long geographical distance between tiers, etc.) while efficiently maintaining itslevel of service.

The challenges at stake in large-scale systems or even ultra-large-scale sys-tems are mentioned by Blair and Grace in [4]. But the authors assert that thescalability challenge is not the most difficult one to address. Multiscale dis-tributed systems do not only deal with the quantity but also with the hetero-geneity. The multiscale aspect of a system may be studied independently fromits scalability.

2.2 Multiscale distributed systems, from smartdust to Cloud

We depict in Fig. 1 our vision of various ICT infrastructure levels that composemultiscale distributed systems in the context of the IoT. This figure considersfour ICT levels: at the bottom, the smartdust, Radio Frequency Identification(RFID), smart sensors level; at the top, the Cloud computing level; and two inter-mediate infrastructure levels: firstly personal devices and secondly cloudlets [17]in cafes and bus shelters.

Smartdust, a 1997 DARPA proposal, achieved to build wireless sensor nodeswith a volume of one cubic millimeter [20]. This building block of the IoT hasbeen complemented by RFID systems, Wireless Sensor Networks (WSNs), andSmart Objects Networks (SONs). All those kinds of computing things may beincluded in multiscale distributed systems.

Moreover, some IoT networks, such as sensor networks, use specific networkprotocols (e.g., ZigBee). As a consequence, gateways are necessary to intercon-nect these networks to larger scale networks. Finally, mobile devices, such asmobile phones, tablets and laptops are commonly used by nomadic users. Theyare essential for building user-centric services.

In the context of the IoT and mobile computing, the cooperation of smartobjects and cloud computing may be fruitful. Since we consider many objects,

3

Fig. 1. ICT infrastructure levels of a multiscale distributed system

the IoT may generate a huge volume of data, and may require substantial com-puting power for analysis purpose. Since mobile device resources remain scarcecompared to fixed servers’ ones, cooperation between mobile devices and cloudsis a promising approach.

2.3 Multiscale issues

Multiscale distributed systems have to cope with specific issues implied by eachICT infrastructure level they are built upon. Mobility management, disconnec-tions, unstable architecture, fault tolerance, security, latency in long distanceinteractions are some of those commonly identified issues. In addition, we haveidentified several issues specific to multiscale systems. One of this issue is de-scribed by Kessis et al. [9] as the ability to change at runtime the granularityof managed distributed resources.The dynamic distribution of the computationamong the scales with both efficiency and energy consumption preoccupationsis a second issue. Privacy is a third important issue. Users of multiscale sys-tems may require different privacy policies according to considered scales: e.g.,in terms of network, device, or geography.

Lastly, we believe that a transversal issue related to multiscale terminologyemerges from the previous ones. We think that different system engineering con-cerns (such as specification, deployment, safety, or security) will need a commonand dedicated language to express multiscale properties.

3 Related work

We have noticed the rising presence of multiscale systems in several recent re-search studies [9, 16, 19, 4, 1]. Some of these systems are explicitly described by

4

their authors as multiscale [9, 4, 1]. However, we did not find any definition ofmultiscale distributed systems. Moreover, we think that some systems are ac-tually multiscale even if they have not been explicitly described as such bytheir authors [16, 19]. Regarding the IoT field for example, as mentioned by theauthors of [5], the IoT is currently moving from islands of wireless sensor net-works to a global networked infrastructure. The cyber-foraging concept [15] isan architectural pattern where devices offload some of their heavy work to morepowerful computers. For the purpose of latency reduction, cooperation betweenmobile devices and proximity clouds, namely cloudlets, is proposed by Satya-narayanan [17].

In distributed systems, adaptation of the systems (of their structure, of theirbehavior, or of their communication) is a well-known issue. Numerous workspresent propositions for software adaptation. Context-aware systems are exam-ples of adaptive systems [2]. Nonetheless, there is a lack of a uniform way toexpress when adaptation should occur. Many systems offers their own languagesand mechanisms, they request the system designer to express the situations andthe adaptations with different formalisms. Even if not called so, we notice insome of these propositions scale-aware adaptations. Adapting the data (multi-media) to maintain the best QoS in heterogeneous networks is discussed in [18].The topology of a network is considered to adapt a communication protocol at alow level in [12]. At a higher level but in the network point of view, the authorsof [7] present a broadcasting protocol that dynamically changes according tothe network load. In the network point of view again, mobile software entitiessuch as mobile code or mobile agents can be localized using different protocolsdynamically switched according to the respective network environment of theagents [21, 10].

From these works, we identify the lack of a shared multiscale vocabularyand scale-aware framework.We believe that this would allow system designers tobetter take into account multiscale adaptation requirements.

4 Multiscale distributed systems characterization process

In Section 4.1, we present the MuScA approach. Then, we study the networkviewpoint through several dimensions in Section 4.2. Finally, we detail the char-acterization process in 4.3.

4.1 MuScA approach

Fig. 2 depicts the general approach followed with the MuScA framework. Thedesign process, which is detailed with a SPEM [11] diagram, is made up of threemain activities. The first activity is the multiscale characterization to qualify themultiscale nature of the system. The result of this activity is a MuScA model.In the second activity, multiscale probe artifacts are generated from a MuScAmodel. Those probes consolidate data provided by lower level probes, called basicprobes, to identify the scales of the system entities. The third activity, is not

5

presented in this paper. It illustrates the possible use of a MuScA model in thedefinition of adaptation rules.

The right side of the figure depicts how the probes could be used in anautonomous loop [8] for scale-awareness purpose. Scale-aware components mayadapt their behavior based on the knowledge of the scale they are associated to,provided by the multiscale probes.

Design time Runtime

Monitoring Analysis Action

Scale-aware Component

Multiscale Characterization of a

System

Generation of Probes API

Definition of Adaptation Rules

Multiscale Characterization of a

System

Work Product

MuScAModel

Work Product

BasicProbes

Generation ofMultiscale Probes

Work Product

Multiscale Probes

Definition ofAdaptation Rules

Work Product

Scale-awarenessAdaptation Rules

Scale-awareness Framework

System DesignerMultiscale

Probes

BasicProbes

Sca

le 1

Sca

le 2

Sca

le 3

System

Fig. 2. MuScA framework approach

4.2 Network viewpoint and some of its dimensions

To introduce the MuScA vocabulary, we detail in this section the network view-point. The study of other viewpoints is available for download5.

In order to study a system through the network viewpoint, we consider thenetworks crossed by the system. We have chosen to study the multiscalabilityof the network viewpoint through three dimensions, respectively associated withthree numeric measures. In Fig. 3, we illustrate those three dimensions: thelatency dimension measured in milliseconds, the bandwidth dimension measuredin kilobits per second and the network range dimension measured in meters.We position some network families (e.g., zigbee, WiFi, satellite) with respectto their estimated dispersion for those three measures. Then, for each coupledimension/measure we identify relevant scales. For the latency, we have selectedtwo scales: low latency under 1s and high latency above 1s. For the bandwidth,we have identified three scales: low bandwidth under 103kb/s, medium bandwidthbetween 103 and 106kb/s, and high bandwidth above 106kb/s. And finally, forthe network range, we have identified the PAN, LAN, MAN and WAN scales.The numeric measures are presented with a logarithmic ruler.

5 http://anr-income.fr/uploads/MultiscaleViewpoints.pdf

6

010-3 10-2 10-1 1 103

102 103 104 105 106

Latency (ms)

Bandwidth (kb/s)

Gigabit Ethernet

ZigBee

Satellite

ZigBee

3G Gigabit Ethernet

10 102

low latency scale high latency scale

low bandwidth

scale medium bandwidth scale high bandwidth scale

Network range (m)

Wi-Fi

Wi-Fi

Satellite

Family of networks Scale

ZigBee

Wi-Fi

Satellite

3G

Gigabit Ethernet

PAN scale WAN scaleLAN scale

3G

1 103 106104 10510 102

MAN

scale

107 108

DWDM

RFID

Fig. 3. Dimensions and scales for the network viewpoint

4.3 Multiscale characterization process

The architecture of a system is obtained by studying this system from differ-ent viewpoints, each viewpoint leads to a view of the system [6]. The networkviewpoint is not the only viewpoint to analyze during the multiscale charac-terization of a distributed system. There are other fundamental viewpoints toconsider such as the study of the devices of the system (device viewpoint), thesocial organization (user viewpoint), the administration organization (adminis-tration viewpoint), the geographical dispersion of the system entities (geographyviewpoint). Indeed, they are related to the main issues at stake in the designand development of such complex systems: the need of computing power or stor-age capacity (device viewpoint), of interaction between distant entities (networkviewpoint), and of social organizations (user viewpoint). In short, the systemdesign may result to different patterns/architecture/solutions when multiscaleis implied in one or more dimensions. The solutions may vary according to theinvolved scales. However, the above viewpoint list is not exhaustive and otherviewpoints, such as data, or time, could also be considered. Depending on theproperties to be highlighted for the systems, one may choose to study differentviewpoints and dimensions; this is the reason why we propose an open multiscalecharacterization process.

Multiscale characterization process: The multiscale nature of a distributed sys-tem should be studied independently from each considered viewpoint. For eachviewpoint, a restricted view of the system is considered. Then, for this view, wechoose one or several dimensions. To identify scales for a given dimension, each

7

dimension is associated with a numeric or a semantic measure. Depending on thetype of the measure, the resulting scales match, respectively, orders of magnitudefor numeric measures, or sets of elements that share common semantic character-istics for semantic measures. The choice of the viewpoints, dimensions/measuresand of the scales relevant for a multiscale characterization, is left open dependingon the properties of the system one wants to highlight. The objective of thesechoices is to highlight specific characteristics to deal with during the systemdesign, or the system runtime.

Multiscale nature of a system: The multiscale nature of a system is relative toa multiscale characterization; it is studied independently from each viewpoint.For a given viewpoint, and for a couple dimension/measure, each element of therestricted view of the system is associated with a scale. For a given characteriza-tion, and a given viewpoint, a distributed system is qualified as multiscale when,for at least one dimension, the elements of its view are associated with differentscales.

5 MuScA framework

In this section, we present the MuScA framework. We begin with the presentationof the model-driven approach in Section 5.1. Then, we formalize the characteri-zation process with the MuScA metamodel in Section 5.2, and give an exampleof a MuScA model in Section 5.3. Thereafter, we describe the generated arti-facts —i.e., multiscale probes— in Section 5.4. Finally, we present some MuScAimplementation details in Section 5.5.

5.1 Model-driven approach

In order to formalize the multiscale characterization process, and to use it inthe design and deployment of scale-aware distributed systems, we have chosento follow a model-driven approach (using the four OMG meta-modeling lay-ers [3]). Fig. 4 shows the mapping between the model-driven architecture levelsand the MuScA levels. We define the MuScA metamodel (M2 level) with theEcore meta-metamodel (M3 level). The classes of the MuScA metamodel repre-sent multiscale concepts. With this metamodel, we are able to define character-ization models (M1 level). This characterization may be used for one or severalreal world systems (M0 level). We also follow the model-driven approach in or-der to automatically produce artifacts, for instance, producing probe artifactsfor scale-awareness purpose.

5.2 MuScA metamodel

The MuScA metamodel is shown in Fig. 5. This metamodel is based on thevocabulary used in the multiscale characterization process.

8

M3

M2

M1

M0

MetametamodelEcore

MetamodelMuScA

ModelA multiscale characterization

Real worldA multiscale distributed system

Fig. 4. MuScA: Model-driven architecture levels

*

*

*

*

*

MSCharacterization

Viewpoint

name : EString

Measure

unity : EStringvalueType : EJavaClass

Dimension

name : EString

ScaleSet

name : EString

Scale

name : EStringmin : EStringmax : EString

minHasRequiredType(EDiagnosticChain, EMap) : EBooleanmaxHasRequiredType(EDiagnosticChain, EMap) : EBoolean

*

Fig. 5. MuScA: Multiscale characterization metamodel

An instance of MSCharacterization is the result of a characterization process.A characterization considers several Viewpoints —e.g., Geography, User, Deviceand Network viewpoints (M1 level classes). Each viewpoint determines a re-stricted view of the system that is studied independently. A view of the systemfrom a given viewpoint is studied through several Dimensions, which are mea-sureable characteristics of the elements of the view. For example, the Deviceviewpoint can be analyzed through the StorageCapacity (M1 level) dimension ofthe system devices. As previously mentioned, a Dimension is measurable, mean-ing that it can be associated with one or several Measures. For example, at M1level, the StorageCapacity dimension may be measured with the Bytes measure orthe KiloBytes measure. For the association of one dimension with one measure,the designer defines a ScaleSet, which is an ordered set of scales relevant for thesystem. For numeric measures, a Scale is defined by its min and max bounds.For some viewpoints, the system may present several instances of one scale. Forexample, if we take the Geography viewpoint, in the Location dimension, theTown scale (M1 level) often has several instances (M0 level) —i.e., the differenttowns where entities of the system are present.

9

5.3 MuScA model as a multiscale characterization

Fig. 6 illustrates an extract of a MuScA model that is the result of a characteriza-tion process. For this model, three viewpoints have been selected: the device, thegeography and the network viewpoints (the network viewpoint scales are hidden).Firstly, we decide to study the device viewpoint through the storage capacitydimension. The storage is measured in bytes (numeric measure), the scale set ismade up of kilobytes, gigabytes, and petabytes scales. Scales are characterized bythe min and max bounds in bytes. Secondly, we study the geography viewpointthrough what we call the “smallest common location” dimension, to measurethe distribution of the system by studying the smallest common administrativelocation of a set of scale-aware entities. For this dimension, measured in what wecall the “smallest common location measure” (semantic measure), we identifythe following scales: street, neighborhood, city, region, country, and world. Anillustration of the result of the smallest common location measure can be foundin Section 5.4, Fig. 8.

Fig. 6. Example of a MuScA model

5.4 From MuScA model to multiscale probes

From a MuScA model, we automatically produce multiscale probe artifacts.These probes are monitoring programs that are to be deployed on each entity ofa multiscale system. We generate one probe per viewpoint. Each probe exposesat least one method by dimension. This mandatory method returns a scale for aset of entities (e.g., the smallest common location measure may return the Town

10

scale). For some dimensions, MuScA also generates one method, which returnsthe scale instance for a set of entities (e.g., the name of the town). For numericmeasures, the methods are automatically generated. The generated methods canbe completed to implement a specific logic, in particular to call basic probes, asshown in Fig. 2, or to implement specific semantic measures.

Fig. 7 shows the class diagrams of generated device and geography multiscaleprobes, based on the MuScA model of Fig. 6. For example, in the DeviceProbe,the getScale StorageCapacity In Bytes method returns the scale associated to thedevice on which the probe is deployed for the storage capacity dimension mea-sured in bytes. This method is automatically generated on the basis of the minand max bounds of each scale of the scale set, as defined in the MuScA model. Inthe GeographyProbe, the two methods return, respectively, the smallest commonlocation scale, and the smallest common location scale instance. They take anarray of remote scale-aware entities as parameters. For example, Fig. 8 showsthe smallest common location scale instance associated to three people travellingin the city of Toulouse. The three people are represented by black circles: Ameland Leon are represented by the same circle because they are travelling together,and Sophie is alone in a second circle. The figure represents the scale instancereturned by a geography probe deployed in Amel’s smartphone. It shows that, atthe beginning, the smallest common location scale is the city, in particular theToulouse instance (M0 level). Then, when Sophie gets closer to Amel and Leon,the smallest common location scale becomes the neighborhood, in this case theSuburb 1 instance (M0 level).

DeviceProbe

getScale_StorageCapacity_In_Bytes() : StorageCapacity_In_Bytes_Scale

StorageCapacity_In_Bytes_Scale

KILOBYTES,GIGABYTES,PETABYTES

GeographyProbe

getScale_SmallestCommonLocation_In_SmallestCommonLocationMeasure(remoteEnts : ScaleAwareEntity[]) : SmallestCommonLocation_In_SmallestCommonLocationMeasure_Scale

getScaleInstance_SmallestCommonLocation_In_SmallestCommonLocationMeasure(remoteEnts : ScaleAwareEntity[]) : String

SmallestCommonLocation_In_SmallestCommonLocationMeasure_Scale

STREET,NEIGHBORHOOD,CITY,REGION,COUNTRY,WORLD

getScaleInstances() : String[]

Fig. 7. Multiscale Device and Geography Probes

5.5 MuScA implementation

We have implemented MuScA with the Eclipse Modeling Framework Project6

(EMF). The MuScA metamodel is defined as an instance of the Ecore metameta-model. EMF generates a specialized model editor. We have extended the editor

6 http://www.eclipse.org/modeling/emf/

11

Fig. 8. Geography viewpoint, Smallest Common Location dimension

for validation purpose. This editor has been used to define the MuScA model pre-sented in Fig. 6. Then, we use the Acceleo7 code generator to produce multiscaleprobes implemented in Java. We have detailed in this paper two multiscale probes(for the device/storage and geography/smallestCommonLocation couples). Thegeography multiscale probe, whose output was used to produce Fig. 8, has beenimplemented by calling the reverse geocoding API of the OpenStreetMap8 Nom-inatim9 service, and the map has been produced using the JMapViewer10 API(also part of the OpenStreetMap project).

6 Conclusion

Multiscale distributed systems raise new kind of issues such as heterogeneitymanagement, granularity variations, distribution over the scales, and privacy.In this paper, we have presented MuScA, a framework to study multiscale dis-tributed systems and to provide them with scale-awareness capability.

The framework is based on a characterization process, which helps design-ers to study the multiscale nature of a given system. We have analyzed manyscenarios and use cases for multiscale systems for the INCOME11 project. Thecharacterization process enables the designer either to select —among existingones— the viewpoints, dimensions and scales relevant for a given system, orto define new ones. For one characterization, MuScA generates probes for run-time scale-awareness. Each characterization enables the framework to extend itsmultiscale vocabulary and its multiscale probes. Thus the framework learns andmemorizes new viewpoints, dimensions and scales to be proposed for a latercharacterization.

We believe that MuScA is helpful to build multiscale distributed systemsthat cope with some of the previously mentioned challenges. We argue that agood knowledge of the multiscale nature of a system contributes to choosing thebest architectural patterns for each multiscale distributed system.

7 http://www.eclipse.org/acceleo/8 http://www.openstreetmap.org9 http://wiki.openstreetmap.org/wiki/Nominatim

10 http://wiki.openstreetmap.org/wiki/JMapViewer11 http://anr-income.fr

12

Currently, we use MuScA in the INCOME project. We have two perspectives.The first one is for an autonomic deployment middleware. We plan to define adomain specific language, based on MuScA, for declaring deployment multiscaleproperties. The second one is for a distributed event based system. We plan touse the scale-awareness capability to filter the distribution of the events. In bothcases, MuScA provides ability to define scale-awareness rules that will respec-tively govern adaptive software deployment, and data distribution in multiscaledistributed systems.

7 Acknowledgments

This work is partly funded by the INCOME ANR project (ANR-11-INFR-009,2012–2015) in which the following French partners are taking part: IRIT (Institutde Recherche en Informatique de Toulouse), Telecom SudParis, and ARTALTechnologies. The authors thank all the members of this project.

References

1. J. P. Arcangeli et al. INCOME a Multi-scale Context Management for the Inter-net of Things. In F. Patern, B. Ruyter, P. Markopoulos, C. Santoro, E. Loenen,and K. Luyten, editors, Ambient Intelligence, volume 7683 of Lecture Notes inComputer Science, pages 338–347. Springer Berlin Heidelberg, 2012.

2. M. Baldauf, S. Dustdar, and F. Rosenberg. A Survey on Context Aware Systems.International Journal of Ad Hoc and Ubiquitous Computing, 2(4):263–277, 2007.

3. J. Bezivin and O. Gerbe. Towards a precise definition of the OMG/MDA frame-work. In Proceedings. 16th Annual International Conference on Automated Soft-ware Engineering, 2001, (ASE 2001), pages 273–280, Nov 2001.

4. G. Blair and P. Grace. Emergent Middleware: Tackling the Interoperability Prob-lem. Internet Computing, IEEE, 16(1):78–82, jan.-feb. 2012.

5. A. Gluhak, S. Krco, M. Nati, D. Pfisterer, N. Mitton, and T. Razafindralambo. ASurvey on Facilities for Experimental Internet of Things Research. IEEE Commu-nications Magazine, 49(11):58–67, Nov. 2011.

6. ISO/IEC/IEEE. Systems and software engineering — Architecture description. In-ternational Standard ISO/IEC/IEEE-42010:2011, ISO/IEC/IEEE Joint TechnicalCommittee, Dec. 2011.

7. S. Karmakar and A. Gupta. Fault-tolerant topology adaptation by localizeddistributed protocol switching. In S. Aluru, M. Parashar, R. Badrinath, andV. Prasanna, editors, High Performance Computing – HiPC 2007, volume 4873of Lecture Notes in Computer Science, pages 528–539. Springer Berlin Heidelberg,2007.

8. J. Kephart and D. Chess. The Vision of Autonomic Computing. IEEE Computer,36(1), Jan. 2003.

9. M. Kessis, C. Roncancio, and A. Lefebvre. DASIMA: A Flexible ManagementMiddleware in Multi-Scale Contexts. In Proc. Sixth International Conference onInformation Technology: New Generations, 2009. ITNG ’09, pages 1390–1396, Apr.2009.

13

10. S. Leriche and J. Arcangeli. Flexible architectures and agents for adaptive auto-nomic systems. In Fourth IEEE International Workshop on Engineering of Auto-nomic and Autonomous Systems, EASe’07., pages 99–106, 2007.

11. Object-Management-Group. Software & Systems Process Engineering Metamodel(SPEM) v2.0. formal/2008-04-01, april 2008.

12. L. Rosa, A. Lopes, and L. Rodrigues. Policy-driven adaptation of protocol stacks.In International Conference on Autonomic and Autonomous Systems. ICAS’06.,pages 5–5, 2006.

13. H. Sandhu and S. Zhou. Cluster-based file replication in large-scale distributedsystems. In Proceedings of the ACM Sigmetrics Performance ’92 Conference, SIG-METRICS ’92/PERFORMANCE ’92, pages 91–102, New York, NY, USA, May1992. ACM.

14. M. Satyanarayanan. Scalable, Secure, and Highly Available Distributed File Ac-cess. IEEE Computer, 23(5):9–18, May 1990.

15. M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE PersonalCommunications, 8(4):10–17, August 2001.

16. M. Satyanarayanan. Mobile Computing: the Next Decade. SIGMOBILE Mob.Comput. Commun. Rev., 15:2–10, Aug. 2011.

17. M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies. The Case for VM-BasedCloudlets in Mobile Computing. IEEE Pervasive Computing, 8:14–23, Oct. 2009.

18. N. Shaha, A. Desai, and M. Parashar. Multimedia content adaptation for qosmanagement over heterogeneous networks. In Proceedings of the InternationalConference on Internet Computing (IC 2001). Press, 2001.

19. M. van Steen, G. Pierre, and S. Voulgaris. Challenges in very large distributedsystems. Springer Journal of Internet Services and Applications, 3(1), 2012.

20. B. Warneke, M. Last, B. Liebowitz, and K. S. J. Pister. Smart Dust: Commu-nicating with a Cubic-Millimeter Computer. IEEE Computer, 34(1):44–51, Jan.2001.

21. Y. Zafoune, A. Mokhtari, and R. Kanawati. Mobile-agent approach for mobile codelocalization in ad hoc networks. In 33rd Annual IEEE International ComputerSoftware and Applications Conference, COMPSAC ’09., volume 2, pages 36–39,2009.

14