DATA MANAGEMENT
`FOR
`MOBILE COMPUTING
`
`by
`Evaggelia Pitoura
`George Samaras
`
`Kluwer Academic Publishers
`Boston/Dordrecht/London
`
`Starbucks Corp. Exhibit 1032
`
`

`
`I
`
`-
`
`" ' '1
`
`Universal access and management of information has been one of the driving
`forces in the evolution of computer technology. Central computing gave the
`ability to perform large and complex computations and advanced information
`manipulation. Advances in networking connected computers together and led
`to distributed computing. Web technology and the Internet went even further
`to provide hyper-linked information access and global computing. However,
`restricting access stations to physical location limits the boundary of the
`vision. The real global network can be achieved only via the ability to
`compute and access information from anywhere and anytime. This is the
`fundamental wish that motivates mobile computing.
`
`This evolution is the cumulative result of both hardware and software advances
`at various levels motivated by tangible application needs. Infrastructure research
`on communications and networking is essential for realizing wireless systems.
`Equally important is the design and implementation of data management
`applications for these systems, a task directly affected by the characteristics of
`the wireless medium and the resulting mobility of data resources and computa(cid:173)
`tion. Although being a relatively new area, mobile data management has
`provoked a proliferation of research efforts motivated by both a great market
`potential and by many challenging research problems.
`
`The focus of DATA MANAGEMENT FOR MOBILE COMPUTING is
`on the impact of mobile computing on data management beyond the net(cid:173)
`working level. The purpose is to provide a thorough and cohesive overview
`of recent advances in wireless and mobile data management. The book is
`written with a critical attitude. This volume probes the new issues introduced
`by wireless and mobile access to data and what are both their conceptual and
`practical consequences.
`
`DATA MANAGEMENT FOR MOBILE COMPUTING provides a single
`source for researchers and practitioners who want to keep current on the latest
`innovations in the field. It can also serve as a textbook for an advanced course
`on mobile computing or as a companion text for a variety of courses including
`courses on distributed systems, database management, transaction management,
`operating or file systems, information retrieval or dissemination, and web
`computing.
`
`ISBN 0-7923-8053-3
`
`ADBSIO
`0-7923-8053-3
`
`9 780792 380535
`
`Starbucks Corp. Exhibit 1032
`
`

`
`DATA MANAGEMENT FOR
`MOBILE COMPUTING
`
`by
`
`Evaggelia Pitoura
`University of Ioannina
`I oannina, Greece
`
`and
`
`George Samaras
`University of Cyprus
`Nicosia, Cyprus
`
`KLUWER ACADEMIC PUBLISHERS
`Boston I Dordrecht I London
`
`Starbucks Corp. Exhibit 1032
`
`

`
`Distributors for North America:
`Kluwer Academic Publishers
`101 Philip Drive
`Assinippi Park
`Norwell, Massachusetts 02061 USA
`
`Distributors for all other countries:
`Kluwer Academic Publishers Group
`Distribution Centre
`Post Office Box 322
`3300 AH Dordrecht, THE NETHERLANDS
`
`Library of Congress Cataloging-in-Publication Data
`
`A C.I.P. Catalogue record for this book is available
`from the Library of Congress.
`
`The publisher offers discounts on this book when ordered in bulk quantities. For
`more information contact: Sales Department, Kluwer Academic Publishers,
`101 Philip Drive, Assinippi Park, Norwell, MA 02061
`
`Copyright © 1998 by Kluwer Academic Publishers
`
`All rights reserved. No part of this publication may be reproduced, stored in a
`retrieval system or transmitted in any form or by any means, mechanical, photo(cid:173)
`copying, recording, or otherwise, without the prior written permission of the
`publisher, Kluwer Academic Publishers, 101 Philip Drive, Assinippi Park, Norwell,
`Massachusetts 02061
`
`Printed on acid-free paper.
`
`Printed in the United States of America
`
`Starbucks Corp. Exhibit 1032
`
`

