MuScA: A Multiscale Distributed Systems Scale-Awareness Framework

Transcription

1 MuScA: A Multiscale Distributed Systems Scale-Awareness Framework Sam Rottenberg 1, Sébastien Leriche 2, Chantal Taconet 1, Claire Lecocq 1, and Thierry Desprats 3 1 Institut Mines Télécom/Télécom SudParis, CNRS UMR 5157 SAMOVAR firstname.lastname@telecom-sudparis.eu 2 Toulouse University, ENAC firstname.lastname@enac.fr 3 Toulouse University, CNRS UMR 5505 IRIT firstname.lastname@irit.fr Abstract. Nowadays, complex systems are distributed over several levels of Information and Communications Technology (ICT) infrastructures. 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 computers. These systems are sometimes referred to as multiscale systems. The word multiscale may qualify various distributed systems according to different viewpoints such as their geographic dispersion, the networks they are deployed on, or their users organizations. For one entity of the multiscale system, communication technologies, non-functional components (for persistence or security purpose) or architectures to be favored may vary from one scale to another. Ad hoc development and management 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 the concepts of viewpoints, dimensions and scales. These concepts constitute the core of a dedicated metamodel. The proposed framework allows multiscale software designers to share a vocabulary for qualifying their own system. At system design time, the result of such a qualification is a model from which the framework produces scale-awareness artifacts. At runtime, those artifacts provide scale-awareness capabilities for autonomous management of the components of the multiscale system. As an illustration of this model-driven approach, we show how multiscale probes are generated to provide multiscale components with an embedded scale-awareness ability. Keywords: Multiscale, Distributed systems, Middleware, IoT, Cloud. 1 Introduction Several recent research works [16, 19, 4] consider distributed systems that include 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.

2 This collaboration enables each system to benefit from the capabilities of the others. Some of these systems also involve intermediate computers such as mobile devices or proximity servers. These collaborating systems are sometimes called multiscale distributed system. The term multiscale system appears in several research papers [4, 9, 19], and in recent research groups such as the FCRP MUSYC research group (The Multiscale Systems Center 4 ). The multiscale concept is also present in other scientific domains. In physics, laws vary according to the studied scales i.e., microscopic scale for atoms, mesoscopic scale for nanotechnology, and macroscopic scale for body. For example, at the microscopic scale, quantum mechanics applies, whereas at the macroscopic scale classical mechanic applies. In the traffic simulation domain as well, the applied models vary according to the examined scale. We argue that communication protocols, system behaviors, and architectures of systems also 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 hetorogeneity meaning. Multiscale distributed systems refer to a wide range of distributed systems. The system heterogeneity may come from differences of latency or protocols of involved networks, from differences of storage capacity or nature of devices, or from dispersion variations between entities. Each heterogeneity characteristic may lead to specific communication, performance, behavior, architecture choices. For this purpose, the system entities may benefit from the knowledge of their multiscale nature in terms of networks, devices, and geographical dispersion. In this paper, our contribution is a scale-awareness framework, called MuScA (Multiscale distributed systems Scale-Awareness framework). The aim of this framework is to provide multiscale systems with scale-awareness capabilities. The first contribution is a multiscale characterization process. It is based on the concepts of viewpoints, dimensions and scales. We follow a model-driven approach to produce an editor to qualify multiscale systems. Thus, multiscale software designers share a vocabulary to qualify their systems. As a second contribution, multiscale probe artifacts are generated for scale-awareness purpose. With those artifacts, system entities become aware of the scales they are running on. System entities may then choose the components, the behavior, the architecture, the design pattern, and the communication means, the most appropriates to their current scales. The organization of the paper is the following. In Section 2, we present the motivations for a scale-awareness framework. In Section 3, we present related work. Then, in Section 4, we propose a generic characterization process for multiscale systems. Finally, we present the MuScA framework in Section 5, and we conclude in Section

