Introduction

  Distributed object systems provide the key to build large scale distributed applications that can execute on a range of platforms. Examples of systems which hope to address interoperability and heterogeneity issues include the various CORBA (Common Object Request Broker Architecture) [28] compliant object systems. Existing implementations of these systems experience communication latency inherent in distributed systems as well as the software overheads associated with messages that are exchanged when a client node invokes methods of an object that is implemented by a remote server. These overheads can be reduced significantly if the client node is allowed to cache the object state locally. In this case, future invocations can be executed locally which could lead to better performance.

The benefits of caching are well known and have been demonstrated in systems that range from shared memory systems to distributed file systems. This important technique and the implementation issues related to it have not been addressed in CORBA specifications. A goal of this paper is to contribute towards the discussion about adding caching as a common object service to CORBA. We describe the design and implementation of Flex, a scalable and flexible distributed object caching system. We wanted to build Flex on top of a general purpose and a generally available platform. We chose Fresco [12] which uses the CORBA object model (and was readily available from the X11-R6 distribution). Fresco runs on UNIX and provides an object wrapper around Sun RPC. All invocations on a distributed object reference are translated to remote procedure calls to the object server. In Fresco, object interfaces are specified using OMG's Interface Definition Language (IDL). Flex enhances Fresco by adding caching to it. In addition to the implementation of Flex, issues and solutions discussed in this paper have also been influenced by our previous prototyping of caching in IBM's System Object Model (SOM/DSOM) [15].

Caching has been studied extensively in the realm of file systems [14][30] and software based implementations [5][18][19][22] of distributed shared memories (DSM) in which files, memory pages, etc. are cached. We will refer to the entities that are cached in these systems as flat objects to distinguish them from the more sophisticated objects (which we will just refer to as objects) which is the focus of this paper. Though object caching has many similarities to caching flat objects, there are a number of important differences.

1. Not all objects encapsulate just data. Many objects are really wrappers around control or hardware devices. Thus, it is not possible or desirable to cache all objects. In particular, it leads to the issue of control over what objects get cached.
2. Objects have references to other objects. Thus, when an object created at a server is cached by a client, it is not always appropriate to cache all objects referenced by the object; some control is needed regarding which of the referenced objects, if any, should be cached. Issues such as this and the previous one leads us to provide object caching as a Common Object Service [28] rather than make it a part of the Object Request Broker (ORB).
3. Objects have method level access and it is customary to allow clients to have access only to specific methods of an object. While this is true even of flat objects, they support only two elementary types of accesses - namely, read and write. Security considerations resulting from these differences have implications in the design and implementation of object caching.
4. When methods are invoked on objects, it is harder to detect the type (read or write) of access. This is because objects are accessed using method invocations instead of elementary operations such as read and write.
5. Information about objects is accessed more often than the objects themselves. Object caching, therefore, should also be concerned about caching associated information that is stored outside the object.

While the above design issues are specific to object-oriented systems, some caching issues that are not specific to object-oriented systems can be addressed better by object technology. For instance, caching creates multiple copies of an object which introduces the problem of consistency among the copies. The performance and functionality of a distributed object system could depend very much on the level of consistency it provides. Instead of providing a single consistency level to applications, we take the approach of providing multiple consistency guarantees. In Flex, we take advantage of object technology by allowing class implementors to subclass from a specific consistency class in the consistency framework (described in section 4.1).

The paper is organized as follows. We start with some details on the technique that we use to build multiple consistency levels in section 2. The issues involved in building an object caching system, possible solutions in the context of Fresco and UNIX that take advantage of object technology, and the ones we adopted are discussed in Section 3. Section 4 includes an overview of our implementation of Flex. We present preliminary performance results in Section 5 which demonstrate that caching could result in improved performance for applications that exhibit a reasonable amount of locality of access. Our experience with CORBA and UNIX are detailed in Section 6 and we conclude the paper in Section 7.