`
`SOFTWARE ARCHITECTURES
`
`2
`
`The mobile computing environment is constrained in many ways. Mobile ele(cid:173)
`ments themselves are resource-poor and unreliable. Their network connectivity
`is often achieved through low-bandwidth wireless links. Furthermore, connec(cid:173)
`tivity is frequently lost for variant periods of time. The difficulties raised by
`these constraints are compounded by mobility that induces variability in the
`availability of both communication and computational resources. These severe
`restrictions have a great impact on the design and structure of mobile com(cid:173)
`puting applications and motivate the development of new computing models.
`These mobile computing models must provide efficient access to both existing
`and new applications which is a key requirement for the wide acceptance of
`mobile computing.
`
`An important design consideration is the type of functionality assigned to mo(cid:173)
`bile hosts. Mobile units are still characterized as unreliable and prone to hard
`failures, i.e., theft, loss or accidental damage. Mobile elements are also resource(cid:173)
`poor relative to static hosts. For these reasons, there are approaches that treat
`the mobile unit as a dumb terminal running just a user-interface. The InfoPad
`[123] and ParcTab [154] projects employ such a dump terminal approach and
`off-load all functionality from the mobile unit to the fixed network. On the
`other hand, slow and unreliable networks argue for placing more functionality
`at the mobile hosts so that they are less dependent on remote servers. Al(cid:173)
`though, there is no consensus yet on the specific role the mobile host must
`play in distributed computation, the above contradictory considerations tend
`to favor models that provide for a flexible adjustment of the functionality as(cid:173)
`signed to mobile clients. For instance, in anticipation of a disconnection, a
`disconnected mobile host may be assigned additional functionality to operate
`autonomously.
`
`15
`
`Starbucks Corp. Exhibit 1032
`
`

`
`16
`
`CHAPTER 2
`
`Besides the partition of data and computation of mobile applications between
`mobile and static elements, two important considerations in designing software
`systems for mobile computing are: what is an appropriate model for mobile
`computing systems, and whether mobility should be made transparent to appli(cid:173)
`cations. We address these issues next. The chapter concludes with an example
`that clarifies the above considerations and at the same t ime introduces issues
`covered in the following chapter.
`
`2.1 M OBILE COMPUTING MODELS
`
`Devising appropriate models for structuring applications that involve wireless
`elements is an issue central to developing software for mobile computing. In this
`section, we elaborate on such models, their strengths and weaknesses. First,
`we consider extensions to the popular client/server model, then the use of peer
`to peer models, and finally the employment of mobile agents.
`
`2.1.1 Mobile Client/Server Models
`
`With client/server computing in its simplest form, an application component
`executing in one computing system, called the client, requests a service from
`an application component executing in another computing system, called the
`server.
`In a wireless setting, the mobile host acts as the client requesting
`services from servers located at the fixed network (Figure 2.l(a)) . In some
`cases, functionality and data are distributed across multiple servers at different
`fixed hosts that may have to communicate with each other to satisfy the client's
`request. In many cases, a server is replicated at different sites of the fixed
`network to increase availability in cases of network or site failures. Server
`replication is also employed for performance and scalability. Widely scattered
`replicated servers are also used for efficiently accommodating highly mobile
`clients.
`
`There is no clear division of functionality between the mobile client and the
`server at the fixed network. [150] talks about an extended client/server model
`where the roles of clients and servers are temporarily blurred. The most evident
`such case is during disconnections, when a disconnected client has to emulate
`the functionality of a server to continue operating.
`
`Starbucks Corp. Exhibit 1032
`
`

