Informatiques et Télécommunications

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

Continuer la lecture

7.3 Scénario d’application

Dans cette section, nous présentons le calcul du risque utilisant le modèle présenté pour une transaction de commerce électronique. Le scénario de l’application est celui que nous avons utilisé au chapitre 6. Il s’agit d’une transaction de commerce électronique; la transaction est paramétrée par le coût de la transaction (la somme totale engagée) et l’historique des entités participant à la transaction.

Dans cet exemple de transaction, la négociation est réalisée entre le client A et le vendeur B. Chaque partie utilise le risque comme paramètre de la transaction. Pour chaque partie, nous identifions d’abord le risque potentiel, puis nous en calculons la valeur en utilisant le modèle que nous venons de présenter. Notons que nous réutilisons la structure d’événements définie dans l’exemple d’application du chapitre 6.

7.3.1 Politique du tiers de paiement

Le client et le vendeur impliqués dans une transaction peut utiliser le service d’un tiers de paiement pour gérer le paiement. Nous supposons que le tiers de paiement T T P utilise pour sa politique par les contraintes suivantes :

-Le client peut déposer un montant pour un paiement d’une transaction, la commission dans ce cas est de 5% du montant de la transaction. Par contre, quand il a déposé le montant pour la transaction, et qu’il veut le récupérer, il doit payer une commission de 20% du montant.

-Le vendeur, pour récupérer le paiement d’une transaction, doit également payer une commission de

Continuer la lecture

7.2 Modèle du risque

Nous appliquons les principes du risque tel que défini en économie, le risque lié à une transaction est la perte potentielle qu’elle peut provoquer. Lorsqu’une entité prend une décision concernant une action, il en découle un ensemble de conséquences potentielles et à chacune de ces conséquences peut être associée une probabilité d’occurence.

Notre modèle du risque est une interprétation du modèle théorique de calcul quantitatif du risque basé sur la notion de coût/bénéfice, que appliquons dans le domaine des applications de e-commerce.

Dans notre cas, le bénéfice (ou le coût) d’une transaction est la valeur de gain (ou de perte) de la transaction évaluée par chacune des parties engagée dans la transaction. Le bénéfice indique une transaction réussie, par contre le coût indique une transaction échouée. La transaction peut être réussie pour l’une des parties, mais échouée pour l’autre.

Nous nous intéressons plutôt à l’aspect d’analyse du coût des conséquences. Dans la pratique, nous trouvons que réaliser une action ou ne pas la réaliser implique toujours un coût, et cela peut expliquer le coût lié à des choix différents. Nous donnons un exemple pour concrétiser :

