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 la fin de la transaction. En recevant un message du type Proposition ou du type Rejet, on peut mettre fin à la négociation en utilisant ce message. La négociation est une réussite si son objectif a été atteint, un échec sinon.
Nous distinguons ces types de message pour faciliter les échanges entre les deux entités les modélisant par la structure d’événements. Les messages sont constitués à partir des événements observés. Nous présentons dans la section suivante la procédure de transformation événement → message et le format standard des différents types de message.
Structure du message
Le format des messages peut être adapté à chaque application, mais il est préférable d’utiliser un format standard. Certains messages peuvent contenir des données sensibles et il est important de les prendre en compte lors de leur définition. Les messages doivent contenir les informations suivantes : l’identifiant de l’entité partenaire, le type du message et les données échangées.
Un message est constitué des éléments suivants :
structure message{ Identifiant: entite_msg; Type: type_msg;
Data: donnee_msg;
}
Le champ entite_msg identifie l’entité partenaire de la négociation. Le champ type_msg décrit le type de message, et il peut être d’un des types : Proposition, Négociation, Rejet ou Conclusion. Le champ donnee_msg décrit des données échangées.
6.3.2 Échanges
Le déroulement complet du protocole est conservé sous la forme d’un ensemble d’événements dans une session de l’historique. Ce déroulement est spécifié par la suite des échanges entre les deux parties. Supposons que deux entités A et B décident de mener à bien une transaction, ils échangent des propositions sous la forme de messages
Fig. 6.3 Un scénario de négociation
et ils peuvent négocier sur leur proposition. Le processus de négociation se déroule de la manière suivante :
-Le protocole démarre par une proposition de A à B en vue d’obtenir un service ou une ressource : mapro1.
-B analyse la demande de A et lui répond par une proposition d’échange mbpro1.
Cette proposition peut être une demande d’informations complémentaires (une qualification nécessaire pour avoir le droit d’accéder au service par exemple). Si B n’accepte pas cette proposition, il envoie à A un message de conclusion ou de négociation. Si c’est un message de conclusion, cela amène à la fin de la négociation.
-A reçoit à son tour un message de B, qui peut être une conclusion, une proposition ou une négociation, et l’analyse. Si c’est une proposition, A peut l’accepter, la refuser (avec le message de Conclusion ), faire une autre proposition (avec la Proposition ) ou faire une re-négociation (message de Négociation). Si c’est une re-négociation, A peut la rejeter (avec le message de Rejet ) ou effectuer une autre proposition. Sinon, le message Conclusion signifie la fin de la négociation.
-Le processus d’échange des messages continue de cette manière jusqu’au moment où les deux parties atteignent la fin de l’échange, indiquée par le message Conclusion.
Tous les messages reçus sont analysés par l’Event Analyzer et interprétés sous la forme d’événements. Tous les messages envoyés sont constitués des événements fournis par le module Strategy Negotiation, et convertis en messages par l’Event Analyzer.
Dans le scénario illustré par la figure 6.3, l’entité A envoie une proposition initiale à B (mapro1); B lui répond par une contre-proposition (mbpro1). A envoie alors à B une demande de négociation (maneg ); Puis B fait une proposition alternative (mbpro2).
Fig. 6.4 Automate de négociation
Finalement A accepte cette proposition et met fin à la négociation par le message de conclusion maf in .
Le schéma 6.4 présente les différentes étapes possibles lors de la négociation. Chaque étape est représentée par un état de l’automate. Chaque type d’échange entre les entités est spécifié par un changement d’état dans l’automate, la flèche indiquant si le message est envoyé (mess →) ou reçu (→ mess).
Dans cette figure, l’état 1 est l’état initial de l’entité. Quand il reçoit une pro-
position, l’automate passe à l’état 2 . Ensuite, il peut passer aux états 3 , 4 ou 5 en fonction de l’interprétation qu’il fait de la proposition reçue à l’étape précédente : mettre fin à la négociation (objectif atteint ou non), faire une contre-proposition ou faire une demande de re-négociation. En passant à l’état 6 , l’entité indique qu’elle a atteint la fin de la transaction. L’état 7 indique que l’entité fait face à un refus de son partenaire (message reçu rejet ). L’état 8 indique que l’entité envoie une conclusion après avoir refusé la négociation.
6.3.3 Fin de l’échange
En utilisant la structure d’événements pour modéliser notre système de négociation, nous voyons qu’une exécution du protocole est équivalente à une session de l’historique. Une session de l’historique qui représente l’exécution complète (lorsque la négociation est terminée) du protocole est une configuration maximale telle que nous l’avons présentée dans la section 4.5.2
Dans le processus de négociation, quand une partie se trouve dans une configuration maximale, elle en déduit qu’elle a atteint la fin des échanges du protocole, que le but de la négociation soit atteint ou pas.
En terme de messages échangés par le protocole, lorsqu’il y a envoi d’un message de type conclusion, cela indique la fin de la négociation.
Quand l’entité trouve un événement qui lui permet de compléter sa session sous la forme d’une configuration maximale cela peut amener la fin de la négociation :
-Si cet événement est l’interprétation d’un message reçu (le message de son partenaire), l’entité peut envoyer soit une négociation, soit une conclusion à son partenaire. Si le message est une négociation, cela signifie que l’entité veut encore re-négocier; sinon la fin de négociation est conclue avec le message de type conclusion.
-Si cet événement implique une réaction, l’entité peut envoyer soit une proposition, soit une conclusion à son partenaire. Si le message est une proposition, cela signifie que son partenaire peut encore re-négocier; sinon il met fin à la négociation avec un message de type conclusion.
6.3.4 Transformation des messages-événements
Le protocole de négociation est lié au module de stratégie de négociation par l’ Event Analyzer. Le protocole travaille avec des messages, en revanche la stratégie de négociation traite des événements. Il faut donc transformer les événements en messages et les messages en événement. Cette fonctionnalité est prise en charge par le module event analyzer.
Si l’on s’intéresse à nouveau à l’exemple d’une transaction concernant un achat en ligne, nous voyons que lorsque la stratégie de négociation sélectionne l’événement paiement, cela se traduit par le fait que le client effectue le paiement au marchand.
L’Event Analyzer envoie au marchand un message contenant toutes les informations nécessaires pour valider le paiement (numéro de carte bancaire et montant payé). Nous venons de voir que le mécanisme de négociation permet de re-négocier une action en envoyant un message de type négociation à son partenaire. En conséquence il est nécessaire d’en différencier les contenus.
Un événement peut être transformé en messages de type différents, selon son utilisation dans le processus de négociation. Considérons l’exemple suivant (ref : la structure d’événement du client dans la section 6.5) : lorsque l’événement pay_direct est activé pour la première fois, l’Event Analyzer l’interprète comme une proposition de paiement, et un message de type proposition contenant l’ensemble des informations nécessaires est construit et envoyé.
Par contre, lorsque cet événement apparait une deuxième fois dans le processus, l’Event Analyzer, sachant que l’on est dans une phase de re-négociation, l’interprète comme un message de type négociation qui ne contient que les informations liées au comportement effectué dans l’étape précédente (qui rappellent les caractéristiques du paiement précédemment effectué, par exemple en indiquant l’identifiant de la transaction bancaire).
