Prototype de négociation de la confiance : Architecture
Chapitre 8 – Prototype de négociation de la confiance
Dans ce chapitre, nous présentons l’implémentation de notre prototype de bibliothèque de négociation de la confiance. Il s’agit d’un prototype qui implémente le scénario d’application pour les transactions de e-commerce.
Le modèle de la négociation de ce prototype a été présenté au chapitre 6 et se compose de plusieurs éléments : l’historique, la politique de confiance et la vérification de la conformité de cette politique. Nous avons choisi de réaliser ce prototype sous la forme d’un module de négociation de manière à ce qu’il puisse être facilement intégré à différentes applications.
Dans un premier temps, nous allons présenter l’architecture générale du prototype, puis nous présenterons les détails de l’implémentation de chaque module.
Le prototype est implémenté en langage Java. Dans le cadre du développement de ce prototype, nous utilisons certains packages et certaines classes proposés par K. Krukow [58] avec son application JavaHBAC1 .
8.1 Architecture
La négociation entre deux entités est réalisée sous la forme d’un protocole mis en œuvre par le module intégré à chaque l’entité. Le prototype est construit pour implémenter le scénario de négociation entre les deux entités. Il utilise quelques éléments (classes, une partie du schéma XML) issus de l’application JavaHBAC [58].
Le prototype est implémenté en Java. Chaque partie participant à la négociation, le client ou le vendeur, est représentée par une application. La communication entre deux parties (les deux applications) est assurée par le protocole de négociation. L’architecture commune à chaque application est présentée figure 8.1. Elle est constituée des composants suivants :
-Policy : la spécification de la politique de chaque participant est stockée sous la forme d’un fichier XML. Ce formalisme nous permet de représenter et de manipuler efficacement les politiques de confiance (PP-LTL). Ce fichier de politique est chargé et traduit dans la représentation interne au programme à l’aide d’un analyseur syntaxique XML standard lors de l’initialisation du module.
-Negociation Agent : ce module gère la stratégie de l’acteur associé à l’application.
Il s’agit de classes Java qui sont en relation avec les composants suivants : History,
l’application JavaHBAC est un démonstrateur de son système de réputation qui permet de contrôler les droits d’accès à des fichiers disponibles sur une machine.
Fig. 8.1 Architecture de l’application
Risk Manager, Interface & Protocole et Policy Verification.
-Risk Manager : ce module réalise les calculs de risque conncernant la transaction en cours.
-Policy verification : ce module est chargé de vérifier en permanence que la politique de confiance est satisfaite (vérification de la satisfiabilité d’une formule logique PP-LTL sur d’un historique donné). Il doit pouvoir accéder à l’historique et à la politique de l’acteur.
-Interface & Protocole : ce composant assure deux fonctions — l’échange d’informations entre les deux parties et l’interface interactive avec l’application. L’interface permet à l’utilisateur d’interagir avec le module lorsque lui seul est à même de prendre une décision, et elle permet aussi d’afficher des informations ou des explications sur la transaction en cours. Les messages échangés par les deux parties sont pré-définis et constituent le protocole de communication.
La description de l’architecture de l’application nous a donné une vue globale du prototype. Le développement de ces composants et leur fonctionnement est détaillé dans les sections suivantes.
