Framework Capabilities

Frameworks and architectures such as PVM [1], CORBA [3], COM/DCOM [6] have introduced interesting mechanisms for performing computations collaboratively over clusters of workstations. Some examples of these mechanisms are typed interprocess communication, synchronization mechanisms, remoting, naming services and remote method invocations. Frameworks for mobility such as Aglets [5] and Voyager [8] implement mobility at object level. As compared to various available message frameworks in these categories of parallel, distributed and mobile computing frameworks, the ARC framework on .NET discussed in this paper specializes from the point of view of integrating anonymity, service orientation, mobility and remoting in a distributed scenario. Lightly loaded participant machines may join an ARC system dynamically or leave dynamically. An ARC computation may make use of these services to benefit from available computing capacity in a network. A horse power factor service and a fault tolerance service are provided as support services for computing in presence of load and failures. The framework is also extended to support multiple hopping of objects (including state and code) and remoting abilities to ARC objects.

Various features of the ARC framework are discussed in this section. First the features are introduced and then the architecture is discussed in next section. Figure 1 shows a use-case diagram [4] bringing out the functional view of the ARC framework. Two kinds of actors namely Parallel/Distributed Application and Node Administrator can be noted. Parallel or distributed applications use constructs provided by ARC system to develop programs involving more than one machine. Node administrator deals with join and leave services. The functionalities identified in the use case diagram are elaborated below.

Figure 1:Use-Case Diagram for ARC

• Specifying an ARC object: An object is specified as an ARC object through inheritance. An ARC object obtains all the capabilities provided by the ARC system.
• Anonymity in node selection: An application may select a machine by its Horse Power Factor (HPF) value, while the machine remains anonymous for the application. HPFs may be obtained via a call to getHPFVector() to a local HPF server. An HPF value is an instance of a class. An HPF server communicates with other HPF servers in the network.
• Explicit node selection: An application may also select a machine explicitly for migration through a call to getHPFValue() on local HPF server.
• Migration assurance: When an application obtains an HPF value of a machine, or a vector corresponding to a set of machines, each value represents an assured slot for receiving a migrating object. The slots are unlocked through a call to release() on the local HPF server.
• Migration: Migration of an ARC object to an anonymous machine. An ARC object may be migrated by calling a method push() on the object. The method requires an HPF value corresponding to an anonymous machine as its parameter.
• Trigger: A method body to be executed after the object moves to remote machine is implemented as method Trigger() by the arc-object.
• Parallelism: While an application migrates an ARC-object to an anonymous remote machine due to a call to push, it may continue in a non-blocking fashion. A result of remote execution available as ARC object's state after it retracts.
• Auto-retraction: Asynchronous return of an object after completing the task at remote machine is a default retraction mechanism. After the object retracts, all invocations on the object are performed locally. The application remains unaware of the location of the object due to an internal automatic proxy switching mechanism.
• Wait till retraction: An application may wait on an ARC object till it is retracted through a call to sync() on the ARC object. If the object is already retracted, the call is returned immediately.
• Explicit retraction: An object may be called back to originator when required through a call to GracefulRetract() on the ARC object. The remote ARC object is intimated via a flag which may be checked through a method isRetractionSet(). The trigger method in an ARC object may be implemented to handle an incoming graceful retract request.
• Roaming: An object may re-hop over a network of machines by means of a call to push() on the object. This call can be made by the originator, by its current context or by the object itself. The protocol followed by push is the same as that followed on its originating machine. For the originating application code, the object's location need not be known for call invocations on the roaming object. To establish this communication, the originating application needs to call a connect() invocation on its local ARC object handle. Proxy switching is performed internally in response to connect.
• Fault Tolerance: A desired fault tolerant behavior for an ARC object may be specified. Before an ARC object is migrated, to access a failure recovery service, the object is registered with a fault tolerance service (FTS) through a call to register() specifying the desired fault tolerance semantics for a given ARC object. An FTS server communicates with remote FTS servers for failure detection. Upon a failure detection, the FTS carries out resend operations through local ARC system interface.
• Communicating mobile objects: Roaming objects may exchange messages between each other. If the location of an object is known, an explicit proxy to the object may be obtained. For communication among roaming objects, their locations need to be known to each other. An explicit proxy is required for all contexts other than the originating code for communication with a roaming object.
• Dynamic join and leave: Machines may join or leave an ARC system dynamically through a Join service and a Leave program. Every active participant exports a copy of the Join server. The list of currently active nodes is updated by join service on every machine.