3 2 Motivations for a scale-awareness framework This section presents our motivations for a scale-awareness framework. In Section 2.1, we distinguish multiscale systems from large scale systems. Afterwards, we discuss in Section 2.2 the heterogeneity of the distributed systems from the ICT infrastructure viewpoint. Then, we highlight some issues of multiscale systems in Section Multiscale vs large-scale First of all, it is important to differentiate multiscale from large-scale distribution. 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 quantitative meaning. In other words, a large-scale distributed system is highly distributed in terms of numbers of involved tiers, or geographical distance between tiers. Likewise, the term scalability designates the ability of a system to go from a low distribution (few tiers, close tiers, etc.) to a higher distribution (many tiers, long geographical distance between tiers, etc.) while efficiently maintaining its level of service. The challenges at stake in large-scale systems or even ultra-large-scale systems are mentioned by Blair and Grace in [4]. But the authors assert that the scalability challenge is not the most difficult one to address. Multiscale distributed systems do not only deal with the quantity but also with the heterogeneity. The multiscale aspect of a system may be studied independently from its scalability. 2.2 Multiscale distributed systems, from smartdust to Cloud We depict in Fig. 1 our vision of various ICT infrastructure levels that compose multiscale distributed systems in the context of the IoT. This figure considers four ICT levels: at the bottom, the smartdust, Radio Frequency Identification (RFID), smart sensors level; at the top, the Cloud computing level; and two intermediate infrastructure levels: firstly personal devices and secondly cloudlets [17] in cafes and bus shelters. Smartdust, a 1997 DARPA proposal, achieved to build wireless sensor nodes with a volume of one cubic millimeter [20]. This building block of the IoT has been complemented by RFID systems, Wireless Sensor Networks (WSNs), and Smart Objects Networks (SONs). All those kinds of computing things may be included in multiscale distributed systems. Moreover, some IoT networks, such as sensor networks, use specific network protocols (e.g., ZigBee). As a consequence, gateways are necessary to interconnect these networks to larger scale networks. Finally, mobile devices, such as mobile phones, tablets and laptops are commonly used by nomadic users. They are essential for building user-centric services. In the context of the IoT and mobile computing, the cooperation of smart objects and cloud computing may be fruitful. Since we consider many objects, 3

4 Fig. 1. ICT infrastructure levels of a multiscale distributed system the IoT may generate a huge volume of data, and may require substantial computing power for analysis purpose. Since mobile device resources remain scarce compared to fixed servers ones, cooperation between mobile devices and clouds is a promising approach. 2.3 Multiscale issues Multiscale distributed systems have to cope with specific issues implied by each ICT infrastructure level they are built upon. Mobility management, disconnections, unstable architecture, fault tolerance, security, latency in long distance interactions are some of those commonly identified issues. In addition, we have identified several issues specific to multiscale systems. One of this issue is described by Kessis et al. [9] as the ability to change at runtime the granularity of managed distributed resources.the dynamic distribution of the computation among the scales with both efficiency and energy consumption preoccupations is a second issue. Privacy is a third important issue. Users of multiscale systems 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 terminology emerges from the previous ones. We think that different system engineering concerns (such as specification, deployment, safety, or security) will need a common and dedicated language to express multiscale properties. 3 Related work We have noticed the rising presence of multiscale systems in several recent research studies [9, 16, 19, 4, 1]. Some of these systems are explicitly described by 4

5 their authors as multiscale [9, 4, 1]. However, we did not find any definition of multiscale distributed systems. Moreover, we think that some systems are actually multiscale even if they have not been explicitly described as such by their authors [16, 19]. Regarding the IoT field for example, as mentioned by the authors of [5], the IoT is currently moving from islands of wireless sensor networks to a global networked infrastructure. The cyber-foraging concept [15] is an architectural pattern where devices offload some of their heavy work to more powerful computers. For the purpose of latency reduction, cooperation between mobile devices and proximity clouds, namely cloudlets, is proposed by Satyanarayanan [17]. In distributed systems, adaptation of the systems (of their structure, of their behavior, or of their communication) is a well-known issue. Numerous works present propositions for software adaptation. Context-aware systems are examples of adaptive systems [2]. Nonetheless, there is a lack of a uniform way to express when adaptation should occur. Many systems offers their own languages and mechanisms, they request the system designer to express the situations and the adaptations with different formalisms. Even if not called so, we notice in some of these propositions scale-aware adaptations. Adapting the data (multimedia) 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 a low level in [12]. At a higher level but in the network point of view, the authors of [7] present a broadcasting protocol that dynamically changes according to the network load. In the network point of view again, mobile software entities such as mobile code or mobile agents can be localized using different protocols dynamically switched according to the respective network environment of the agents [21, 10]. From these works, we identify the lack of a shared multiscale vocabulary and scale-aware framework.we believe that this would allow system designers to better 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 network viewpoint through several dimensions in Section 4.2. Finally, we detail the characterization process in MuScA approach Fig. 2 depicts the general approach followed with the MuScA framework. The design process, which is detailed with a SPEM [11] diagram, is made up of three main activities. The first activity is the multiscale characterization to qualify the multiscale nature of the system. The result of this activity is a MuScA model. In the second activity, multiscale probe artifacts are generated from a MuScA model. Those probes consolidate data provided by lower level probes, called basic probes, to identify the scales of the system entities. The third activity, is not 5

