Information Access in Mobile Computing Environments - CiteSeerX

Information Access in Mobile Computing Environments Dinesh C. Kulkarni, Arindam Banerji, Michael R. Casey, David L. Cohn Distributed Computing Research Lab University of Notre Dame Notre Dame, IN 46556 Technical Report 93-11 October 1993.

Information Access in Mobile Computing Environments Dinesh C. Kulkarni, Arindam Banerji, Michael R. Casey and David L. Cohn Distributed Computing Research Laboratory University of Notre Dame Notre Dame, IN 46556-5637, U.S.A. +1 219 631 6694 (Voice), +1 219 631 9260 (Fax) Contact: [email protected]

Abstract: Accessing a rich set of information repositories in a mobile computing environment is difficult because the data resources change dynamically, physical resources are constrained and the information has diverse forms and sources. We propose a new virtual repository, which we call the Pi repository, to address this problem. The Pi repository will provide generic access interfaces for a variety of information resources, such as files and email, in a highly dynamic environment, while allowing application and object-specific customizations. Its application programming interfaces for such accesses is much like those provided by file systems for file access. A framework for such a repository which allows generation of customized instances is described. The framework decomposes elements of information access like naming (names, attributes, namespaces, binding, resolution), access interface and caching. Further, each component provides explicit control over its implementation. The framework defines a second interface that allows application programmers to fine-tune the virtual repository implementation according to the needs of the application and to the changes in resource constraints. It provides a set of information access and management tools to application programmers who may be the direct users of data objects or providers of further services to browse, filter and modify those objects.

Information Access in Mobile Computing Environments

1

1. Introduction Mobile computing based on small, highly portable devices presents some challenging system software questions. This paper considers how mobility will impact the access to and management of information. It proposes a new structure, referred to as a Pi repository, that would replace traditional file systems. Information access and management are critical software problems for mobile computing. Intermittent connectivity and resource limitations distinguish mobility from the classic case, but they are not the only issues. At least as important are the new categories of applications that will result from the ubiquitous nature of mobile computing. These will use highly diverse data formats and demand a fresh look at how information storage and retrieval is handled. A key point is that a successful information access and management system must incorporate flexibility as a central design criterion. Mobile computers will be used a both gateways to a dynamically changing set of resources and as stand alone computing elements. They will provide a front end to a collection of information repositories, I/O devices and computing elements while retaining their usefulness in disconnected mode. Thus, designers of information storage subsystems can no longer focus only on supporting authoring-type applications. Instead, they must consider applications such as catalog browsing and personal communication to be of equal, or even greater, importance [Marsh, 93]. Mobile computing will put a new premium on system software flexibility. Requirements will vary with application and with time. The new applications will access a diverse collection of information ranging from normal files through stock quotes to multimedia messages; the data’s sources and access patterns will show an equal amount of variety. As a mobile computer moves, the underlying communication environment will change. Thus, the kind of services system software provides, and the mechanisms used to provide them will have to change dynamically. This paper focuses on the design of a flexible data repository for mobile computing. The term repository is used in the logical sense, and refers to that system component which maintains the logical view of data. It is comparable to the client in a client-server file system or to one instance of the file system in a peer-to-peer model. This logical repository is intended to integrate existing information servers like NFS [Kleiman, 86], ftp [Postel, 85], gopher and WWW [Berners-Lee, 93a], so it must coexist within an existing set of protocols. Since mobile computers must work in disconnected and weakly connected environments, data caching will be an important function. It must not only be based on usage patterns, but also must understand communication and storage constraints. With these goals in Information Access in Mobile Computing Environments

2

mind, a framework for an extensible repository is proposed that provides sophisticated information access and cache control. Traditional file systems, such as that in Unix and its distributed outgrowths like NFS and AFS, provide facilities for naming, data storage, communication and caching. Applications such as World Wide Web (WWW) and Post Office Protocol (POP) provide interfaces to more structured repositories which have been built on top of the file systems. In the following discussion, both these categories of repositories and their clients are considered. This paper begins with a description of the inherent problems in using file systems as generic information access tools. It then describes the Pi repository architecture, in brief, before discussing some of the high-level design issues that have motivated the authors. Section 5 details the architecture, its several components and some implementation issues. The paper ends with a discussion of main contributions of this work and its relationship to other similar research projects.

