Using reflective features to support mobile users

Transcription

1 Using reflective features to support mobile users V.Marangozova, F.Boyer Laboratoire /Projet INRIA SIRAC, INRIA/INPG/UJF, France ( Replication is a technique that allows the construction of applications ensuring normal execution regardless of the mobile users connection state. To satisfy application-specific requirements as well as different computing environment constraints, both replica management and connection/disconnection processes should be adaptable. This paper presents how reflective features can be used to meet this objective. Our reflective support is an extension of the Java environment which provides the notion of adaptable objects able to dynamically modify their behavior. 1 Motivations 1.1 General observations The continuously increasing user mobility and the appearance of various mobile devices such as PDAs, portable computers, etc. presents new challenges to the area of distributed applications. One of the major problems faced is disconnection. In order that mobile users could use normally their computing environments regardless of their state of connection, programmers need an adapted support allowing the creation of distributed applications capable of adapting and executing in disconnected mode. In this paper we present our approach to providing such a support. The disconnection management is based on component replication and respectively reconciliation. The disconnections we consider are not hazardous and due to network fluctuation but are explicitly launched by the users. Our opinion is that the management of an application's data and/or code at transitions (disconnections and reconnections) should be specific to the application. This is explained by our belief that a generic replication and reconciliation protocol cannot satisfy the needs of all types of applications. To attain this objective, we believe that it is essential for the mobile users support to be adaptable. Adaptability is needed both at the application and at the middleware level. As far as the application is concerned we think that there should be means of adapting both the data and the code to be replicated. The contents of the replicated data should be defined by following some application-specific rules. We can cite a simple example of a user of an agenda wanting to take away the list of his rendez-vous during the two weeks of his absence and not the list for all the year. The adaptations concerning the code which is to be downloaded on the user's device before disconnection may address the right to access some operations (forbid some operations on shared data during the disconnection) or change the execution of operations whose behavior must be connection-dependent. The validation of a reservation is for example an operation which needs the global context available only in connected mode and therefore cannot be executed in the same way during disconnection. Middleware adaptations are also needed in order to support application execution in different computer environments characterized by different computational constraints. The adaptation can consist of simplifying or even suppressing the transaction management. It can address the persistency service and consist in using data stored in local files rather than managed in a database (a database is a memory-consuming application which is a problem for PDAs). Finally, the adaptation can also concern the communication protocols. 1.2 Approach We believe that a reflective approach is a uniform way to achieve the goals of adaptability and specificity. At the middleware level, a reflective architecture can adapt itself to a given configuration, either by replacing some parts of code or by adding new functionalities [BP97]. Instead of having to manage an important number of system versions and choose the most appropriate one at loading time, a reflective architecture allows the building a minimal system which can be dynamically extended with more or less independent services [BR2000], also called aspects in other systems [KLM+97]. In our context this is applied literally. Having in mind the complexity of distributed applications, the various parameters of configuration, the diversity of mobile devices and the infinity of users' preferences and ways of utilization, it is not realistic to have all the versions pre-programmed and available. In order to prepare the work in disconnected mode and to take into account the specificity of the working environment (the device), the specificity of the application (internal logic)

2 and the specific preferences of the mobile user (possibly given at the moment of disconnection) we need a reflective architecture which can adapt dynamically. At the application level, the adaptation of the code and the data can be managed by specific interposition objects that intercept the calls to the objects of the application. This is indeed a good way to separate the functional code from the management of the application properties such as persistency, security, replication, etc. Such interposition objects are often application-specific. However, they are generally static i.e they are fixed to correspond to only one type of computing environment and do not support adaptation. It is the reason why we are currently working on the relevance of building interposition objects with reflective features. This would allow the application's behavior to be adapted according to the properties of the computing environment. In the following of this paper we present the way we use reflective mechanisms to build an adaptable middleware. This middleware allows the application's behavior to be dynamically adapted and supports mobile users through the replication of objects. The middleware architecture is presented in section 2, while the principles of the management of mobile users are explained in section 3. 2 The JavaPod reflective architecture The architecture we use as a support for mobile users is called JavaPod and is inspired by the Enterprise Java Beans platform architecture [EJB]. The main difference with EJB is that JavaPod provides a more important degree of adaptability as explained in the following. 2.1 Adaptable objects Adaptable objects are the basic reflective entities used by JavaPod. An adaptable object (Figure 1) is composed of a totally ordered set of objects (subobjects). The first sub-object in this order is called extensible object while the others are extensions. While the extensible object is invariant, any of its extensions can be added, removed or replaced dynamically. A method call on an adaptable object is executed by the last (in the considered order) sub-object. If there is no sub-object which implements the method, the call fails. Any extension has the ability to call the same method on the lower level sub-object. In other words, an extension can add new methods on the extensible object, or modify the existing ones. Client N() N() Extension e Extensible object o Figure 1 : Adaptable object (o < e) T This composition model is made available through an extension of the Java language, called ejava. In ejava, an extensible object is a Java object extending the ExtensibleObject class. In the same way, an extension is a Java object extending the Extension class. The following example illustrates the basic mechanisms provided by ejava. The object of class C can be dynamically modified with an extension such as D, through a call to the addextension(new D()) method defined in ExtensibleObject objects. class C extends ExtensibleObject { private int value; public int getvalue () { return value;} public void setvalue (int value){ this.value = value; } public void printvalue () { System.out.println(value); } } class D extends Extension { public void printvalue () { System.out.print("the value is"); super.printvalue(); } public void addvalue (int value) { int oldvalue = ((C)this).getValue(); ((C)this).setValue( oldvalue+value);} } //the cast (C) is possible because class D is an extension of class C 2.2 The JavaPod architecture A JavaPod application is composed of a set of components. A component is a non-distributed entity consisting of a graph of objects which may be adaptable or not, according to the developer s needs. Components are associated with containers, which represent their system view.

3 A container encapsulates a component i.e. it intercepts any communication between the component and the external world. A container is more precisely an adaptable structure, composed of adaptable stubs and skeletons which can manage the incoming and outgoing communications according to some application-dependent constraints. Containers are executed within Servers, which act as providers of services such as communication protocols, persistence, replication, security. A server is itself programmed as an adaptable object. container server S1 container server S2 Figure 2 : The JavaPod architecture 3 Support for disconnected users The main idea of our proposal is to enable the application s programmer to define explicitly the replication/ reconciliation protocol for a given application and to connect this application-dependent part to a generic support whose adaptations during transitions (connections/disconnections) are also controlled by the programmer. As our support for mobile users is based on replication, we present in Section 3.1 the principles of the replication management. In section 3.2 we discuss how ejava extensions and thus reflexivity are used to ensure a normal working environment in disconnected mode. 3.1 Replication management Replication units While the replication of fine-grained objects would be inefficient, JavaPod allows to consider the replication of components (clusters of objects) which are the basic units of construction of an application. The different replicas of a given component C may have different contents. However, they all provide the same interface. This allows to program calls to components without worrying about their replication state. Replication model We use a one master- many slaves replication model. There is one master replica per component and it coordinates replicas creation, placement, deletion and reconciliation. For the moment we consider masters as fixed entities which do not migrate. Replication management at the application level In order to reflect the application s specificity in the creation and reconciliation of replicas, we propose that a particular interface (ReplicableComponent, Figure 3) is implemented by components. Basically the methods are ComponentClone(...) for creating a specific replica and ComponentMerge(...) for application-specific reconciliation. This upcall mechanism will come as a complement to the and thus adapt it to the application s semantics. Although at the moment we think of this interface and its implementation as being fixed during the implementation of the application, we can imagine to implement it as an adaptable object and allow the programmer to choose different extensions (depending on the user s preferences) at different disconnections. Thus the replication strategy would become adaptable while remaining specific to the application. When we talk of adaptation of the replicas contents, we refer mainly to the data manipulated by the component. This allows the user to take away only the data he needs. For the moment we are not considering the possibility of mechanisms allowing a user to open a component and to replicate only a part of its operations. This feature could be considered if we are interested in rendering the components lighter by replicating only the treatments wanted by the user. Component ComponentClone(...) ComponentMerge(...) Figure 3 : Interface ReplicableComponent To allow the user to explicitly request a disconnection, we think of providing a disconnect operation in the interface of the application. This operation would start the process of replication and thus of adaptation to the new environment and may be interactive. The user can be requested to give his preferences and choose to use the data to be replicated. It is this dialogue which will be used to define the components needed to be replicated. Calls can then be made to the in order to create the corresponding replicas. At reconnection time, an operation connect should take into account different possibilities of interaction. In the case of a demand for reconciliation, the modified content of a component will be merged with the master by using the methods programmed specifically in the ReplicableComponent interface. To identify the modified content, the support could be aided by the information

4 given at disconnection and concerning the mode of utilization. (If a method is forbidden for a user, there are no modifications due to calls to this method.) The reconciliation is not necessarily followed by a destruction of the local replicas. The user may wish to continue working in disconnected mode. The connect operation can also be used in order to complete a local configuration of the application and create additional replicas. In this case, we will use the same mechanisms as explained above. Replication management at the middleware level There are several important points to consider about replication management at the middleware level. First, the communication between application s components is depending on the connection context. In connected mode this communication is mostly distributed (for example RMI), while in disconnected mode replicas communicate locally. This is one of the features to be adapted while switching the mode. With the JavaPod reflective architecture this is to be done using the capacity to dynamically adapt a container s stubs and make them reference the local replicas. The references used depend on the connection context. Locally we will use the replicas local references, while in a distributed context, the only valid references would be those of the master components. The switching from local to global references and vice versa is done only when needed (changing of context for example) by using a bijective mapping. The services and protocols used either implicitly or explicitly by the application have to be adapted too. For instance, the transaction service may be absent during disconnection, the transactions being performed at reconciliation time. The change of the persistency service, as we ve already mentioned it in the introduction of this paper, is also an example of the adaptation needs. Adaptations are also to be made at reconnection. The system has to be adapted to the distributed context. Knowing that this context could be different from the one used before disconnection, the readaptation is not necessarily a restore of a connected state. Figure 4 presents schematically the replication management support. It shows the communications between the and a component which are used for the application specific replication/reconciliation protocol. There are also the list of server s extensions (, etc.) as well as the stubs of communication allowing adaptations thanks to the JavaPod reflective capacities. Replication Service ComponentClone(...) ComponentMerge(...) Persistency Service adaptable stub Server Figure 4 : Replication support 3.2 Managing disconnected users: an example We will illustrate the operation of the proposed support by an example of a shared agenda. The agenda is managing reservations and is located on a server. The reservations are stored in a database. While connected, the user accesses the agenda through a user interface (UI, Figure 5) executed on the client s machine (e.g an applet). The user can create reservations or demand to see the reservations for a given period of time (a month for example). When this happens, a component Month is created and becomes part of the application. It is not compulsory for the database or for the newly created components Month to reside on the same server as the component agenda. UI Agenda January Client C Server S Figure 5 : Client and Server in connected mode At disconnection time, the user chooses to keep the data corresponding to the reservations for the month of January. The disconnect() operation then calls the createreplica(...) method of the of the client s server for the components to be replicated, in our example the root component agenda and the component representing the month January. The communicates with the Replication Service of Server S, which addresses the specific clone methods provided by the two components to get their replica content. The has then to adapt the UI and namely his stubs and skeletons in order to use the local

5 replicas. The communication between the replicated components (agenda and month January) is also to be local even if the master components are possibly distributed. UI In our example, the two stubs for communicating with the agenda and the month component, as well as the stub between the agenda and the month, are adapted to reference the local replicas. 4 Related work The idea of allowing the application's programmer to define the process of data reconciliation at reconnection has been explored in other projects such as Bayou [TTP+95]. Compared to our proposal, Bayou addresses file replication at the server side for availability reasons. Others projects have tried to support disconnected work at the file system level ([Sat96], etc.). They have addressed the problems of data prefetching and optimistic concurrency control. There are systems or middlewares which use reflective features for providing a [KIG96]. However, at our knowledge, they do not really address the same objectives, mainly because they provide replication in order to increase the efficiency and the availability of an application. Finally, other projects such as Rover [JLT+95] define an architecture for allowing work to be done in the presence of network disconnections. One major difference with our proposal is that Rover objects are specifically programmed, and communicate through a specific access manager. Moreover, the problem of adapting the middleware to the constraints of a client's host is not addressed. In general, the using of reflective features in distributed systems is becoming more and more attractive because there is a need to provide open middlewares which can be adapted to the environment, to the application and to the users needs [BCR+97, Led99]. 5 Conclusion Agenda January adapted stub Figure 6 : Client in Disconnected mode In this paper we presented our framework enabling the construction of applications supporting disconnected mode of work. Disconnection is supported through replication and we allow the definition of application specific replication/reconciliation protocols. Reflection is used in order to effect the needed adaptations (both the application and the middleware levels) at disconnection and reconnection times. We expect to provide an intelligent support which could be easily adapted to various types of applications. We are actually working on our first prototype and plan experimentations with different applications. Some interesting issues to consider in the future include for example support for unpredictable disconnections. Acknowledgments We wish to thank Eric Bruneton for the valuable discussions concerning reflection and replication issues as well as for his remarks helping the redaction of this paper. References [BCR+97] G.Blair, G.Coulson, P.Robin, M. Papathomas, An Architecture for Next Generation Middleware, In Proc. Of Middleware 98, Springer-Verlag, Septembre 1998 [BR2000] E.Bruneton and M.Riveill, JavaPod: une plate-forme à composants adaptable et extensible, INRIA research rapport 3850, January 2000 [EJB] Entreprise JavaBeans, produects/ejb [JLT+95] A.Joseph, A.deLespinasse, J.Tauber et all. Rover: A Toolkit for Mobile Information Access, In Proc. of the Fifteenth ACM Symposium on Operating Systems Principles (SOSP), Copper Mountain Resort, CO, 1995 [KIG96] J.Kleinöder, M.Golm MetaJava: An Efficient Run-Time Meta Architecture for Java. In Proc. of the International Workshop on Object Orientation in Operating Systems - IWOOS 96, October 1996, IEEE 1996 [KLM+97] G.Kiczales, J.Lamping, A.Mendhekar et all. Aspect-Oriented Programming, ECOOP 97, Jyväskylä, Finland, June 1997 [Led99] T.Ledoux, OpenCorba: a Reflective Open Broker, Reflection 99, Saint-Malo, France, July 1999 [Sat96] M.Satyanarayanan, Mobile Information Access, In IEEE Personal Communications p.26-33, February 1996 [TTP+95] D.Terry, M.Theimer, K.Petersen et all. Managing update conflicts in a weakly connected replicated storage system, In Proc. of the Fifteenth ACM Symposium on Operating Systems Principles (SOSP), Copper Mountain Resort, CO, 1995