DISCONNECTED OPERATION

The CORBA environment is essentially a connection-oriented programming environment, a client must maintain a connection to a server. In a mobile domain the challenge is to maintain that logical connection between the server and client regardless of what happens at the communication level.

What is required is a mobile aware ORB that has techniques for optimising access to server objects, which will deal with the latency and bandwidth problems. It also needs some techniques for disconnected operation, which may include object replication, object caching on mobile hosts and some method of deferred remote invocation when a connection is down.

Some of these techniques overlap in supporting the various requirements. Object caching and object replication can help with optimised access to objects and also in disconnected operation. The following sections look at various existing projects that have used and experimented with some of the mechanisms mentioned. The aim is to use some of these ideas and present some possible solutions supporting mobile operation for CORBA applications in a wireless network.

Replication is one of approaches that can be taken for disconnected operation in a client/server paradigm that were discussed at the start of section 2.1. Replication introduces problems such as consistency and conflict resolution.

2.4.1.1 Using the Disconnected File System Approach

File caching is one approach that enables disconnected operation for extended periods of time in a file system. By using this approach it must be accepted that it will lead to conflicts, which will affect to validity of certain read and write operations. A user of such a system must be aware that a write operation may fail long after it may have been committed on the local host and also a read operation may return some outdated information without showing any errors.

Coda [Kistler ’91] is a diconnectable file system. It provides resilience to server and network failure through the use of server replication and disconnected operation. The name-space is mapped to individual file servers as volumes. Each client has a cache manager in charge of caching the volumes. To achieve availability Coda uses replication, allowing volumes to be read and written at more than one server. Coda uses an optimistic replication strategy, which provides high file availability by allowing reads and writes even when the server and clients are not connected. The strategy can be described as read-status-from-all, read-data-from-one,

write-to-all [Saty ’89]. With optimistic replication there will be conflicts. In Coda write-write

conflicts are detected using version vectors. A version vector summarises the modification history of a file and conflicts are detected by comparing version vectors. If the vectors are the same then there is no conflict, if they are different then a resolution process must take place. This is done by a resolution protocol and if it’s not successful then by a manual process.

Disconnected operation in Coda takes place when the replicated servers are unreachable and the client enters what is called emulation state where the cache emulates the server. At reconnection the cache volume is merged with the servers volumes. Conflicts are detected as described above.

Disconnected operation may only be acceptable to the user if reconciliation of conflicts is automatic, and is done in a predictable, repeatable and acceptable way. One wireless experiment has defined a number of algorithms for automatic resolution of conflicts based on priority assignments and invalidation [Hild ’95]. It was illustrated that total reconciliation can be performed as a sequence of partial reconciliations.

At the University of Washington a disconnected operation programming environment for mobile computing devices was developed based on experience building a disconnected NFS for portable computers. Concepts from the CODA file system approach were used to develop a proxy to add to the standard client/server scenario. The proxy was used to mask mobility. It acted as a pseudo-server to the client and a pseudo-client to the server. In the connected state the proxy forwarded all of the client requests to the real server. In the disconnected state the proxy emulated the real server but the proxy maintains a log of modifying operations that were to be reflected on the server on reconnection [Fiuczynski ’95].

2.4.1.2 AspectIX

AspectIX [Geier '98] is and open architecture defined to overcome CORBA’s limitations when it comes to providing an open architecture for use in a mobile environment. It moves beyond the static client-server relationship of CORBA and uses the concept of distributed objects. In this system an object is made up of distinct fragments and each fragment communicates with other fragments to achieve the desired behaviour. The client in this architecture is a little different from the CORBA one where the local object is a stub that delegates invocations to the server object. In AspectIX the client of the object always has one of these fragments in its local address space. The fragment could be a simple stub as in CORBA. The stub may connect to another fragment (like the server object in CORBA) that implements the object’s functionality. The fragment at the client side may also be a little more intelligent and may cache some of the object’s data or implement some of the object’s functionality locally. This kind of behaviour would be very useful in a mobile communications environment.

For replication the distributed object is extended by an additional fragment, which just acts as a replica. The replica has the responsibility of implementing the consistency model communicating with other fragments. For mobility the distributed object is extended with a new fragment at the destination site. The state of the original fragment is then transferred to the new one and the old fragment can be replaced by a simple stub acting as a forwarding entity. The original fragment can then be deleted, this results in the migration of the distributed object. The distributed object makes the decisions about replication and mobility based on the requirements of client.

This mechanism could be a useful way of extending CORBA’s static client server architecture and allow it to function in a mobile environment using the tools of replication and migration in a distributed object scenario.

2.4.2

Using Disconnected Operation In CORBA

In supporting disconnected operation in a CORBA environment it is obvious that the mechanisms of replication and relocation will be required. The next section describes how disconnection can be integrated with the ALICE framework and proposes the mechanism of Object by Value which was used as the approach in this project for moving objects around to enable disconnected operation. However, as the previous sections pointed out there is also a penalty of having to provide some support for conflict detection and resolution.

Chapter 3