2. File Systems and Beyond Workstation file systems act essentially as data repositories. They assign user-friendly names to data objects and organize them in a hierarchy. Thus, they define names and namespaces. The names are resolved to the correct data object using one or more contexts. The context may be the root directory, the working directory, or a list of names specified by some environment variable. Namespaces themselves can be manipulated through mechanisms like mount. Besides naming, workstation file systems provide storage and access facilities. These may involve reading from a local disk or communicating with another file systems to obtain data from a remote machine. (In most cases, caching is utilized for better performance, and some mechanism is provided for mutual exclusion and coherency between replicas.) For a Unix file system, data is manipulated through a set of system calls appropriately augmented with a set of standard library functions. This interface is used regardless of the semantics of the stored data; other interfaces can be layered on top of the file system to interpret the data. Even for distributed file systems, the design focuses on adhering to the same interface, often ignoring any special attributes of the stored object. A view of the repository desired by a user may be different from the organization of the storage. Grouping of logically related but separately stored objects is supported to a very limited extent by symbolic links. The Semantic File System [Gifford, 91] and Prospero [Neuman, 92] provide a much better, customizable organization, albeit under the file system interface.


3

The standard repository is limited because it is attached to a machine or a set of machines. A user can normally only customize a part of the hierarchy and a few other aspects like the contexts used for name resolution. The per-process file hierarchy in Plan 9 [Pike, 93] and the virtual system model used in Prospero [Neuman, 92] aim at remedying this problem. A logical view may involve multiple servers, possibly speaking different protocols. A keyword-based search may utilize utilities like find and grep on a UNIX file system and the WAIS interface for other logically related objects available from a different server. The name mapping, cache management and interface design typically seek two basic goals: uniformity and transparency. On the one hand, these two principles simplify the design of applications that use file systems, however, a great deal of control is sacrificed. Our work focuses on the need for greater control through object-specific customization because not all objects should have the same ‘interface’. Two examples will illustrate where this is useful. Consider the use of a PDA for electronic mail. While in principle, a file system that supports weakly connected and disconnected operation like Coda [Satyanarayanan, 93] can provide transparency for an email application, it is not the an optimal way of designing an email application. A mailer that reads all of /usr/spool/mail/username or ~/mbox is likely to upload too much data on the PDA. Also, the user would have to manually prioritize and store the email in such a way that only the necessary messages are kept on the PDA. However, a smart mailer could use a hierarchical data model protocol like IMAP [Crispin, 92], and upload only parts of messages. This saves money for a user who is paying for cellular or wireless connectivity. As a second example, consider a journalist working on a story. He or she may deal with an email message from a colleague, a PostScript report from an intern and a video clip from a staff photographer. The repository would have to know how to access each of these data items and how to process it. The nature of the processing would depend heavily on the resources available to the journalist. These examples show that transparency and uniform access methods can be a hinderance, not a help. They also make a case for investigating the different components that go into a file system and the possibility of unbundling them. Once unbundled, these components can then be individually controlled, modified and matched to get the required behavior.

3. Basic Approach The major components of the Pi repository include naming, access interface, caching and communication. These components are all implicitly included in conventional file systems. The naming component includes the names themselves, their associated attributes,


4

