MAGNET: An Architecture for Dynamic Resource Allocation Patty Kostkova and Julie A. McCann High-Performance Extensible Research Group (HiPeX) City University, London, UK {patty, jam}@soi.city.ac.uk Abstract adjustment. Computer systems no longer operate in centralized isolated static environments. Technological advances, such as smaller and faster hardware, snd higher reliability of networks have resulted in the growth of mobility of computing and the need for run-time adaptability and reconfigurability. However, mobile and roaming users need to dynamically adapt to local system configurations to order to fully utilize resources currently available, such as a fast network con- nection, an available colour printer etc. In order to pro- vide support for this type of application, a dynamic resource manager supporting indirect resource requests and runtime reconfigurability is essential. This paper addresses the design of a resource manager, MAGNET, fulfilling the requirements of applications operat- ing in frequently-changing environments. In particular, we present a framework enabling user-customized dynamic re- source allocation supporting runtime adaptation. 2 The MAGNET Architecture This paper proposes a new dynamic resource manage- ment architecture, MAGNET, to provide run-time adaptabil- ity for mobile applications. MAGNET enables the dynamic trading of resources which can be requested indirectly by the type of service they offer, rather than directly by their name. In addition, MAGNET enables runtime user-customized adap- tation to services. A resource manager which can provide dynamic resource allocation requires the following features: dynamic trading, extensibility, dynamic rebinding, resource monitoring and reconfigurability. These features and the high-level design of the MAGNET architecture are discussed in this section. The key component of the framework is a ‘Bader that collects information on services, and dynamically matches requests against demands (by type of service and not the name given to the service, e.g., printer and not ‘LPRP’). In doing this, it can establish dynamic binding between compo- nents which did not need to know their identity in advance. 1 Introduction In order to meet the requirements of mobile and roaming users, the role of resource management needs to be extended to enable user customization of resource allocation policies and to provide the support for runtime adaptation to chang- ing conditions. The Trader must not constrain the format or the seman- tics of information on services and should allow the user to customize the matching process between servers’ offers and applications’ requests. This provides extensibility in terms of enabling new requests and services to be dynamically gen- erated but also in terms of customizing the matching process itself. In open systems, there is a requirement to enable re- quests for services to be described by a type of service (e.g., a printer), rather than directly by its name. Without this, communication between system components which did not know their identity a priori, cannot happen. In addition, dy- namic features such as the monitoring of selected resource features, and the provision of location and time-dependent information are also required. Further, to support runtime adaptation and system re- configuration dynamic rebinding is required. That is, the old binding is dropped and a new binding is established in order to better meet application requirements. This may be as a result of client., server or a third party initiation. Existing operating systems, and middleware platforms dealing with dynamic resource allocation do not provide sufficient support for mobile applications in terms of user- customization of the allocation strategies and their runtime For example, a mobile client currently using its lor..l disk may wish to join a new, more stable environment in h., office to upload data. Therefore it will unbind from its current disk and rebind to the office disk. Information on client demands and service capabilities is maintained either manually (i.e., carried out by the components themselves) or automatically (by a monitoring process). Permission t(, makc digital or hard copies of a11or part or this wd hr pc,.sonal or c,assroonl llsc is granted without fee provided that copies are ,,ot made or distributed for profit or commercial advaoWe and that cop;es bear this notice and the full citalion (111 the tirst page. To WV otl,er,“ise, 1o republish, to post on servers or to rcdisuihutc to lists. rcquircs prior specific permission and/or a fee. MobiDE ScattIc WA USA Copyright ACM 1999 I-581 13-175-5/99/08...$5.00 2.1 Using the Tuplespace Paradigm for the Trader The Trader is the key component in the MAGNET architec- ture. The Trader accesses a shared data repository available to all components. We call this data structure an infor- mation pool, its structure is similar to the tuplespace’ The Trader consists of three distinctive elements: 'The information pool is actually a tuplespace. However, the term ‘tuplespace’ is often associated with the Linda distributed program- 77