6 Scale 1 Scale 2 Scale 3 presented in this paper. It illustrates the possible use of a MuScA model in the definition of adaptation rules. The right side of the figure depicts how the probes could be used in an autonomous loop [8] for scale-awareness purpose. Scale-aware components may adapt their behavior based on the knowledge of the scale they are associated to, provided by the multiscale probes. Design time Runtime Scale-awareness Framework Work Product Scale-aware Component System Designer Multiscale Definition of Characterization of a Adaptation Rules System Definition of Adaptation Scale-awareness Rules Adaptation Rules Monitoring Analysis Action Multiscale Probes Multiscale Characterization of a System Work Product Generation of Probes MuScA API Model System Basic Probes Work Product Work Product Basic Probes Generation of Multiscale Probes Multiscale Probes 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 viewpoint. The study of other viewpoints is available for download 5. In order to study a system through the network viewpoint, we consider the networks crossed by the system. We have chosen to study the multiscalability of the network viewpoint through three dimensions, respectively associated with three numeric measures. In Fig. 3, we illustrate those three dimensions: the latency dimension measured in milliseconds, the bandwidth dimension measured in kilobits per second and the network range dimension measured in meters. We position some network families (e.g., zigbee, WiFi, satellite) with respect to their estimated dispersion for those three measures. Then, for each couple dimension/measure we identify relevant scales. For the latency, we have selected two scales: low latency under 1s and high latency above 1s. For the bandwidth, we have identified three scales: low bandwidth under 10 3 kb/s, medium bandwidth between 10 3 and 10 6 kb/s, and high bandwidth above 10 6 kb/s. And finally, for the network range, we have identified the PAN, LAN, MAN and WAN scales. The numeric measures are presented with a logarithmic ruler

7 ZigBee Satellite 0 Gigabit Ethernet Wi-Fi 3G low latency scale high latency scale Latency (ms) ZigBee RFID 3G Wi-Fi Gigabit Ethernet Satellite low bandwidth scale medium bandwidth scale high bandwidth scale Bandwidth (kb/s) Gigabit Ethernet Satellite ZigBee PAN scale Wi-Fi LAN scale 3G MAN scale DWDM WAN scale Network range (m) Family of networks Scale 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 different viewpoints, each viewpoint leads to a view of the system [6]. The network viewpoint is not the only viewpoint to analyze during the multiscale characterization of a distributed system. There are other fundamental viewpoints to consider such as the study of the devices of the system (device viewpoint), the social organization (user viewpoint), the administration organization (administration viewpoint), the geographical dispersion of the system entities (geography viewpoint). Indeed, they are related to the main issues at stake in the design and development of such complex systems: the need of computing power or storage capacity (device viewpoint), of interaction between distant entities (network viewpoint), and of social organizations (user viewpoint). In short, the system design may result to different patterns/architecture/solutions when multiscale is implied in one or more dimensions. The solutions may vary according to the involved scales. However, the above viewpoint list is not exhaustive and other viewpoints, such as data, or time, could also be considered. Depending on the properties to be highlighted for the systems, one may choose to study different viewpoints and dimensions; this is the reason why we propose an open multiscale characterization process. Multiscale characterization process: The multiscale nature of a distributed system should be studied independently from each considered viewpoint. For each viewpoint, a restricted view of the system is considered. Then, for this view, we choose one or several dimensions. To identify scales for a given dimension, each 7