namespaces which organize them hierarchically or otherwise, their binding to objects and their resolution to access identifiers. The access interface component specifies the interaction between an application and the repository for a given object and has associated semantics. An example of an access interface is the set of Unix file system calls that allow reading, writing and file pointer positioning. The caching component deals with replication of an object in storage that involves less overhead than that at the object’s default location. Main memory and disk storage on the local machine are typical examples of caching storage. Communication components like ftp over TCP/IP are essentially implicit, but show through in their ability to access certain servers and to impact performance. The Pi repository is designed as a framework which ensures smooth interaction between these components. A framework is a generic design for an object-oriented system which specifies the components of the system and the interaction between these components. It is a collection of interacting classes. Subject to certain constraints, a framework instance may include specific classes to achieve a suitable trade-off between functionality, complexity and overhead. It contains specific instances of components that can interoperate. For example, an access interface that guarantees a serializable write operation must have a corresponding cache component that provides for serializability through some suitable mechanism like locking. In the distributed file system world, rudiments of decomposition can be found in the Vnode interface [Kleiman, 86] and the Sprite file system [Welch, 90]. Our approach carries this decomposition further, beyond virtual file systems. The proposed framework allows incremental changes to one or more components of the repository. An implementor can choose the most convenient representation for a subset of the namespace, the names contained therein, the object interfaces etc. While in principle the framework permits significant reimplementation of functionality, most changes are expected to be incremental or a selection between pre-specified options. As such, code reuse should remain significant because of the common functionality. Constitution of a framework using components is the first step in providing flexibility. A statically defined framework would not be adequate to meet the challenges posed by a dynamic environment. For example, an application could not alter the caching scheme in response to a run-time communication cost if the caching component was statically chosen. To address such needs, further details about the functioning of components and intercomponent interaction need to be exposed and made controllable. This is done in accordance with the Pi object model which is described in detail elsewhere [Kulkarni, 93]. However the essential techniques used for the design of Pi repository are described in the next section.


5

4. Reification and Reflection Reification is the act of making an implicit or abstract thing explicit or concrete. It is a mechanism to expose the details that are normally hidden from the ‘user’ of the system, in this case a programmer who uses the repository interfaces. In an object-oriented system such as the one proposed in this paper, reification amounts to making the objects that implement the system available to its users. Reified objects are often referred to as metaobjects and computation related to them is termed metacomputation. Reified objects are provided with interfaces that allow changes in their behavior. Hence, the system behavior can be suitably changed by effecting changes to the behavior of its constituent objects. Such a system is said to be reflective and the invocations on reified objects are called reflective programming or meta-programming. The causal link between the reified objects and the system they implement ensures that a reflective computation does indeed change the behavior of the system [Maes, 87]. Such an approach to software engineering has also been advocated in [Kiczales, 92]. In the design of repository, the objects that implement functions like naming, interface binding, caching and I/O are reified as metaobjects. This provides two avenues for reflective computation - either by invoking methods provided by these metaobjects or by affecting the interoperation between these metaobjects that form a flexible framework. An example of the former is association of annotations or version numbers with a document through the addition of an appropriate attribute to its name. The latter could be used to attach a filter to a directory and transform stream-based files into record-based files. The framework is supported by generic object services that allow the composition of objects into a customized virtual repository for a particular client or a data object. Event, scope and interface management are such generic services. Event management services allow registration and announcement of events and notification upon event occurrences much like in OMG event services [OMG, 93b]. These event services can be used to implement the caching interface described in the next section. Scope management handles the correspondence between a change induced by metacomputation and the objects that are to be affected by this change. Interface related services maintain information about interface types, their versions and compatibility.

5. Pi Repository The Pi repository is a tool that allows information access and manipulation of the mechanisms used for information access. A key element of the architecture is the name abstraction. A name identifies an information object, and is associated with a set of meta-objects that not only provide access mechanisms but also allow fine-grained control of the access Information Access in Mobile Computing Environments

6

mechanism implementation. The next few sections describe the different pieces of the Name abstraction and the other component meta-objects that form the architectural framework, as shown in Figure 1.

Mail-tool

Address Book

Applications

Access interface

Browser

Protocol

Files

ID

Email

Cache

Stock Quotes

Context Binding & Resolution Name

Metaobject interface

Pi Repository

Data Storage

Figure 1: Pi Repository - Structure and Relationship with Clients

