Context-Aware Adaptive Object Migration

Universität UlmFakultät für InformatikVerteilte Systeme Context-Aware Adaptive Object MigrationRüdiger KapitzaHolger SchmidtFranz J. HauckBericht Nr. VS-R04-20062006-08-30Context-Aware Adaptive Object MigrationR¨udiger Kapitza Dept.of Comp.SciencesInformatik4University ofErlangen-N¨urnbergGermany rrkapitz@cs.fau.deHolger SchmidtDistributed SystemsLaboratoryUniversity of UlmGermanyholger.schmidt@uni-ulm.deFranz J.HauckDistributed SystemsLaboratoryUniversity of UlmGermanyfranz.hauck@uni-ulm.deABSTRACTCurrent systems restrict object migration support to a cer-tain language and environment.Only few systems sup-port heterogeneous environments by specifying a language-independent state transfer format and requiring the same implementation in every target language.In the con-text of Ambient Computing with mobile applications and users and context-aware adaptive software,a more platform-independent,flexible and adaptive approach for object mi-gration is required.This paper presents a novel approach for adaptive ob-ject migration in heterogeneous systems.It is also based on language-independent state transfer but uses stan-dard mechanisms using CORBA value types.This offers ORB-and platform-independent object migration between all CORBA-supported programming languages.Adaptive object-based migration is achieved by providingflexible mechanisms for reducing,expanding or transforming the state of an object before and after migration,respectively, and for adapting the provided functionality according to the current context’s requirements(e.g.resource limitations or different steps in a workflow).For this purpose,we intro-duce a separation of state,functionality and code instead of mapping particular state on particular code.Our prototype system is based on our recent platform-independent CORBA-compliant Life-Cycle–Service imple-mentation.So far,we support Java and C++,but an imple-mentation for any other CORBA-supported programming language is possible.1.INTRODUCTIONThere is an ongoing trend to integrate and link the physi-cal world to the virtual world of computing resources and applications.Techniques like RFID(radio frequency iden-tifications),sensors(e.g.BTNodes1)and mobile devices, 1http://www.btnode.ethz.ch but also positioning systems like GPS(global positioning system)and wireless communication of all kinds,push this trend.Accompanied with this evolution and the rising di-versity of systems,new concepts and techniques to provide adaptable and context-aware applications are required.Of-ten,these applications will migrate between different plat-forms during their lifetime.As a typical example,a“follow me”application(e.g.personal information manager appli-cation)can have a different interface and state on a laptop, a cellular phone or a publicly accessible web-terminal.In the first case,the full set of features is provided,whereas in case of the cellular phone some data-intensive parts are left out. Finally,in the last case,one would only provide the essential parts of the state to fulfil the demanded task for privacy rea-sons.In all cases,different hardware and software systems can be expected.In other words,we expect that a mobile application has to adapt its state,the provided functionality and the implementation basis to its execution context,the target system and application-dependent restrictions.Most recent object-based middleware and agent platforms restrict migration support to a certain programming lan-guage and environment.Only a few systems provide support for migration in heterogeneous environments such as Agent-Factory[1]or ATS[2].These rely on a custom language-independent serialisation format for state transfer and re-quire an implementation providing the same functionality in every target language.This results in high implementa-tion costs in terms of porting the system to a new platform and providing a fully-fledged implementation of a mobile object for each supported target language.The latter is es-pecially the case if only parts of the functionally should be provided or are required on certain systems.In scenarios where the ability to adapt the provided functionality and state is needed like outlined by the“follow me”example a more platform-independent,flexible and adaptive approach for object migration is required.In this paper,we propose the concept of adaptable mobile objects.These objects are capable of adapting their state, functionality and underlying code basis during migration to the requirements of the target platform and the needs of the object itself.We focus on weak migration.This means that only the state of an object is migrated but no execution-dependent state like,e.g.,values on the stack.We build on our recent platform-and ORB-independent implemen-tation of the CORBA Life-Cycle Service[3]that is basedon CORBA value types[4],a standard CORBA mechanism for passing objects by value.This service combined with a logical separation of the mobile object’s state,functional-ity and code enables support for adaptive object migration in heterogeneous environments.In fact,our current pro-totype of a dynamic adaptation service for mobile objects, the adaptive object migration(AOM)service,supports the migration of objects between Java and C++.Supporting other CORBA-supported languages requires only moderate implementation effort.To assist the developer during the implementation process,we provide a tool—the AOM tool. Additionally,we offer support for mobile objects acting as mobile agents(an object having an own thread that executes autonomously on behalf of a user).The paper is structured as follows:In Section2,we give an overview of mobile object systems and the CORBA Life-Cycle-Service specification.Then,we present our approach of implementing adaptive object migration for mobile ob-jects.In Section4,we show related work.Finally,we con-clude and discuss future work in Section5.2.MOBILE OBJECTSIn the following section,we give a brief overview about sys-tems providing object mobility in homogeneous and het-erogeneous environments.Then,we introduce our recent realisation of the CORBA Life-Cycle–Service specification. Based on this approach,we built our platform that supports adaptation of an object’s state and code.2.1Providing Object MobilityIn the past,a lot of mobile agent systems have been devel-oped,like MOA[5],Mole[6]or Aglets[7],to name a few. However,all of them only provide mechanisms for migra-tion in homogeneous environments.Most of these systems are Java-based and rely on the Java serialization ing Java serialization the whole agent object is transferred to the agent’s new location.In this case,the state of an agent is tightly attached to the actual implemen-tation.Thus,migrating a specific version to a new place with another implementation version will probably lead to serialization errors.Furthermore,no adaptation of the mo-bile agent’s state or code is supported at all. Nevertheless,mobile agent systems for heterogeneous envi-ronments have been developed as well.In[1]a platform-neutral approach of agent migration is presented,based on transferring a blueprint instead of the code.This approach can be realised by assuming that an agent consists of a set of different components.For the creation of such an agent, a special AgentFactory is specified,which is responsible for creating an executable agent consisting of the right compo-nents from a received blueprint.Thus,migration is based on transferring the blueprint and the state of an object. However,the AgentFactory approach does not provide any support for the adaptation of state or functionality.Choy et al.describe a CORBA environment supporting mo-bile agents based on mobile CORBA objects[8].Based on the Life-Cycle Service and the Externalization Service a con-cept was developed,but apparently not implemented.Fur-thermore,the concept does not support adaptation of the mobile agent’s state or code.For gaining higher interoperability of heterogeneous mobile agent systems,the Object Management Group(OMG)de-veloped a standard for agent communication:the Mobile Agent System Interoperability Facility(MASIF)[9].The Foundation for Intelligent Physical Agents(FIPA)1is an-other standardisation approach for mobile agent systems. Both,MASIF and FIPA,provide only support for interop-erability of agent platforms of different vendors,but lack support for inter-platform migration.Furthermore,they provide no support for adaptation of agents.2.2CORBA Life-Cycle ServiceCORBA is a standardized architecture defined by the Ob-ject Management Group(OMG).This architecture enables programmers to create and access objects deployed in a distributed system and provides platform-and mon middleware tasks like object lo-cation,request marshalling and message transmission are performed by the Object Request Broker(ORB).A server object is specified by describing the object’s interface using the Interface Definition Language(IDL).This interface is used to generate platform-specific stubs for the client and skeletons for the server side.Both entities act as surrogates dealing with heterogeneity and handle remote invocations and marshalling for the object.Objects are actually im-plemented by servants that are registered with an object adapter.For invoking remote methods,a client only needs a valid object reference that can be bound by the local ORB instance.CORBA specifies a set of CORBA services.These ser-vices represent optional ORB extensions and address general needs of CORBA applications.The Life-Cycle Service[10]is such a CORBA service,as it enables application-controlled object management including mobility and other life-cycle operations.Recently,we proposed a platform-independent implemen-tation of the CORBA Life-Cycle–Service specification[3]. Although our initial prototype implementation is based on Java,it is easily portable to any other CORBA-supported language and can be used in different ORBs as it just relies on standard CORBA without any ORB-specific extensions. This has been verified by a further interoperable implemen-tation in C++.The CORBA Life-Cycle Service describes the interfaces of all required components for enabling object mobility in great detail.However,the specification leaves open important issues.For migrating a mobile object,the state and the code have to be transfered(this implies determining the state of the mobile object dynamically at runtime).In principle,the specification describes these processes as an object-specific task that should be handled by the object developer.This has various disadvantages as state transfer methods have to be implemented from scratch for each object.This is error-prone and leads to serious interoperability problems in heterogeneous environments.For state transfer in heterogeneous environments we intro-duced value types.Value types are a well-known part of the 1http://www.fi/Figure1:Object Migration using the Life-Cycle Ser-vice(UML Communication Diagram)CORBA specification[4].In contrast to standard CORBA objects,value types are transferred by value(call-by-value semantics),leading to a complete copy of the value type at the receiving ing value types enables an easy descrip-tion of an object’s state using standard IDL syntax.Fur-thermore,developers do not have to write special methods for state transfer,as value types are marshalled and demar-shalled automatically by the ORB.Like standard CORBA objects,value types can also be activated.In this case, a value type has to support a standard CORBA interface which enables a call-by-reference semantics.Thus,weak heterogeneous object migration can be realised using the CORBA Life-Cycle Service in combination with value types.The Life-Cycle–Service specification defines a LifeCycleObject-interface that is implemented by our mo-bile object.The mobile object is actually a value type that supports the LifeCycleObject-interface,which,be-side other methods,offers a move()-method.In conjunction with a remote factory(GenericFactory),that enables the creation of objects on remote servers,the move()-method implements object migration.For this process,another entity—a FactoryFinder—is needed for searching for an ap-propriate factory on a remote server.The appropriate loca-tion is determined by evaluating parameterized criteria that specify possible target locations.After having found such a factory,the object aka value type can be passed by value as a method-parameter using standard marshalling and de-marshalling mechanisms.The created value type has to be activated by the factory using the original object’s object-identifier.Then,the original object has to be removed. Fig.1shows the basic workflow of an object migration using the CORBA Life-Cycle Service.As we also intented to support heterogeneous systems,in which the object’s code might not be present at thefinal location,we provided a solution to dynamic code provi-sion as well.Based on our previous work,the Dynamic Loading Service(DLS)[11],we developed a special type of GenericFactory that transparently enables loading of ap-propriate platform-specific code on demand.This allows dynamic instantiation of previously unknown objects. Furthermore,our solution enables persistent object refer-ences by maintaining the object identifier for the whole life-time of a mobile object.We achieve this by providing a special type of location service that manages the system’s object references.For avoiding a bottleneck we enable the usage of arbitrary location services.3.ADAPTIVE OBJECT MIGRATIONIn this section,we present our approach of object migra-tion supporting adaptation of state and functionality.First, we give basic background information and outline our basic concept.Then,we sketch possible implementation realisa-tions.3.1Basic DefinitionsFor transferring a mobile object in homogeneous environ-ments usually the state and the code of this object have to be transferred.Therefore,recent systems only separate the state and the code of an object.For addressing hetero-geneous platforms we introduce another abstraction:the separation of state,functionality,and the realising code. Thereby,the functionality of an object is defined by its most derived supported interface.This enables a selection of an appropriate implementation based on a supported interface as already described in Section2.2.Migration in heterogeneous environments enforces differenti-ating between implementation-dependent and-independent state.For example,a java.util.Hashtable object from the Java class library contains many implementation-dependent state-variables, e.g.,a set of diverse constants regarding the used hash-function.In heterogeneous systems it does not make sense to transfer state that is highly specific for a certain implementation,as other implementations are not able to understand these values.This is especially the case if an object is migrated between different pro-gramming languages(enabled by our implementation of the CORBA Life-Cycle Service).In such systems,just the implementation-independent state should be transferred;in case of a Hashtable-Object,this state is represented by the actual<key,value>-pairs.To sum it up we consider:•Implementation-dependent state as values that are spe-cific for a certain implementation variant of an inter-face•Implementation-independent state as values that are needed by any possible implementation to provide the functionality defined by an interface and values that would be considered as information loss if they were omittedWe identified the fact that in various scenarios only parts of the object state are accessed,can be available or should be accessible.If a mobile object moves from one host to an-other one for fulfilling various steps in a complex workflow, there is data which is not needed on every target platform. Thus,there is state that we call passive on these platforms. Going back to the“follow me”example from the introduc-tion,the whole state of the personal information manager (PIM)application can be considered as active state on a laptop,as all data can be accessed and modified.As this application object moves to a cellular phone certain data items might not be accessible due to device limitations,like private movies or pictures from the last holiday.In this case,the movies and pictures are passive state that is not available.If the PIM application is accessed from a public web-terminal,huge parts of state might not be transferred due to privacy reasons.Thus,this information can also beFigure2:Adaptation of State According to an Ob-ject’s Functionalityconsidered as passive state as it should not be accessible. We define active and passive state as follows:•Active state is represented by the state variables that are used and needed for fulfilling the object’s function-ality at a certain location•Passive state is the state of an object that is not needed,not available or not accessible at a certain lo-cation.We believe that in all these three exemplary cases not only the state of an object changes or should be changed but also the interface and the implementation that are provided at the target platform.Fig.2shows the adaptation of state and interface on demand according to an object’s functionalities’requirements.For this purpose,parts of the full state might become passive.However,this passive state might become active again,whenever the object migrates to another loca-tion.Thus,even the passive state should be stored,as it might be used again later.3.2Basic ConceptFig.3shows our concept of adaptive object migration (AOM).We enable adaptation of an object’s state accord-ing to the required functionality as specified by the interface (cf.Section3.1).In contrast to previous work,we enable at-taching state to a special functionality instead of attaching an object’s state to a special implementation(represented by code).For migrating a mobile object,just the state and a description of the required functionality have to be trans-ferred to the new location(cf.Fig.2).At the new location, our factory is able to create an object that fulfills these re-quirements containing the active state,which is specified by the required functionality.Our infrastructure supports passivating parts of the state in special staterepositories Figure3:Basic Concept of Adaptive State Transfer Mechanismthat might be local or remote regarding the current object. We support adaptation of the mobile object whenever it en-ters or leaves a location.At these intervention points(State Adaptors),we enable activating and passivating state for fu-ture implementations of the required functionality.Support-ing adaptation on the origin side enables a secure transfer of sensitive data and supports target-systems that are not capable of our adaptive object migration implementation2. On the other side,the possibility of adaptation on the target side minimizes adaptation efforts on the origin side and,in case of bad network connectivity,allows receiving and stor-ing the complete state for further local adaptation steps. This requires a local state repository as shown on Host D in Fig.3.3.3Implementation DraftIn this section,we present an implementation draft for real-ising our introduced concept for adaptive object migration.As afirst step,the developer has to decide which kinds of functionalities should be supported.These kinds of func-tionalities represent the different facets3,which the mobile object can adopt during it’s life cycle(this affects the be-haviour of the object but not the actual object identifier;cf. Section1).For any functionality,an IDL interface and the correspond-ing value type(supporting the interface and containing the active and implementation-independent state)has to be specified.For supporting our adaptive object-migration ser-vice the value type has to support the LifeCycleObject interface as well.In the next step,the developer has to run a tool—our AOM tool—that will create a union value type called 2However,these target-systems have to support the CORBA Life-Cycle Service.Then,migration of already adapted value types is possible.3According to the current context,an object with a spe-cific object identifier can have different facets represented by different functionality,state and codevaluetype A {private i n t c o u n t e r ;private S t r i n g message ;};valuetype B {private i n t c o u n t e r ;private S t r i n g l o g i n ;};valuetype a o m f u l l {private i n t c o u n t e r ;private S t r i n g message ;private S t r i n g l o g i n ;};Figure 4:Two Value Types and the resulting aom full ValueTypeFigure 5:Process of Object Migration on the Origin Side (UML Communication Diagram)aom full <id >containing the union set of state variables of all defined value types (representing the facets of a mobile object—represented by the same object identifier but of-fering different functionality).This is done using a simple name matching algorithm,i.e.,if a state variable has the same name in different value types,then we assume that these state variables represent identical data (cf.Fig 4).Defining value types containing states with identical names but different types results in an error.Thus,our AOM tool creates a value type that contains the complete set of state variables.This state might become active and passive dur-ing runtime,respectively.After having run the AOM tool ,the developer has to imple-ment the actual value type realisations for all the program-ming languages and platforms that should be supported (supporting all facets of the mobile object).This also in-cludes the implementation of the life-cycle operations.How-ever,this effort is quite moderate because the whole mi-gration functionality is provided by the move()-method of the provided AOMManager (cf.Figure 5).This method just has to be called from within the LifeCycleObject ’s move()-method.An implementation of the other life-cycle opera-tions is simple as well.In [3],we describe this processin detail.3.3.1AOMManagerThe AOMManager is responsible for the adaptation processon the origin side (cf.State Adaptors,Fig.3).Further-Figure 6:Exemplary Hierarchy of Possible Keys in the FactoryFinder ’s Repository more,it is also responsible for searching for an appropriate target location for a pending migration.For this task,a known FactoryFinder is queried on possible factories rep-resenting possible migration targets within the scope of the FactoryFinder .These factories have to fulfill given criteria .Our offered FactoryFinders support criteria defining concrete locations (e.g.,DNS-Name,IP-Address)and discrete locations specified by a required functionality (see Section 3.3.2).The result of the query is a list of appropriate factories,which are able to create a copy of the mobile object for re-alising the migration.Our AOMManager is able to select the “best”factory that is used for object migration.In our pro-totype implementation,we use the factory at the head of the list,but obiously user-defined policies can be implemented by providing a custom selectFactory()method as well (cf.Fig.5).For supporting adaptation on the origin side our AOMManager is able to save the active state of the value type to a trusted state repository.Therefore,a saveState()-method of the value type,which has been generated by our AOM tool be-fore,is called.Then,this state is stored to the state reposi-tory containing the current aom full <id >value type.In the next step,the AOMManager either adapts the value type to the target value type or sends the original value type—which can be adapted at the target side by the factory—to the factory by invoking the remote method createFromValueType .Passing the value type as a param-eter results in transferring a description of the functionality and the affected state to the factory.The application devel-oper decides which variant is processed by passing a boolean parameter (local adaptation ).If the mobile object has been created successfully at the factory,the original object is removed and the reference in the location service is updated (see [3]).3.3.2FactoryFinder As already mentioned in Section 3.3.1,the FactoryFinder represents some kind of abstract location within the CORBA Life-Cycle–Service specification.It provides meth-ods for querying for appropriate factories acting as tar-gets for object migration.For fulfilling this task,the FactoryFinder has to maintain a repository of possible fac-tories within the FactoryFinder ’s domain.Fig.6shows our realisation of the repository.Our reposi-tory is able to store factories according to their location andprovided functionality.Therefore,our factory enables regis-tering and deregistering factories including their metadata. The FactoryFinder’s find factories method allows to search for registered factories residing at particular locations and providing particular functionalities,respectively(a list containing every appropriate factory is returned).For this purpose,find factories receives a CORBA Naming Ser-vice NameComponent sequence.A NameComponent consists of an<identifier,kind>-pair of strings.We specified two possible kind-values for our FactoryFinder.For a func-tionality we specified“IFC”and for a location we specified “LOC”.The particular identifier represents the functionality and the location,respectively.As find factories receives a NameComponent-sequence,searching for specific functional-ities at specific locations within the FactoryFinder’s repos-itory is possible as well.3.3.3FactoryOn the factory side,a value type is automatically created according to the transferred specifications during the un-marshalling process.Our factory is able to use the Dynamic Loading Service(DLS)to load locally unavailable code on demand.This enables instantiating previously unknown ob-jects.If needed,the factory is able to adapt the value type according to the actual platform’s and criteria’s require-ments.In this case,the passivated part of the state is stored to the trusted state repository again.The active state is then loaded from the repository into the adapted value type implementation using the value type’s loadState()-method (generated by the AOM tool as well).After this process,the value type is activated,which enables accessing the object from remote clients.3.3.4State RepositoryThe State Repository is an entity that is able to store the current state of a mobile object.This entity is a plain CORBA object that can be located locally or remotely to the mobile object.The state repository contains the cur-rent aom full<id>value type and offers two methods for loading and saving the state,respectively(load state(), save state()).The load state()method takes the de-scription of the desired value type as a parameter and,thus, is able to return the appropriate part of the state.The actual implementation of the State Repository is left open to the developer. E.g.,the State repository can be realised by serialising the mobile object’s state to external storage(reducing the actual memory load).For reducing communication costs on mobile pervasive devices,it can be useful to have a local State Repository.Then,further adap-tations can be done locally.3.4Persistent Object ReferencesIn heterogeneous environments containing mobile objects, persistent object references are needed for clients to access the mobile object anytime.We realised these object refer-ences using a special location service(see[3]).However, adapting the functionality(interface)of a mobile object might result in remote call exceptions on the client side, as particular methods might not be present any more.This problem can be solved by asuming that the mobileobject Figure7:Public and Location-Dependend Interface of a Mobile Objecthas a public interface that does not change and a location-dependend interface that might change(cf.Fig.7).This can be realised by a value type that has to support the public interface while optionally supporting other location-dependend interfaces.Thus,the location-dependend inter-face is just used for platform-internal purposes.Neverthe-less,this interface is remotely accessible and can be used by clients(these have to handle exceptions if a special location-dependend interface is not existent).As already mentioned in Section1,our system is able to re-alise an agent that is able to adapt to the current location’s needs.An adaptive mobile agent(AOM-agent)will have management methods for intervening into the agents work-flow(public interface).Furthermore,that agent will also offer methods that can be used on the current local node, e.g.,for collecting data(location-dependend interface).“Careful”persistent references can be realised by a mobile object that is just accessed using an object-specific adapter. This adapter is able to throw exceptions in case of non-existent methods.For supporting the client,these excep-tions contain the interfaces offering the needed method4. Thus,the client is able to adapt the mobile object to cur-rent needs.4.RELATED WORKAlmeida et al.propose a dynamic reconfiguration service for CORBA[12].This service is able to upgrade objects without taking them offline.This entails operations for migration, replacement,addition and removal of managed objects.Ob-jects should provide methods for inspecting and modifying the state.This breaks the OOP concept of encapsulation, as internal state is publicly accessible,and in contrast to our approach object developers have to implement these meth-ods on their own.Furthermore the dynamic reconfiguration service does not allow switching the object’s interface or state adaptation.The work of Garbinato et al.introduces Frugal Objects (FROBs)for mobile computing[13].FROBs are objects within an event-based computing model,which provide adaptability according to their interface(which is repre-sented by events that can be accepted)and their code.These objects support migration as well,but a drawback of this solution is the requirement of using a special non-intuitive 4The adapter can automatically be generated by our AOM tool and has to catch CORBA BAD OPERATION ex-ceptions and forward system-defined exceptions containingthe needed interface.Nevertheless,by calling the remote object’s get interface def()-method the currently sup-ported interface can be obtained.。