`
`--
`
`Software Architectures
`
`17
`
`An important parameter of client/server architectures is the type of commu(cid:173)
`nication mechanism used to exchange information between the client and the
`server. One possibility is the direct exchange of messages between the client
`and the server. This approach is not adequate for slow and unreliable networks
`such as in wireless computing. In such environments, a less direct mechanism,
`in which messages are queued at the two ends is more appropriate. This leads
`to various levels of indirection. A second possibility is invoking a remote proce(cid:173)
`dure call (RPC) mechanism. In this paradigm, a client calls a procedure which
`is executed at a remote server.
`
`However, synchronous RPCs are inadequate since the client is blocked in cases
`of disconnections. Moreover, traditional RPCs leave small chance of reducing
`communication cost. To address these problems, there have been various pro(cid:173)
`posals for an asynchronous RPC [94, 26, 20]. In asynchronous queued RPC
`[94], when an application issues an RPC, the RPC is stored in a local stable
`log and control is immediately returned to the application. When the mobile
`client is connected, the log is drained in the background and any queued RPCs
`is forwarded to the server. Queueing RPCs leaves space for performing various
`optimizations on the log. For instance, the Rover toolkit [94] reorders logged
`requests based on consistency requirements and application-specified operation
`priorities. Delivering any replies from the server to the client at the mobile
`host may require multiple retries [94, 26]. Specifically, if a mobile host is dis(cid:173)
`connected between issuing the request and receiving the reply, the server may
`periodically attempt to contact the mobile host and deliver the reply. This
`extended RPC mechanism enables applications to use different communica(cid:173)
`tion channels for the requests and responses and to close channels during the
`intervening period [94].
`
`Extensions to the traditional client/server model, such as queueing RPC, are
`necessary to sustain disconnected operation and weak connectivity. Further
`optimizations, such as filtering or compression, are also important. For these
`reasons the traditional client/server model must be extended to provide com(cid:173)
`ponents responsible for implementing such appropriate optimizations and thus
`imposing minimum changes in clients and servers. In addition, for light-weight
`and unreliable clients, it is critical to be able to move part of their operation to
`the fixed network. Such considerations led to the extensions of the client/server
`model presented in the following sections.
`
`Starbucks Corp. Exhibit 1032
`
`

`
`18
`
`CHAPTER 2
`
`Wlrdeu Link
`
`; - ----
`
`Fixed ~e rwork
`
`(a)
`
`'l Application Client 1----------------------- -; -I Agent
`
`MoblleHos1
`
`' (b)
`
`(c)
`
`Figure 2.1 Client-Server based Models: (a) Simple Client/ Server Model , (b)
`Client/Agent/Server Model, (c) Client/ Intercept/ Server Model.
`
`The Client/ Agent/Server Model
`
`An emerging computational model is a three-tier or client/agent/server (c/a/s)
`model [22, 55, 131, 183, 166], using messaging and queuing infrastructure for
`communications from the mobile client to the agent and from the agent to
`the server (Figure 2.1(b)). In its most generic form, an agent or proxy is just
`a surrogate of the client on the fixed network. This architecture somewhat
`alleviates the impact of the limited bandwidth and the poor reliability of the
`wireless link by continuously maintaining the client's presence on the fixed
`network via the agent. Agents split the interaction between mobile clients and
`fixed servers in two parts, one between the client and the agent, and one between
`the agent and the server. Different protocols can be used for each part of the
`interaction and each part of the interaction may be executed independently of
`the other.
`
`Minimum functionality at the agent includes support for messaging and queuing
`for communication between the mobile client and the agent. The agent can also
`assume a more active role [131 , 166], in which case, when application-specific
`predefined events occur, it notifies the client appropriately. Furthermore, to
`limit computations on the mobile unit, the agent might be responsible for
`starting/stopping specific functions at the mobile unit or for executing client
`specific services. The c/a/s model is most appropriate for light-weight clients
`of limited computational power and resources. It moves responsibilities from
`
`Starbucks Corp. Exhibit 1032
`
`

`
`Software Architectures
`
`19
`
`the client to the agent. For example, a complex client request can be managed
`by the agent with only the final result transmitted to the client. Located on
`the fixed network, the agent has access to high bandwidth links and large com(cid:173)
`putational resources, that it can use to benefit its client. Similarly, performing
`caching at the agent can minimize long round trips on the network and thus
`reduce application response time. To further enhance the client's benefit, the
`agent can be used to off-load significant computational burden from the server.
`For example, data compression can be performed by the agent instead of the
`server. In general, how the agent's resources are used, that is the functionality
`of the agent, greatly depends on the specific application the client needs to
`support.
`
`To deal with disconnections, a mobile client can submit its requests to the
`agent and wait to retrieve the results when connection is re-establish. In the
`meantime, any requests to the disconnected client can be queued at the agent
`to be transferred upon reconnection. The agent can be used in a similar way
`to preserve battery life. The client submits its requests to the agent, enters the
`doze mode, and waits the agent to wake it up when the response becomes avail(cid:173)
`able. Weak connectivity can be effectively handled by the agent in a variety of
`ways. The agent can employ a number of optimization techniques to minimize
`the size of data to be transmitted to the client depending on the type of data
`and on the specific application. The agent can manipulate the data prior to
`their transmissions to the client [183, 55, 166], by changing their transmission
`order so that the most important information is transfered first, by performing
`data specific lossy compression that tailors content to the specific constraints
`of the client, or by hatching together multiple replies.
`
`Agents are used in a variety of forms and roles in this particular architecture.
`At one extreme, an agent acts as the complete surrogate of a mobile host on the
`fixed network. In this case, any communication to and from the mobile host
`goes through the mobile host's agent. The surrogate role of an agent can be
`generalized by having an agent acting as a surrogate of multiple mobile hosts
`[55]. At the other extreme, the agent is attached to a specific service or appli(cid:173)
`cation, e.g., web browsing [69] or database access [131]. Any client's request
`and server's reply associated with this application is communicated through
`the service-specific agent. In this scenario, a mobile host must be associated
`with as many agents as the services it needs access to. This second case can be
`symmetrically generalized by having a service-specific agent servicing multiple
`clients [69].
`
`The situation becomes more involved when a service is associated with multiple
`agents (131] and this group of service-specific agents serves multiple clients. In
`
`Starbucks Corp. Exhibit 1032
`
`