5.1 Naming Names form a fundamental abstraction of the Pi repository and are used to identify various information resources. These names can be associated with various attributes and can be clustered in a container like a directory. A realization of the name abstraction allows application programmers to control the binding of these names to information objects. It also allows control over the manner in which a given name is resolved to a particular object at run-time. In this architecture, name binding, resolution and contexts are represented through meta-objects hierarchies that provide direct control to the application programmer. A name may be an identifier such as a virtual address, an object id, a user-friendly name or a more complex structure. A structural name could include hierarchical information about the logical or physical organization of the object that it identifies. Since one kind of name is not sufficient to satisfy the desire for functionality, mobility and performance, the Pi repository uses a class hierarchy to represent the name abstraction. Different classes in this hierarchy may be associated with different attributes and accessing options. Subclassing or even substitution with user-defined names provides further flexibility. Some of these classes are engineered to store additional attributes such as a version number or the related display tool. Where appropriate, such attributes are mapped onto the facility provided by


7

the host; e.g in OS/2, extended attributes can be used. Thus, in effect, inheritance mechanisms are used to associate a particular name with different attributes and variations in functionality. A file system hierarchy provides containers for names. The Unix directory structure and its tree of directories are containers with well-defined and semi-rigid structures and interfaces. The Pi repository uses additional containers like hash tables and allows a variety of implementations that conform to the specified interfaces for the traversal of namespaces. In effect, a hard-wired component such as a directory, with the function calls that it supports, is replaced by a flexible software component that abides by a contract [Helm, 90], [Meyer, 92]. Name binding and resolution are handled by user-modifiable components. The process of name binding essentially establishes a correspondence between multiple names. An example of this binding is association of a user-specified name like best_buys with a file on an ftp site, say hostname.subdomain.domain.com:pub/stocks/xyz. In particular, the URLs [Berners-Lee, 93b] used by the World Wide Web are supported by the Pi repository. The binding and resolution interfaces are comparable to those proposed for OMG Object Services [OMG, 93a]. As mentioned before, the user may choose to finetune the default binding and resolution mechanisms by using the reflective interfaces provided by the meta-object hierarchies. If major changes are required, the programmer may create new subclasses of the existing meta-classes to effect them. Name resolution and binding is performed in a certain context. Common contexts include the root directory, current directory or some other context specified through mechanisms like environment variables. Additionally, a context may be associated with a group of objects accessible through the repository [Radia, 93], [Lantz,85]. Specification of explicit context information for an activity or a set of objects is also permitted. In our case, ‘root’ does not refer to any global naming system but to the root of the repository as seen by this user. Name resolution is an activity that can be separated from access to the object whose name is resolved. This allows the possibility of having a name server that is distinct from the object server. For example an X.500 name [Hunt, 92] can be resolved through an X.500 server to obtain information about the location of an object and then the object-server can be contacted. This is a significant departure from the approach used in V, where each server implements its own namespace for resiliency [Cheriton, 89]. While we do not preclude objects that require both servers to be the same, we feel that such a requirement is too restrictive for general usage in a heterogeneous, wide-area setting. A similar approach is used in UDS [Lantz, 85].


8

In fact, the granularity of names used during the resolution process, depends upon the nature of the server that stores the actual information objects. For example, in NFS, file names are resolved on a per directory component basis, while if AFS [Howard, 88] support is added, the namespace seen by the repository would consist of file ids rather than multi-component path names. This interaction is affected by caching of namespaces as described next.

