• Aucun résultat trouvé

Gestion des objets

Chapitre 2 : Les syst•mes distribuŽs ˆ objets 11

2.4 Gestion des objets

Les objets sont les entitŽs fondamentales des SDO. Par consŽquent, leur gestion est une fonction essentielle de ces syst•mes. Dans cette partie, nous nous intŽressons aux prin-cipales techniques qui permettent :

¥ de synchroniser les exŽcutions concurrentes dÕopŽrations au sein de lÕobjet, ¥ et de protŽger les objets contre des acc•s non autorisŽs.

2.4.1 Synchronisation

Une autre caractŽristique importante des SDO est de garantir que les activitŽs de mul-tiples actions qui impliquent le m•me objet, ne rentrent pas en conflit ou nÕinterf•rent pas les unes avec les autres. Une action ne devrait pas •tre autorisŽe ˆ observer ou mo-difier lÕŽtat dÕun objet qui a ŽtŽ partiellement modifiŽ par une autre action qui nÕa pas encore ŽtŽ validŽe. Ainsi pour garantir la sŽrialisation et pour protŽger lÕintŽgritŽ des Žtats des objets, un mŽcanisme de synchronisation est nŽcessaire. On peut grosso modo distinguer deux grandes catŽgories :

¥ Les mŽcanismes de synchronisation pessimistes. Dans ce cas le syst•me ou lÕutili-sateur prend les mesures nŽcessaires pour Žviter les conflits (en suspendant tem-porairement les actions qui vont interfŽrer avec lÕaction en cours).

Les SDO suivants supportent un mŽcanisme pessimiste : AmÏba (lorsquÕune ac-tion affecte plusieurs objets), Argus (qui utilise des simples verrous en lecture/ Žcriture. De plus, une action et ses sous actions ne peuvent modifier simultanŽ-ment un m•me objet), Clouds (deux niveaux de mŽcanismes sont fournis : un mŽ-canisme automatique (rŽalisŽ par le syst•me) qui utilise des verrous en lec-ture/Žcriture, et un mŽcanisme personnalisable qui permet ˆ lÕutilisateur de crŽer des r•gles spŽcifiques de synchronisation en employant des sŽmaphores ou des verrous. Le mŽcanisme personnalisable a lÕavantage de pouvoir augmenter le de-grŽ de parallŽlisme des acc•s. En revanche, la sŽrialisation des acc•s ne peut plus •tre absolument garantie par le syst•me [cas dÕune erreur de programmation par exemple]), COOL (comme dans Chorus, toutes les invocations qui sont faites par un processus sont dŽposŽes dans une file dÕattente, et que ces requ•tes ne seront traitŽes quÕapr•s la terminaison de lÕopŽration en cours, nous en dŽduisons que chaque objet ne peut rŽaliser quÕune seule invocation ˆ la fois), Eden (utilisation de moniteurs au niveau du langage), Emerald (moniteurs), Guide (la sŽrialisation des acc•s aux mŽthodes des objets se fait gr‰ce ˆ des clauses de synchronisation attachŽes ˆ chaque mŽthode et qui contiennent des variables de lÕobjet, des para-m•tres de la mŽthode et des compteurs de synchronisation, Cf. Chapitre 4 sur la synchronisation des objets pour plus dÕinformations), PEACE (sŽmaphores), et

SOS (verrous en lecture/Žcriture).

¥ Les mŽcanismes de synchronisation optimistes. Comme un objet ne prend aucune prŽcaution pour prŽvenir les conflits, avant de valider une action, il faut sÕassurer que les opŽrations sur les donnŽes en cours ne vont pas entrer en conflit avec des modifications dŽjˆ effectuŽes par une autre action (qui a ŽtŽ prŽcŽdemment vali-dŽe). Par exemple, si des donnŽes dŽtenues sont obsol•tes, alors toute mise ˆ jour avec ces donnŽes risque dÕ•tre incorrecte. En consŽquence, cette action doit •tre avortŽe. Pour rŽduire les conflits potentiels, les objets peuvent •tre reprŽsentŽs par un ensemble de pages ou dÕobjets dÕun grain infŽrieur permettant ainsi une modi-fication indŽpendante. Ceci permet un maximum de concurrence.

