Mobile and Group-Oriented Distributed Computing

ODP-Based Distributed Platform:Policy-Driven Engineering Support forMobile and Group-Oriented Distributed ComputingKazi Farooqui, Luigi Logrippo,Department of Computer Science,University of Ottawa,Ottawa, K1N 6N5, Canada.(farooqui | luigi@csi.uottawa.ca)AbstractThis paper deals with “object-based distributed computing platforms” in general, and “mobile and group-oriented distributed computing platforms” in particular. It presents an abstract distributed platform model composed of pre-defined architectural components which provides an infrastructure for the support of mobile and group-oriented distributed computing. The aim of this paper is to give an abstract model of an object-based, imple-mentation-independent and policy-driven “distributed platform” which provides the engi-neering mechanisms for the support of migration transparency and group transparency (required in an ODP programming model). It is proposed to identify such architectural objects and their interfaces so that they can be used as plug-in-mechanisms for the real-ization of the transparency.The focus is therefore on the engineering support for mobile and group-oriented distributed computing. The idea is to develop a function-based and customisable distributed platform environment which provides support for dynamic object migration and object group interaction based upon application requirements and policies specified in the programming model. The paper develops the notion of policy-driven “dis-tribution transparency-support machines”.1.0 IntroductionMuch research has been done in the area of location update protocols, reliable group com-munication protocols, multicasting protocols, etc.A generic model of object migration and group orientation in distributed systems is yet to be developed. This paper presents such an abstract and generic engineering model of mobile and group-oriented distributed computing that will form a blue print for the design activity in a technology-specific distributed platform such a CORBA, DCE, TINA-DPE, etc. . A characteristic feature of our work is the separation of structure (of the model) from the algorithms (or protocols for migration, replication and group communication). The protocols can then be associated with the appropriate interfaces of identified engineering components.Identifying and specifying the interfaces of an appropriate set of engineering mechanisms to support mobile and group-oriented distributed computing is still a research topic [10]. Ulti-mately the aim is to have a structured kit of architectural components and then using rules and recipes to select the appropriate engineering mechanisms to satisfy specific transparencies and the associated policy requirements.As mentioned in [11,12], further work is needed to understand how to configure a consis-tent set of engineering mechanisms (objects) to satisfy specific transparency requirements. The work reported in this paper intended to be a step in that direction.2.0 ODP Engineering Model: A Model for an Object-Based Distributed PlatformThe basis of our work is the ODP engineering model which provides an architectural frame-work for the design of an object-based distributed platform. The model reveals the structure of a distributed platform. As shown in [13], the set of basic services and mechanisms, which enable, regulate, and hide distribution are identified in the engineering model as a collection of interacting (engineering) objects which together provide support for the realization of interactions between distributed application components (in the programming model).The distribution-support objects (engineering objects) possess multiple interfaces. Each interface provides a distinct distribution-support service. The interaction between the interfaces of engineering objects provide support for the realization of programming-level object interactions.The engineering model provides a vocabulary of distribution support concepts. It is a frame-work for the organization of different types of distribution-support (engineering) objects such as stubs, binders, protocol objects in the distributed platform [14].3.0 ODP Distributed Platform: Repository of Pre-Defined Architectural ComponentsThe ODP distributed platform can be statically viewed as a modular set of communication support functions (protocol objects), distribution transparency support functions (transparency objects), and other domain-specific distribution-support functions. Subsets of these components can be dynamically combined to configure distribution-support machines (figure 1), which pro-vide the required functionality of service for the support of interactions between distributed appli-cation components. The distribution-support machines form the active parts of the system. They can be created, modified, and deleted dynamically.The idea is to develop a distribution-support environment in which distribution support for application components can be engineered out of generic architectural components [15, 16]. In this paper we focus on distribution-support machines which support object mobility and object group communication.It is proposed to develop a high performance function-based distributed platform that provides support for flexible application-driven component configuration based on varying levels of quantitative and qualitative application requirements (stated in the ODP pro-gramming model [17]). The component-based style supports customization of a given distributed application in the engineering model using pre-defined components. If the function definition is fine enough, the distribution-support services offered by the engineering model can be adjusted precisely to application needs.The pre-defined architectural components should possess fine-grain function definition, high-level functionality, generality, compositionality, and correctness[15]. The idea of a function-based and customisable distributed platform is also a key requirement of industry distributed sys-tems architectures such as Advanced Networked Systems Architecture (ANSA) [1-3], T elecom-munication Information Networking Architecture (TINA) [4, 5], Common Object Request Broker Architecture CORBA) [6], and RACE Open Systems Architecture ROSA [7, 8, 9].The aim of this paper is to identify a set of pre-defined architectural components (engineer-ing objects) required for the support of the mobile and group-oriented distributed computing. The configuration of these components comprise the “distribution-support machines” also referred to as “transparency-support machines”. This is shown in the following sections.4.0 Model for Mobile and Group-Oriented Distributed ComputingOur model assumes a mobile and group-structured object-based distributed environment. The model of distribution is that objects in the system can be freely spread over the system andcan be freely moved between nodes. The objects can be migrated without being affected in any way other than performance and fault-tolerance.The system consists offine-grained,dynamically created objects which are highly mobile in nature, objects which are replicated, objects which are organized as a group, and objects to which concurrent access can be made. Object migration, object replication, and configuration of objects as a group is dynamically initiated by the underlying distributed platform during object interac-tions based on constraints and policies specified in their interface specifications as part of the transparency-schemas in the ODP Programming Model [17].There exist objects in the distributed environment which can offer their services either as sin-gletons or as members of a group. In particular, the objects possess management interfaces to enable them to bind to groups. The dynamic object-based environment permits changes to the degree of replication of an object and the organization of the objects as an object group to accom-plish a particular application-specific task.This paper is based upon the ANSA model for object groups [10]. The basic group abstrac-tion (in the programming model) is to treat a set of objects organized as a group as though they were one. All members of the group may provide the same service leading to a homogeneous group (replica group) or the members may be functionally distinct and arrange to partition the work amongst themselves (to exploit parallelism) whilst still appearing to be a single object lead-ing to the formation of a heterogeneous group.The members of the heterogeneous group may be replicated to provide fault tolerance.In addition to server groups, clients may also be organized as a group resulting in a client group. A client group is also created when members of a server group make invocations on a (same) server object outside the group.Group-orientation will be a prevailing paradigm in the future distributed systems [19]. W e look at groups as an architectural solution to the problem of supporting dependable distributed systems. The notion of object groups offers a powerful abstraction mechanism for the construc-tion of large dependable systems [18].5.0 Projections on the Proposed ModelThe distinctive features of the proposed engineering model for mobile and group-oriented systems are:1.object-based model: We propose an object-based engineering architecture for the support of mobile and group-oriented distributed systems. The aim is to identify the architectural compo-nents for the engineering support of migration and group transparencies that are of fered in the programming model [17]. The transparency support objects constitute a library of pre-defined architectural components.2.configurable model: The idea is to define a configurable model of transparency support objects such that a transparency together with its associated policies (see [17]) can be implemented as a set of plug-in-mechanisms. Given this we need to identify (and specify) the interfaces of trans-parency support objects such that:a. the interfaces are generic irrespective of any protocol or algorithm used to exchange theoperations identified for the interface.This involves detailed interface specifications including identification of operations (and their terminations) exchanged between the interfaces of transparency-support objects as well as the behavior exhibited at these interfaces, such as the possible ordering of operations invo-cations that can be emitted and/or accepted at these interfaces.b. the programmer defined application objects can be bound to the transparency support objectsusing these generic interfaces. In the transformation/compilation (from programming model to distributed platform model) process, the programmer-defined objects need to be enriched with extra interfaces to bind to transparency support objects.The main characteristics of the proposed model arefine-granularity (in function definition), modularity,module configurability, and its application interface.3.application-policy driven model: The aim is to define a flexible application-driven “transpar-ency-support machine”. It is required to associate application policies concerning migration, replication and grouping (specified in the transparency schemas in the programming model (see [17])) with the generic engineering objects, such that the behavior of these objects is modified by application policies and requirements. Hence, we need to define policy interfaces on the transparency support objects.6.0 Basic Assumptions on Local EnvironmentsAs mentioned earlier, the primary aim of this paper is to concentrate on the “distribution-related” aspects of engineering support required for the provision of migration transparency and group transparency (to application programmers). Moreover the emphasis is on the definition of an abstract and generic object-based infrastructure, in an “implementation-independent” manner. However, these transparencies involve to a certain extent the “local” node capabilities as shown below. These capabilities are assumed available from the local environments.1. The representation of an object in the stable object store may differ from its volatile store repre-sentation. Our model assumes that an object is responsible for providing the relevant state transformation operations that enable its state to be stored and retrieved from the object store.2. The state of an object can have either a context (machine)-independent representation (i.e., free of references to the address space of a local node) or machine-independent representations of data can be obtained (through local transformation techniques) for storage or transmission overa network.3. We assume local mechanisms exist for generating the replicas of an object. (However, the issue of keeping the replicas consistent is managed through appropriate replica-consistency proto-cols. Such protocols can be integrated into our model at appropriate interface of architectural objects).In order to provide abstraction over these local facilities, we model them as generic objects: 1.Persistent Object Store: The persistent object store abstracts the local object storage system. It hides system specific details of stable storage, and provides a uniform service interface for per-sistent objects. It supports operations such as read_state(),write_state(),create_object(), delete_object(), etc.2.State Transformer Object: The state transformer object provides capabilities for packing object state suitable for transmission over network and unpacking a previously packed (transformed) object state into the instance variables (state) of the local object. In particular it provides trans-formations to convert local interface references into remote ones when an object is migrated.3.Replicator Object: The replicator provides the copies,replicas, of an object. The initial state version of a copy of an object is always kept at the local object store before an object is made torun in its local environment. This implies that object can also be migrated by transferring the initial state replica of the object together with its current state.7.0 Interplay of Engineering Mechanisms and Application-Specific PoliciesThe selection, configuration, and the behavior of engineering mechanisms in the distributed platform is governed by the application-specific migration, replication, and grouping-related poli-cies (such as the ones in the transparency schemas) specified in the programming model (see [17]). Transparencies are selectable and graduated. The transparency requirements of an applica-tion constrain the set of engineering mechanisms which can be used in the infrastructure.Transparency is achieved in the programming model by employing a set of engineering mechanisms in the distributed platform to compensate for an unwanted property of the system. We cannot generally identify a particular transparency with a particular mechanism (or an object), rather a set of mechanisms (encapsulated within objects) are orchestrated to implement a particu-lar transparency. These compensating mechanisms can be located in the local nodes of the involved interacting objects and in the intervening distribution-support environment[10]. As transparencies may be deployed in many parts of the distributed platform, an engineering mecha-nism can be invoked either by applications or other engineering objects.A mechanism provides a service through a typed interface (which can be defined in some interface definition language as a set of operation signatures). This enables existing mechanisms to be substituted by new mechanism conforming to the same interface type as the original. It is required to identify and specify these interfaces of engineering mechanisms (objects) required for the support of migration transparency, replication transparency, and group transparency.The behavior of engineering mechanisms can be altered by application-policies specified in the transparency schemas. (A possible representation of policies in the interface templates in the programming model is shown in [17]). Since the focus is on the application-driven flexible con-figuration of transparency-support machines, it is desired to represent engineering objects and application policies in such a way that engineering objects are influenced by policies. Although it is yet to be explored how to model policies in the engineering infrastructure, a possibility is to represent them as policy objects which are invoked by engineering mechanism (objects). These policy objects have typed interfaces which can be defined and specified in an interface definition language. The behavior of engineering mechanism (object) can be partially changed by passing to it an interface reference to different policy objects.Policy-driven engineering support can be achieved by representing policies as objects, the policy managers, which are invoked by engineering objects in order to determine what actions out of a set of possible ones should be performed by engineering objects. For example, on receiving a request to join a group, the group manager will ask the policy object whether the join should be allowed or not, and if permitted, the object is included as a member and the member list is updated.Policy objects are an engineering convenience for changing the behavior of a generic engi-neering mechanism (object) without having to build a completely new one. For example, an inter-face to a collator mechanism will support the operations necessary to reduce multiple messages to a single message. Precisely how this is done will be determined by policy objects. Some mecha-nisms may not make use of policy objects; a change of behavior may involve using a new mecha-nism. Introducing policy driven decision taking in the engineering infrastructure leads to a whole set of additional functions whose effect is guided by the policies.8.0 Policy-Driven Transparency Support MachinesThe transparencies (discussed in this paper) are realised in the engineering model by a com-bination of object management functions,binding management functions,domain-specific policy support functions and other generic “distribution-support” functions (such as relocation). Together they constitute pre-defined architectural components of the distributed platform. Hence, in general, the transparency support objects include a range of objects that provide support for these functions. The configuration of engineering objects (supporting the above mentioned func-tions), required for the provision of transparency, constitute the transparency-support-machine. This machine is constructed using pre-defined architectural components of the distributed plat-form.The mechanisms for the provision of domain-specific (distribution-related) policies are often embodied in the form of “pre-defined domain-specific components”. One of the main features of our model is the provision of application policy guarantees. Ideally, the policy specifications (made in the programming model) should be passed to the engineering mechanisms. But policy specifications are specific to an application-domain and therefore require domain specific engi-neering (policy support) objects.In the following sections we discuss the distributed platform (engineering support) required for the provision of migration transparency and group transparency in the programming model.9.0 Migration Transparency-Support Machine:Engineering Framework for the support ofMigration Transparency In this section we identify the engineering mechanisms (objects) and the configuration of these objects required for the construction of“policy-driven migration-transparency support machine”. Figure 2 shows the model of a policy-driven migration-transparency support machines placed between two mobile objects. This engineering framework described in detail in figure 3 is explained by identifying the core functionality of each object and its interactions with other objects.Figure 3 shows the engineering framework required for the support of policy driven object mobility and migration transparency between two mobile objects (client and a server). The migra-tion transparency is provided to the application objects in the ODP programming model through a combination of objects supporting the object management function, the binding management function, the domain-specific policy support function and other generic distribution-support func-tions.A.Binding Management: The support for migration transparent interactions between mobilemigration binder objects in the client and server half of the trans-parency machine and the client relocator and server relocator objects(support functions) out-side the machine.1.Migration Binder: An application object which is mobile or which interacts with a mobile object is bound to the migration binder object in its node. The migration binders establish, maintain, and terminate the binding between mobile objects. They maintain the integrity of the binding between the interacting objects even if one or all the objects in the binding are mobile by exchanging additional data in interactions through the binders. The migration binders inter-cept operation invocations and terminations (replies). If the object is not available to receive the operation invocation or the termination, then the migration binders either redirect the operation/ termination to the new location of the object or inform the peer migration binder (associatedwith the interacting object) that the object is “unknown” in the node (and optionally name the relocator to contact). The former option is unattractive as it results in multiple forwarding chains in a highly mobile environment. It is costly to store forwarding chains and the purging (garbage collection) of stale chains requires complex distributed algorithms. The latter option is preferred as shown in the discussion on relocation. When the migration binder receives an “object-unknown” response it contacts the relocator of the object (with the old interface refer-ence as an argument) and obtains its current location information. The undelivered operation orProgrammable Policy.2.Relocator: Object migration results in an object being disassociated from a node. The relocator has a directory of locations for interfaces that have had their locations changed as a result of migration, deactivation, reactivation, replication, etc. In a highly mobile environment, it is pos-sible that each object (or its interface) has an associated relocator. An engineering interface identifier must, therefore, contain the addressing information about the relocator for the inter-face in addition to the addressing information for the interface itself [21]. A relocator need notbe on the same node as that of the mobile object. Relocators are replicated for reliability. The relocator is an example of the support function.3.Protocol Object: Protocol objects represent the functionality necessary to achieve end-to-end communication between interacting objects.B.Domain-Specific Migration Policy Support Functions: Object mobility is controlled by the may be specific to a domain and hence require domain-specific support mechanisms in the engineering model. One or more policies can be achieved by a single engineering mechanism (object). Conversely a single policy can be achieved by a combination of mechanisms. Each of these mechanism has an interface with the policy administrator object. The figure 3 shows a set of domain-specific mechanisms corresponding to some of the migration schema policies that may be specified by the programmer.4.Traffic Monitor: It monitors the messages exchanged between the mobile objects through the migration binders via T interface (figure 3). If the messages exceed the maximum limit imposed by the policy administrator, the traffic monitor advises the migration manager to ini-tiate object migration. Either the client or the server or both will be migrated depending on their mobility characteristics and migration semantics (specified in the migration schema).tency Monitor: It monitors the response delay of the operation invocations issued by the cli-ent object through the migration binders via L interface (figure 3). If the latency exceeds the maximum limit imposed by the policy administrator, the latency monitor advises the migration manager to initiate object migration. Either the client or the server or both will be migrated depending on their mobility characteristics and migration semantics (specified in the migration schema).6.Performance Monitor: It monitors the availability of processing, storage, and communication resources to the object. If the availability falls below the limit imposed by the policy adminis-trator, the performance monitor advises the migration manager to initiate object migration. Either the client or the server or both will be migrated depending on their mobility characteris-tics and migration semantics (specified in the migration schema).7.Policy Administrator: The policy administrator acts on behalf of the mobile object in order to achieve (application) requirement-driven object mobility and migration-transparency. The pol-icy administrator contains the policies specified in the transparency schemas. The policy administrator interfaces with domain-specific policy-support functions as shown in figure 3. The policy administrator interfaces with the migration binder to assert interaction policies (such as if the number of object migrations exceeds a threshold, inform the attached object). There is one policy administrator per mobile object in the node. When the object migrates the policy administrator also migrates with it.C.Mobility Management: The mobility management functions takes the decision on object migra-8.Migration Manager: The migration manager takes the decision on object migration on receiv-ing the requests from the policy support objects. If the migration manager (based upon the pol-icies) decides that the remote object should be migrated, then it sends a request to the migration manager of the remote object. If it decides that the local object need to be migrated then it con-tacts the object management functions such as the concurrency manager and the transaction manager to find out:1. if the current operation is completely executed at the local node.2. that the concurrency control policies of the object have been satisfied.3. that the object is not currently involved in a transaction.On receiving a confirmation from the object management functions, the migration manager advises the checkpoint manager to obtain the checkpoint (state) of the object. The state trans-former converts local interface references into remote ones. Finally, the migration manager ini-tiates migration through the protocol object. It is the responsibility of the migration manager to inform the migration binder associated with the object in the source node about the migration of the object. The migration binder puts this information in the relocator associated with the object.Additionally, the migration manager can issue requests to its peer managers tofix a mobile object temporarily at a node (to satisfy some performance policies) and later unfix it.On receiving the checkpoint of an object, the migration manager advises the object cloner to instantiate an object from its checkpoint and to allocate required resources to the cloned object. The migration managers must agree that the required resources are available and will be allo-cated before initiating object migration.D.Object Management: The principles of encapsulation and autonomy of objects means that each agement approach means that management operations can only be requested on the object through its management interface. Being in consensus with the object-oriented paradigm, each object contains all methods (operations) needed for its management. Ultimately, the responsi-bility for managing an object in a distributed system lies with the object itself.Hence the engineering of a mobile object must include the addition of an object management interface (to the object) supporting operations for the checkpointing and deletion of the object. Additionally, the object management interface may include operations to test the execution sta-tus of the object, and the concurrency and the transaction status of the object. The object man-agement interface is used by the checkpoint manager,concurrency manager, and the transaction manager.9.Transaction Manager: The transaction manager informs the migration manager about the transaction status of the object. An object involved in a transaction may not be migrated until the completion of the transaction.10.Concurrency Manager: The concurrency manager informs the migration manager about the concurrency status of the object including the completion of the execution of a previously sub-mitted operation.11.Checkpoint Manager: The checkpoint manager obtains the checkpoint of an object from its object management interface and deletes the object. The checkpoint manager then gives the checkpoint of the object to the state transformer object.12.Object Cloner: The object cloner instantiates the object from its checkpoint information.13.State Transformer: For object migration, it is necessary to convert local interface references to remote ones, transmit the state of the object in a packed form as a message, unpack the contents of the received message into the instance variables of the object, associate the necessary opera-tions of the object with this set of variables, and update state bindings. These functions are “programming language specific” and are performed by language-specific transformers.With the exception of the policy administrator all other object in figure 3 are one per node. The system designers may choose alternative options to improve performance.10.0 Group Transparency-Support Machine:Engineering Framework for the support of GroupTransparencyIn this section we identify the engineering mechanisms (objects) and the configuration of these objects required for the construction of“policy-driven group-transparency support。