these doctorat une architecture de securité

More documents

Recommendations

Info

Chapitre 4. Contexte : ProActive FIG. 4.1 – Du séquentiel au multi-threadé et distribué tel-00239252, version 1 - 5 Feb 2008 lui rajouter, de manière transparente des comportements supplémentaires. On peut citer par exemple : la transparence vis-à-vis de la localisation physique de l’objet ou encore les mécanismes de synchronisation. Du point de vue applicatif, un objet actif est composé d’un objet racine possédant une activité et d’un graphe d’objets passifs (ne possédant pas d’activité). Le type de l’objet actif dépend de l’objet racine. l’ensemble contenant l’objet actif et le graphe d’objets passifs se nomme sous-système. Il est important de noter que le seul point d’entrée dans un objet actif est l’objet racine. La sémantique ne permet pas le partage entre des objets passifs : les seuls objets qui peuvent avoir une référence sur un objet passif d’un objet actif sont les objets appartenant au même objet actif. Un objet passif d’un object actif ne peut avoir de référence sur un objet passif d’un autre objet actif. Par contre, un objet passif peut avoir une référence sur un objet actif. Les diverses références possibles sont présentées sur la figure 4.2. FIG. 4.2 – Compositions d’Objets actifs 4.2.1 Anatomie d’un objet actif L’objet actif est une composition de plusieurs objets évoluant sur deux niveaux différents (figure 4.3). Le premier niveau nommé de base contient l’objet java standard rendu actif et son graphe d’objets passifs. Le second niveau appelé méta-niveau contient tous les objets qui vont rajouter des propriétés non fonctionnelles à l’objet. Ils ont été rajoutés à l’objet quand il a été rendu actif. La partie méta de l’objet actif est en charge d’assurer la transparence des communications, de gérer la file d’attente des appels de méthodes qui vont être exécutés sur l’objet rendu actif. Les objets qui composent la partie méta d’un objet actif sont agencés de manière à séparer le plus distinctement possible les différents mécanismes définissant les divers comportements fonctionnels (migration, communication de groupe) ou non-fonctionnels (sécurité, tolérance aux pannes) d’un objet actif. Ainsi, à chaque service fourni par un objet actif correspond au moins un méta- 50
Section 4.2. Objets Actifs objet. tel-00239252, version 1 - 5 Feb 2008 FIG. 4.3 – Anatomie d’un objet actif À tout objet actif sont associés un Proxy et un Body. Le Body est le point d’entrée d’un objet actif. C’est la seule partie visible et accessible d’un objet actif. Le body sert de chef d’orchestre et gère le comportement de tous les autres méta-objets. L’ensemble Stub-Proxy est ce qu’on peut appeler une référence vers un objet actif. Il permet de masquer la notion de référence locale ou distante. Il sert à relayer les communications provenant d’un objet (actif ou non) vers un objet actif. Le stub est un objet java qui est polymorphiquement compatible avec l’objet rendu actif. Ce polymorphisme est assuré par héritage. Le stub est créé dynamiquement lors de la création d’un objet actif. Il est la représentation locale d’un objet distant. La figure 4.4 présente les divers objets et méta-objets traversés lors d’un appel de méthode d’un objet actif sur un autre. Premièrement, le stub intercepte les appels de méthode vers l’objet actif qu’il représente et réifie l’appel de méthode (1). Réifier un appel de méthode consiste à transformer un élément abstrait (l’appel de méthode) en un objet concret afin de pouvoir le manipuler. Une fois l’appel de méthode réifié, il est envoyé au proxy (2) qui contient tout le code nécessaire pour transférer l’appel de méthode au body de l’objet actif cible. Notamment, le Proxy crée un objet de type Requête qui va encapsuler l’appel de méthode ainsi que d’autres paramètres qui permettent, entre autre chose, de gérer la transmission du résultat de l’appel de méthode s’il y en a un ou encore l’asynchronisme de cet appel. Le Proxy passe la Requête au body de l’objet appelant (2) qui le transmettra à son RequestSender (3). Le RequestSender est le méta-objet en charge de l’expédition de la requête au body. La requête est envoyée au body de l’objet actif distant (4). Quand un body reçoit une requête, il la passe à son RequestReceiver (5). Le RequestReceiver place ensuite la requête (6) dans la queue des requêtes. Le méta-objet Service représente l’activité de l’objet actif. Il contient la thread Java et sert les requêtes en les récupérant dans la queue des requêtes suivant le comportement qui lui a été défini. Si l’exécution d’une méthode renvoie une valeur de retour, il crée la réponse et la passe au méta-objet chargé de l’expédition des valeurs de retour. Symétriquement au RequestSender et au RequestReceiver, il existe des méta-objets qui gèrent l’envoi et la réception des réponses : le ReplySender et le ReplyReceiver. 4.2.2 Création d’un objet actif L’instanciation d’un objet java standard se fait par l’instruction A a = new A (2, "salut" ); Si nous voulons lui ajouter les fonctionnalités que proposent les objets actifs, il suffit seulement de modifier le code responsable de l’instanciation de cet objet. Il existe trois manières d’instancier un objet actif à la place d’un objet java standard. 51
Page 1 and 2:
THÈSE DE DOCTORAT École doctorale
Page 3 and 4:
tel-00239252, version 1 - 5 Feb 200
Page 5 and 6:
Table des matières Remerciements x
Page 7 and 8:
TABLE DES MATIÈRES 6.3.3 Optimisat
Page 9 and 10:
Table des figures tel-00239252, ver
Page 11 and 12:
Liste des tableaux 2.1 Niveau de co
Page 13 and 14: Remerciements Mes remerciements von
Page 15 and 16: Chapitre 1 Introduction tel-0023925
Page 17 and 18: Section 1.1. Problématique et obje
Page 19 and 20: Chapitre 2 Théories et Modèles Ce
Page 21 and 22: Section 2.2. Vulnérabilités des s
Page 23 and 24: Section 2.3. Le contrôle d’accè
Page 25 and 26: Section 2.4. Introduction à la cry
Page 27 and 28: Section 2.4. Introduction à la cry
Page 29 and 30: Section 2.5. Les infrastuctures à
Page 31 and 32: Section 2.6. Les politiques de séc
Page 33 and 34: Section 2.6. Les politiques de séc
Page 35 and 36: Section 2.7. Programmation Réflexi
Page 37 and 38: Section 2.7. Programmation Réflexi
Page 39 and 40: Section 2.8. Sécurisation du code
Page 41 and 42: Section 2.9. Conclusion ce contexte
Page 43 and 44: Chapitre 3 Étude d’intergiciels
Page 45 and 46: Section 3.2. Open Grid Service Arch
Page 47 and 48: Section 3.2. Open Grid Service Arch
Page 49 and 50: Section 3.3. CORBA // recuperation
Page 51 and 52: Section 3.4. Les Entreprise JavaBea
Page 57 and 58: Section 3.5. La plateforme .NET sé
Page 59 and 60: Section 3.5. La plateforme .NET } L
Page 61 and 62: Section 3.6. Bilan Legion Globus CO
Page 63: Chapitre 4 Contexte : ProActive tel
Page 67 and 68: Section 4.3. Sémantique des commun
Page 69 and 70: Section 4.5. Communications de grou
Page 71 and 72: Section 4.5. Communications de grou
Page 73 and 74: Section 4.6. Déploiement des appli
Page 75 and 76: Section 4.6. Déploiement des appli
Page 77 and 78: Section 4.7. Conclusion Le con
Page 79 and 80: Chapitre 5 Une architecture de séc
Page 81 and 82: Section 5.2. Un modèle de sécurit
Page 87 and 88: Section 5.3. Authentification des e
Page 93 and 94: Section 5.4. Politiques de sécurit
Page 95 and 96: Section 5.4. Politiques de sécurit
Page 97 and 98: Section 5.5. Négociation Dynamique
Page 99 and 100: Section 5.5. Négociation Dynamique
Page 101 and 102: Section 5.6. Sécurité induite par
Page 109 and 110: Section 5.7. Propagation dynamique
Page 111 and 112: Section 5.8. Exemple du journal int
Page 113 and 114: Chapitre 6 Implantation dans ProAct
Page 115 and 116:
Section 6.1. Création des entités
Page 117 and 118:
Section 6.2. Interface de programma
Page 119 and 120:
Section 6.3. Migration et sécurit
Page 121 and 122:
Section 6.4. Communications de grou
Page 123 and 124:
Section 6.4. Communications de grou
Page 125 and 126:
Section 6.5. Architecture pair-à-p
Page 127 and 128:
Section 6.5. Architecture pair-à-p
Page 129 and 130:
Section 6.6. Tolérance aux pannes
Page 131 and 132:
Section 6.7. Modèle à composants
Page 133 and 134:
Section 6.7. Modèle à composants
Page 135 and 136:
Section 6.8. Sémantique des commun
Page 137 and 138:
Section 6.9. Conclusion Pour qu’u
Page 139 and 140:
Chapitre 7 Tests et performances 7.
Page 141 and 142:
Section 7.2. Les itérations de Jac
Page 143 and 144:
Section 7.2. Les itérations de Jac
Page 145 and 146:
Chapitre 8 Conclusion Ce chapitre r
Page 147 and 148:
Section 8.2. Perspectives tel-00239
Page 149 and 150:
Section 8.2. Perspectives ouverte ;
Page 151 and 152:
Annexe A Grammaire de la politique
Page 153 and 154:
Bibliographie tel-00239252, version
Page 155 and 156:
BIBLIOGRAPHIE tel-00239252, version
Page 157 and 158:
Page 159 and 160:
show all

these doctorat une architecture de securité

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?