5.2 Caching and Locking Caching is of paramount importance in a mobile computing environment where connection to the server may be unavailable, limited due to low bandwidth and high delay or prohibitively expensive. Each name (actually the object that represents it) in the Pi repository is automatically associated with a caching protocol. This protocol is implemented as a meta-object hierarchy and provides interfaces to control the caching behavior associated with its information object. This section describes the caching protocol, the flexibility it brings and some of its implementation details. Due to reification of the metaobjects that implement the repository, it is possible to tailor the caching behavior for a single object or a group of objects. The same is true of namespaces as well, thus allowing for the caching of directory component locations for traditional file-systems, such as NFS and AFS. The namespace supported by a remote server may be cached for those applications that can tolerate stale data or would rather use a suspect copy than nothing in case of disconnection. An object has a default caching behavior based on the interface it supports and its home server, if any. This default behavior can be overridden by specifying an alternate behavior through a profile or at run-time by installing the appropriate caching interface. The framework implementation would then verify that the installed interface is compatible with the server and proceed to provide alternate caching and locking behavior. For example, if the server does not provide callbacks, a callback-based caching interface would be rejected, but periodic updates would be accepted. Truly flexible caching can be supported only with some degree of help from the repository responsible for the latest copy. In the case of an information server that does not provide asynchronous invalidation requests to its clients, it becomes the responsibility of the Pi respository client to monitor the validity of its caches. To some extent, this situation could be alleviated by a proxy of the Pi repository on the server or peer machine. This proxy could provide a callback facility to the Pi repository, thus ensuring that cache validity monitoring does not generate too much network traffic. In the absence of such a facility, for example in the case of servers where proxies cannot be maintained, server-blind caching can still be done. However, as discussed in [Terry, 87], a namespace or object cache so maintained could be incoherent. Hence, the explicit notion of a confidence value based on Information Access in Mobile Computing Environments

9

expected mean-time between updates is introduced. A function for computing such a value can be provided by the user to override the defaults. Cache updates may be initiated by the client or a by server (or a by peer). In the former case, the repository may be asked to get an updated copy on demand, periodically or when some other condition is satisfied such as the availability of an inexpensive communication link. In the latter case, a server (or a peer) that supports callbacks can inform the repository about a new version. Similarly locks (exclusive or shared) may be acquired for a certain duration or until explicit release. Caching has been investigated extensively for file systems and databases. The most relevant related work is hoarding in Coda [Kistler, 92], callbacks in AFS [Satyanarayanan, 90] and leases [Gray, 89]. Coda provides an interface in the form of a hoard profile that is an addition to the normal file interface in Unix. AFS uses the idea of informing clients when a change notification is received by the server and leases introduce the idea of locking for a certain duration for resiliency. These interfaces essentially respond to Hauser’s plea [Hauser, 92] to support caching. But because of the dynamically changing environment, the repository has to rely not only on the user who can request the most appropriate caching behavior but also on the environment to provide information about factors such as the characteristics of the communication link, availability of additional storage and the constraints thereupon. Obviously, such an approach to caching crosses the boundary imposed by transparency. It also allows compromise over coherency. But the cause for such behavior is the dynamic nature of the environment and the resource constraints rather than a design artifact. It is possible to limit the design to provide only strict semantics (such as the semantics of a single machine Unix file system), but in our opinion, the advantages to advanced users of added features outweighs the additional complexity in the non-uniformity of the semantics.

5.3 Access Mechanisms The objects available through the repository can support a variety of access mechanisms. The email example mentioned in Section 2 best illustrates the need for alternate access mechanisms. In the case of email, it may be desirable to just obtain the headers and then decide whether or not to retrieve the message. A second example illustrates the limitations of the vnode-interface, a de facto standard in distributed Unix file system interfaces. To copy a file from one directory on the server to another directory on the same server, NFS actually fetches the file to the client machine, creates another file, copies the first file and then sends back the copied file to the server. A Information Access in Mobile Computing Environments

10

simple addition of the copy operation to the interface would save a lot of unnecessary traffic and communication cost. Of course, only those operations that are understood by the server can be meaningfully supported by the Pi repository. In the case of a file copy, a proxy of the repository may have to be present on the NFS server to perform a copy operation on behalf of the client/repository. In general, supporting higher-level semantics at the server site can significantly improve performance. This issue has been investigated in QuickSilver [Theimer, 89]. Other applications with potential for separate interfaces include record-based files, DLLs and hypertext [Noll, 91]. Individual interfaces are associated with an object or a group of objects. Use of an interface different from that associated with the object requires installation of appropriate transducers that can perform the conversion. For example a file-to-link transducer is used to get at an ftp’able file associated with a file-interface in the repository. In addition to basic functionality such as search, retrieval and storage of data, features like quality of service, security and cost are becoming increasingly important. The Pi repository’s biggest advantage is that its interfaces are not rigidly defined at design-time. For example, it is possible to impose encryption as a requirement on certain objects when they are transmitted to a remote server and then augment the read/write interface to include an encryption key.