En plus du mŽcanisme pessimiste dŽjˆ citŽ, AmÏba supporte aussi un mŽcanisme optimiste lorsquÕun seul objet est pris en compte.

2.4.2 Protection

Fournir un mŽcanisme de protection sur les objets afin de garantir que seuls les utilisa-teurs autorisŽs pourront les invoquer est une nŽcessitŽ. Ce mŽcanisme peut •tre fourni soit par le syst•me soit par lÕutilisateur.

Un mŽcanisme courant de protection est celui basŽ sur des capacitŽs. Une capacitŽ est une clŽ, souvent cryptŽe (pour emp•cher les contrefa•ons), qui contient deux champs : un nom qui identifie un objet et des droits dÕacc•s. Chaque capacitŽ dŽsigne un seul ob-jet. Cependant un objet peut avoir plusieurs capacitŽs (ceci permet ainsi des variations au niveau des droits dÕacc•s de lÕobjets). Pour pourvoir accŽder ˆ un objet, il faut dŽte-nir au moins une capacitŽ de cet objet, et cette capacitŽ est passŽe en param•tre de toute requ•te. La vŽrification, la gestion et la maintenance des capacitŽs peut •tre la respon-sabilitŽ soit du syst•me, soit des objets.

Un autre mŽcanisme est basŽ sur une procŽdure de contr™le. Avec cette approche, chaque objet dispose dÕune procŽdure spŽciale qui filtre les requ•tes en contr™lant par exemple la liste les utilisateurs autorisŽs ˆ invoquer lÕobjet. Ce mŽcanisme est Žvidem-ment le plus flexible et tr•s difficile ˆ contourner, puisque les informations de protec-tion sont contenues dans lÕobjet lui m•me.

Ces deux mŽcanismes sont souvent combinŽs pour offrir un niveau maximum de pro-tection.

Les SDO suivant utilisent des capacitŽs pour la protection des objets : AmÏba (une plus grande sŽcuritŽ peut encore •tre obtenue en cryptant ces capacitŽs ˆ lÕaide de puces spŽ-cialisŽs insŽrŽes entre chaque processeur et le rŽseau), Clouds, COOL (pour les objets globaux), Eden, PEACE, SOS (pour les mandataires de chaque objet).

Peu de SDO permettent une synchronisation fine des acc•s. LÕunitŽ dÕacc•s est gŽnŽra-lement lÕobjet, ce qui ne permet pas un fort degrŽ de parallŽlisme. Seuls Clouds et sur-tout Guide (sŽrialisation possible au niveau de la mŽthode) permettent une synchronisa-tion personnalisŽe.

LÕutilisation de capacitŽs semble actuellement •tre le mŽcanisme le plus usitŽ pour la protection des acc•s aux objets. Il sÕaccompagne souvent dÕun cryptage des informa-tions sensibles.

De lÕŽtude sur leur gestion, nous pensons que la synchronisation des objets ne doit pas •tre seulement assurŽes par le syst•me, car dans ce cas lÕunitŽ dÕacc•s est lÕobjet, ce qui ne permet pas une synchronisation fine des acc•s (qui permet dÕaugmenter le degrŽ de parallŽlisme). CÕest pourquoi nous avons dŽcidŽ dÕoffrir un mŽcanisme personnalisable basŽ des scripts de synchronisation attachŽs aux mŽthodes des objets. Enfin, un syst•me devant toujours offrir un mŽcanisme de protection, m•me rudimentaire, pour garantir la sŽcuritŽ des objets, nous protŽgerons les objets de ParObj par des capacitŽs (ce choix ayant ŽtŽ imposŽ par le mŽcanisme de protection de PARX qui sÕappuie sur des capaci-tŽs).