`
`20
`
`CHAPTER 2
`
`this case, any client's request associated with the service can be serviced by any
`available agent in the group. All this flexibility, however, entails the need of a
`more complex management function. A service-specific meta-agent is required
`to coordinate clients requests and the service-specific group of agents. In (131),
`the role of the meta-agent is played by an agent management facility, called
`Message Gateway.
`
`The exact position of the agent at the fixed network depends on its role. Placing
`the agent at the fringe of the fixed network, i.e., at the base station, has some
`advantages especially when the agent acts as the surrogate of mobile hosts under
`its coverage (183, 22): it is easier to gather informations for the wireless link
`characteristics; a special link level protocol can be used between the mobile
`host and the agent; and personalized information about the mobile hosts is
`available locally. On the other hand, the agent may need to move along with
`its mobile host, or the current base station may not be trustworthy. In the
`case of service-specific agents, it makes sense to place them either closer to the
`majority of their clients or closer to the server.
`
`The introduction of agents affects routing (see also Chapter 5) in various ways
`depending on the exact role the agent plays. If the agent totally represents one
`or multiple mobile hosts, then all traffic involving the mobile hosts flows through
`the agent. Thus, special treatment is required to direct all such communication
`through the agent. To this end, [182) augments the Columbia Mobile IP pro(cid:173)
`tocol [82) to allow a mobile host to choose one certain host to be its agent and
`guarantee that all traffic will pass through it. If the agent represents services
`[69, 131), then only communication related to the service passes through the
`agent.
`
`While the client/agent/server model offers a number of advantages, it fails to
`sustain the current computation at the mobile client during periods of discon(cid:173)
`nection. At the event of a disconnection, the mobile client cannot continue to
`operate uninterrupted. Furthermore, although the server notices no changes,
`the model still requires changes to the client code for the development of the
`client/agent interaction rendering the execution and maintenance of legacy ap(cid:173)
`plications problematic. Finally, the agent can directly optimize only data trans(cid:173)
`mission over the wireless link from the fixed network to the mobile client and
`not vice versa.
`
`Starbucks Corp. Exhibit 1032
`
`