5.4 Communication Multiple protocols are supported both for name resolution and for access to the objects stored. The common protocols include the Unix file system protocol, vnode-VFS protocol [Kleiman, 86] and ftp [Postel] and IMAP [Crispin, 92] for email. Other protocols with compliant interfaces can also be inserted by the user into the framework. At the lower level, support for communication is further complicated by the requirement that the repository work with existing protocols that are unfamiliar with mobility and disconnection. At present, we are experimenting with portable communication endpoints that can move from one machine to another and still maintain their transport-level connection for a byte-stream or reliable datagram protocol. This is made possible by a repository proxy at the server end, that keeps the connection with the server open, while allowing the client to disconnect and reconnect with a unique key.

5.5 Framework The framework maintains the combined information for a set of data objects or a client. For example, when a browser requests a specific naming and caching scheme for a set of objects, the implementation of the framework installs the appropriate caching metaobjects for data access and provides the naming objects. It also acts as a clearinghouse for events Information Access in Mobile Computing Environments

11

of common interest like availability of greater bandwidth on the communication channel. It filters and processes events so that repository metaobjects and clients who have installed callbacks are notified. Alternately, clients and metaobjects may choose to poll for the event that they are interested in to avoid asynchronous event notifications. The implementation of this framework is currently in progress.

5.6 Implementation Issues Implementation of class hierarchies for the components as well as the framework is currently in progress. The current implementation is entirely at the user level and avoids kernel modifications. The components described here are implemented as a set of C++ libraries and servers on AIX and OS/2. Eventually, some of the components, especially cache management, may have to be moved inside the kernel. The interfaces that we have selected are similar to those described in OMG object service submission [OMG, 93a]. A client application can choose a suitable name, and bind it to some object like a file in some context. At the time of this binding, the repository implementation associates an interface with the name for future resolutions. Depending on the nature of the object, the binding may be cached to speed up resolutions. As shown in Figure 1, the name gets resolved to an ID representing a cached object or a proxy for the object to be fetched. In response to a read call (or an equivalent call in the custom interface), an uncached object gets fetched from a remote server using the appropriate protocol. The exact nature of the object is defined by the client while naming it. For example, if the named object is an email header, just the header is retrieved using the IMAP protocol. These features are presented as sets of class hierarchies to applications. The naming class hierarchy currently supports various kinds of name implementations such as identifiers, and string names, each of which may be associated with a member of the binding and resolution class hierarchy. The caching interface may be used to fine-tune local storage of information through the manipulation of expiration times, enforcing periodic refreshes and installing invalidation callbacks. On the protocol side, classes for FTP and IMAP (at present) are used in addition to those for the standard file system protocol. Client applications use IDL interface specifications to automatically include the correct libraries in the generated C++ code. Interfaces are stored in an interfaces repository provided by SOM [IBM, 93] or alternate CORBA [OMG, 91] implementation. In addition, we foresee the need for an implementation repository as is provided by some CORBA realizations [IONA, 93]. The implementation repository is used to keep track of location information of the Pi repository class hierarchy implementations, as well as for the information object servers. In essence, the current realization uses a CORBA implementation that supports meta-objects, like SOM does. It is the design of the class hierarchies that


12

constitute the visible repository interfaces and the construction of the implementation repository that represents significant additions to the CORBA model.

