Améliorations – utilisation d'un agent broker

Le temps nécessaire pour créer un contrat n’est pas satisfaisant et des améliorations sont nécessaires. La première que nous avons faite est d’ouvrir une seule connexion pour toute la négociation, et non une pour chaque paire de messages envoyés/reçus. La deuxième a été d’envoyer des messages similaires vers la même destination comme un seul message, et pas comme des messages séparés. Par exemple, l’UA n’envoie plus au début de chaque négociation trois messages cfp différents aux trois CA qui se trouvent sur le même objet. Il met ces trois messages dans un seul qu’il envoie au PA se trouvant sur cet objet. Le PA reçoit le message, le divise en trois et envoie chaque partie à son CA destinataire. La troisième amélioration faite a été de modifier légèrement le protocole de négociation. L’UA envoie seulement un message accept (s’il accepte une proposition) et n’envoie plus des messages reject. Un CA considère implicitement que sa proposition est refusée s’il ne reçoit pas un message accept.

des agents avant de négocier avec eux. Nous voulons diminuer ce temps passé dans la phase de découverte d’agents. Ce n’est malheureusement pas possible puisque cette durée est un des paramètres du port Bluetooth. En plus d’imposer un retard dans la création des contrats, la découverte d’objets/agents consomme la batterie de l’objet portable. Pour résoudre ces problèmes, nous avons décidé de changer l’architecture du système. Pour minimiser le temps de découverte et la consommation de la batterie de l’objet portable, l’UA ne cherche plus des objets dans son voisinage. C’est l’agent proxy qui effectue ce processus de découverte. Nous avons ainsi décidé d’échanger les rôles de serveur et client Bluetooth entre l’agent utilisateur et l’agent proxy. Dans cette configuration, l’agent utilisateur s’enregistre comme un service Bluetooth spécifique sur l’objet portable sur lequel il s’exécute. Quand il veut créer des contrats, il met l’objet dans l’état non-caché, c.-à-d., l’objet peut être découvert par d’autres objets Bluetooth. Il attend ensuite des connexions entrantes d’autres objets. Cependant, l’amélioration la plus significative a été faite dans le processus de négociation qui était l'étape la plus longue de la formation d'un contrat. Ainsi, nous avons décidé de transformer l'agent PA en un broker (Sycara et al., 1997). Un UA délègue le processus de négociation à l’agent broker (BA), qui négocie ensuite pour son compte avec les CA disponibles. L’UA ne demande plus au BA la liste d’agents CA disponibles, mais il lui demande de négocier pour son compte en lui envoyant une offre. Le BA négocie avec les CA exécutés sur le même objet portable ou PC pour créer un contrat. Si la négociation se termine avec succès, le contrat créé est envoyé par le BA à l’UA qui l’exécute.

Le plus grand avantage d’utiliser un agent broker dans notre système est que la négociation des contrats devient plus rapide. Le BA connaît la liste de CA disponibles qui sont en général exécutés sur la même machine. La négociation est alors presque instantanée. Du point de vue de l’agent utilisateur, un contrat est créé en envoyant un seul message et en recevant sa réponse. Un autre avantage est qu’un protocole de négociation plus complexe peut être mis en place. Puisque le BA n’est pas contraint par les ressources limitées d’un objet portable, des protocoles ou des stratégies de négociation plus complexes peuvent être envisagés. En revanche, la délégation du processus de négociation à un tiers présente un désavantage pour l’agent utilisateur. Dans ce cas, l’UA (et son utilisateur) n’a plus de contrôle sur la création des contrats. L’UA doit accepter le contrat créé par le BA à sa place, il n’a aucune possibilité de le refuser. Ceci peut constituer un désavantage parce que l’UA et l’utilisateur doivent faire confiance à l’agent broker. L’utilisateur et son UA cèdent ainsi leur pouvoir de choisir d’accepter des contrats qui sont avantageux, même s’ils ne respectent pas les conditions initiales. Malgré ces désavantages, l’utilisation d’un broker dans notre scénario diminue la durée de la création des contrats. Le tableau ci-dessous montre que la durée totale de création d’un contrat après les améliorations effectuées est de 12-13 secondes :

Tableau 10.2. Durée de création des contrats après toutes les améliorations Phase de création de contrat Durée (sec.)

Découverte d’objets/agents 10 Négociation de contrat 2-3

Un autre avantage prototype amélioré est qu’un UA peut être découvert alors qu’il négocie et/ou exécute un contrat. Si nous considérons que plusieurs BA, exécutés sur plusieurs PC, sont distribués aux alentours comme des bornes d’accès, ils peuvent chercher continuellement les objets portables. Quand l’utilisateur se déplace, son UA négocie et exécute des contrats, tout en étant découvert par plusieurs BA. C’est à dire que chaque fois qu’un UA veut créer un contrat, il peut le faire parce qu’il a déjà été découvert par au moins un BA. Idéalement, dans cette situation la phase de découverte peut être ignorée et un contrat peut être créé en 2-3 secondes !

10.2.3. Synthèse

Nous avons implémenté le scénario ADOMO présenté dans ce chapitre et nous l'avons déployé sur des objets portables tels que un PDA et un téléphone portable, comme montrer dans la Figure 10.3 ci- dessous. Pour nous assurer que les agents auront le temps nécessaire de négocier des contrats avant que les utilisateurs se déplacent hors de portée, nous avons du envisager plusieurs solutions. Notamment, les agents utilisateurs peuvent négocier des contrats directement avec des agents commerciaux ou ils peuvent déléguer la tâche de négociation à un agent broker qui négociera pour eux. Dans le premier cas un agent utilisateur garde le contrôle sur le processus de négociation, mais il court le risque de ne pas pouvoir finir la négociation si elle prend trop de temps et son utilisateur se déplace hors de la porté de l'objet portable. Dans le deuxième cas, l'agent utilisateur doit faire confiance à l'agent broker – la négociation est très rapide et donc il a plus de chances de former un contrat, mais il ne peut pas être sûr des termes de ce contrat.

Figure 10.3. ADOMO sur un PDA et un téléphone portable

Dans la section suivante nous décrivons ce choix entre deux possibilités sous la forme d'une structure organisationnelle dans laquelle un agent utilisateur à le choix entre deux rôles et nous décrivons la représentation des contraintes existante à l'aide de notre modèle et le raisonnement a priori institutionnel utilisé pour faire le choix.