Nous nous intéressons à une action d’adjudication sur un appel d’offre de projet. Si nous ne participons pas, nous perdons le bénéfice que nous pouvons faire dans cette opération. Si nous participons, nous avons des coûts (coût financier, temps de préparation d’une ébauche de

Continuer la lecture

Politique de confiance dans une transaction de e-commerce

6.5.3 Observations et structures d’événements

Nous proposons dans cette section un modèle d’observation de la transaction. Celuici est décrit par la structure d’événements définie par chacune des entités, le vendeur et l’acheteur. Nous précisons que le modèle d’observation de chaque entité lui est propre et dépend de la structure d’événements qu’il a choisie. Nous présentons la structure d’événements de l’acheteur dans la figure 6.7 et celle du vendeur figure 6.8.

Fig. 6.7 Acheteur : Structure d’événements

La structure d’événements de chaque entité décrit les relations de conflit et de causalité que doivent respecter les événements. Les points suivants présentent des explications détaillées sur chacun des événements de la structure d’événements de l’acheteur et du vendeur.

Fig. 6.8 Vendeur : Structure d’événements

Acheteur : structure d’événements

La spécification des événements de la structure d’événements de l’acheteur est donnée ci-dessous.

• -object_request : événement local indiquant que l’acheteur passe une commande à un vendeur.
• -object_received : indique qu’il reçoit un message contenant une confirmation du paiement et un plan d’envoi du produit de la part du vendeur.
• -obj_time_out : indique qu’il n’a reçu aucune information du vendeur après avoir passé sa commande.
• -high_risk, average_risk, low_risk : événements locaux qui

  Continuer la lecture

Dans cette section, nous allons illustrer le fonctionnement de notre mécanisme de négociation avec un exemple de transaction dans le domaine du commerce électronique. Nous détaillons d’abord le scénario puis nous en présentons le déroulement selon les principes de notre système de négociation.

6.5.1 Transaction de e-commerce en ligne

Nous imaginons un système de commerce en ligne qui permette à des vendeurs et des clients de mener à bien des transactions. Nous allons étudier le cas des transactions où un client veut acheter un produit à un marchand. Les deux parties veulent pouvoir réaliser la transaction en toute confiance : le client veut être sûr qu’il recevra bien le produit s’il l’a payé et le vendeur veut être sûr d’être payé s’il livre le produit au client.

L’acheteur et le vendeur ont besoin de négocier pour réaliser une transaction de ce type. La négociation se déroule sous la forme d’une suite d’échanges de messages entre les deux parties tout en respectant la politique de confiance de chacun. Dans le cas général, nous pourrions observer la séquence d’échanges suivante :

• L’acheteur envoie une commande pour un produit au vendeur pour débuter la transaction.
• Le vendeur analyse la commande (disponibilité du produit, profil de l’acheteur . . . ). Si les conditions de la commande sont valides, le vendeur envoie une demande de paiement à l’acheteur.
• L’acheteur analyse à son tour cette réponse pour décider s’il continue la

  Continuer la lecture

6.4 Module de négociation de la confiance

Dans cette section, nous présentons le modèle de notre mécanisme de négociation. Il se compose de deux parties distinctes : la gestion de la confiance et la gestion de la négociation.

La gestion de la confiance ayant été présentée en détail dans le chapitre 5, nous expliquons comment nous modélisons les activités de chaque entité à l’aide d’une structure d’événements, comment nous définissons leur politique et nous proposons une stratégie pour mener à bien les négociations.

6.4.1 Structure d’événements

Comme nous l’avons présenté au chapitre 5, nous utilisons une structure d’événements et une politique pour modéliser le comportement des différentes entités du système.

Aucun des participants ne connait la politique de l’autre; une politique de confiance est quelque chose de personnel, on ne la partage pas, pour éviter que son correspondant n’en tire un profit concurrentiel par exemple (si mon correspondant connait le montant maximum que je suis prêt à dépenser pour acquérir un bien, c’est cette somme qu’il me réclamera même si elle est supérieure au montant qu’il comptait me demander).

Chaque entité doit définir sa propre structure d’événements. Un soin particulier doit être pris lors de la définition des relations de conflit et de causalité. Ces relations sont à la base du comportement de l’entité et doivent lui permettre des interactions riches avec ses correspondants.

On distingue deux types d’événements dans

Continuer la lecture

Dans notre approche, le protocole de négociation est une séquence d’actions des deux parties. Il est constitué d’une suite d’échanges de messages. Ces messages sont observés et traduits par chacune des parties sous la forme d’événements, et ils doivent en respecter la structure. Autrement dit, l’ordre dans lequel les messages sont échangés entre les deux parties est induit par leurs structures d’événements.

6.3.1 Messages

Pour les messages échangés dans le protocole, nous nous intéressons à leurs deux aspects : leur type et leur structure.

Types de messages

Selon la nature des informations à échanger, nous pouvons classer les messages en quatre catégories élémentaires :

-Proposition : ce sont les messages qui indiquent une proposition d’échange, une demande de service. Quand une partie envoie une message de proposition, elle s’attend à recevoir un message de type proposition ou de type Rejet de son partenaire.

-Négociation : ce message demande au partenaire de modifier des données échangées à l’étape précédente ou de faire une autre proposition. Lorsque l’on reçoit ce type de message, si l’on est d’accord ou si c’est possible, on répond par une nouvelle proposition, sinon un message de type Rejet est envoyé.

-Rejet : les messages de ce type indiquent que l’on n’accepte pas la proposition ou la demande de négociation. Lorsqu’elle reçoit ce message, l’entité met fin de la transaction.

-Conclusion : Le message indique

Continuer la lecture