8 dimension is associated with a numeric or a semantic measure. Depending on the type of the measure, the resulting scales match, respectively, orders of magnitude for numeric measures, or sets of elements that share common semantic characteristics for semantic measures. The choice of the viewpoints, dimensions/measures and of the scales relevant for a multiscale characterization, is left open depending on the properties of the system one wants to highlight. The objective of these choices is to highlight specific characteristics to deal with during the system design, or the system runtime. Multiscale nature of a system: The multiscale nature of a system is relative to a multiscale characterization; it is studied independently from each viewpoint. For a given viewpoint, and for a couple dimension/measure, each element of the restricted view of the system is associated with a scale. For a given characterization, 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 different scales. 5 MuScA framework In this section, we present the MuScA framework. We begin with the presentation of the model-driven approach in Section 5.1. Then, we formalize the characterization process with the MuScA metamodel in Section 5.2, and give an example of a MuScA model in Section 5.3. Thereafter, we describe the generated artifacts i.e., multiscale probes in Section 5.4. Finally, we present some MuScA implementation details in Section Model-driven approach In order to formalize the multiscale characterization process, and to use it in the design and deployment of scale-aware distributed systems, we have chosen to follow a model-driven approach (using the four OMG meta-modeling layers [3]). Fig. 4 shows the mapping between the model-driven architecture levels and the MuScA levels. We define the MuScA metamodel (M2 level) with the Ecore meta-metamodel (M3 level). The classes of the MuScA metamodel represent multiscale concepts. With this metamodel, we are able to define characterization models (M1 level). This characterization may be used for one or several real world systems (M0 level). We also follow the model-driven approach in order to automatically produce artifacts, for instance, producing probe artifacts for scale-awareness purpose. 5.2 MuScA metamodel The MuScA metamodel is shown in Fig. 5. This metamodel is based on the vocabulary used in the multiscale characterization process. 8

