1 Introduction

Sharing objects in a distributed environment should be supported in any distributed autonomous object environments. We propose a Global Store abstraction (GS) for building high-performance reliable collaborative applications sharing a large amount of objects. The global store or the fault-tolerant store (FTS) can also be used to implement a fault tolerant mobile agent platform. A store is composed of a set of objects. Each application has a reference to the store. The application accesses objects with a transactional interface. Users connect and disconnect to the store dynamically. GS allows local modifications to be seen instantaneously without waiting for a slow network. Applications can also update objects without worring about concurrency control and store failure. The GS handles site crashes which are invisible to the user i.e. crashes are only visible as possible delays of objects updates. If there are n sites, n-1 crash sites are tolerated. The global coherence of the store is maintained in case of site crashes.As long as at least one site runs, the store survive. No persistence is used; the redundancy of multiple localStore is enough to provide fault tolerance. We use a client-server architecture, the server is a lightwight server whose main purpose is to manage locks on objects in the store. Server can migrate to any client's site. A server crash is tolerated; in this case the a live clients runing a consensus algorithem to select a new leader that creates a new server. All this is invisible to the user, who sees failures as temporary slowdown in the time it takes to reply a commit/abort message. The global coherence is maintained at all times

GS provides several types of transparencies:

• Failure transparency: which hides failures from an object to enable fault tolerance.

• Slow network transparency: which hides delays of network operations to enable instantaneous updates of objects.

• Transaction transparency: which hides coordination of activities amongst a configuration of objects to achieve consistency.

• Migration transparency: which hides from the object the system's ability to change the location of that object, e.g. for load balancing, or reducing latency.

The current implementation of the GlobalStore Module have two constraints:

• Store objects must have no references to resources. [Where a resource is part of system that is located on one site e.g. file system, graphics interface, etc.]

• In the current release only the permanent site failure is tolerated.

The GS module is composed of three parts:

• Connection part: offers procedures for initialising a new store and adding dynamically objects and users to the store.

• Transactional part: offers a programming interface to the fault-tolerant transactional protocol for updating objects in the store.

• Notification part: offers procedure to be installed by the client to give a coherent view of GS.

Our future research includes:

• Addressing the problem of network partitioning.

• Implementation of real-world collaborative applications.

• Implementation of mobile agent applications.

A documentation on GS is available from Chapter 13 Mozart book which is a part of the Distributed Programming chapter in the upcoming Mozart book.