`
`-
`
`Software Architectures
`
`21
`
`The Client/Intercept/Server Model
`
`To address the shortcomings of the c/a/s model, [148, 69) propose the deploy(cid:173)
`ment of a client-side agent that will run at the end-user mobile device along
`with the agent of the c/a/s model that runs within the wireline network (Figure
`2.1(c)). The client-side agent intercepts client's request and together with the
`server-side agent performs optimizations to reduce data transmission over the
`wireless link, improve data availability and sustain uninterrupted the mobile
`computation. From the point of view of the client, the client-side agent ap(cid:173)
`pears as the local server proxy that is co-resident with the client. Similarly,
`the server-side agent appears as the local client proxy that resides on the fixed
`network, most likely, but not necessarily, co-resident with the server represent(cid:173)
`ing the client. This model can be viewed as the adaptation of the client/server
`model for wireless computing with the pair of agents responsible for minimizing
`the effect of the wireless link. Since the pair of agents is virtually inserted in
`the data path between the client and the server, the model is named in [148, 69)
`for short client/intercept/server instead of client/agent/agent/server model.
`
`The intercept model is transparent to both the client and the server. Therefore,
`the agent pair can be employed with any client application. The communication
`protocol between the two agents can facilitate highly effective data reduction
`and protocol optimization without limiting the functionality or interoperabil(cid:173)
`ity of the client. The cooperation of the two agents allows for more efficient
`optimizations of the wireless link for the benefit of different applications. In
`addition, application specific optimizations can be more effectively realized by
`the agent pair.
`
`The model offers flexibility in handling disconnections. For instance, a local
`cache may be maintained at the client-side agent. The cache can be used to sat(cid:173)
`isfy the client's requirements for data during disconnections. Cache misses may
`be queued by the client-side agent to be served upon reconnection. Similarly,
`requests to the client can be queued at the server-side agent and transfered to
`the client upon reconnection. Weak connectivity can also be handled in a vari(cid:173)
`ety of ways. For example, relocating computation from the client-side agent to
`the server-side agent or vice versa can minimize the effect of weak connectiv(cid:173)
`ity. Background prefetching to the client-side agent can reduce communication
`during weak connectivity.
`
`The intercept model is more appropriate for heavy-weight clients with enough
`computational power and secondary storage. The main weakness of the model
`is that every application requires development work both at the server and at
`
`Starbucks Corp. Exhibit 1032
`
`

`
`22
`
`CHAPTER 2
`
`the client site. However, there is no need to develop a pair of agents for every
`instance of an application. Instead, since the functionality and optimizations
`performed by the agent pair is generic enough, it is only required to develop
`a different pair of agents per application type e.g., file, database, or web ap(cid:173)
`plication. For example, prefetching documents at the cache of the client-side
`agent follows the same principles independently of the specific type of web(cid:173)
`application.
`
`Classifying the roles of the two agents results in a taxonomy similar to that
`provided in the previous section for the agent role of the client/agent/server
`model. For example, the server-side agent can be a surrogate of the client or
`be attached to a specific service.
`
`The intercept model provides for a clear distinction and splitting of responsi(cid:173)
`bilities between the client and server agents. The idea of employing proxy pairs
`has been gaining lately some attention (183, 55]. An intercept approach is em(cid:173)
`ployed by WebExpress [69], an IBM system for optimizing web browsing in a
`wireless environment. In this system the client-side agent is called client-side
`intercept ( CSI), while the server-side agent is called server-site intercept (SSI).
`
`2.1.2 Peer-to-Peer Models
`
`In a peer-to-peer distributed architecture, there is no distinction between clients
`and servers. Ideally, each site has the full functionality of both a client and a
`server. Adapting such models in mobile computing, makes mobile hosts equal
`partners in distributed computations and thus is only appropriate for heavy(cid:173)
`weight clients. Disconnections have the additional negative effect of making
`the server unavailable to clients requesting its services. Thus, to deal with
`disconnections and weak connectivity a server-side intercept agent may need to
`be placed on the mobile host as well. In this case, agents may possess special
`features to take into account the fact that the server is running on a mobile
`host. For instance, a server at the mobile host cannot be continuously active
`because, to conserve power, the mobile host may be switched-off or operating
`in the doze mode. A mechanism to automatically start applications on demand
`[20] is useful in such cases.
`
`There are certain applications for which the peer-to-peer model is adequate
`[144]. Consider the case of two partners performing cooperative work on some
`data using their portable computers. In a client/server model, they cannot
`trade their updates directly. Instead, each client has to connect with the server
`
`Starbucks Corp. Exhibit 1032
`
`

`
`r
`
`Software Architectures
`
`23
`
`machine to be informed of each other's actions. This may incur excessive
`communication costs, when the server is located far away from the clients.
`Even worst, in cases of physical disconnection of the clients from the server,
`there is no way that the two clients can interact with each other, even when a
`communication path connecting them is available.
`
`2.1.3 Mobile Agent Models
`
`Mobile agents are processes dispatched from a source computer to accomplish
`a specified task [43, 176]. Each mobile agent is a computation along with its
`own data and execution state. In this way, the mobile agent paradigm extends
`the RPC communication mechanism according to which a message sent by a
`client is just a procedure call. After its submission, the mobile agent proceeds
`autonomously and independently of the sending client. When the agent reaches
`a server, it is delivered to an agent execution environment. Then, if the agent
`possesses necessary authentication credentials, its executable parts are started.
`To accomplish its task, the mobile agent can transport itself to another server,
`spawn new agents, or interact with other agents. Upon completion, the mobile
`agent delivers the results to the sending client or to another server.
`
`Besides their computational components, mobile agents are equipped with in(cid:173)
`telligence to reason, make decisions, and solve problems. Thus, there are two
`kinds of languages involved with an agent. One is a programming language in
`which the programming content of the agent is written. This is usually a script(cid:173)
`like language. The other language is concerned with the intelligent aspects of
`mobile agents. This is a language for knowledge representation. Languages
`for knowledge representation provide the means to express goals, tasks, pref(cid:173)
`erences, beliefs and vocabularies appropriate to various domains. A leading
`approach in defining interoperable languages for knowledge-presentation is the
`ARPA knowledge sharing effort [19].
`
`Besides intelligence, some of the key aspects of the mobile agent computing
`paradigm are:
`
`1. the ability of an agent to interact and cooperate with other agents,
`
`2. agent autonomy, in the sense that agents' execution proceeds with little or
`no intervention with the sending client,
`
`3. agent interoperability, i.e., agents can be executed in diverse platforms,
`
`Starbucks Corp. Exhibit 1032
`
`

`
`24
`
`CHAPTER 2
`
`4. agent reactiveness, the ability of an agent to respond to external events,
`and
`
`5. agent mobility, i.e. , their ability to roam among a set of networked servers.
`
`One of the main obstacles to the acceptance of mobile agents in commercial
`applications is security. Protection against viruses, preventing mobile agents
`entering endless loops and consuming all available resources, authentication,
`and privacy are just a few of the implementation challenges to be addressed.
`General Magic's Telescrtipt (TM) technology [56] is possibly one of the most
`well-known implementations of the concept of mobile agents in a commercial
`setting. [118] provides a rich source of information relating to mobile agents.
`
`The driving force motivating mobile agent-based computation is twofold. First,
`mobile agents provide an efficient, asynchronous method for searching for in(cid:173)
`formation or services in rapidly evolving networks: mobile clients are launched
`into the unstructured network and roam around to gather information. Sec(cid:173)
`ond, mobile agents support intermittent connectivity, slow networks, and light(cid:173)
`weight devices. This second property makes the use of mobile agents in mobile
`computing very attractive [43, 134] .
`
`The agent computational model supports disconnected operation. During a
`brief connection service, a mobile client submits an agent and then disconnects.
`The agent proceeds independently to accomplish the delegated task. When the
`task is completed, the agent waits till reconnection to submit the result to the
`mobile client. Conversely, a mobile agent may be loaded from the fixed network
`onto a laptop before disconnection. The agent acts as a surrogate for the
`application allowing interaction with the user even during disconnections. Weak
`connectivity is also supported by the model since the overall communication
`traffic through the wireless link is reduced from a possibly large number of
`messages to the submission of a single agent and then of its result. In addition,
`by letting mobile hosts submit agents, the burden of computation is shifted
`from the resource-poor mobile hosts to the fixed network. Mobility is inherent
`in the model. Mobile agents migrate not only to find the required resources
`but also to follow mobile clients. Finally, mobile agents provide the flexibility
`to load functionality to and from a mobile host depending on bandwidth and
`other available resources.
`
`The mobile agent computational paradigm is not orthogonal to the client/server
`model and its extensions. For example, the agent of the cfa/s model may be
`seen as a form of static agent , i.e, an agent lacking the ability to migrate to
`other servers. Alternatively, one can implement the agent of the c/a/s model
`
`Starbucks Corp. Exhibit 1032
`
`

`
`Software Architectures
`
`25
`
`as a mobile agent and let it move on the fixed network following its associated
`client.
`
`Mobile agents can be used in conjunction with agents located at the fixed
`network. Let's call the agents at the fixed network proxies for clarity. In this
`scenario, a client submits a general mobile agent to its proxy. The proxy refines
`and extends the mobile agent before launching it to servers on the network.
`When the mobile agent finishes its task, it first communicates its results to the
`proxy. The proxy filters out any unnecessary information and transmits to the
`mobile client only the relevant data. Such an approach entails enhancing the
`proxies with capabilities to process mobile agents. Building on this approach,
`a proxy may be programmable, that is extended with the ability to execute
`mobile agents submitted to it by clients or servers. Such an approach is in
`accordance with current research on active networks [166].
`
`2.2 ENVIRONMENTAL AWARENESS
`
`The agents, placed between the mobile client and the fixed server, alleviate
`both the constraints of the wireless link, by performing various communica(cid:173)
`tion optimizations, and of any resource constraints, by undertaking part of the
`functionality of resource-poor mobile clients. In this section, we consider two
`important design issues. First, we motivate the need for adaptivity. Then, we
`argue about the level at which mobility and adaptivity must be handled.
`
`The mobile environment is a dynamically changing one. Connectivity con(cid:173)
`ditions vary from total disconnections to full connectivity. In addition, the
`resources available to mobile computers are not static either, for instance a
`"docked" mobile computer may have access to a larger display or memory.
`Furthermore, the location of mobile elements changes and so does the network
`configuration and the center of computational activity. Thus, a mobile system
`is presented with resources of varying number and quality. Consequently, a
`desired property of software systems for mobile computing is their ability to
`adapt to the constantly changing environmental conditions (97, 150, 94, 53].
`
`But how can adaptivity be captured and realized? A possible answer is by
`varying the partition of duties between the client and the server. For instance,
`during disconnection, a mobile client works autonomously, while during periods
`of strong connectivity, the client depends heavily on the fixed network sparing
`its scarce local resources. Another way to realize adaptivity is by varying the
`
`Starbucks Corp. Exhibit 1032
`
`

`
`6
`
`CASE STUDIES
`
`This chapter presents four case studies of existing mobile software systems. The
`systems presented are (Table 6.1): MIT 's Rover distributed object development
`environment, CMU's Coda file system, Xerox's Bayou replicated storage sys(cid:173)
`tem, and IBM's WebExpress web browsing system. Each one of these systems
`belongs to a different level of the software stack. Rover provides a distributed
`object architecture for developing mobile applications. Coda and Bayou pro(cid:173)
`vide specific system support at the file and database level respectively. Finally,
`WebExpress is a specific application.
`
`Besides