Designing Distributed Object Systems for Mobile Computing Larry T. Chen
Tatsuya Suda
[email protected]
[email protected]
Department of Information and Computer Science, University of California, Irvine August 21, 1996
Abstract
enable a mobile computing system to operate as a uni ed computing entity, or distributed system. The distributed object paradigm has proved to be indispensable in the design of traditional distributed systems due to its inherent ability to hide heterogeneity between various platforms (i.e. network, machine, and operating system heterogeneity) [1]. When mobility is introduced into a distributed system, the degree of platform heterogeneity will likely increase. Since mobile computing intends to provide ubiquitous access to computing resources for users, the system software must accomodate wide platform heterogeneity. In addition, mobile computing introduces other heterogeneity considerations, including:
This article examines the impact of mobile computing on the design of distributed object systems. The de ning characteristics of mobile computing, such as the frequent movement of users and hosts, the scarcity of network and local computing resources available to the mobile host, and the possibility of disconnections, present dicult challenges in providing a highly-available distributed object system. Meeting these challenges requires dynamic resource management techniques in the xed-network architecture as well as optimistic concurrency control techniques to support disconnected operation in the mobile client architecture. Various issues and solutions in dynamic resource management and disconnected operation are discussed. In addition, mobile computing introduces new security concerns in distributed object systems, including the increased possibility of eavesdropping and the need to provide location untraceability for users, hosts, and data residing in objects. Security issues and solutions pertinent to distributed object systems for mobile computing are also discussed.
variations in device capabilities, such as display,
input, and processing capabilities on both the server and client;
variations in resource availability due to the mo-
bility of users and hosts.
The requirements of mobile computing applications also di er from those of traditional distributed system applications. A majority of future mobile applications will fall into three categories: information services, vir1 Introduction tual oce applications, and computer-supported coopIn recent years networking technology has advanced erative work (CSCW) applications. These applications to where mobile, nomadic, and ubiquitous computing are characterized by the following distinguishing re(henceforth collectively termed mobile computing) is a quirments: plausible reality. While the required wireless hardware Resource awareness: technology is rapidly maturing into standardization, equally important system software support is still in Applications adapt to the availability of resources its infancy. Required are software paradigms that will in its environment. Resource-aware applications 1
would run on a variety of display devices, on computers with varying processing power, and under various network bandwidth limitations.
Connection transparency: Frequent hando
and disconnections results in frequent disruptions and changes to the connection between mobile host and server, possibly in the middle of an application session. An application should be able to carry on a session over several disjunct connections, each possibly using di erent network protocols. In the event of complete disconnection, the system should provide seamless, automated disconnected operation for the application.
Context Awareness: Applications adapt func-
tionally to its environment. As mobile hosts move, applications designed for the environment where a host currently resides are loaded. (For example, a train schedule is displayed automatically when a user carries his laptop into a train station.) communication costs, and even non-technical aspects such as lighting, noise level, and social situation (e.g. whether you're working with a manager or a co-worker).
Indirect interaction: User input processing
should be done as close to the mobile host as possible to minimize interactive feedback delay. The e ect of the unreliable wireless connection on application availability and responsiveness should be minimized.
Ubiquitous
Access: A user's personal workspace along with his favorite applications are accessible from any location, permitting remote read/write access to the user's personal data.
Adaptive communication protocols: With
mobile hosts facing variable bandwidths and heterogeneous network platforms, applications need to adapt accordingly to provide maximum usability given available communication facilities.
Provision of these application features requires a dynamic resource architecture, where resources are distributed dynamically to accomodate changing access patterns from mobile users. We believe the distributed object paradigm presents the most natural, e ective programming paradigm currently available for developing distributed systems for mobile computing environments. Platform, device, and resource heterogeneity can be addressed by object encapsulation and polymorphism, while provision of a dynamic resource architecture is addressed by object replication, migration, and delegation. The physical limitations of mobile and wireless technology present further challenges in designing a distributed object system for mobile computing. Unlike classical distributed systems consisting of highpowered workstations running over reliable xed highspeed networks, mobile distributed systems are faced with (1) frequent disconnections from the network, (2) widely variable bandwidths among wired and wireless links, (3) limited CPU power and device capacity, and (4) transient servers due to frequent hando (i.e. the server for the mobile host changes frequently). These constraints imply that systems for mobile environments need to adhere to the following design guidelines:
Application partitioning: Since mobile hosts
will often operate disconnected or weaklyconnected (connected via a slow or unreliable connection), applications need to be designed so that some of its components can be migrated to and run on the mobile host.
This article examines issues in applying the distributed object paradigm to building mobile applications and systems. Section 2 presents a general distributed object architecture for mobile computing. Section 3 explores issues in building the xed network server architecture for a mobile computing environment. Section 4 follows with an examination of issues in building mobile client applications and environments. Finally, we focus on security concerns exacerbated by the introduction of mobility and the wireless medium in Section 5. 2
Distributed Object Management Architectures for Mo-
Minimum host-network coupling: Given the
bile Computing
unreliable nature of the wireless connection, applications must be designed with minimum coupling between mobile host and network host/server.
2.1 A General Architecture 2
of its functionality implemented using mobile objects does not have to reside in its entirety on a single host. The application may be partitioned between the MSS and the MH; that is, parts of the application may migrate to a MH client, while the remainder resides on a MSS in the xed network. Application partitioning achieves smoother performance across a slow link from the MH to the MSS. Also, by allowing parts of the application to run on the mobile host, application partitioning also enables disconnected operation, where the user continues working with the application even while the MH is not connected to the xed network. Similarly, data residing in mobile objects may move or replicate among MSSs and MHs. Replication provides increased availability of data, especially in the event of a network partition, or a breaks in the general network interconnectivity. A network partition may be caused, for example, by a mobile host disconnecting from the xed network, or the detachment of a MSS from the xed network. Replication of data objects also introduces the problem of consistency management among multiple replicas. Replica consistency management is especially dicult in the event of network partitions. Resources provided as mobile objects originate and reside on xed hosts, but may be replicated or migrated to a secondary host to decrease latency between the MH client and desired resources on the xed network. Mobility of network resources also accommodates user mobility. A user may move between his oce computer and his home computer, and his personal customized workspace will migrate along with the user. It is important to note that, in the scenario presented above, there are three possible migrating entities: the host, the user, and the object. Objects usually migrate or replicate to accommodate the the movement of hosts and users.
Figure 1: A General Architecture In this article, we assume a general physical architecture consisting of mobile hosts (MHs), mobile support stations (MSSs), and xed hosts (FHs) interconnected by a xed wide-area network such as the Internet, as shown in Figure 1. Mobile hosts communicate with mobile support stations (MSSs) on the xed network through either a wireless or wired link. Mobile hosts are assumed to have limited but reasonable processing power, disk space, and memory, as in modern laptop and notebook computers. Client applications running on mobile hosts access shared resources provided in the form of resource objects. Most of these resource objects are also mobile objects; that is, they are able to migrate or replicate to remote hosts. Each MH possesses an object cache capable of caching resource objects obtained from the the xed network. Mobile support stations are xed hosts which contain hardware and software mobility support, including wireless network interfaces, mobile-aware routers, and mobile object servers. Mobile object servers are temporary execution environments for mobile resource objects. Fixed hosts, such as data and application servers, are the original holders and providers of resource objects for MH clients. An object refers to any software entity representing a logical grouping of data and methods, e.g. les, application components, dynamic libraries, Java applets, etc. A resource object, then, provides services such as shared data storage, information retrieval, or application component functionality. We classify resource objects into objects whose primary purpose is to provide application or service functionality, or application objects, and objects whose primary purpose is to provide data storage and retrieval, or data objects. Application objects are typically stateless; that is, they provide a set of read-only methods as a service to a client application. For example, an object which returns the current stock quotes would be a stateless application object. Application objects may also contain application components, which are dynamically installed on MH clients. Data objects, on the other hand, possess state, i.e. client applications may read and write to data objects. Objects in an object-oriented database are examples of data objects which possess state. A mobile object may move or replicate among MSSs and MHs; thus, an application which has part or all
Mobile host constraints Mobile hosts operate under a variety of varying energy and bandwidth constraints. The possible operating states of a mobile host may be categorized on one axis by quality of network connection (available bandwidth), and on the other axis by power consumption (available CPU power), as shown in Figure 2. In terms of available bandwidth, the mobile host may operate under varying degrees of network connectivity, including: completely disconnected (with an e ective network bandwidth of zero), weakly-connected via wire3
where, a general consensus in the design of shared mobile systems has emerged [18, 19, 20] to provide maximum availability at the expense of full consistency.
Figure 2: Space of possible mobile host states less (where the connection is intermittent and unreliable), connected via wireless (such as over a relatively reliable wireless LAN), or connected with a wireline link (e.g. connected via Ethernet). In terms of available CPU power, the mobile host may be: suspended while operating on batteries (thus with very little available CPU power), running normally on batteries (with full CPU power available but e ort should be made to conserve energy), or running on "unlimited" power from an electrical power outlet. The mobile host's various possible operating states raise several interesting fundamental tradeo s, namely:
2.2 Location Management Architectures 2.2.1
Host, user, and object mobility
As described previously, three entities|the host, the user, or the object, may move in a mobile distributed object environment. Host mobility refers to the physical movement of computers, usually the movement of portable computers connected to the xed network via a wireless interface. User mobility is characterized by the users moving to di erent hosts to access computing services on the xed network. For example, a user may access his daily schedule from his laptop, his home computer, or his oce computer. It is important to distinguish between host and user mobility since users may not always carry their portable computers, yet users may desire access to common services from any terminal (host). Object mobility refers to the migration of objects from one host to another. Object migration may take place between servers, between clients and servers, or between clients. Support for object mobility is important to achieve dynamic and adaptive resource architectures (to be discussed in Section 3.4). When designing distributed object systems for mobile environments, all three types of mobility must be considered and addressed.
bandwidth conservation (or client vs. server computation). Conserving energy implies that computations should be minimized on the mobile host. On the other hand, conserving bandwidth implies that computations requiring communication over the wireless link should be avoided as much as possible. That is, most computations should be done locally on the mobile host, and results should be sent over the communication channel only when necessary and even then preferably en masse. Whether energy or bandwidth should be regarded as the precious resource depends on the operating mode of the mobile host, as summarized in Figure 2.
Energy vs.
Consistency: A basic service of a mobile computer system is read and write access to shared data stored on the xed network from remote locations. Given that mobile hosts are frequently weakly-connected or completely disconnected, a fundamental tradeo arises of whether full availability or full consistency is more important. To provide full availability, users must be allowed access to shared data even during weak-connection and disconnection. Attempting to enforce full consistency, on the other hand, would incapacitate mobile hosts during disconnection, since full consistency cannot be maintained without communication between the mobile host and xed network.
Availability vs.
2.2.2
Naming Services and Routing Functions
Support host, user, and object mobility raises two basic concerns: how an application refers to these entities (naming) and how messages send to these entities reach their mobile physical locations (routing). A naming service to allow location-transparent access to hosts, users, and objects is essential. An existing naming service for hosts is the domain name system (DNS) of the Internet. DNS provides a basic mapping between hostnames (which may be considered as virtual addresses) and IP addresses (which may be considered as physical addresses). However, DNS assumes Since the underlying motivation for mobility is to that hosts remain generally static, and therefore has increase the availability of a computer system so that no provisions for handling frequently changing physiusers have access to its shared data anytime and any- cal addresses. A user naming service is analogous to 4
of a mobile addressing scheme such as Mobile IP. To support user and object mobility, object and user naming services can maintain dynamic object-to-host and user-to-host mappings, respectively, using existing host naming services. The primary advantage of using mobile addressing and routing is that it permits existing applications intended for xed networks, using xed IP addresses, to run in a mobile environment. Also, existing host name servers need not be changed. On the other hand, the disadvantages of introducing mobility at the network layer cannot be ignored. Existing routers need to be changed to support mobile addressing. In addition, since layers above the network layer are unaware of mobility, session and transport protocols, for example, cannot be optimized according to the characteristics of mobile computing.
Figure 3: Two Mobility Managment Architectures Unix's database of user login names. A naming service for objects is exempli ed by the Name Service de ned in OMG's Common Object Services Speci cation [16]. The Name Service maintains a name-to-object mapping which allows clients to access objects by name in a location-independent manner. The general goal of these services is to provide uniform access to entities by name, so that applications do not have to track the frequently changing locations of these entities. Since users and objects reside on hosts, user and object naming services map user and object names to host names. Routing messages to users and objects therefore involve rst nding the mobile destination host. Routing messages to mobile hosts may be approached in two ways: (1) introduce mobility support at the network layer, or (2) use application layer routing mechanisms in conjunction with normal IP routing services. The rst approach (Figure 3(a)) is best exempli ed the proposed mobile addressing and routing schemes (e.g. Mobile IP [9] and VIP [10]). These schemes augment the standard IP address with a secondary address pointing to the current MSS serving as the mobile host's interface to the xed network. Applications may continue to use the normal xed IP address; underlying addressing and routing protocols will ensure that packets reach their intended mobile host. A drawback is that enhanced router software must be installed at routers to recognize mobile IP headers. The second approach (Figure 3(b)) requires that the user and object name servers running in the application layer also dynamically track the changing physical locations of mobile hosts. Name servers maintain an up-to-date mapping of host names to IP addresses. Unlike the mobile IP approach, applications must refer to mobile hosts by name. 2.2.3
Mobility Transparency vs. Awareness
Application Layer Routing
At the other extreme, the architecture may be designed so that all layers, up to and including the application layer, are aware of host mobility. In this scenario software in the application layer on MSSs and mobile hosts must handle routing. Potential advantages of this design over the network-layer mobile addressing approach include: (1) optimization of session protocols and RPC protocols to account for the possibility of disconnections and hando s; (2) integration with existing networks which do not have routers capable of handling mobility; and (3) uniform location management of hosts, users, and objects. Mobile addressing and routing schemes only track mobile hosts and do not track objects and users. A higher layer mobility management approach permits the tracking hosts, objects, and users in a uniform, integrated manner. Given the advantages described above, the rest of this article will assume mobility awareness in the upper layers (session, presentation, and application layers) as issues in the design of distributed object-oriented systems for mobile environments are presented.
Mobility
The routing tradeo described in the previous section 2.2.4 Location Management Schemes characterizes two general mobility management architectures shown in Figure 3. Whether we need to track the locations of users, hosts, Network Layer Routing or objects, the required location management schemes By using mobile addressing and routing schemes fall into two general categories: broadcast-based and such as Mobile IP, all layers above the network layer query-based [17]. For the sake of illustration, we will remain unaware of host mobility. Existing host nam- discuss the following schemes in the context of host ing services (e.g. DNS) can continue to run on top mobility management. 5
Figure 4: Location Management Schemes
Figure 6: Agent-based message delivery
Figure 5: Hierarchical Location Management Architecture
Figure 7: Connection Transparency tonomous navigation and replication capabilities. An
Broadcast-based: A simple but unscalable so- example of the bene ts that can be derived from agent
lution, broadcast-based schemes require a mobile host to notify all all hosts in the system after every location change (Figure 4(a)). Also, every host in the system is required to maintain a location database of all other hosts with which it wishes to communicate.
based message delivery can be seen in Figure 6. A message needs to be multicast to three location servers, but the messages originates from a mobile host connected over a slow wireless link. An autonomous agent can rst send one copy of itself to the xed network, then replicate itself to multicast three copies of the message Query-based: An alternative approach is to to the three location servers. By sending only one mesmaintain a centralized database of the locations of sage over the wireless link, message overhead is reduced all hosts in the system at a location server (Fig- and the wireless bandwidth is conserved. ure 4(b)). A moving host noti es the location server when it reaches its new location. Any host 2.2.6 Connection Transparency wishing to contact a mobile destination host rst In a mobile environment, a connection to a server may queries the location server. not be maintained through the duration of an application session, or even through the duration of an operaA simple implementation of either broadcast-based tion. Mobile hosts may move to another cell during an or query-based schemes does not scale well. In a application session, perhaps requiring another MSS to broadcast-based system, the number of hosts may ful ll the application's requests. The mobile host may reach a point where broadcast becomes inecient or move into cells with heterogeneous underlying network impossible. In a query-based system, the central loprotocols, and may even become temporarily disconcation database grows beyond manageability. A realnected during an application session. To the user the istic scalable implementation will likely combine both application should appear to run uninterrupted obliviapproaches by interconnecting heterogeneous subnetous of the mobile host's mobility and connection status. works hierarchically, as shown in Figure 5. (See Figure 7.) To achieve such connection transparency, the frame2.2.5 Message Delivery work must provide a session abstraction which may Implementation of the above location management possibly span several connections and disconnections schemes will require unicast and multicast capabili- in sequence. The details of connection hando and disties in the network. Traditionally, messages are pas- connection should remain hidden from the user. While sive, that is, network routers and applications dictate the mobile host is disconnected, the underlying frameexactly where messages will travel. Active messages work emulates the server so that applications conbased on autonomous mobile agents [30, 12] are an at- tinue running without interruption as much as possitractive alternative for message delivery in a mobile ble. (Disconnected operation will be discussed in depth computing environment. Autonomous mobile agents in Section 4.) are intelligent messages with self-routing capabilities To provide consistent service and resource availabiland self-replication capabilities. The agent's ability ity from one cell to another, the new MSS must be able nd its way through the network makes them suit- to reproduce the services and resources of the former able for a wide-area network with an unknown net- MSS, either through replication of the original server work topology, as may be the case in an environ- object, migration of the original resource object to the ment with mobile clients. Autonomous agents may be new MSS, or delegation of requests to the original reprogrammed to carry out query-based or broadcast- source object. Dynamic management of server objects based location management, given that they have au- on MSSs constitutes dynamic resource management, 6
which is the topic of the next section. 3
Replication undergoes a nal stage when multiple replicas of an object are reconciliated, i.e. combined back into one primary copy. Final overhead, incurred when replicas are reconciliated and removed from the secondary hosts, may be low if consistency among the replicas was constantly maintained. If replicas are consistent immediately prior to reconciliation, the replicas on the secondary hosts may simply be removed, leaving only the original copy of the object at the primary host. However, if replication occurred across a network partition (i.e. if a replica resides on a host which became disconnected from the rest of the network, then reintegration of inconsistent replicas may be necessary, thus incurring a high nal overhead. (The reintegration process is discussed in Section 4.7.)
Server Object Management
We now discuss mechanisms for providing a dynamic resource architecture where resources are provided as application and data objects. Application and data objects originate at xed hosts called primary hosts. The mobile support stations (MSSs) which temporarily hold migrated or replicated mobile objects are secondary hosts. To provide ubiquitous access to an application or data resource, the MSS serving the mobile host (MH) in question must either (1) possess the requested resource object or (2) forward the request to a host that has the requested resource object. The MSS may possess the requested resource object because either the MSS is the primary host for the requested object, or the MSS is acting as a secondary host as a result of replication or migration of the requested object. If the MSS forwards the request to another host which possesses the requested object, then the MSS is performing delegation. With these three available mechanisms, the goal is to provide a dynamic resource architecture which achieves high availability and low access latency of resources for MH clients.
3.2 Object migration Replication may not always be the best solution to increasing the availability and eciency of services provided by an object server. In certain cases, it may be better to migrate the resource object from its original primary host to a secondary host, thereby maintaining only one unique copy of the resource object in the system. Having one unique copy of a resource object eliminates the need to propagate updates to multiple replicas to maintain consistency, thus eliminating much of the maintenance overhead involved in object replication. A unique copy of the server object may also be preferable for security reasons. Migration may also be preferable to save computing resources by removing processor load from the original host. In situations where the access pattern of a particular resource object shows a distinct migration of the access concentration area from one part of the network to another, migration of the resource object may be preferable.
3.1 Object replication Replication of resource objects on secondary hosts such as MSSs is an attractive technique for providing high availability and low latency of resources for MH clients. Replication increases the likelihood that a server with the requested resource object will be near the requesting MH. In the event of network partitions, replication increases the likelihood that a requested resource object will reside in the MH's current partition. For example, when a MH disconnects from the xed network, the MH itself and the rest of the xed network become two disconnected parititions. Availability of a requested resource is ensured if a replica of the resource object resides in the MH's current partition, i.e. on the MH itself. This scenario is the special case of disconnected operation, to be discussed in Section 4. Replication incurs a high setup overhead, since the entire object must be copied across the network and the secondary host needs to create a new process for the replicated object. Replication also incurs high maintenance overhead during access due to the need to maintain consistency between object replicas.
Note that migration still su ers the same high setup overhead of replication, due to the need to transfer the object across the network and create a new process on the secondary host. Maintenance overhead while the object is being accessed is minimal since there's only one copy of the object. Final overhead may include migration costs back to the original primary host if so desired. Alternatively, the migrated object may be left at its new location so that the secondary host becomes the new primary host. 7
3.3 Object delegation
Figure 8: Tradeo s between delegation, migration, and replication
Object replication and delegation incur high setup overheads, and thus may not always be the solution to providing wide availability of a resource object. If an MSS needs to temporarily provide the services of a rarely used remote resource object, requests from a MH may simply be forwarded, or delegated, to a host which has the requested resource object, thereby avoiding the relatively expensive overhead of replication or migration. The MSS which delegates requests to other hosts essentially hosts a proxy object, which appears to a MH client as a normal resource object, but the implementation of its methods and the storage for its data resides elsewhere on another host. Delegation avoids the initial setup overhead of sending an object across the network, as well as the overhead of ongoing consistency management between object replicas. Final overhead, a concern especially in replication, is non-existent in delegation.
the pre-allocation of resources to eliminate perceived delay of resource access as mobile hosts move around. Pre-allocation of resources is based on the mobility patterns of users and hosts and their resource access statistics, using migration or replication to place resources at locations where a high concentration of MHs desiring those resources will most likely be. If migration or replication overhead is determined to be too high, delegation is used. Figure 3.4 summarizes the tradeo s between replication, migration, and delegation. Intuitively, a balance in the replication, migration, and delegation tradeo would yield an optimal resource placement, where resources are placed such that resource objects are close to those mobile hosts that access them the most, and the overhead of migration or replication is justi ed by predicted availability and performance improvements for a large number of mobile users. Dynamic resource allocation may be performed on a variety of temporal granularities. Resource allocation on a real-time basis constitutes the nest temporal granularity. Real-time information regarding a particular mobile host, such as its current movement direction, may be used to predict where the mobile host may move to next. Resources are therefore preallocated at the adjacent cells to where the mobile host will likely move [28]. To pre-allocate resources on a coarse-grained temporal basis, general resource access statistics collected over large time intervals, such as the resource access patterns during the course of a day, may be used. Possible correlations may be found among other parameters, such as access location, type of service, type of user, number of users, and end-user satisfaction. For example, another possible correlation is: Time of day vs. access location: \During the daytime, most clients are accessing resource object A from the oce or the road. During nighttime, most clients are accessing resource object A from home." Other possible correlations may relate services to access location, or services to time. Machine learning techniques employing maximization of information gain may be applicable here [29]. These machine techniques may be used to identify pairs of parameters with high correlations. A detailed formulation of this ma-
3.4 Dynamic resource management We have discussed three mechanisms, replication, migration, and delegation, for providing wide availability of resources to a mobile host. What combination of these mechanisms should be utilized to increase performance and availabilty for users while conserving host processor load and network bandwidth? From the user's standpoint, ideally desired resources should be replicated on nearby MSSs or locally on the MH, thus incurring minimal delays when accessing the resources. However, consistency management of the resulting deluge of replicated objects may consume network bandwidth. From the server's point of view, there should be as little replication as possible to conserve host processor load; however, resorting to migration or delegation may increase latency for the client, since these techniques may not be able to place resource objects close to all MHs who desire them. There is some threshold at which the bene ts of the heavyweight approach (replication or migration) outweigh the drawbacks of replication or migration and the simplicity of delegation. This threshold depends on the frequency that resource objects are accessed, the locations of clients from which resource objects are accessed, and the times (e.g. time of day) during which resource objects are accessed. Resources need to be dynamically managed according to these access statistics. The central goal in dynamic resource management is 8
tion with the xed network (Figure 9(c)). Whether the Figure 9: The Three Phases of Disconnected Operation cached and replicated server objects are read-only or modi able has a substantial e ect on the complexity chine learning problem is beyond the scope of this ar- of the reconnection stage. An object which provide read-only methods can be simply discarded from the ticle. client cache upon reconnection. However, if an objects involved in disconnected operation exports methods which allow writes to the object, then any modi ed 4 Client Object Management replicas in the client cache needs to be reintegrated with On the client side, techniques to provide high perfor- the primary copy of the object in the xed network. mance and availability of computing services are deModi able objects introduces the general problem sired. High performance implies fast user-perceived of consistency management in disconnected operation. response times. High availability implies that useful Consistency management may be done at various granwork can be done while the mobile host is in any of ularities. In Sections 4.6 and 4.8, We will consider its various connection states (disconnected, weakly- coarse-grain consistency management, which uses an connected, and connected). A major challenge arises entire object as its basic unit, and ne-grain consisin providing disconnected operation,or continued op- tency management, which uses read/write operations eration of client applications which require access to on members of the object as its basic unit. server objects (objects provided by a server) after disWe will rst discuss the simpler case of providing connection from the xed network. disconnected operation for stateless, read-only objects. Techniques for providing high performance and availability generally involve the migration or replica- 4.1 Stateless Objects in Disconnected tion of server objects (objects that originate on the Operation server) to the client. Server object migration has been used to minimize invocations across the network to en- To provide disconnection operation for a stateless, hance performance in the client/server model. For ex- read-only server object, the server object can be ample, Java applets successfully employ migration of prefetched from the primary copy site and replicated objects from the server to enable complex Web page on the client before disconnection, then held in the behavior that would have been inecient and impracti- client's local cache during disconnection, and simply cal over the standard client/server model. Smart proxy discarded upon reconnection. Since the object cannot objects [13, 24] also employ server object migration to be modi ed by the client, no reintegration of object reduce remote object invocations in a client/server ses- data with the primary copy of the server object is necsion. essary. Examples of such objects are: a mathematiServer object migration (or replication) is also essen- cal function library, an information server (for news, tial in achieving disconnected operation. To keep the weather, stock reports), and operating system and apmobile client operating during disconnection, server plication modules. Currently, Java applets are stateobjects required to operate the client applications must less, since most of them provide only functionality on be prefetched (or hoarded) from MSSs or other servers the client and do not store any data. Also, Java has in the xed network and replicated inside the client no automatic facilities to upload the Java applets back cache before disconnection (Figure 9(a)). While the to the server for reintegration purposes. client is disconnected, the client caching system emuAn intuitive solution for handling cache-misses with lates the xed network by handling requests locally us- a stateless object is to defer invocation of the remote ing the cached replicated server objects (Figure 9(b)). stateless object until it is available at reconnection A cache-miss may occur when requests are made for time. However, if client applications become blocked the services of a server object which was not pre- waiting for the availability of the remote object, the fetched into the client cache. In the event of a cache- usefulness of disconnected operation is defeated. miss, requests made to the missing server object may A possible improvement is to save the remote invobe queued for r may be reissued to the actual server ob- cation request in a log and return immediately to the ject upon reconnection. The nal step in disconnected client application. However, in the case that the client operation takes place upon the mobile host's reconnec- application expects a result from the remote invoca9
tion, it may be necessary to suspend execution if the client application needs the result of the remote invocation to continue. This problem suggests that client applications need to be designed so that parts of it may continue execution even without the result of a remote invocation. The Rover mobile access toolkit [20] developed at MIT addresses this problem by allowing the client application to choose between blocking and non-blocking remote invocations during disconnected operation. A blocking invocation (a traditional RPC) suspends application execution if the remote object is not available. A non-blocking invocation, or a queued RPC (QRPC), is saved into a persistent log, and upon reconnection, the QRPC is automatically executed and the client application is noti ed via a registered callback function. The client application must be designed so that useful work can be done using QRPCs rather than traditional RPCs during disconnected operation. Another mechanism to enhance the QRPC model is the addition of a scheduling policy to prioritize replay within a log of QRPCs. For example, queued RPCs to a mail server to send outgoing e-mail can be prioritized over requests for the weather report. These priorities can be assigned by the application or the user.
4.2 Modi able Objects in Disconnected Operation The discussion in the previous subsection has only considered accessing stateless, read-only objects for disconnected operation. Accessing modi able objects, on the other hand, introduces the non-trivial problem of data consistency management between the original object at the server and the replica at the client. Most disconnected operation paradigms use an optimistic concurrency control scheme; that is, local replicas at the client are given unrestricted read/write access (with the caveat that all modi cations to the local cached object are recorded so that rollback/undo can be performed when necessary). Multiple clients may potentially modify di erent replicas of the same shared object while disconnected, thus introducing the dicult problem of integrating several possibly inconsistent replicas at the primary host of the shared object. To handle cache-misses for write operations on a shared object, an approach similar to remote invocation queueing (e.g. QRPC) can be used. However, the assumption that all operations on the remote object are read-only is no longer valid. The queue of
Figure 10: Comparison of Pessimistic and Optimistic Replica Control Figure 11: Con icts in Optimistic Replica Control remote invocations on a modi able object is in e ect a sequence of read/write operations on the remote object. Upon reconnection, the scheduling of these operations must preserve serializability. The problem is compounded by multiple clients simultaneous replaying their read/write operation logs on the same shared object.
4.3 Optimistic Replica Management Disconnected operation requires replication of server objects, and replicas need to be kept consistent as much as possible. In managing the consistency of replicas, two general options are available. One may take a pessimistic approach by assuming that any inconsistency is unacceptable and therefore inconsistencies between replicas should be avoided entirely. Pessimistic schemes, such as read-all/write-one, permit only one user to hold a write lock to an object, i.e. only one user may modify any replica of object at any given time. While such schemes may guarantee full consistency, they provide low availability. One user's possession of a write lock on an object prevents all other users from modifying any of its replicas. If the user fails to release his write lock on the object, perhaps due to disconnection of his mobile computer from the network, productivity of all of other users who need to modify that object is brought to a standstill. The alternative approach is optimistic replica control, which adopts a weakly-consistent read-any/writeany policy. Any user may read or write any replica of the shared object at any time. The general goal of optimistic replica control is to provide read/write availability of a shared object even when preserving consistency between replicas is not possible. Optimistic replica control adopts the philosophy that applications should not be interrupted if there are temporary disruptions in the network connection. The application must be allowed to proceed at the mobile host without interfering with user responsiveness. Figure 10 presents a summary of the comparison between pessimistic and optimistic replica control. In optimistic replica control, since the system
10
permits modi cations to replicas even when consistency between replicas cannot be maintained, possible read/write and write/write con icts may occur. As an example, consider the two clients A and B sharing an object X in Figure 11. Both clients A and B maintain local replicas of X . Local replicas of X are kept consistent with the primary copy as much as possible. However, due to the weak-consistency model, clients who are disconnected are still permitted to modify their local replicas, producing possible read/write and write/write con icts. Read/write con icts are usually not detected immediately when it happens. This is because the infringing client (client C in Figure 11) may not know that the version of the shared object it has prefetched into its object cache is not the most up-to-date. If client C is disconnected, the detection of a read/write con ict is not even possible. The best possible solution is to notify the client of the read/write con ict once it is reconnected. Read/write con icts can be detected by the server maintaining a list of all client-cached objects. If an object on this list is modi ed by some other entity while a client is disconnected, and the cached object in question was used (read) by the client during disconnection, then a read/write con ict has occurred, and the client needs to be noti ed when it becomes reconnected. Write/write con icts may be easily detected when the system attempts to reintegrate di erent versions of replicas when the connection with the xed network is restored. Reintegrating con icting versions of a shared object may involve a variety of tasks, from merging lines in two les to letting the human users involved work out the con ict manually. Ideally reintegration should require as little human intervention as possible. The detection of con icts as described above and the resolution of con icts (described in Section 4.7) are required in an optimistic replication model, and they incur substantial overhead. The overhead of con ict detection and resolution must not outweigh the bene ts of increased availability provided by optimistic concurrency control. Empirical results have shown that for many mobile applications such as personal information management (schedules and calendars), and computer supported cooperative work (CSCW) environments, availability is perhaps more important than strict consistency. For example, empirical studies of the Coda le system has shown that for most shared le/object environments running personal information management applications or cooperative development
environments, write/write con icts are very rare, on the order of 0.4% probability within a one-week period [18]. Given the rareness of write/write con icts, the overhead of reintegrating con icting objects may be a justi able expense for the increased availability. Having adopted an optimistic replication model, let us now consider how optimistic replication may be applied to disconnected operation. As explained earlier (in the introduction of this section), there are three main phases in carrying out disconnected operation: prefetching (hoarding), server emulation, and reintegration. In these three phases, steps must be taken to minimize cache-misses during server emulation and to minimize read/write and write/write con icts (or to facilitate the resolution of con icts) during reintegration. Reducing cache-misses is handled by the prefetching system. Minimizing con icts and facilitating reintegration is an issue that the application design must address. Objects used by applications should be structured such that integrating inconsistent replicas can be done in a well-de ned, orderly fashion. These are issues to keep in mind as we discuss in detail the three phases involved in disconnected operation.
4.4 Prefetching/Hoarding Achieving seamless and automated disconnected operation requires that the system predict which objects will be needed during disconnection, which depends on what tasks the user will perform during disconnection. Therefore, user input is critical in successful hoarding. User input may be given by hoarding pro les, where the user speci es which objects he/she will need during disconnection. A more usable approach would allow the user to merely specify what applications will be used during disconnection, or even what tasks will be performed during disconnection. Allowing the user to give a high-level description greatly reduces the burden on the user because the user typically does not know what obscure objects an application requires. Of course, the system must then automatically track which objects a particular application or task requires. A tracing tool can monitor the object reference pattern of an application during the course of its execution. Hoarding also typically incorporates a Least-RecentlyUsed (LRU) policy, which discards from the hoarding pro le objects that have not been used for the longest time. In constructing hoarding pro les, user input and automatic object usage tracking by the system are both important in constructing an e ective hoarding pro le,
11
Figure 12: Causal Consistency
Figure 13: Versioning of Replicas
but we would like to minimize the burden on users by but does not nd it in the cache (i.e. a cache-miss), prompting for only high-level user input. the operation may be recorded into an operation log to be performed upon reconnection. Mutual Consistency: Vector Clocks and Causal Consistency
4.6 Coarse-grain Object Reintegration
When hoarding objects for disconnected operation, it is also important to maintain mutual consistency within the set of hoarded objects. For example, consider a set of les representing a software program. Assume that a method signature is changed in le A and that les B and C contains calls to the method in le A. Then, les B and C should be changed accordingly Files A, B, and C are mutually consistent if les B and C re ect the change in le A. When les are prefetched for disconnected operation, the client desires a mutually consistent set of les A, B, and C. In order for disconnected operation to be practical, the system needs to guarantee mutual consistency in a set of cached objects while allowing read/write operations to complete using the cached objects during disconnection. An appropriate level of consistency satisfying this requirement is known as causal consistency [2]. Causal consistency uses the technique of vector clocks [25] to guarantee mutual consistency in a group of objects within a mobile host's cache while allowing read/write operations to complete using the cached objects. Consider Figure 12, where Host 1 modi es version A0 to produce version A1. Host 2 then reads version A1 and subsequently writes another object B0 , possibly using information from A1 . Causal consistency guarantees that mobile hosts wishing to cache objects A and B will use versions A1 and B0 (instead of A0 and B0 , which are not mutually consistent).
4.5 Server Emulation During disconnection, the goal of the system is to emulate the server as much as possible to permit continued execution of applications which perform operations on shared objects in the server. The primary method of server emulation is using hoarded objects in the client's local cache to simulate objects on the server. Operations originally performed on shared objects at the server are instead performed on replicated objects in the client's cache. If an application needs an object,
4.6.1
Single Object Versioning
Proper reintegration of inconsistent replicas requires complete version information about each replica. Merely timestamping the replicas is insucient. An object versioning scheme must capture the complete modi cation history of the object. For example, in the version tree in Figure 13, versions A1:1:2 and A1:2 are independently modi ed versions of A1 . The timestamp information alone does not reveal the dependency structure between A1:1:2 and A1:2. A1:1:2, with a timestamp of 116, is not necessarily based on the changes of A1:2, with a timestamp of 103. A1:1:2 and A1:2 are, in fact, on two di erent branches of the version tree. When the di ering versions need to be reintegrated, a fair policy would mandate that one version does not take precedence over the other.
4.7 Reintegration and Con ict Resolution To perform proper resolution of write/write con icts between two or more con icting replicas of an object, the con ict resolver needs speci c knowledge about the internal syntax and semantics of the object. For example, if the object is a text le, inconsistent replicas may be merged line by line. If the objects are database records, individual elds can be merged. Only the applications which created the objects would understand the internal semantics of an object and would thus be the best candidate to perform the reintegration. Therefore, the most sensible approach is to perform application-speci c resolution; in other words, the application which created the objects provides the functionality to resolve con icts. Incorporating application-speci c resolution into an optimistic replica control system is a widely-used technique [18, 19, 20]. There are two approaches to providing application-speci c resolution: (1) applications can install code into the object to perform resolution along with each write, or (2) applications can install modules
12
to perform reintegration into the mobile operating system on the MSS. The Rover toolkit takes the former approach by requiring that the application programmers insert code for con ict detection and resolution into methods that update an object. The Bayou architecture also takes the former approach, but instead of de ning con ict detection and resolution methods in the shared object itself, the Bayou architecture requires that clients pass a mergeproc (merge procedure) along with a write operation to a shared object on a server. The mergeproc is a function migrated from the client to the server and runs in a safe execution environment. Coda takes the latter approach by preinstalling con ict resolution modules into the operating system for speci c object ( le) types. (In Coda, the basic unit resembling a shared object is a le.) Although integration may be largely automated by application-speci c resolvers, at times con icts which occur at the nest granularity may require user intervention. For example, if two users modify the same line of code, and the application-speci c resolver determines that one modi cation did not causally follow the other, then the con ict must be forwarded to the human users who created the con icting versions. The system can facilitate human resolution by providing a group decision mechanism to suggest and vote on proposed resolutions of the con ict. Such mechanisms are commonly used in groupware applications which use optimistic concurrency control [21].
4.8 Fine-grain Object Concurrency Control The preceding replica management techniques described in Section 4.6 are well-suited for applications which use les and other coarse-grain objects as units of shared data storage and run in an environment with relatively long disconnections. Objects in these types of applications are often modi ed incrementally with multiple users typically modifying di erent parts of the object (e.g. incremental revision of a document), thus permitting smooth reintegration given con icting replicas. However, there are situations where coarse-grain objects are inappropriate and more precise, ne-grain concurrency control is required, A distributed database system is such an example. To apply ne-grain optimistic concurrency control for disconnected operation, two separate techniques for handling cache hits or and cache misses are required. When there's a cache hit,
the mobile transaction model, which relaxes the traditional ACID (Atomicity, Consistency, Isolation, Durability) properties [26] and provides optimistic tentative commits may be applied to replicated objects in the cache. When there's a cache miss, individual read and write operations may be recorded in an operation log which is then replayed upon reconnection (similar to the queued RPC model described in Section 4.1. 4.8.1
Mobile Transactions
Let us rst examine how the traditional transactional model needs to be adapted for mobile environments by rst considering which characteristics of mobile computing a ect transactions. In a mobile environment, the following may occur to disrupt the normal completion of a transaction: Movement and hando of client; Disconnection of client; High-latencies between client and server (coordi-
nator).
The traditional ACID (Atomicity, Consistency, Isolation, Durability) properties enforce strict, pessimistic concurrency control, but the above characteristics of mobile computing environments call for an adapted transaction model which endorses optimistic concurrency control may be more appropriate for mobile computing environments. To allow clients to proceed in the event of a disconnection, we need to introduce the concept of a tentative commit. A tentative commit is a transactional commit performed on a local copy of the data rather than on the primary copy. After a tentative commit, applications proceed as if it was a full commit. There is a chance that the tentative commit may be revoked. For instance, another commit with higher priority simultaneously takes place in another network partition, resulting in revocation of the tentative commit with the lower priority. Therefore, applications using tentative commits must be designed to handle revocations of a tentatively committed transaction. The ACID properties can then be relaxed to accommodate mobile computing as follows: Atomicity: Because mobile hosts are frequently disconnected from the network, transactions are not aborted when the client's communication channel with the server is lost. Instead of a single atomic transaction within one connection, we allow transactions to span di erent connections.
13
Consistency: Allowing tentative commits while present in traditional distributed systems: the suscep-
the network is partitioned means that a globally consistent state may not exist after a tentative commit. This is because preservation of consistency requires communication with the primary copy, which is not possible between partitions, by de nition. A client who is temporarily disconnected from the coordinator may tentatively commit changed values on a local replica. The tentatively committed changes may be read and used by other clients. Consistency is achieved after a full commit, when all clients are reconnected to the network.
Isolation (Serializability): The property that
the operations within a transaction are serializable must still be preserved at full commit; otherwise, the integrity of the server object is destroyed.
Durability: Durability, or the permanence of a
tible wireless communication medium and the mobility of entities (users, hosts, and objects). First, the wireless medium makes eavesdropping easy for intruders. Any information transmitted between hosts over a wireless medium may be intercepted by an intruder while escaping detection by the system. Prevention of wireless eavesdropping calls for encryption of data in transit over open wireless channels. Prevention of masquerade or integrity violation by message tampering calls for message authentication measures. Second, mobility of users, hosts, and objects demands tighter security since the system can no longer assume that a trusted entity will stay at a xed location. Stronger and more frequent object and user authentication measures are required. Another concern arising out of mobility is that the locations of mobile entities (especially users and objects containing sensitive data) need to be concealed. This raises a new class of problems known as location hiding or untraceability.
transaction, must be guaranteed after a full commit, but may not be guaranteed after a tentative commit, since con icts during full commit may 5.1 Encryption cause the tentative commit to be revoked. With mobile systems being susceptible to eavesdropping, the most common security violation may be unThe resulting transactional model is called isolation- intended information disclosure. Eavesdropping on the only transactions [23] or mobile transactions [27] be- message exchanges between interacting clients (or obcause only the isolation property of the ACID proper- jects) constitutes unintended information disclosure, ties is strictly enforced. which may lead to more serious security breaches if authentication information is obtained via eavesdropping. The solution is to encrypt any data in transit 5 Distributed Object Security considered private. Well-known encryption methods such as public key encryption [22] can guarantee that in Mobile Computing an intruder will not be able to decipher the encrypted Security threats in traditional object-oriented dis- message. tributed systems, such as masquerade, information disHowever, message encryption does not completely closure, and integrity violation [5], are exacerbated solve the problem, as masquerade is still possible even by the introduction of mobility and the vulnerable with encryption. If an intruder is able to clone the enwireless communication medium. Masquerade is de- crypted authentication information contained in mes ned as an unauthorized client impersonating as an sages, the intruder may be able to alter the contents authorized client, usually by obtaining the usercode of the message to disrupt transactions or cause damand password of an authorized client. Information age to data at the server, thereby achieving integrity disclosure is release of information not intended for violation. public consumption. Finally, integrity violation ocA possible answer to preventing integrity violation curs when consistency of object/data is compromised by message cloning or alteration is message authenthrough unauthorized creation, alteration, or destruc- tication. In message authentication, each message is tion of object/data, usually occuring after an intruder veri ed using checksums to prevent alteration. A sehas successfully performed masquerade. cret key applied to checksum computation can ensure The threats described above are compounded by two integrity and authenticity of the data contained in new characteristics of a mobile computing system not the message. Cloning, while unpreventable via sim14
ple checksums alone, can be prevented if di erent keys In a mobile computing environment, a user may need are used for each transmission. to prove his identity to a server in a foreign domain to obtain access to services, but at the same time the server in the foreign domain cannot be trusted with the 5.2 Authentication and Access Control user's identity information. For example, a mobile user To defend against masquerade, where an intruding who logs in to a public terminal in a foreign domain client assumes the identity and therefore obtains the is susceptible to password theft and unintended locaprivileges of an authorized client, the standard mech- tion disclosure. The public terminal may record the anism employed is user authentication, usually using user's password or report the user's location for mauser codes and passwords. Once the client is authen- licious purposes. The same problem occurs with host ticated, it is assigned some access level which grants mobility. When a mobile host (MH) needs to prove his the client the privilege to read and/or write certain identity to a foreign mobile support station (MSS) , objects. The access control policy in the Unix le sys- the foreign MSS gains access to the MH's location and tem, for example, attaches to each le read, write, and identity information. A solution to this dilemma is the execute permission for various users at di erent access use of aliases. An entity (user, host, or object) which levels. visits a foreign domain is assigned a random, tempoAuthentication and access control has been tradi- rary alias without any reference or correlation to its tionally been used for users only. However, in a mo- original identity [15] Only a trusted home authority (a trusted authentibile computing system mobile objects (or agents) may perform tasks on behalf of the user. Therefore, au- cation server in the home domain) maintains the mapthentication and access control information need to be ping between the undecipherable traveling aliases and transferred from users to objects (or agents) and from the entity's real identity. Note that an entity should objects to other objects. A policy to transfer authen- be assigned a new aliases each time it enters a new tication between users and objects and between ob- domain to ensure that no movement information is injects and objects is required. Objects may directly ferred from a static alias. inherit the passwords and privileges of users who created them, or the objects may have special passwords 5.4 Mobile Object Security if they are special system objects. For example, if an object is carrying out tasks directly on behalf of the The primary security concern pertaining mobile obuser, i.e. responding to the user's commands, then jects which migrate from servers to clients is the posinheriting the user's password and access privileges is sibility of Trojan horses. A Trojan horse attack is a appropriate. If, on the other hand, an object needs form of object masquerade, where an object posing as special access to system functions as a result of the an authorized or harmless object enters the client's exuser's request, but the user does not have direct con- ecution space and performs malicious actions. Trojan horses may be concocted by simply altering trol over which system functions are called, then it is the contents of an executable object in transit over a appropriate to use special system passwords. network. A recent study demonstrated an attack which com5.3 Location Privacy promised the security features of Netscape by alterThe mobility of users, hosts, and objects also brings ing the executable as it was transferred over the netto light the concern of location privacy. Unauthorized work using the Network File System (NFS). A secure tracking of a user's movements, for example, consti- checksum to verify the integrity and authenticity of tutes a serious violation of privacy. Disclosure of the executables transferred over the network is required to location of sensitive data also poses a serious threat to prevent these types of attacks. Java, for example, verprivacy. Since the locations of users and data may be i es downloaded classes using digital signatures which inferred from host location information, concealment detect any alterations in the class bytecode. of mobile host movements is also necessary. Therefore, Other Trojan horses may be intentionally written in a mobile environment we are interested in providing from ground up to appear as a harmless object, only untraceability of users, hosts, and objects containing to incur major damage when they are executed at the sensitive data. client. Most of these threats can be eliminated by 15
imposing language restrictions on the language used Connection transparency: Hando s and disto implement the mobile object to eliminate possiconnections are transparent to the application and ble sources of damage to the client. Java and Teleuser. An application session may operate over sevscript eliminates pointer arithmetic completely to preeral di erent physical connections in sequence and vent corruption of system address space [14, 12]. If the even over periods of disconnection. Disconnected language contains calls which access resources such as operation calls for optimistic concurrency control the le system, client-side execution environment may schemes to achieve high resource availability. choose to block resource accesses by the mobile object Increased Security Measures: Steps are taken to prevent attacks. The Java run-time environment, to address the added security risk of wireless for example, prevents mobile objects (applets) from eavesdropping and to provide untraceability for accessing client side resources, such les and devices, mobile entities. by voiding any I/O calls that the applet makes. Telescript scans for malicious system calls before executing the code In these systems, security is enforced by the run-time execution environment through resource ac- References cess restrictions. [1] Stikeleather, J. \Why Distributed Object ComputWhile security problems such as Trojan horses are ing is Inevitable." Object Magazine, Vol. 4, No. 1, not new, they will only become more prominent as mo(March-April 1994), pp. 34-7. bile computing brings mobile object technology into greater use. Any distributed object system for mobile [2] Mustaque Ahamad, Francisco Jose Torres-Rojas, computing must take these issues into greater considRammohan Kordale, Jasit Singh, and Shawn eration, since mobile computing only compounds the Smith. "Detecting Mutual Consistency of Shared security risks that already exist in distributed object Objects." Proceedings of the Workshop on Mobile systems. Computing Systems and Applications, Santa Cruz, CA, December 1994. 6
Conclusion
[3] Robert Gruber, Grans Kaashoek, Barbark Liskov, and Liuba Shrira. "Disconnected Operation in the Thor Object-Oriented Database System." Proceedings of the Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, December, 1994.
This article has examined various research issues and possible future directions in distributed object systems as mobile computing technology matures. We conclude by summarizing the major themes regarding distributed object system design that have been discussed [4] Terri Watson. "Application Design for Wireless in this article: Computing." Proceedings of the Workshop on Mobile Computing Systems and Applications, Santa Mobile-aware applications: Applications need Cruz, CA, December, 1994. to be resource-aware in that they make use of nearby resources and are able to adapt to het- [5] Robert H. Deng, Shailendra K. Bhonsle, Weiguo erogeneous platforms. Applications need to be Wang, and Aurel A. Lazar. "Integrating Security context-aware to run location-dependent appliin CORBA Based Object Architectures." Proceedcations and present location-dependent informaings of the 1995 IEEE Symposium on Security and tion. Applications are designed to support disPrivacy, Oakland, CA, May 1995. connected operation using optimistic replica control. Application-speci c con ict resolvers are [6] Mark Weiser. "Some Computer Science Issues in well-integrated with application object structure. Ubiquitous Computing." Communications of the ACM, Vol. 36, No. 7 (July 1993), pp. 75-85. Dynamic server architectures: Resources in the xed network migrate according to user mobil- [7] B. R. Badrinath, A. Bakre, T. Imielinski, and R. ity patterns to optimize performance and conserve Marantz. \Handling Mobile Clients: A Case for Inserver and network resources. direct Interaction." Proceedings. Fourth Workshop 16
on Workstation Operating Systems, Napa, CA, Oc- [18] [Coda] M. Satyanarayanan, James J. Kistler, Lily tober 1993. B. Mummert, Maria R. Ebling, Puncet Kumar, and Qi Lu. "Experience with Disconnected Operation [8] Bill Schilit, Norman Adams, and Roy Want. in a Mobile Computing Environment." Proceedings "Context-Aware Computing Applications." Proof the 1993 USENIX Symposium on Mobile and ceedings of the Workshop on Mobile Computing Location-Independent Computing, Cambridge, MA, Systems and Applications, Santa Cruz, CA, DecemAugust 1993. ber 1994. [19] Alan Demers, Karin Petersen, Mike Spreitzer, [9] J. Ioannidis and G. Q. Maguire, Jr. \The DeDouglas Terry, Marvin Theimer, Brent Welch. sign and Implementation of a Mobile Internet\The Bayou Architecture: Support Data Sharing working Architecture." Proceedings of the Winter among Mobile Users." Proceedings of the Work1993 USENIX Conference. San Diego, CA, Janshop on Mobile Computing Systems and Applicauary 1993. tions, Santa Cruz, CA, December 1994. [10] Fumio Teraoka and Mario Tokoro. \Host Migration Transparency in IP Networks: The VIP Ap- [20] Anthony D. Joseph, Alan F. DeLespinasse, Joshua A. Tauber, David K. Gi ord, and M. Frans proach." ACM Computer Communication Review, Kaashoek. \Rover: A Toolkit for Mobile InformaVol. 23, No. 1 (January 1993). tion Access." Proceedings of the Fifteenth Symposium on Operating System Principles, December [11] Frazer Bennett, Tristan Richardson, Andy Har1995. ter. "Teleporting - Making Applications Mobile." Proceedings of the Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, Decem- [21] Uwe M. Borgho and Gunnar Teege. \Application of Collaborative Editing to Software Engineeering ber 1994. Projects." SIGSOFT Software Engineering Notes, [12] Joseph Tardo and Luis Valente. \Mobile Agent SeJuly 1993. curity and Telescript." Forty-First IEEE Computer Frequently Asked Questions Society International Conference, Santa Clara, CA, [22] \RSA's About Today's Cryptography." RSA Laboratories, February 1996. http://www.rsa.com/rsalabs/faq/faq rsa.html. [13] Larry Chen, Leslee Xu, Tatsuya Suda, Tetsuya Yamamoto, and Koji Obinata. \A Re ec- [23] Qi Lu and M. Satyanarayanan. \Isolation-only Transactions for Mobile Computing" Operating tive Object-based Distributed System for HeterogeSystems Review. Vol. 28, No. 2 (April 1994), pp. neous, Multimedia Environments." Proceedings of 81-87. the International Conference on Communications and Computer Networks. Las Vegas, 1995. [24] \OrbixTalk" IONA Technologies white paper. http:// www[14] S. Shaio, A. Van Ho ,and H. Jellinek. \Java and usa.iona.com/www/Orbix/Talk/WhitePaper/index.html HotJava: a comprehensive overview." Forty-First IEEE Computer Society International Conference, [25] Leslie Lamport. \Time, clocks, and the ordering Santa Clara, CA, February 1996. of events." Communications of the ACM. Vol. 21,
No. 7, pp. 558-565, July 1978. [15] Didier Samfat, Re k Molva, and N. Asokan. "Untraceability in Mobile Networks." Proceedings of [26] T. Harder and A. Reuter. \Principles of MOBICOM '95, Berkeley, CA, 1995. Transaction-Oriented Database Recovery." Computing Surveys, Vol. 15, No. 4, 1983. [16] Common Object Services Speci cation, Volume 1. OMG Document 94-01-01. [27] Jin Jing, Omran Bukhres, and Ahmed Elma[17] Masahiko Tsukamoto, Rieko Tanaka, and Shojiro garmid. "An Ecient and Reliable Reservation AlNishio. "On Query Processing Strategies for Mobile gorithm for Mobile Transactions." Proceedings of Computing." Proceedings for MOBIDATA Workthe 4th International Conference on Information shop, Rutgers Univ., October 1994. and Knowledge Management, 1995. 17
[28] Carlos Olivieria and Tatsuya Suda. \Quality of Service Guarantee in Wireless ATM Networks." Proceedings of the International Communications Conference, Dallas, June 1996. [29] T. Mitchell, R. Caruana, D. Freitag, J. McDermott, and others. \Experience with a learning personal assistant." Communications of the ACM, Vol.37, No.7 (July 1994), pp. 80-91. [30] Lubomir Bic. \Distributed Computing using Autonomous Objects." IEEE Computer, August 1996.
18