9 M3 M2 M1 M0 Metametamodel Ecore Metamodel MuScA Model A multiscale characterization Real world A multiscale distributed system Fig. 4. MuScA: Model-driven architecture levels MSCharacterization Viewpoint name : EString * * * Measure Dimension name : EString * * unity : EString valuetype : EJavaClass Scale ScaleSet name : EString * name : EString min : EString max : EString minhasrequiredtype(ediagnosticchain, EMap) : EBoolean maxhasrequiredtype(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, Device and Network viewpoints (M1 level classes). Each viewpoint determines a restricted view of the system that is studied independently. A view of the system from a given viewpoint is studied through several Dimensions, which are measureable characteristics of the elements of the view. For example, the Device viewpoint can be analyzed through the StorageCapacity (M1 level) dimension of the system devices. As previously mentioned, a Dimension is measurable, meaning that it can be associated with one or several Measures. For example, at M1 level, the StorageCapacity dimension may be measured with the Bytes measure or the 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 the system. 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. For example, if we take the Geography viewpoint, in the Location dimension, the Town scale (M1 level) often has several instances (M0 level) i.e., the different towns where entities of the system are present. 9

10 5.3 MuScA model as a multiscale characterization Fig. 6 illustrates an extract of a MuScA model that is the result of a characterization process. For this model, three viewpoints have been selected: the device, the geography and the network viewpoints (the network viewpoint scales are hidden). Firstly, we decide to study the device viewpoint through the storage capacity dimension. The storage is measured in bytes (numeric measure), the scale set is made up of kilobytes, gigabytes, and petabytes scales. Scales are characterized by the min and max bounds in bytes. Secondly, we study the geography viewpoint through what we call the smallest common location dimension, to measure the distribution of the system by studying the smallest common administrative location of a set of scale-aware entities. For this dimension, measured in what we call the smallest common location measure (semantic measure), we identify the following scales: street, neighborhood, city, region, country, and world. An illustration of the result of the smallest common location measure can be found in 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 of a multiscale system. We generate one probe per viewpoint. Each probe exposes at least one method by dimension. This mandatory method returns a scale for a set of entities (e.g., the smallest common location measure may return the Town 10

11 scale). For some dimensions, MuScA also generates one method, which returns the scale instance for a set of entities (e.g., the name of the town). For numeric measures, the methods are automatically generated. The generated methods can be completed to implement a specific logic, in particular to call basic probes, as shown in Fig. 2, or to implement specific semantic measures. Fig. 7 shows the class diagrams of generated device and geography multiscale probes, based on the MuScA model of Fig. 6. For example, in the DeviceProbe, the getscale StorageCapacity In Bytes method returns the scale associated to the device on which the probe is deployed for the storage capacity dimension measured in bytes. This method is automatically generated on the basis of the min and max bounds of each scale of the scale set, as defined in the MuScA model. In the GeographyProbe, the two methods return, respectively, the smallest common location scale, and the smallest common location scale instance. They take an array of remote scale-aware entities as parameters. For example, Fig. 8 shows the smallest common location scale instance associated to three people travelling in the city of Toulouse. The three people are represented by black circles: Amel and 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 instance returned by a geography probe deployed in Amel s smartphone. It shows that, at the beginning, the smallest common location scale is the city, in particular the Toulouse instance (M0 level). Then, when Sophie gets closer to Amel and Leon, the smallest common location scale becomes the neighborhood, in this case the Suburb 1 instance (M0 level). StorageCapacity_In_Bytes_Scale KILOBYTES, GIGABYTES, PETABYTES DeviceProbe getscale_storagecapacity_in_bytes() : StorageCapacity_In_Bytes_Scale SmallestCommonLocation_In_SmallestCommonLocationMeasure_Scale STREET, NEIGHBORHOOD, CITY, REGION, COUNTRY, WORLD getscaleinstances() : String[] GeographyProbe getscale_smallestcommonlocation_in_smallestcommonlocationmeasure(remoteents : ScaleAwareEntity[]) : SmallestCommonLocation_In_SmallestCommonLocationMeasure_Scale getscaleinstance_smallestcommonlocation_in_smallestcommonlocationmeasure(remoteents : ScaleAwareEntity[]) : String Fig. 7. Multiscale Device and Geography Probes 5.5 MuScA implementation We have implemented MuScA with the Eclipse Modeling Framework Project 6 (EMF). The MuScA metamodel is defined as an instance of the Ecore metametamodel. EMF generates a specialized model editor. We have extended the editor

12 Fig. 8. Geography viewpoint, Smallest Common Location dimension for validation purpose. This editor has been used to define the MuScA model presented in Fig. 6. Then, we use the Acceleo 7 code generator to produce multiscale probes implemented in Java. We have detailed in this paper two multiscale probes (for the device/storage and geography/smallestcommonlocation couples). The geography multiscale probe, whose output was used to produce Fig. 8, has been implemented by calling the reverse geocoding API of the OpenStreetMap 8 Nominatim 9 service, and the map has been produced using the JMapViewer 10 API (also part of the OpenStreetMap project). 6 Conclusion Multiscale distributed systems raise new kind of issues such as heterogeneity management, granularity variations, distribution over the scales, and privacy. In this paper, we have presented MuScA, a framework to study multiscale distributed systems and to provide them with scale-awareness capability. The framework is based on a characterization process, which helps designers to study the multiscale nature of a given system. We have analyzed many scenarios and use cases for multiscale systems for the INCOME 11 project. The characterization process enables the designer either to select among existing ones the viewpoints, dimensions and scales relevant for a given system, or to define new ones. For one characterization, MuScA generates probes for runtime scale-awareness. Each characterization enables the framework to extend its multiscale vocabulary and its multiscale probes. Thus the framework learns and memorizes new viewpoints, dimensions and scales to be proposed for a later characterization. We believe that MuScA is helpful to build multiscale distributed systems that cope with some of the previously mentioned challenges. We argue that a good knowledge of the multiscale nature of a system contributes to choosing the best architectural patterns for each multiscale distributed system

13 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 a domain specific language, based on MuScA, for declaring deployment multiscale properties. The second one is for a distributed event based system. We plan to use the scale-awareness capability to filter the distribution of the events. In both cases, MuScA provides ability to define scale-awareness rules that will respectively govern adaptive software deployment, and data distribution in multiscale distributed systems. 7 Acknowledgments This work is partly funded by the INCOME ANR project (ANR-11-INFR-009, ) in which the following French partners are taking part: IRIT (Institut de Recherche en Informatique de Toulouse), Télécom SudParis, and ARTAL Technologies. The authors thank all the members of this project. References 1. J. P. Arcangeli et al. INCOME a Multi-scale Context Management for the Internet of Things. In F. Patern, B. Ruyter, P. Markopoulos, C. Santoro, E. Loenen, and K. Luyten, editors, Ambient Intelligence, volume 7683 of Lecture Notes in Computer Science, pages Springer Berlin Heidelberg, M. Baldauf, S. Dustdar, and F. Rosenberg. A Survey on Context Aware Systems. International Journal of Ad Hoc and Ubiquitous Computing, 2(4): , J. Bézivin and O. Gerbé. Towards a precise definition of the OMG/MDA framework. In Proceedings. 16th Annual International Conference on Automated Software Engineering, 2001, (ASE 2001), pages , Nov G. Blair and P. Grace. Emergent Middleware: Tackling the Interoperability Problem. Internet Computing, IEEE, 16(1):78 82, jan.-feb A. Gluhak, S. Krco, M. Nati, D. Pfisterer, N. Mitton, and T. Razafindralambo. A Survey on Facilities for Experimental Internet of Things Research. IEEE Communications Magazine, 49(11):58 67, Nov ISO/IEC/IEEE. Systems and software engineering Architecture description. International Standard ISO/IEC/IEEE-42010:2011, ISO/IEC/IEEE Joint Technical Committee, Dec S. Karmakar and A. Gupta. Fault-tolerant topology adaptation by localized distributed protocol switching. In S. Aluru, M. Parashar, R. Badrinath, and V. Prasanna, editors, High Performance Computing HiPC 2007, volume 4873 of Lecture Notes in Computer Science, pages Springer Berlin Heidelberg, J. Kephart and D. Chess. The Vision of Autonomic Computing. IEEE Computer, 36(1), Jan M. Kessis, C. Roncancio, and A. Lefebvre. DASIMA: A Flexible Management Middleware in Multi-Scale Contexts. In Proc. Sixth International Conference on Information Technology: New Generations, ITNG 09, pages , Apr

14 10. S. Leriche and J. Arcangeli. Flexible architectures and agents for adaptive autonomic systems. In Fourth IEEE International Workshop on Engineering of Autonomic and Autonomous Systems, EASe 07., pages , Object-Management-Group. Software & Systems Process Engineering Metamodel (SPEM) v2.0. formal/ , april 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, H. Sandhu and S. Zhou. Cluster-based file replication in large-scale distributed systems. In Proceedings of the ACM Sigmetrics Performance 92 Conference, SIG- METRICS 92/PERFORMANCE 92, pages , New York, NY, USA, May ACM. 14. M. Satyanarayanan. Scalable, Secure, and Highly Available Distributed File Access. IEEE Computer, 23(5):9 18, May M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE Personal Communications, 8(4):10 17, August M. Satyanarayanan. Mobile Computing: the Next Decade. SIGMOBILE Mob. Comput. Commun. Rev., 15:2 10, Aug M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies. The Case for VM-Based Cloudlets in Mobile Computing. IEEE Pervasive Computing, 8:14 23, Oct N. Shaha, A. Desai, and M. Parashar. Multimedia content adaptation for qos management over heterogeneous networks. In Proceedings of the International Conference on Internet Computing (IC 2001). Press, M. van Steen, G. Pierre, and S. Voulgaris. Challenges in very large distributed systems. Springer Journal of Internet Services and Applications, 3(1), B. Warneke, M. Last, B. Liebowitz, and K. S. J. Pister. Smart Dust: Communicating with a Cubic-Millimeter Computer. IEEE Computer, 34(1):44 51, Jan Y. Zafoune, A. Mokhtari, and R. Kanawati. Mobile-agent approach for mobile code localization in ad hoc networks. In 33rd Annual IEEE International Computer Software and Applications Conference, COMPSAC 09., volume 2, pages 36 39,