6. Discussion The Pi repository described above applies several ideas investigated by naming systems and distributed file systems to mobile computing. However, it uses a different model for computation which is centered on a mobile user who can use different machines to get at data stored on a number of sites, possibly scattered all over the world. This model of computation, dictates much of the design of the Pi repository. The nature of services and interfaces provided by the Pi repository was itself strongly influenced by information systems that go beyond file systems. The most notable examples of such systems are Tapestry [Goldberg, 92] which allows filtering of an ocean of incoming information, the World-Wide Web [Berners-Lee, 93a], and the Semantic file system [Gifford, 91]. Emerging applications for mobile computing that utilize the strengths of ubiquity and availability in repositories, while acknowledging the weaknesses of resource limitations and connectivity will greatly enhance the use of mobile computers. The methodology uses controlled exposure of an implementation and extends the benefits of reflection to repositories. Reflection has been successfully applied to languages, especially interpreted languages like CLOS [Kiczales, 91]. In essence, a repository is similar to an interpreter whose language consists of the calls that it supports. However, this ‘language’ is significantly different from a general-purpose programming language. There are many promising areas to investigate in the context of such a repository. We have focussed on the design and implementation of flexible naming and caching interfaces that provide greater control over the behavior of the repository, while keeping the complexity manageable. However, this control does cause non-uniform behavior and the possibility of run-time surprises. Incoherent data or incompatible interfaces may arise because additional control provides the opportunity for additional mistakes. Nonetheless, conformity checks performed by the framework can minimize such problems.

7. Conclusion This work recognizes that the advent of mobile computing will require some rethinking about the way information is handled. Building on familiar information access mechanisms such as file-systems, the Pi repository provides a set of flexible and generic tools that can be used to build information management systems.


13

Perhaps the most important contribution here is the notion that the traditionally implicit aspects of file-systems, such as the binding, name resolution and caching, should be transformed into explicit, concrete entities with programming interfaces. In addition, the Pi repository gives one the ability to tailor information access interfaces to suit the needs of one’s application. The use of a framework-based approach allows application programmers the flexibility to choose the kind of functionality they desire. In addition, the association of caching protocols with information objects ensures that programmers may finetune the information-access performance according to the resource availability. Thus, in effect, this work represents a step towards building abstractions that reflect the way people will use mobile computing resources.

8. References [Berners-Lee, 93a] Berners-Lee T. et. al., World-Wide Web: The Information Universe, available by ftp from info.cern.ch. [Berners-Lee, 93] Berners-Lee T., Uniform Resource Locators, working draft, 14 July 93, IETF URL Working Group, available by ftp from info.cern.ch. [Cheriton, 89] Cheriton D., Mann T., Decentralizing a Global Name service for Improved Performance and Fault Tolerance, ACM TOCS 7(2), May 89, pp. 147-183. [Crispin, 92] Crispin M., Interactive Mail Access Protocol - Version 2, RFC 1176. [Douglis, 92] Douglis F., Marsh B., The Workstation as a Waystation: Integrating Mobility into Workstation Environments, The Third Workshop on Workstation Operating Systems, IEEE, pp. 17-21. [Gifford, 91] Gifford D. et. al., Semantic File Systems, Proc. 13th ACM Symposium on Operating System Principles, pp. 16-25. [Goldberg, 92] D. Goldberg et. al., Using Collaborative Filtering to Weave an Information Tapestry, Commun. ACM, 35(12), Dec. 92, pp. 61-70. [Gray, 89] Gray C., Cheriton D., Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency, Proc. 12th ACM Symposium on Operating Systems Principles, Dec. 89, Operating Systems Review, 23(5), pp. [Hauser, 92] Hauser C., A Plea for Interfaces that Support Caching, The Third Workshop on Workstation Operating Systems, IEEE, pp. 137-140. [Helm, 90] Helm R. et. al., Contracts: Specifying Behavioral Compositions in Object-Oriented Systems, Proc. OOPSLA ‘90, ACM, pp. 169-180. Information Access in Mobile Computing Environments

14

