Les objets OpenMASK

Dans sa version distribuée, OpenMASK a deux notions d'objets : les réfé-rentiels et les miroirs. Les objets référéfé-rentiels et les objets miroirs ont de nom-breuses fonctionnalités en commun. Ils conservent cependant quelques diérences de comportement. Le modèle référentiel/miroir est complètement transparent à l'utilisateur. En eet, l'objet simulé associé à un référentiel est presque identique à celui associé à un miroir sauf qu'il peut être initialisé diéremment. Dans ce dernier cas l'utilisateur peut attacher à un référentiel un comportement qui lui est propre. Ce comportement est déni pendant la phase d'initialisation de l'ob-jet référentiel. Par contre, ce qui fait la diérence principale entre les deux, c'est le gestionnaire d'objet en question qui leur est couplé. Deux types de gestion-naires d'objets existent dans OpenMASK : le gestionnaire d'objet référentiel et le gestionnaire d'objet miroir. C'est le gestionnaire associé à l'objet qui contrôle sa vraie nature. Ainsi, nous pouvons dire qu'un référentiel est un mariage entre un objet simulé et un gestionnaire de référentiel. Nous pouvons aussi dénir un miroir de la même manière, mariage d'un objet simulé et d'un gestionnaire de miroir (Fig. 6.6).

114 Migration

Objet simulé _{Objet simulé} Gestionnaire de référentiel Gestionnaire de miroir

Objet référentiel Objet miroir

Fig.6.6  Référentiel et miroir

6.4.1.1 L'objet référentiel

Dans une simulation distribuée sur plusieurs sites, un objet simulé est assigné à un processus qui est à son tour assigné à un site. Ainsi à l'intérieur de chaque processus se trouvent un certain nombre d'objets qui y sont assignés et que nous appelons des référentiels. Le référentiel exécute le calcul interne de l'objet qui est responsable de son évolution et de son comportement. Le référentiel répond aux requêtes d'abonnement et désabonnement en provenance de ses miroirs et traite aussi les diérents événements reçus par ces derniers. Nous pouvons dire qu'un référentiel est un objet "maître" qui possède l'unité de calcul, contrairement aux miroirs qui sont des objets sans "intelligence" (ils ne réalisent aucun calcul) qui ne font que reéter l'apparence externe de leurs référentiels.

6.4.1.2 L'objet miroir

Un objet miroir possède la même interface que son référentiel distant et se situe en local. La fonction d'un objet miroir est d'empaqueter les paramètres et les événements reçus pour envoi au référentiel distant qui ouvre et traite ces messages. Un miroir est créé localement dès que son référentiel est utilisé d'une manière ou d'une autre sur n'importe quel processus autre que celui qui détient le référentiel. Un miroir n'exécute aucun calcul interne. En eet, un miroir peut être vu comme une jonction entre l'objet référentiel distant et les objets locaux, permettant ainsi leurs interactions.

À la création d'un miroir sur un site donné, un canal de communication par ots de données est créé par le noyau OpenMASK entre le site détenant le miroir et celui du référentiel. Il demande ensuite l'abonnement pour pouvoir lire les attributs de sorties de son référentiel et les tenir à la disposition des référentiels situés sur son processus.

Mise en ÷uvre de la migration d'objets 115

6.4.2 Métamorphose

Nous avons choisi de réaliser un mécanisme de migration d'objets par chan-gement d'état. Ceci veut dire qu'un objet donné doit être capable de se méta-morphoser pour changer de statut. Ainsi un miroir peut devenir référentiel et un référentiel peut devenir miroir.

Dans le contexte particulier d'OpenMASK, la réalisation de la migration par changement d'état peut être envisagée selon deux méthodes diérentes.

6.4.2.1 Métamorphose par mutation interne

La première méthode consiste à re-concevoir la structure interne des référen-tiels et des miroirs de manière à ce qu'ils implémentent exactement la même interface. Ceci veut dire qu'un objet référentiel contiendra exactement les mêmes fonctionnalités qu'un objet miroir ou en d'autres termes il est référentiel et miroir à la fois. Ces fonctionnalités seront activées ou désactivées selon le comportement voulu de l'objet (référentiel ou miroir). Du côté de l'objet miroir, ce sera exacte-ment la même chose (Fig. 6.7).

L'avantage de cette méthode est la mutation simple d'un objet référentiel vers un objet miroir. Pour une transformation d'un référentiel en un miroir par exemple, il sut d'activer les méthodes propres au comportement d'un miroir au sein de l'objet même et désactiver les méthodes qui dénissent le comportement d'un référentiel. L'inconvénient est la modication importante de la structure interne d'un objet simulé dans OpenMASK. Ceci contredit notre but de réali-ser le mécanisme de migration en utilisant la limite de l'infrastructure existante d'OpenMASK pour ne pas trop changer le noyau ni modier son principe de fonctionnement. Pour cette raison, nous avons décidé d'adopter une deuxième méthode.

6.4.2.2 Métamorphose par changement de nature

La deuxième méthode consiste à ne pas modier le comportement d'un objet référentiel ni d'un objet miroir. Nous allons en fait remplacer le gestionnaire associé à un objet sans détruire l'objet lui même.

L'opération consiste donc à détruire le gestionnaire associé à un objet (ré-férentiel par exemple), re-créer un autre gestionnaire (de miroir), et associer ce nouveau gestionnaire à l'objet sans modier aucun de ses attributs.

Il faut aussi prendre en considération le cas où un utilisateur a décidé d'asso-cier un comportement spécial à son objet référentiel (voir 6.4.1). Dans ce cas nous devons transmettre ce comportement et l'attacher au nouveau référentiel. Pour cela nous avons déni deux méthodes à redénir par l'utilisateur qui souhaite ex-primer des aspects propres à un objet donné. Ces deux méthodes sont emigrate()

116 Migration Objet simulé Objet simulé Objet référentiel Objet miroir Gestionnaire de référentiel Gestionnaire de référentiel Gestionnaire de miroir Gestionnaire de miroir Activé D ésactivé D ésactivé Activé

Fig. 6.7  Métamorphose par mutation interne

et immigrate(). Dans ces méthodes, un utilisateur doit spécier le comportement particulier à faire migrer avec l'objet d'un site à un autre.

Nous avons réalisé l'implémentation de cette méthode au sein du noyau Open-MASK. Les détails du fonctionnement du protocole de migration sont discutés dans la section suivante.