[Howard, 88] Howard J. et. al., Scale and Performance in a Distributed File System, ACM TOCS 6(1), Feb. 88, pp. 51-81. [Hunt, 92] Hunt R., CCITT X.500 Directories - principles and applications, Computer Communications, 15(10), December 92, Butterworth Heinemann Ltd., UK. pp. 636-645. [IBM, 93] The SOM Toolkit User’s Guide, IBM Corp. [IONA, 93] ORBIX-Advanced Programmer’s Guide, IONA Technologies, Ltd. June, 1993. [Kiczales, 91] Kiczales G. et. al., The Art of Metaobject Protocol, MIT Press. [Kiczales, 92] Kiczales G., Towards a New Model of Abstraction in Software Engineering, Proc. Workshop on Reflective and Meta-level Architectures, IMSA ‘92, Tokyo. [Kistler, 92] Kistler J., Disconnected Operation in the Coda File System, ACM TOCS 10(1), pp. 3-25. [Kleiman, 86] Kleiman S., Vnodes: An Architecture for Multiple File System Types in Sun UNIX, Proc. Summer USENIX Conf., June 86, pp. 238-247. [Kulkarni, 93] Kulkarni D. et. al., Structuring Distributed Shared Memory with the Pi Architecture, Proc. 13th ICDCS, pp. 93-100. [Lantz, 85] Lantz K. et. al., Towards a Universal Directory Service, ACM Symposium on Principles of Dist. Computing, ACM, pp. 250-260. [Marsh, 93] Marsh B. et. al., Systems Issues in Mobile Computing, Tech. Report MITLTR-50-93, Matsushita Information Technology Laboratory, Princeton, Feb. 93. [Meyer,92] Meyer B., Design by Contract, Advances in Object-Oriented Software Engineering, Ed. D. Mandrioli & B. Meyer, Prentice Hall. [Neuman, 92] Neuman B., The Virtual System Model: A Scalable Approach to Organizing Large Systems, Ph.D. Dissertation, University of Washington. [Noll, 91] Noll J., Scacchi W., Intergating Diverse Information Repositories: A Distributed Hypertext Approach, IEEE Computer 24(12), Dec. 91, pp. 38-45. [OMG, 91] The Common Object Request Broker Architecture and Specification, OMG Document No. 91.12.1. [OMG, 93a] Naming Service Specification, OMG TC Document 93.5.2, Object Management Group, Rev. May 14, 93. [OMG, 93b] Event Service Specification, OMG TC Document 93.7.3, Object Management Group, Rev. July 2, 93.


15

[Pike, 93] Pike R. et. al., The Use of Name Spaces in Plan 9, Operating Systems Review, 27(2), April 93, ACM, pp. 72-76. [Postel, 85] Postel J., Reynolds J., File Transfer Protocol (FTP), RFC 959. [Radia, 93] Radia S., Coherence in Naming in Distributed Computing Environments, Proc. 13th ICDCS, pp. 83-92. [Saltzer, 93] Saltzer J., Needed: A Systematic Structuring Paradigm for Distributed Data, Operating Systems Review, 27(2), April 93, ACM, pp. 77-81. [Satyanarayanan, 90] Satyanarayanan M., Scalable, Secure, and Highly Available Distributed File Access, IEEE Computer, 23(5), pp. 9-21. [Satyanarayanan, 93] Satyanarayanan M. et. al., Experience with Disconnected Operation in a Mobile Environment, Proc. USENIX Mobile & Location Independent Computing Symp., USENIX Association, pp. 11-28. [Terry, 87] Terry D., Caching Hints in Distributed Systems, IEEE Trans. on Software Engg., SE-13(1), Jan. 87, pp. 48-54. [Theimer, 89] Theimer M. et. al., QuickSilver Support for Access to Data in Large, Geographically Distributed Systems, Proc. 9th ICDCS, IEEE, pp. 28-35. [Welch, 90] Welch B., Naming, State Management, and User-Level Extensions in the Sprite Distributed File System, Ph.D. Dissertation, University of California, Berkeley.


16