THÈSE DE DOCTORAT de l’Université Paris XII - Val de Marne
présentée par
Sebastian KANZOW pour l’obtention du grade de Docteur en Sciences Spécialité : Informatique
Approche pour l'ordonnancement distribué de workflows dans le contexte d'entreprises virtuelles Une méthodologie basée multi-agents pour la planification et l’exécution de processus distribués
Soutenue publiquement le 13 décembre 2004 devant le Jury composé de Serge HADDAD, Professeur à l’Université Paris-Dauphine
examinateur
Kamel BARKAOUI, Professeur au CNAM de Paris
rapporteur
François BOURDON, Professeur à l’Université de Caen
rapporteur
Pascale MINET, Chercheur habilité à diriger la rechercher à l’INRIA de Rocquencourt
examinateur
Yacine AMIRAT, Professeur à l’Université Paris - Val de Marne
directeur de thèse
Karim DJOUANI, Chercheur habilité à diriger la rechercher à l’Université Paris - Val de Marne co-directeur de thèse
Résumé Les workflows inter-organisationnels sont soumis à des contraintes particulières : leur nature distribuée exclut toute gestion centralisée, pour des raisons de confidentialité et d’échelle. Nous développons une méthodologie multi-agents, pour l’ordonnancement distribué dynamique de tâches assujetties à des contraintes temporelles et de ressources. L’algorithme d’ordonnancement est basé sur un calcul dynamique de la priorité des tâches. La confidentialité est respectée, en limitant les informations échangées à des valeurs probabilistes. L’architecture s’appuie sur la mobilité d’agents chargés de l’exécution des tâches et sur la gestion réactive des ressources, où des perturbations sont absorbées implicitement. Nous définissons le protocole de négociation entre les agents et deux heuristiques pour l’allocation et l’ordonnancement de tâches. Mots-clés : workflow, systèmes multi-agents, ordonnancement dynamique distribué, auto-ordonnancement, entreprise virtuelle
Abstract Inter-organizational workflows are particularly constrained: their distributed nature excludes centralized management, for confidentiality and scalability reasons. We develop a multi-agent methodology for distributed dynamic scheduling of tasks that are subject to temporal and resource constraints, based on a dynamic priority determination. Confidentiality is respected by limiting information exchange to probabilistic values. The proposed architecture relies on mobile agents for task execution and reactive resource management, where perturbations are absorbed implicitly. We define a negotiation protocol between agents and two heuristics for task assignment and scheduling. Keywords: workflow, multi-agent systems, dynamic distributed task scheduling, self-scheduling, virtual enterprise
Table des matières Introduction générale Motivation 2 Contribution 3 Organisation du mémoire
Chapitre I
1
4
Gestion de workflows
5
I.1
Introduction
6
I.2
Définitions
7
I.3
Types de workflow
10
I.3.1
Les workflows de production
11
I.3.2
Les workflows administratifs
11
I.3.3
Les workflows ad hoc ou collaboratifs
12
I.4 I.4.1
Collaboration inter-organisationnelle
13
Concept de l’entreprise virtuelle Cas No. 1 : La collaboration à court terme 14 Cas No. 2 : L’entreprise étendue - Gestion de la chaîne logistique 14 Cas No. 3 : Gestion de développement de produit dans un consortium
13
14
I.4.2
Contraintes spécifiques du workflow dans l’entreprise virtuelle
15
I.4.3
Concepts d’interopérabilité pour workflows inter-organisationnels
16
I.5
Systèmes de workflow centralisés
18
I.6
Systèmes à base de composants communicants
20
I.7
Systèmes à base d’agents
21
I.7.1
Définition d’un système multi-agents
21
I.7.2
Travaux relatifs aux approches agents pour systèmes de workflow
23
ADEPT 25 METEOR2 25 CrossFlow 27 EvE 28 METUFlow29 WONDER 30 DartFlow 31
I.7.3 I.8 Chapitre II
Discussion
32
Conclusion
33
Ordonnancement
34
II.1 Introduction
35
II.2 Généralités
35
II.3 Définitions
38
II.4 Méthodes exactes
40
II.4.1
Le « backtrack »
40
II.4.2
Grid Search
41
II.4.3
Divide-and-Conquer
41
II.4.4
Programmation dynamique
41
II.4.5
Branch-and-Bound
42
II.4.6
Propagation de contraintes
43
II.4.7
Ordonnancement en présence d’incertitudes
43
II.5 Méthodes approchées
44
II.5.1
Recherche de voisinage
44
II.5.2
Recuit simulé
44
II.5.3
Algorithmes génétiques
44
II.5.4
Recherche tabou
45
II.6 Ordonnancement à l’aide de systèmes multi-agents
45
II.6.1
Agents coopérants pour l’exploration de l’espace de recherche
47
II.6.2
Agents élaborant itérativement des solutions partielles
47
II.6.3
Agents négociants
48
II.6.4
Auto-ordonnancement par agents
49
Routage de tâches par collaboration de « guêpes » 49 Système multi-agents pour la planification de transports militaires 50 Agents réactifs coordonnés 50 Résolution Coopérative et distribuée d’un problème d’ordonnancement 51 Ordonnancement par système multi-agents dans le contexte de calcul partagé
II.6.5
Discussion
II.7 Conclusion Chapitre III
Modèles d’organisation et d’architecture d’agents
52
53 54 55
III.1 Introduction
56
III.2 Définition des objectifs
57
III.3 Hypothèses
58
III.4 Modèle comportemental des agents
60
III.4.1
Modèle de l’agent WF
62
III.4.2
Modèle de l’agent de ressources
68
III.4.3
Modèle de l’agent manager
71
III.5 Conclusion Chapitre IV
Modèle de collaboration
75 76
IV.1 Introduction
77
IV.2 Etape 1 : Création d’agents et allocation de tâches
78
IV.3 Etape 2 : Exécution d’une instance de workflow
80
IV.4 Communication entre agents
81
IV.5 Traitement de points de décision dans un schéma workflow
84
IV.6 Cohérence globale et comportement cyclique
85
IV.6.1
Respect de la cohérence globale
85
IV.6.2
Traitement des oscillations
86
IV.7 Exemple d’exécution d’un workflow
87
IV.8 Formulation algorithmique
89
IV.8.1
Définitions
89
IV.8.2
Algorithme d’allocation de tâches aux agents WF
89
Première étape : Déterminer un ordonnancement valide, basé sur l’hypothèse qu’il existe des ressources illimitées 90 Deuxième étape : Partitionner l’ensemble des tâches 90
IV.8.3
Algorithme de calcul des priorités des tâches
93
IV.8.4
Complexité algorithmique
96
Complexité algorithmique des agents WF 97 Complexité algorithmique des agents de ressources 98 Complexité algorithmique du protocole de négociation 98
IV.9 Conclusion Chapitre V
99
Test et validation
100
V.1 Introduction
101
V.2 Présentation du simulateur d’agents
101
V.2.1
Module « Générateur de scénarii »
104
V.2.2
Module « Exécution »
105
La classe CWFAgentApp 106 Les classes CMessageQueue et CStructMessage La classe CAgentThread et ses dérivées 108 Les classes auxiliaires 110
V.2.3
107
Module « Solveur optimal »
111
V.3 Evaluation des performances
113
V.3.1
Allocation de tâches
113
V.3.2
Exécution des instances de workflow : ordonnancement dynamique
115
V.3.3
Mesure de la borne supérieure du nombre de messages
119
V.3.4
Comparaison avec la solution optimale
121
V.4 Conclusion
122
Conclusion générale Résumé 124 Perspectives
Annexe I
123 126
Détails des classes d’agents CAgentManagerThread CResAgentThread CWFAgentThread
I II III III
Annexe II
Le schéma XSD des messages échangés entre agents
VI
Annexe III
Un exemple d’un fichier de scénario
X
Liste des tableaux Tableau 1 : Les trois types d’agents de l’approche proposée
61
Tableau 2 : Messages XML pour la communication entre agents
83
Tableau 3 : Messages pour la synchronisation des négociations
83
Tableau 4 : Liste des méthodes surchargeables pour la personnalisation du comportement d’un agent Tableau 5 : Corrélation de deux ensembles de données résultant de 100 scénarii
109
119
Liste des figures Figure 1 : Phases du management workflow [9]
8
Figure 2 : Exemple de flux de contrôle [12]
10
Figure 3 : Transfert d’instances de workflow [18]
16
Figure 4 : Couplage souple [18]
17
Figure 5 : Approches centralisée (à gauche) et distribuée (à droite)
18
Figure 6: Modèle de référence de la WfMC [4]
19
Figure 7 : Modèle d’interaction de METEOR2 [35]
26
Figure 8 : Coopération entre deux systèmes workflow selon CrossFlow [40]
27
Figure 9 : Communication entre les composants de METUFlow [45]
30
Figure 10 : Architecture de WONDER [42]
31
Figure 11 : Méthodes d’optimisation et d’ordonnancement sous contraintes
37
Figure 12 : Système de routage de tâches par collaboration de « guêpes »
50
Figure 13 : Perception d’un CSP selon le modèle CORA [68]
51
Figure 14 : Réordonnancement en 6 étapes selon la méthode RCDP [69]
52
Figure 15 : Exemple d’une instance de workflow
61
Figure 16 : Architecture d’un agent WF
62
Figure 17 : Influence de la « taille » des agents sur le nombre de communications
64
Figure 18 : Diagramme d’état de l’agent WF
66
Figure 19 : Propagation des probabilités d’exécution des prédécesseurs
67
Figure 20 : Architecture d’un agent de ressources
69
Figure 21 : Diagramme d’état de l’agent de ressources
70
Figure 22 : Mécanisme de réservation pour une ressource
71
Figure 23 : Architecture de l’agent manager
72
Figure 24 : Diagramme d’état de l’agent manager
74
Figure 25 : Validation des contraintes de précédence en fonction de l’état des tâches
86
Figure 26 : Diagramme de collaboration pour l’exécution d’un scénario modèle
88
Figure 27 : Etapes de l’algorithme d’allocation de tâches aux agents WF
92
Figure 28 : Etape 1 - Ordonnancement avec ressources illimitées
92
Figure 29 : Etape 2 - Répartition des tâches en groupes disjoints
93
Figure 30 : Pseudo-code pour la détermination de la priorité d’une tâche
97
Figure 31 : Pseudo-code pour le calcul de la disponibilité d’une ressource
98
Figure 32 : Modules du simulateur
104
Figure 33 : Hiérarchie des classes principales du simulateur d’agents
106
Figure 34 : Affichage de la fenêtre principale après instanciation d’un objet du type CAgentApp
107
Figure 35 : Synoptique du mécanisme de notification d’arrivée de messages
108
Figure 36 : Classes du simulateur d’agents
110
Figure 37 : Simulation d’un scénario
111
Figure 38 : Résultats de l’allocation de tâches pour 100 scénarii aléatoires
114
Figure 39 : Rapport entre le nb. total de contraintes de précédence et le nb. de contraintes de précédence interagents
115
Figure 40 : Influence de la taille de la fenêtre prévisionnelle sur 16 solutions trouvées
116
Figure 41 : Nombre de messages échangés lors de l’exécution de 60 scénarii
117
Figure 42 : Rapport entre les paramètres des scénarii et le nb. de messages
118
Figure 43 : Comparaison de la borne calculée avec le nombre de messages échangés pour une fenêtre prévisionnelle de taille 1
120
Figure 44 : Comparaison de la borne calculée avec le nombre de messages échangés pour une fenêtre prévisionnelle de taille 4
120
Figure 45 : Qualité de l’ordonnancement par rapport à la solution optimale
121
Figure 46 : Structure StructTask pour le stockage des paramètres d’une tâche
IV
Figure 47 : Extrait du code de la fonction handleXMLMessage() de l’agent WF
V
Je dédie ce travail à Annabelle Carole Coffinet.
Remerciements L’ensemble des travaux présentés dans ce mémoire a été effectué au Laboratoire d’Informatique Industrielle et d’Automatique (LIIA) de l’Université Paris 12 Val de Marne. J’adresse mes sincères remerciements à Monsieur Serge HADDAD, Professeur à l’Université ParisDauphine, qui m’a fait l’honneur de présider le jury de thèse. J’exprime ma profonde reconnaissance à Monsieur Kamel BARKAOUI, Professeur au CNAM, Paris, et à Monsieur François BOURDON, Professeur à l’Université de Caen, pour l’intérêt qu’ils ont bien voulu porter à ce travail en acceptant de l’examiner et d’en être rapporteurs. Je remercie également Madame Pascale MINET, chercheur habilité à diriger des recherches à l’INRIA de Rocquencourt, d’avoir accepté d’être examinateur de mon travail. Ma profonde gratitude et mes remerciements les plus sincères vont au directeur de ma thèse, Monsieur Yacine AMIRAT professeur à l’Université Paris-Val de Marne et directeur du LIIA, pour m’avoir accueilli dans son laboratoire, m’avoir accordé son aide sans compter les heures et m’avoir encadré tout au long de ces dernières années. Je tiens aussi à exprimer ma gratitude au co-directeur de mes travaux, Monsieur Karim DJOUANI, Maître de Conférences à l’Université Paris Val de Marne et habilité de diriger des recherches, pour m’avoir donné des bons conseils au bon moment. Leurs expériences de la recherche et leurs encouragements m’ont été très précieux. Je tiens également à remercier l’ensemble des membres du LIIA, qui resteront anonymes dans cette page, mais qui m’ont permis de mener à terme ce travail dans une ambiance chaleureuse.
Introduction générale
Motivation Depuis quelques années, les entreprises sont entrées dans l' ère de la collaboration informatisée et, pour rester compétitives, elles doivent constamment améliorer leur efficacité opérationnelle. L' accessibilité à un volume croissant d' informations et l’intégration de solutions logicielles variées créent de nouvelles exigences par rapport aux outils de gestion de la collaboration, aussi bien au sein de l’entreprise que dans le cadre d’une coopération inter-organisationnelle. Le workflow est un concept permettant de modéliser et de gérer des procédures industrielles ou administratives, impliquant plusieurs acteurs, documents et tâches. Il consiste en des modèles de travail permettant de coordonner les activités de chaque participant et d' assurer leur parfaite interconnexion en s’appuyant sur les systèmes d' informations existants. Au-delà des bénéfices qui peuvent être tirés de la mise en oeuvre d’un système de gestion de processus de travail, la restructuration de l’entreprise en vue de son adaptation à l’informatisation peut améliorer un nombre de points clés de sa performance [3] : •
L’efficacité - L’automatisation des processus dans l’entreprise élimine souvent des tâches non nécessaires.
•
La possibilité de contrôle - Une meilleure gestion des processus est obtenue par des méthodes de collaboration standardisées et donc par la disponibilité de traces pour l’audit.
•
Un meilleur service client - Rendre les processus cohérents apporte un gain de qualité de service.
•
Amélioration des processus de travail - Une vue orientée « flux » apporte une simplification des processus par rapport à une vue centrée sur les rôles. Un système de workflow opérationnel apporte les avantages essentiels suivants :
•
La flexibilité - Un contrôle par logiciel des processus permet leur modification dynamique, lorsque les besoins de l’entreprise changent.
•
L’optimisation - Des solutions optimales, par exemple pour l’organisation des tâches, peuvent être calculées mathématiquement, ce qui permet d’améliorer les performances par rapport aux solutions informelles.
•
La sécurité - Les droits d’accès sont définis à l’avance de manière stricte. Grâce à ces avantages, l’utilisation d’outils informatiques pour la gestion des processus à l’intérieur d’une
entreprise est aujourd’hui largement acceptée, mais son emploi dans le cadre de contextes inter-organisationnelles se heurte encore à un nombre d’obstacles, dont les plus importants sont la difficulté du respect de la confidentialité entre les différents partenaires et le manque de standardisation lors de l’interconnexion des différents processus locaux. Néanmoins, malgré ces difficultés, l’évolution des entreprises va clairement vers un niveau d’intégration informatique de plus en plus élevé, pour tout ce qui concerne les processus inter-organisationnels, tels que la soustraitance, la gestion de la chaîne logistique ou encore la coopération dans le cadre d’une « entreprise virtuelle ». De nombreux travaux de recherche ainsi que certains produits commerciaux tentent actuellement de remédier aux lacunes des systèmes existants. Contribution
Ce mémoire a pour but de proposer une solution algorithmique et méthodologique au problème de l’ordonnancement de tâches dans le contexte de processus inter-organisationnels. Les tâches à ordonnancer sont soumises à des contraintes temporelles, ainsi qu’à des contraintes de ressources. Sa mise en œuvre s’appuie sur le paradigme définissant l’interaction entre les collaborateurs inter-organisationnels comme une coopération dans un système « multi-agents », c’est-à-dire des entités logicielles communicantes. Lors de l’analyse de systèmes existants, nous avons noté l’absence d’approches concluantes pour l’ordonnancement de tâches en présence de la contrainte de confidentialité, telle qu’elle existe dans le domaine de la collaboration entre entreprises autonomes. En réponse à cette lacune, nous développons deux contributions algorithmiques. La première consiste en une métaheuristique, déterminant l’allocation de tâches aux agents logiciels (c’est-à-dire l’attribution de la responsabilité de leur exécution), en optimisant un critère donné : Le critère retenu est la minimisation des interdépendances entre tâches gérées par différents agents. La deuxième contribution concerne la proposition d’une algorithmique pour l’ordonnancement dynamique des tâches préalablement allouées à des agents. Elle s’appuie sur une négociation entre agents gérant des ressources et agents gérant des tâches. Un calcul de priorité, basé sur l’état des tâches précédentes et sur la disponibilité des ressources, définit l’ordre d’exécution de ces tâches. Nous formulons ces calculs, ainsi que le protocole de négociation sous-jacent. Grâce au principe du calcul distribué et dynamique de la détermination des priorités des tâches, d’éventuelles perturbations lors de l’exécution d’un workflow sont absorbées de façon implicite.
Organisation du mémoire Dans le Chapitre I, après avoir introduit quelques définitions de base et les différents types de workflow, nous présentons le contexte industriel de l’application de systèmes informatisés pour la gestion de workflows inter-organisationnels. Nous analysons ensuite les contraintes spécifiques et les exigences qu’implique ce type d’application. Nous exposons les solutions technologiques, en comparant les systèmes centralisés aux solutions distribuées. Finalement, nous énumérons les avantages des approches basées sur le concept « multi-agents » et nous présentons quelques travaux de recherche significatifs dans ce domaine. Le Chapitre II traite de la problématique de l’ordonnancement de tâches. Ainsi, nous présentons un bref aperçu des méthodologies d’ordonnancement, après avoir défini la terminologie que nous avons adoptée. Nous nous intéressons d’abord aux méthodes exactes, puis aux méthodes approchées. Ce chapitre se termine par une discussion sur l’application des systèmes multi-agents pour l’ordonnancement distribué et sur les systèmes d’autoordonnancement Dans le Chapitre III, nous développons une solution répondant à la problématique de l’ordonnancement distribué de tâches dans un contexte inter-organisationnel. Cette solution est basée sur le paradigme multi-agents, mettant en œuvre un protocole de négociation pour l’ordonnancement dynamique de tâches sous des contraintes temporelles et de ressources. Après avoir défini les objectifs de cette approche et les hypothèses retenues spécifiques au contexte workflow, nous présentons le modèle comportemental de l’organisation et des agents employés. La première partie du Chapitre IV précise les détails du modèle de collaboration, définissant les interactions entre agents et le protocole de communication. Sa deuxième partie est consacrée à la formulation algorithmique des deux métaheuristiques que nous avons développées pour l’allocation et l’ordonnancement dynamique des tâches.
Le Chapitre V est consacré à la validation des modèles proposés. Nous décrivons d’abord la mise en œuvre d’un simulateur multi-agents, incluant un générateur de scénarii de test et un module d’évaluation des performances de l’algorithme d’ordonnancement. Nous terminons ce chapitre par la présentation et l’analyse statistique des résultats d’exécution d’un ensemble de scénarii aléatoires. Pour montrer l’intérêt de l’approche approchée, ces résultats sont comparés à ceux de la solution optimale, obtenue à partir d’une recherche exhaustive dans l’espace des solutions. Enfin, la dernière partie conclut ce mémoire en établissant un bilan des travaux présentés et en ouvrant un certain nombre de perspectives de recherche.
Chapitre I
Gestion de workflows
I.1 Introduction Les débuts de la technologie workflow datent de la fin des années 80, lorsque des grandes entreprises d’assurances américaines ont réalisé que le traitement informatique pouvait optimiser la gestion des contrats et des remboursements, qui auparavant était effectuée sur un support papier. Le premier produit commercial workflow était le logiciel FileNet, basé sur l’exécution de scripts, suivi par le premier système de workflow graphique, Sigma Imaging Systems, commercialisé en 1989 [1]. Depuis, de nombreux autres produits ont été développés et commercialisés, donnant lieu à des définitions et des terminologies souvent peu unifiées, voire même contradictoires. Dans ce chapitre, nous établissons tout d’abord quelques définitions permettant de caractériser et de classifier les différents types de workflow. Nous examinons ensuite les modes de collaboration interorganisationnelle et notamment ceux employés dans une entreprise virtuelle. Il s’agit en particulier d’étudier les contraintes que ce type de contexte impose aux logiciels de gestion de workflows. Enfin, dans la dernière partie, nous présentons et comparons trois approches, permettant de traiter le problème du workflow : la méthodologie centralisée, les technologies composants et finalement les approches « multi-agents ». Compte tenu de l’intérêt que cette dernière méthodologie représente pour le workflow inter-organisationnel, nous en présentons une étude détaillée, illustrée par quelques exemples d’approches développées dans le cadre de plusieurs projets de recherche.
I.2 Définitions La « Workflow Management Coalition » est un consortium dont le but est d’uniformiser et de promouvoir l’implémentation de processus informatisés dans les entreprises. Elle définit un workflow de la façon suivante : « The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. » [4] Cette définition, bien qu’étant la plus utilisée dans la littérature, n’est néanmoins pas entièrement satisfaisante. Tout d’abord, la distinction entre documents, information et tâches est inutile d’un point de vue informatique, car documents et tâches font partie de l’information. Ensuite, la notion de « règles procédurales » est trop vague et doit être affinée avant d’être employée dans un système réel. Nous préférons donc la définition établie dans [5] : « Le management d’un workflow est réalisé par un système proactif pour la gestion d’une série de tâches qui sont transmises aux participants appropriés dans le bon ordre et qui sont complétées dans des temps donnés… » Cette définition nous amène à définir les termes fondamentaux suivants : •
Un système proactif - Un tel système génère et satisfait des objectifs. Contrairement à un système réactif, son comportement n’est pas seulement conditionné par des évènements, mais aussi par des considérations internes au système [6].
•
Les participants appropriés - Ils sont souvent appelés acteurs ou ressources. Il peut s’agir aussi bien de personnes que d’entités logicielles.
•
Le bon ordre - Les tâches peuvent être liées entre elles par des contraintes de précédence. Autrement dit, une tâche doit avoir débuté (ou fini) avant le commencement de la tâche suivante. On distingue deux étapes dans la gestion d’un workflow. La première concerne la conception et la
définition des processus (en anglais Build Time) ; et la seconde le contrôle de l’exécution des processus (en anglais Run Time). La Figure 1 illustre la relation entre ces deux étapes. Lors de la phase de conception et de définition, un schéma de workflow est établi. Des outils permettant de simplifier la conception du workflow (méthodes graphiques, vérification de validité du schéma, etc.) ont été développés [9]. Lors de la seconde phase, plusieurs instances du schéma de workflow sont crées, puis exécutées à l’aide de ressources [7]. A chaque instance est associé un état d’exécution. Il s’agit d’un ensemble de variables permettant de savoir quelles tâches ont été effectuées et avec quel résultat [10]. Cette deuxième phase est réalisée par le moteur de workflow, appelé aussi « run-time engine ». Il consiste en une interface utilisateur et en des applications informatiques permettant de coordonner et d’exécuter des processus et des activités. Le travail est acheminé d’un poste informatique à un autre, à chaque fois qu’une étape de la procédure est achevée [16].
Figure 1 : Phases du management workflow [9] Un système workflow est en général un système distribué. On entend par système distribué un système formé de composants logiciels, localisés sur plusieurs ordinateurs reliés par un réseau, et interagissant entre eux en vue de répondre à un besoin donné [11]. Actuellement, avec l’émergence de la mobilité des postes de travail (ordinateurs portables, PDAs, etc.), un système distribué se modifie souvent de façon imprévisible (perte de connexion, intégration dynamique de nouveaux matériels). Dans un schéma de workflow, les transitions entre les activités des différentes tâches d’une instance sont décrites. L’ensemble des conditions associées à ces transitions est appelé flux de contrôle (en anglais « control flow »). Les flux de contrôle peuvent être de plusieurs types [8] : 1.
Acheminement parallèle - Plusieurs tâches peuvent être exécutées parallèlement
2.
Acheminement séquentiel - Une séquence de tâches (un seul fil de contrôle)
3.
Branchement multiple - Répartition d’un fil de contrôle en plusieurs fils parallèles
4.
Rendez-vous - Point de synchronisation où plusieurs fils de contrôle s’unissent
5.
Aiguillage - Branchement conditionnel (une activité parmi plusieurs est choisie pour continuer l’exécution d’un fil de contrôle)
6.
Jonction - Convergence de plusieurs fils de contrôle (aucune synchronisation)
7.
Itération - Répétition d’une même séquence de tâches
8.
Pré-condition - Le critère de démarrage d’une séquence de tâches
9.
Post-condition - Le critère d’arrêt d’une séquence de tâches
10.
Transition et Transition-Condition - Passage d’une tâche à une autre, éventuellement conditionné par des critères donnés
La Figure 2 représente le graphe acyclique dirigé d’un exemple de flux de contrôle dans un workflow d’assistance téléphonique.
Figure 2 : Exemple de flux de contrôle [12]
I.3 Types de workflow Dans la littérature, on distingue entre plusieurs types de workflow [13] : •
Les workflows de production ;
•
les workflows administratifs ;
•
les workflows ad hoc ou collaboratifs.
Cette distinction peut bien sûr être remise en cause et souvent, les workflows ad hoc sont distingués des workflows collaboratifs [14]. Par ailleurs, il n’est pas toujours possible de différencier les workflows administratifs des workflows collaboratifs.
I.3.1 Les workflows de production Ce type de workflow est également appelé « workflow procédural ». La gestion de workflows de production a pour but d’optimiser des processus répétitifs et bien maîtrisés, afin d’augmenter la productivité et la qualité des articles produits. Le niveau d’automatisation des tâches du processus est en général très élevé et le rôle du système de workflow est le plus souvent limité à la gestion des exceptions. Les tâches et leurs contraintes sont définies de manière rigoureuse, ce qui permet une planification déterministe des séquences de tâches, effectuée hors ligne, avant le démarrage de la production. Ce workflow se doit surtout d’être rapide, fiable et sécurisé, car les chaînes de production tournent souvent sans arrêt, 24 heures sur 24. Sa flexibilité se limite à l’application de scénarii prédéfinis.
I.3.2 Les workflows administratifs Comparés aux workflows de production, les workflows administratifs possèdent une définition moins précise des tâches à effectuer. Une tâche administrative n’est définie que dans ses grandes lignes et ainsi le nombre de tâches par heure est souvent dix à cent fois inférieur par rapport aux workflows de production [14]. La gestion de ce type de workflow doit être souple, afin de prendre en compte les contraintes de flexibilité imposées par les procédures administratives.
I.3.3 Les workflows ad hoc ou collaboratifs Les workflows ad hoc ne sont pas connus a priori, au niveau organisationnel. Ils sont crées individuellement, à la demande de chaque utilisateur. Dans ce type de workflow, l’optimisation de l’exécution d’une instance de workflow est moins importante que la capacité de réagir de manière flexible aux modifications imprévues ; et les processus sont définis de manière informelle. Les acteurs humains peuvent intervenir à tout instant dans la décision du cheminement du processus. Un système pour la gestion des workflows collaboratifs doit permettre aux individus ou aux équipes de coopérer afin d’atteindre un objectif commun. L’outil classique pour les workflows collaboratifs est le groupware. L’exécution d’une tâche dans le cas d’un workflow ad hoc se décompose en quatre étapes [15] : 1.
La négociation (Y a-t-il une ressource disponible ?)
2.
L’accord (Oui, la ressource est disponible)
3.
L’allocation (La ressource est utilisée pour l’exécution de la tâche)
4.
La vérification (La tâche a-t-elle été correctement exécutée ?)
I.4 Collaboration inter-organisationnelle I.4.1 Concept de l’entreprise virtuelle Le concept de l’entreprise virtuelle (EV) est basé sur un échange intensif d’informations entre les différentes entreprises participantes. Initialement, ce concept a été utilisé pour l’intégration de la chaîne logistique complète, du producteur des matières premières jusqu’à l’acheteur du produit final. Une autre application du paradigme EV est l’ingénierie concurrente ou simultanée. Dans une entreprise virtuelle, un fabricant ne crée plus un produit complet de façon autonome : il s’intègre dans un réseau de fournisseurs, clients, ingénieurs, etc. Trois types d’EV peuvent être distingués [18] : •
EV à court terme - La collaboration est basée sur une affaire unique. Les projets sont en général bien décomposables et les activités de collaboration sont souvent asynchrones. Le système workflow interorganisationnel contrôle l’activité globale, mais les détails sont implémentés localement au niveau de chaque participant.
•
EV basée sur l’entreprise étendue - Les entreprises intègrent des collaborateurs (fournisseurs, clients) dans leur système de façon permanente, selon une hiérarchie claire. Le système workflow doit traverser les limites des entreprises, afin d’assurer une intégration étroite de tous les participants, notamment pour la gestion de la chaîne logistique.
•
EV sous forme de consortium - Il s’agit également d’une collaboration permanente entre les participants de l’EV, mais la structure n’est pas hiérarchique. Chaque participant garde un degré d’indépendance, ce qui exige une très grande flexibilité et réactivité, d’autant plus que, tout en travaillant pour le même objectif, les membres de l’EV peuvent être concurrents. Dans les sections suivantes, nous allons détailler les particularités de ces trois types d’entreprises virtuelles
et leurs exigences spécifiques vis-à-vis des outils de gestion de workflow.
Cas No. 1 : La collaboration à court terme Dans le cas d’une coopération ponctuelle entre deux entreprises, l’effort de mise en œuvre d’une structure commune de gestion de workflow dépasse souvent le bénéfice de celle-ci. L’échange d’informations et la synchronisation des activités se limitent à des contacts informels, du type mail ou téléphone. L’émergence d’un vrai standard de description de processus de travail pourrait à terme changer la donne, mais aujourd’hui l’incompatibilité d’outils informatiques et le manque de rigueur dans la formalisation des workflows freinent considérablement l’application de systèmes de gestion automatisée.
Cas No. 2 : L’entreprise étendue - Gestion de la chaîne logistique La chaîne logistique est une succession d' interventions industrielles et commerciales qui va de l' approvisionnement en matières premières jusqu’à la vente d' un produit à son client. Plusieurs entreprises participent à une telle chaîne et interviennent à différentes étapes. Les solutions de gestion de la chaîne logistique (GCL) visent à automatiser et à optimiser les processus de passage d' une étape à une autre de la chaîne. [21] Dans le passé, seuls les producteurs régulaient la chaîne logistique, en contrôlant la vitesse et la
distribution des produits. Aujourd’hui, les clients sont plus exigeants et gèrent eux-mêmes le rythme de la chaîne. Dans ce contexte de concurrence, les fournisseurs sont constamment tenus d’améliorer leurs chaînes de production, afin de répondre aux exigences des clients en termes de flexibilité et de transparence de leurs processus de production. [22] Par conséquent, les outils de gestion de workflow doivent permettre l’intégration inter-organisationnelle des différents processus afin d’en assurer la flexibilité et la transparence, tout en respectant la diversité des modes opérationnels des participants.
Cas No. 3 : Gestion de développement de produit dans un consortium Dans la coopération classique inter-entreprises, une seule entreprise est chargée de la gestion de projet, entourée par des sous-traitants et des fournisseurs. Toutes les responsabilités et particulièrement le management et le contrôle de qualité sont assurées par cette dernière de manière centralisé. Dans une entreprise virtuelle en forme de consortium, le développement d’un produit est géré de façon conjointe par un réseau d’entreprises, où chacune est responsable d’une partie du développement. Le réseau intègre une structure non-hiérarchique, afin de généraliser l’ingénierie concurrentielle. Chaque entreprise garde son indépendance, tandis qu’une structure d’organisation commune est mise en place pour gérer la communication et la collaboration entre les partenaires. [18] L’organisation commune repose largement sur l’échange d’informations à travers un réseau informatique commun. Actuellement, cette communication se limite souvent à l’échange de mails, mais des outils spécifiques peuvent contribuer à optimiser la coopération et la réactivité de la structure.
I.4.2 Contraintes spécifiques du workflow dans l’entreprise virtuelle L’exécution d’un workflow inter-organisationnel dans un contexte d’entreprises virtuelles est caractérisée par : 1. Une collaboration entre partenaires géographiquement distribués, travaillant sur un même projet, mais pouvant en même temps être concurrents par rapport à d’autres projets. 2. Le besoin de création de liens dynamiques de collaboration sous forme de partenariats ad hoc. 3. La nécessité d’une forte intégration des différents partenaires dans un même processus, afin d’assurer la réactivité globale en cas de perturbations et la réorganisation dynamique vis-à-vis de modifications imprévues. 4. Une optimisation globale du processus à travers les limites organisationnelles entre les entreprises, en se basant sur des vues locales de l’état du système. 5. Un besoin de confidentialité concernant l’état d’exécution d’une instance de workflow. Il est indispensable de cacher l’état interne exact de l’instance du workflow aux autres participants. Nous souhaitons souligner l' importance du dernier point par un exemple : Soit un fournisseur travaillant pour deux clients. Un retard dans l’exécution d’une tâche pour un client peut être induit par le fait de traiter prioritairement celle destinée à un autre client. Il est évident que le premier client n’est pas censé connaître cette information, mais il est tout de même important de le prévenir du retard, pour qu’il puisse adapter son planning à
cette nouvelle situation.
I.4.3 Concepts d’interopérabilité pour workflows inter-organisationnels Le contrôle et la gestion d’un workflow impliquant plusieurs participants, peuvent être distribués de différentes manières [18] : •
Le partage de capacités - Les tâches sont allouées aux participants selon des règles définies, par une instance de gestion centrale. Cette méthode nécessite un serveur unique, mais l’exécution de tâches peut s’effectuer de manière distribuée.
•
L’exécution en chaîne - Le workflow est découpé en plusieurs parties, qui sont exécutées séquentiellement par les différents participants. Dès que l’un d’eux a fini sa partie, il cède le contrôle au participant suivant. Contrairement aux systèmes utilisant le partage de capacités, l’exécution et le contrôle sont ainsi distribués.
•
La sous-traitance - La gestion du workflow est distribuée de façon hiérarchique entre les participants. Le niveau supérieur cède le contrôle d’une partie de son workflow au sous-traitant. Celui-ci exécute les tâches et rend le contrôle au niveau supérieur après avoir fini l’exécution.
•
Le transfert d’instances de workflow (en anglais « case transfer ») - Chacun des participants possède une copie du schéma complet du workflow. Seules les instances du workflow (« workflow cases ») sont transférées entre les participants, afin d’équilibrer le partage de charges ou parce qu’une tâche doit être exécutée par un participant précis.
Figure 3 : Transfert d’instances de workflow [18]
•
Le couplage souple (en anglais « loosely coupled ») - Des parties d’un schéma workflow sont distribuées entre les participants et peuvent être actives en parallèle. Les participants ne connaissent pas toujours le schéma et l’état des instances de workflow de leurs partenaires. La communication entre les instances se
fait selon un protocole commun.
Figure 4 : Couplage souple [18] •
L’approche « Public vers Privé » [19] - Un schéma global est disponible pour tous les participants du workflow distribué. Chacun des participants crée son propre schéma à partir d’un schéma public, en respectant les contraintes qui y sont imposées. Le schéma privé est donc une sous-classe d’une partie du schéma public. En ce qui concerne l’utilité des différentes approches pour le contexte spécifique de l‘entreprise virtuelle,
il est évident que le contrôle centralisé, nécessaire aux systèmes de partage de capacités, pose un problème organisationnel (cf. Section I.5). L’exécution en chaîne est uniquement adaptée à des processus ordonnés séquentiellement, ce qui rend cette approche très contraignante. Dans la réalité des entreprises virtuelles, il n’est souvent pas possible de transmettre le contrôle entier d’une partie de l’instance d’un workflow à un participant. Les approches a priori adaptées à la réalisation d’un système de gestion informatique de workflow sont donc la sous-traitance, le transfert d’instances, le couplage souple et bien sûr l’approche « Public vers Privé ». Cette dernière est la seule à introduire un formalisme de protection des connaissances confidentielles.
A partir de ces considérations conceptuelles, nous allons présenter et analyser trois approches pour la gestion d’un workflow : •
L’approche centralisée ;
•
l’approche distribuée par composants communicants ;
•
l’approche distribuée par agents logiciels.
Figure 5 : Approches centralisée (à gauche) et distribuée (à droite)
I.5 Systèmes de workflow centralisés Les systèmes de workflow les plus utilisés ont une architecture du type client - serveur, avec un ordinateur puissant jouant le rôle de serveur et des postes informatiques individuels, moins performants, dans les bureaux des collaborateurs. Toutes les machines sont interconnectées par un réseau du type LAN ou WAN. Les systèmes sont basés sur des applications de type mail, base de données relationnelles ou encore de traitement de documents, selon l’historique du créateur du logiciel [16]. Sur le serveur se trouve une base de données contenant les schémas de workflow et l’application « moteur de workflow », qui synchronise l’exécution des tâches sur les postes clients. Le serveur s’occupe de l’ordonnancement et de la distribution des tâches, mais il est également chargé de la supervision, du traitement des exceptions et des opérations de sauvegarde. L’avantage de cette approche se situe dans la bonne maîtrise des technologies employées : Aujourd’hui, les bases de données sont fiables et la communication client - serveur ne pose pas de difficulté particulière. Un autre avantage est la simplicité de mise en œuvre de l’application cliente. Il n’y a pas de services à installer et à configurer sur les différents postes informatiques. De plus, la maintenance du système est relativement simple : Les applications clientes n’étant pas très complexes, les postes des utilisateurs ne nécessitent que rarement des mises à jour. Ainsi, il suffit en général de maintenir le serveur à jour. Les principaux inconvénients sont d’abord l’interaction continuelle entre le poste client et le serveur central : une perte de connexion paralyse l’application cliente. Aujourd’hui, il est largement reconnu que le modèle
centralisé pour la description et l’exécution d’un workflow, tel qu’il a été proposé par la WfMC (cf. Figure 6), n’est pas adapté à la coopération entre entreprises. Ainsi, même si son interface vers les autres moteurs workflow offre la possibilité d’interconnecter des moteurs de workflow différents au niveau technique, le modèle n’offre aucune spécification de coopération au niveau du processus workflow, pourtant primordiale pour assurer une exécution distribuée [17].
Figure 6: Modèle de référence de la WfMC [4] Un tel modèle ne respecte pas la confidentialité des données concernant l’état d’exécution d’un workflow : le fait que tout l’état du workflow soit stocké dans la base de données du serveur n’est pas acceptable dans le cas d’une coopération inter-organisationnelle d’entreprises indépendantes. De plus, le système centralisé ne permet pas de redimensionner dynamiquement la granularité du workflow. La granularité peut être vue comme la précision avec laquelle les tâches sont décrites (p.ex. « construire une maison » vs. « poser une fenêtre »). Un autre problème du modèle monolithique est son inaptitude à créer des liens ad hoc de coopération entre des participants et des partenaires extérieurs. Ce modèle est encore moins adapté quand il s’agit de créer des liens sans en informer les participants non concernés. Afin de pallier ces insuffisances, la recherche s’est orientée vers des systèmes distribués pour la gestion de workflows. Dans ce qui suit, nous exposons deux approches pour la décentralisation du moteur workflow, les systèmes à base de composants communicants et les systèmes basés sur le paradigme
multi-agents.
I.6 Systèmes à base de composants communicants Un composant est une entité logicielle qui peut être utilisée et assemblée par des applications variées, à travers des interfaces normalisées, et ce sans que le programmeur n’ait à connaître sa réalisation interne. C’est le principe de la blackbox réutilisable, qui diminue le coût du développement, tout en augmentant la fiabilité. Les standards de composants les plus connus sont CORBA [24], JAVABeans [25] et COM [26]. En ce qui concerne les composants pour workflow, la recherche actuelle n’a pas encore réussi à en donner une définition complète, ni à définir une approche systématique pour le développement de systèmes de workflow [23]. Néanmoins, il existe des solutions hybrides, utilisant un moteur de workflow centralisé, ayant la possibilité de communiquer ou d’invoquer des composants externes, comme par exemple Oracle Workflow avec les composants J2EE [27]. A l’heure actuelle, les composants constituent essentiellement une technologie auxiliaire pour la gestion de workflows et sont souvent utilisés pour exécuter des tâches précises. Cependant, ils sont moins adaptés à une organisation de haut niveau. Pour la création d’un système de workflow intégralement basé sur des composants, peu de composants standardisés sont disponibles. La solution à ce problème consiste à utiliser des standards existants et d’y adjoindre une partie « connaissance de métier ». Ainsi, les approches proposées (cf. section I.7.2), se basent souvent sur le standard CORBA pour la communication. Or, un système à base de composants distribués, enrichi par de l’intelligence métier, peut être vu comme un système multi-agents. Dans la section suivante, nous analyserons les différences entre les approches basées sur le paradigme d’agents et les autres systèmes distribués, comme les systèmes à base de composants ou les architectures client - serveur.
I.7 Systèmes à base d’agents I.7.1 Définition d’un système multi-agents Dans tout système distribué, l’interaction entre les entités distribuées est d’une grande importance, mais la réalisation de cette interaction varie selon le type d’architecture. Dans les systèmes client - serveur, c’est uniquement au client d’initier l’interaction. Dans les systèmes à base de composants, ces derniers doivent en général être invoqués explicitement par l’application « cliente » avant de fournir le service demandé. Dans les deux cas, seul le client est responsable du choix de la suite d’actions tandis que le « fournisseur de service » ne fait que réagir. Ceci peut être suffisant pour des applications destinées à un nombre limité d’utilisateurs, dans un environnement bien défini, mais pas adapté aux environnements ouverts ou concurrentiels. Jennings et Wooldridge [28] ont montré les limites de ce type d’approches : « Des analyses obtenues grâce aux sciences organisationnelles et scientifiques indiquent que ce type d’approches unilatérales ne se prête pas bien à l’agrandissement du système. Il est préférable de permettre à l’exécuteur d’avoir "son mot à dire" (par exemple, l’invocation d’une action devient un processus de consensus mutuel). Ainsi, l’exécuteur, qui par définition connaît plus intimement les détails des actions à réaliser, pourrait connaître la raison pour laquelle un comportement ne doit pas être invoqué dans la situation actuelle. Dans ce cas, l’exécuteur doit être capable de refuser la requête ou tout au moins expliquer les conséquences potentiellement endommageantes de sa réalisation. Ces observations deviennent d’autant plus pertinentes, lorsqu’un logiciel n’est plus sous le contrôle d’une seule organisation, mais migre vers des environnements ouverts, où le système est constitué d’organisations concurrentielles. » Bien qu’il existe un consensus général concernant les limitations des systèmes classiques et le besoin d’évolution vers des systèmes à base d’agents, la question de ce qui caractérise un système multi-agents n’a pas encore été tranchée. La définition d’un agent la plus employée dans la communauté francophone est sûrement celle de Ferber [29] : « Un agent est une entité physique ou logique capable d' agir sur elle-même et sur son environnement, qui dispose d' une représentation partielle de cet environnement et qui, dans un univers multi-agents, peut communiquer avec d' autres agents et dont le comportement est la conséquence de ses observations, de sa connaissance et des interactions avec les autres agents » D’autres définitions incluent d’autres caractéristiques, comme par exemple la capacité d’apprentissage ou la continuité de l’existence de l’agent (par opposition à des objets ou composants invoqués seulement sur besoin). Dès le début des années 1970 et jusqu’à aujourd’hui, il existe une école de pensée des systèmes multiagents qui met en avant l’aspect délibératif, communicatif ou bien « social » de ces systèmes. Par contre, depuis le début des années 1990, nous assistons au développement d’un autre « courant », plus pragmatique, ayant effectué un glissement du paradigme du « raisonnement » vers celui de l’action. Cela a eu pour conséquence l’émergence ces dernières années d’un très grand nombre d’applications multi-agents. Nwana [30] ironise : « Some cynics may argue that this strand arises because everybody is now calling everything an agent, thereby resulting, inevitably, in such broadness. » Tout en admettant qu’il n’est pas possible d’établir une classification qui convient à tous les systèmes multi-agents existants, Nwana propose de distinguer entre sept différents types d’agents : •
Agents collaborants - Ils sont autonomes et coopèrent, afin d’atteindre un but. Souvent, ils doivent négocier pour trouver des accords mutuellement acceptables.
•
Agents interfaces - C’est le cas de l’assistant personnel, capable d’apprendre les objectifs d’un utilisateur humain et d’agir de façon autonome pour l’aider ou pour exécuter des tâches à sa place.
•
Agents mobiles - Il s’agit de processus logiciels capables de se déplacer à travers des réseaux informatiques, afin d’obtenir des informations localement disponibles ou d’exécuter des tâches distantes.
•
Agents d’information/Internet - Ils gèrent, collectionnent et résument des informations dont la taille est trop grande pour être traitées manuellement, comme par exemple les agents des moteurs de recherche sur Internet.
•
Agents réactifs - Ce type d’agents ne possède pas de modèle interne de son environnement, mais répond selon le principe « stimulus - réponse » aux événements détectés. L’interaction entre agents relativement simples peut mener à l’émergence d’un comportement synergétique de groupe.
•
Agents hybrides - Ils possèdent plusieurs caractéristiques parmi celles énumérées ci-dessus.
•
Agents Intelligents - Cette dernière classe d’agents est définie pour répondre au mieux à un problème donné ; chaque application pouvant avoir des besoins différents. BT Labs a par exemple identifié comme exigence minimale pour un agent intelligent qu’il doit être autonome, capable d’apprendre et de collaborer.
I.7.2 Travaux relatifs aux approches agents pour systèmes de workflow Dans la littérature, il subsiste une difficulté à distinguer clairement entre un système multi-agents et d’autres systèmes distribués, dotés de plus ou moins d’autonomie et de réactivité. C’est la raison pour laquelle nous englobons sous l’appellation « Systèmes multi-agents pour workflow » toute approche d’exécution de workflow entièrement distribuée, mettant en œuvre des entités possédant une certaine capacité de coopération et de délibération. Dans cette section, nous présentons les projets de recherche concernant des systèmes workflow distribués que nous estimons les plus significatifs. Etant donné la nature récente de ce domaine, il n’existe pas encore de terminologie commune qui faciliterait la comparaison des différentes approches. Nous constatons notamment une confusion entre les approches « agents », les approches « distribuées ou décentralisées » et d’autres approches « inter-organisationnelles ». En faisant abstraction de l’appellation donnée par les concepteurs des différents systèmes, nous avons retenu un nombre d’approches intéressantes, possédant les caractéristiques suivantes : •
Elles sont basées sur des entités distribuées, capables de communiquer.
•
Ces entités peuvent influencer la suite de l’exécution d’un processus, en choisissant de façon autonome l’action suivante.
•
Les entités ont un état qui leur appartient et qui n’est pas connu des autres entités.
•
Elles ont une vue limitée de l’état du système.
•
L’interaction automatisée entre les différentes entités conduit à des solutions nouvelles à des problèmes, comme par exemple l’optimisation d’un ordonnancement, la conclusion d’un contrat de service, etc. Cette classification exclue donc les approches du type purement client - serveur ainsi que les systèmes
nécessitant une intervention humaine pour toute prise de décision (par exemple du type « groupware »). On peut classer les approches agents pour workflow en trois catégories [31]:
6. Les agents agissant en tant qu’acteurs coopérants. Chaque agent joue ici un rôle, plus ou moins calqué sur les rôles existants dans la réalité de l’entreprise (agent comptable, agent de production, etc.). Nous décrivons trois exemples pour cette classe d’approches : ADEPT, METEOR2, CrossFlow. 7. Les agents agissant en tant que moteur d’exécution décentralisé. Les agents sont ici responsables de la coordination réactive de tâches. Ils sont basés sur des activités et non pas sur un rôle. Ils se coordonnent selon le schéma du workflow, sans nécessiter un moteur central d’exécution. A titre d’exemple, nous présentons les approches EvE et METUFlow. 8. Les agents migrants qui passent d’un « point de service » au suivant, en transférant la partie du schéma du workflow dont ils sont responsables. Les exemples présentés sont WONDER et DartFlow. Par la suite, nous allons présenter succinctement ces sept exemples d’approches multi-agents pour workflow.
ADEPT Né de l’idée d’automatiser des workflows flexibles chez British Telecom, le projet ADEPT (Advanced Decision Environment for Process Tasks) [32] était une des premières tentatives d’employer des agents pour l’allocation de ressources aux processus dans l’entreprise. Sa logique repose sur des agents jouant le rôle d’acteurs coopérants. Chaque agent est capable de fournir un ou plusieurs services. Le service le plus simple consiste en une seule tâche indivisible. Des tâches peuvent être composées à l’aide d’opérateurs définissant des contraintes (séquence, parallélisme, etc.) et des conditions, afin de créer des services complexes. Les services peuvent être imbriqués entre eux à tous les niveaux. Au plus haut niveau, tout le processus global de l’entreprise peut être vu comme un service. Les agents, responsables de leurs services respectifs, doivent conclure des accords s’ils ont besoin de services fournis par d’autres agents. Ces accords sont appelés « service level agreements » (SLA). Un protocole de négociation et un langage de description des services ont été proposés, permettant aux agents de découvrir les services appropriés et de négocier leurs conditions d’exécution (exécution unique ou répété, temps de démarrage, etc.). La stratégie de négociation est modélisée explicitement dans deux bases de connaissances : la première est déclarative et représentée sous forme d’un réseau causal. Elle sert à décrire les objectifs et le contexte de la négociation (par exemple, adapter le prix d’un service à la charge d’un agent). La deuxième base de connaissance inclut des règles de négociation, par exemple une stratégie de vente aux enchères pour l’obtention du meilleur tarif.
METEOR2 Le projet METEOR2 (Managing End-To-End OpeRations) [33][34] a débuté en 1994. La définition des workflows est réalisée à l’aide du METEOR Designer/Builder (MTDes), un outil graphique pour la création de schémas de workflow. Elle est exprimée dans un langage script, spécialement conçu pour METEOR. Les scripts sont exécutés en cascade et servent à générer automatiquement du code pour l’exécution des tâches, les accès aux données et le traitement d’exceptions.
Figure 7 : Modèle d’interaction de METEOR2 [35] En ce qui concerne le moteur d’exécution, le projet METEOR2 propose deux modules différents : WebWork et OrbWork. Le premier est une implémentation « allégée » d’un service d’exécution de workflow. Il est entièrement distribué et basé sur la technologie Web/Internet. OrbWork est un moteur qui offre plus de capacités de reconfiguration dynamique, en se basant sur le standard CORBA. Dans METEOR2, un workflow consiste en des tâches, des gestionnaires de tâches, des entités de traitement et des interfaces (cf. Figure 7) [36]: •
Une tâche représente une unité de travail dans une instance de workflow. Les tâches sont modélisées par des graphes, dont les nœuds sont des états visibles depuis l’extérieur. Les arcs décrivent des transitions d’un état à l’autre. Les transitions dites « contrôlables », peuvent être activées de l’extérieur, tandis que l’activation des transitions « incontrôlables » reste propre à la tâche. Les tâches peuvent avoir deux types d’interdépendances : dépendances de contrôle et dépendances de données. Ces dépendances spécifient la façon dont la transition contrôlable peut être activée.
•
Un gestionnaire de tâches (en anglais : « task manager ») est créé pour chacune des tâches, afin de contrôler et d’ordonnancer la tâche associée.
•
Une entité de traitement (en anglais « processing entity ») est l’agent responsable de l’exécution d’une tâche. Il peut être humain ou automatisé, selon les circonstances.
•
Une interface définit l’interconnexion entre la tâche et son entité de traitement. Selon la nature de ce dernier, il peut s’agir d’une interface IDL/CORBA, d’appels RPC ou d’une interface graphique. L’exécution d’une tâche commence lorsque son gestionnaire détermine que les conditions de son
activation sont remplies, en évaluant son arbre de dépendances. Cet arbre est construit de manière incrémentale, puisque chaque tâche signale consécutivement son état de terminaison à tous ses successeurs [37]. Bien que n’étant pas formellement basé sur le paradigme multi-agents, ce projet est néanmoins intéressant dans le contexte de workflows inter-organisationnels, grâce à sa nature entièrement distribuée.
CrossFlow Le projet CrossFlow (Cross-Organizational Workflow Support in Virtual Enterprises) [38], a pour objectif de fournir un support à haut niveau pour des workflows inter-organisationnels dans des entreprises virtuelles formées dynamiquement lorsque certaines activités sont sous-traitées à des fournisseurs externes. Ce support logistique aux entreprises est réalisé par la proposition de services abstraits, servant à trouver des partenaires potentiels et à réaliser une coopération étroite. Les services de coopération sont gérés par des « gestionnaires de contrats » (en anglais : « contract managers »), cf. Figure 8.
Figure 8 : Coopération entre deux systèmes workflow selon CrossFlow [40] Les concepteurs ne font pas explicitement appel à la notion de système multi-agents, mais CrossFlow peut néanmoins être considéré comme un système à base d’agents, car il s’agit bien d’entités autonomes et distribuées, mettant en œuvre une coopération au sein d’une entreprise virtuelle. Le projet, avec la participation notamment d’IBM, a débuté en 1998. Son objectif est de développer une infrastructure informatique pour la gestion de processus dans des organisations virtuelles dynamiques. Les objectifs de CrossFlow sont les suivants [40] :
•
La sous-traitance dynamique de services. Ce paradigme stipule que les clients trouvent les fournisseurs appropriés en s’appuyant sur des méthodes du marché. Les partenaires compatibles sont déterminés à l’aide de « modèles de contrats », en passant par une entité appelée « Contract Manager ». Les offres et les demandes peuvent être adaptés avant de conclure un contrat définitif.
•
La spécification de services basée sur des contrats. Cette spécification détaillée, qui fait partie du contrat préalablement conclu, est à la base d’une coopération étroite entre le fournisseur de services et son client.
•
Un maillage très fin d’interactions entre le fournisseur de services et le client, décrit à un haut niveau sémantique. Les spécifications n’incluent pas seulement l’objet du contrat, mais aussi une vue restreinte sur les opérations nécessaires pour son accomplissement. Les deux organisations peuvent donc être interconnectées lors de l’exécution du processus.
•
Création dynamique d’infrastructures de communication entre les systèmes informatiques du fournisseur et ceux du client, selon le type et la spécification du contrat. Ce processus est entièrement automatisé et lorsque le contrat prend fin, l’infrastructure interconnectée est automatiquement désactivée. EvE Le projet EvE (an Event-Driven Distributed Workflow Execution Engine) [41] a pour but de permettre
l’exécution distribuée d’un workflow, réalisée par communication d’événements. Tous les états du workflow sont décrits comme une combinaison d’événements. Des agents (appelés en anglais « brokers ») réagissent aux occurrences de ces événements. EvE possède une architecture multiserveur, où un serveur est responsable pour un LAN entier. Les serveurs eux-mêmes sont interconnectés par un WAN. Cette structure est transparente pour les composants (agents), qui peuvent traverser les limites entre les domaines grâce à des « adaptateurs ». EvE est donc un middleware qui fournit les services et capacités suivants : •
Des capacités de détection d’évènements, de notification et d’allocation de tâches, afin d’exécuter une instance de workflow, ainsi que des capacités de communication et de détection d’événements entre serveurs distribués. Les composants sont répartis à travers un réseau étendu pour permettre une exécution distribuée du workflow.
•
Un service d’entrepôt de données d’exécution. Pour rendre le système workflow opérationnel, des services d’annuaire, de persistance et de récupération sont nécessaires. L’entrepôt contient et fournit de l’information concernant les agents, les événements et les règles du type ECA (événement - condition action). Les informations peuvent être mises à jour dynamiquement, sans que le système n’ait à les recompiler et à redémarrer.
•
Des services de sauvegarde de l’historique pour des fins d’analyse et de récupération d’erreurs. Des défaillances peuvent intervenir à deux niveaux : au niveau des défaillances du système (matérielles ou logicielles) et au niveau de l’exécution d’un workflow (tâches retardées, ressources indisponibles, etc.). EvE permet de gérer la notification d’exceptions, les alertes et a la capacité de reprendre l’exécution après déconnexions temporaires, grâce à des files d’attente d’événements persistantes. L’exécution d’un workflow démarre ou se poursuit lorsqu’un événement est généré par un agent. Le
serveur EvE local réalise la détection de l’événement et l’exécution des règles appropriées. Les agents sont
informés de l’occurrence de l’événement et réagissent selon les règles « ECA ». Ensuite, ils peuvent, à leur tour, générer des événements qui sont traités par les serveurs EvE.
METUFlow L’objet du projet METUFlow [45] est le développement d’un système de gestion de workflows entièrement distribué. Il est basé sur un langage de description de processus, appelé MFDL (METUFlow Description Language). Un workflow est défini comme une collection de blocs, de tâches et de sous-processus. Une tâche est l’unité basique de l’exécution. Les processus et les tâches ont des données en entrée et en sortie, leur permettant de communiquer avec d’autres processus ou tâches. Les blocs se distinguent des processus dans le sens où un bloc est une entité purement conceptuelle, ne servant qu’à spécifier l’ordre et les dépendances entre les tâches.
Figure 9 : Communication entre les composants de METUFlow [45] Les blocs sont traduits en un arbre de processus, qui sert à générer des entités logicielles appelées « gardes » (en anglais « guards »). Ces derniers restent en attente d’événements pour déclencher l’action appropriée pour la suite du processus. L’ordonnancement des tâches est distribué entre les gardes, qui activent les tâches à travers des gestionnaires de tâches (en anglais « task managers »), dont le rôle est de s’interfacer entre la tâche et le garde (cf.
Figure 9). La communication entre les différents composants de METUFlow est basée sur le standard CORBA.
WONDER L’architecture WONDER (Workflow ON Distributed EnviRonment) [42] représente un système pour l’exécution d’un workflow distribué, basé sur le paradigme des agents mobiles et ne nécessitant pas une supervision centralisée (cf. Figure 10). Chaque agent est un « micro-moteur » de workflow, contenant aussi bien les données que le plan d’exécution d’une instance de workflow. Des agents mobiles (« activity managers ») migrent à travers le réseau en se reproduisant sur les différents lieux d’exécution de leurs tâches. Cette migration est réalisée en utilisant le standard CORBA [24]. Il n’y a pas de transfert de code et seuls l’état et les données sont transmis. D’autres agents sont responsables de la synchronisation entre les différentes activités. Ils sont créés préalablement à l’exécution d’une instance de workflow et restent en attente d’événements, comme par exemple la terminaison d’une activité ou l’occurrence d’un événement externe.
Figure 10 : Architecture de WONDER [42] DartFlow Le système de gestion de workflow DartFlow [43] utilise des agents mobiles comme moteur d’exécution distribuée. Les agents migrent de machine en machine, en transférant leur état courant. L’implémentation d’agents migrants est basée sur le langage Tcl [44]. L’architecture de DartFlow est composée de quatre éléments principaux : •
L’interface utilisateur graphique. Il s’agit de formulaires qui sont traités par un utilisateur. Leur envoi
déclenche l’exécution d’un script qui sert à créer ou à réveiller des agents mobiles. •
Des agents mobiles, transportant données et informations concernant le flux de contrôle.
•
Le serveur de l’organisation, incluant le noyau fonctionnel de DartFlow. Il maintient une base de connaissances pour le routage d’informations (les flux d’information dans les processus de l’entreprise), le traitement d’exceptions et la gestion d’agents. Il communique ces informations aux agents mobiles quand ceux-ci en ont besoin.
•
Le serveur de la liste de tâches, chargé de communiquer les résultats fournis par les agents mobiles aux interfaces utilisateurs, à la fin de l’exécution de chacune de leurs tâches. Après réception d’une liste de tâches du serveur d’agents, les agents mobiles deviennent autonomes vis-à-
vis de ce dernier. On peut noter ici un problème de notification des changements dans l’état du système (une tâche annulée, par exemple). C’est la raison pour laquelle un serveur de suivi est chargé d’assurer le lien entre l’agent et le serveur.
I.7.3 Discussion Nous avons vu dans la section précédente qu’un certain nombre de travaux de recherche ont été menés dans le domaine de la gestion de workflows inter-organisationnels. Les systèmes que nous avons présentés sont basés sur la coopération d’entités logicielles dotées de capacités d’agir, qu’on peut qualifier d’agents logiciels. Les approches les plus récentes font de plus en plus appel au concept des agents mobiles, permettant le transfert d’informations nécessaires à l’exécution d’une instance de workflow. La conclusion de « contrats » entre agents, la capacité de réagir aux événements, ainsi que l’implémentation de protocoles de communication constituent les principales caractéristiques de ces projets. Or, pour être capable de s’adapter aux situations imprévues, un logiciel de gestion de workflows doit forcément intégrer un module d’ordonnancement de tâches. Bien qu’il soit acquis que la coopération inter-organisationnelle exige un moteur d’exécution entièrement distribué, peu de travaux traitent le problème de l’ordonnancement dynamique et distribué, notamment en présence de la contrainte de respect de confidentialité de chaque participant.
I.8 Conclusion L’utilisation d’outils informatiques pour la gestion des processus à l’intérieur d’une entreprise est aujourd’hui largement acceptée. Cependant, son emploi dans le contexte inter-organisationnel se heurte encore à certains d’obstacles, dont les plus importants sont la difficulté du respect de la confidentialité entre les différents partenaires et le manque de standardisation lors de l’interconnexion des différents processus locaux. Dans la coopération classique inter-entreprise, une seule entreprise, entourée de sous-traitants et de fournisseurs, est chargée de la gestion du projet. Toutes les responsabilités et particulièrement le management et le contrôle de qualité sont centralisés au sein de cette entreprise. Dans une entreprise virtuelle en forme de consortium, le développement d’un produit est géré de façon conjointe par un réseau d’entreprises, où chacune est responsable d’une partie du développement. Le réseau intègre une structure non-hiérarchique, afin de généraliser l’ingénierie concurrentielle. Chaque entreprise garde son indépendance, tandis qu’une structure d’organisation commune est mise en place pour gérer la communication et la collaboration entre les partenaires. L’organisation commune repose largement sur l’échange d’informations à travers un réseau informatique commun. Des outils spécifiques peuvent contribuer à optimiser la coopération et la réactivité de la structure. Les tâches du workflow sont soumises à des contraintes temporelles (contraintes de précédence, échéances) et de ressources (hommes ou machines). Compte tenu de la nature distribuée du workflow interorganisationnel, des événements imprévisibles peuvent survenir à tout instant. Ainsi, la coordination de l’exécution des tâches doit être faite de manière dynamique, afin de neutraliser ou de réduire l’impact des perturbations. Un système multi-agents constitue une solution permettant de gérer la collaboration entre partenaires distribués de façon réactive et dynamique. Un grand nombre de travaux de recherche se base sur ce type de méthodologies. Cependant, nous constatons qu’aucun de ces travaux ne traite le problème de l’ordonnancement dynamique sous la contrainte additionnelle du respect de la confidentialité des données privatives (état d’exécution par exemple) de chaque participant.
Chapitre II
Ordonnancement
II.1 Introduction Les tâches d’un workflow sont classiquement soumises à des contraintes temporelles (contraintes de précédence, échéances) et de ressources (hommes ou machines). Compte tenu de la nature distribuée du workflow inter-organisationnel, des événements imprévisibles peuvent survenir à tout moment. Ainsi, la coordination de l’exécution des tâches doit être faite de manière dynamique, afin de réduire ou de neutraliser l’impact des perturbations. Pour ce faire, nous nous focaliserons dans ce chapitre sur le problème d’ordonnancement dans le domaine discret. On peut distinguer deux types d’approches permettant de solutionner ce type de problèmes : les méthodes exactes, dont nous présentons une sélection dans la Section II.4 et les méthodes approchées, que nous exposons à l’aide de quelques exemples dans la Section II.5. Nous terminons le chapitre par une analyse des différentes approches d’ordonnancement basées sur le paradigme des systèmes multi-agents (Section II.6).
II.2 Généralités Il y a problème d’ordonnancement quand un ensemble de travaux est à réaliser, que cette réalisation est décomposable en tâches, que le problème consiste à définir la localisation temporelle des tâches et/ou la manière de leur affecter les moyens nécessaires. Autrement dit, il s’agit d’allouer des ressources aux activités et d’affecter à chaque opération une date de démarrage. La problématique de l’ordonnancement de tâches fait partie des problèmes appelés « optimisation sous contraintes » (en anglais : CSP, Constraint Satisfaction Problem).
On distingue trois catégories de problèmes d’ordonnancement [46]: •
Les problèmes d’ordonnancement pur - Dans ce type de problème, on sait quelle ressource est utilisée par quelle activité et en quelle quantité. Les capacités des ressources sont aussi connues, bien qu’elles puissent varier avec le temps. Le problème est de placer les activités dans le temps sans excéder les capacités des ressources disponibles. L’exemple classique du problème d’ordonnancement pur est le « Job shop scheduling problem »
•
Les problèmes d’allocation de ressources pures - Dans ce cas, l’instant d’exécution de chaque tâche est connu ; il s’agit seulement d’allouer les bonnes ressources, de façon à assurer qu’à tout instant, leur disponibilité dépasse la demande. A titre d’exemple, on peut citer l’allocation de personnel et la gestion des lits au niveau du bloc opératoire d’un hôpital.
•
Les problèmes conjoints d’ordonnancement et d’allocation de ressources- Il existe un degré de liberté aussi bien en ce qui concerne les activités à effectuer que les ressources à utiliser. La dimension du problème peut varier entre quelques dizaines et quelques milliers de tâches. Parfois, il
s’agit de trouver, de façon rapide, une solution faisable, mais non-optimale. Dans d’autres circonstances, il est indispensable de trouver la meilleure solution, au prix d’un temps de calcul plus élevé. Par ailleurs, toutes les données du problème ne sont pas forcément toujours observables. La grande variété des problèmes d’ordonnancement a conduit à tout autant de méthodologies pour les solutionner. On distingue principalement entre méthodes exactes et méthodes approchées. Les premières calculent la solution globalement optimale, mais nécessitent souvent un temps de calcul croissant exponentiellement avec la dimension du problème. Les méthodes approchées se contentent, quant à elles, d’une solution approximative, obtenue en général en un temps borné. La Figure 11 liste les méthodes de recherche d’optima dans un espace de solutions, qui peuvent s’appliquer au problème d’ordonnancement.
Figure 11 : Méthodes d’optimisation et d’ordonnancement sous contraintes
II.3 Définitions Dans cette section, nous définissons la terminologie couramment employée dans la problématique de l’ordonnancement des tâches d’un workflow. Activité / tâche - Opération faisant partie d’un schéma de workflow, effectuée sur ou par une ressource selon un planning défini et pouvant dépendre de l’exécution d’autres activités. Ressource - Les ressources sont nécessaires à l’exécution de tâches. Le besoin en ressources pour l’exécution d’une tâche est appelé « contrainte de ressource ». Dans le cas du workflow, une ressource peut être un poste informatique, une personne, une machine ou un document. L’expression « ressource unaire » caractérise une ressource ne servant qu' à une seule activité à la fois. Il s’agit dans ce cas d’un accès conditionné par l’exclusion mutuelle (l’abréviation anglaise « mutex » y est souvent employée) Préemption - Pour caractériser un problème d’ordonnancement, il est nécessaire de donner l’autorisation ou non d’interrompre des tâches ou des opérations : Dans certains problèmes d’ordonnancement, la préemption est autorisée à tout moment, dans d’autres, typiquement dans le cas des chaînes de production, une interruption ne peut avoir lieu qu’entre l’exécution de deux activités successives d’un lot associé à un travail. Par conséquent, l’interruption est interdite ou limitée à des moments bien précis de l’exécution. Pour le workflow, nous ne considérons que l’ordonnancement de tâches non préemptives. Critère à optimiser - Le paramètre devant être minimal ou maximal après calcul d’ordonnancement et éventuellement après l’exécution de tâches. Il peut s’agir par exemple de la minimisation du temps d’exécution de bout en bout de toutes les tâches du workflow (en anglais « makespan »), du plus grand retard parmi toutes les tâches ayant dépassée leur limite, ou bien du nombre de tâches en retard. La valeur du critère à optimiser est donnée par la fonction objective. Activités disjonctives - Deux opérations sont dites en disjonction, si elles ne peuvent s’exécuter simultanément. En présence de contraintes disjonctives, l’exécution de tâches se fait de manière séquentielle.
Contrainte - Une contrainte est une relation logique (une propriété qui doit être vérifiée) entre différentes inconnues, appelées variables, chacune prenant ses valeurs dans un ensemble donné, appelé domaine. Ainsi, une contrainte restreint les valeurs que peuvent prendre simultanément les variables. Contrainte de précédence - Relation temporelle entre deux tâches. Elle peut être du type tdébut(Tâche y) > tterminaison (Tâche x) ou encore du type tdébut(Tâche y) > tdébut(Tâche x). La première expression signifie que la tâche x doit être terminée avant le démarrage de la tâche y et la seconde, que la tâche y doit commencer après le démarrage de la tâche x. Prédécesseur / Successeur - Des tâches liées entre elles par une contrainte de précédence du type tdébut (Tâche y) > tterminaison(Tâche x). Perturbation - Une modification imprévisible de l’état du système, survenant lors de l’exécution des tâches, qui
crée un conflit entre l’ordonnancement planifié et les contraintes définies, par exemple la violation d’une contrainte de précédence à cause d’un retard. Dans le cas de l’exécution d’un workflow, on peut énumérer trois types de perturbations : (1) Occurrence d’un retard lors de l’exécution d’une tâche. (2) Non disponibilité d’une ressource. (3) L’arrivée imprévue d’une nouvelle tâche. Problème de satisfaction de contraintes (CSP) - Il s’agit d’un problème modélisé sous la forme d' un ensemble de contraintes imposées à des variables, chacune de ces variables prenant ses valeurs dans un domaine. De façon plus formelle, on définit un CSP par un triplet (X, D, C), tel que : i.
X = { X1, X2, ..., Xn} est l' ensemble des variables (les inconnues) du problème ;
ii.
D est la fonction qui associe à chaque variable Xi son domaine D(Xi), c' est-à-dire l' ensemble des valeurs que peut prendre Xi ;
iii.
C = {C1, C2, ..., Ck} est l' ensemble des contraintes. Chaque contrainte Cj est une relation entre certaines variables de X, restreignant les valeurs que peuvent prendre simultanément ces variables.
Situation de blocage - Une tel état (en anglais : « deadlock ») est caractérisé par l’impossibilité de la poursuite de l’exécution des tâches sans intervention d’un mécanisme externe. Il peut être atteint, lorsque toutes les conditions suivantes sont réunies : i.
La présence d’une exclusion mutuelle lors de l’accès à une ressource : une ressource est prise par une tâche ou elle est libre.
ii.
Une tâche détenant déjà une ressource peut en nécessiter une autre.
iii.
Il n’y a pas de préemption possible : chaque tâche doit libérer elle-même la ressource.
iv.
Deux tâches ayant simultanément besoin des deux mêmes ressources, sont chacune en attente de la ressource que l’autre détient.
Ordonnancement dynamique - L’ordre des tâches n’est pas fixé à l’avance, mais au fur et à mesure du progrès de leurs exécutions. Ce type d’ordonnancement est adapté aux systèmes qui évoluent de manière imprévisible ou qui ne permettent pas une vue globale de leur état. Priorité -
Deux tâches ayant besoin de la même ressource au même instant peuvent être ordonnancées en fonction d’un paramètre de priorité : la tâche moins prioritaire doit attendre la libération de la ressource détenue par l’autre tâche.
II.4 Méthodes exactes Elles déterminent la solution optimale pour un problème d’ordonnancement donné, en utilisant le principe de l’exploration plus ou moins exhaustive de l’espace des solutions. Du fait de la grande complexité algorithmique des problèmes combinatoires, les méthodes exactes sont souvent limitées à des instances de petite dimension. Dans ce qui suit, nous présentons quelques méthodes bien connues, permettant de trouver la solution optimale par rapport à un critère donné, tout en essayant d’éviter l' énumération exhaustive de l' espace de recherche.
II.4.1 Le « backtrack » Le « backtrack » n’est pas une méthode de recherche de solutions proprement dite, mais l’outil principal pour toutes sortes de méthodes de résolution exactes. Il s’agit de règles d’élimination : Poser une condition et ensuite évaluer son admissibilité à l’aide d’une procédure donnée. Si la condition n’est pas admissible, la solution est invalide. Pour parcourir tout l’espace de solutions, on utilise en général la méthode backtrack qui consiste à instancier les variables du problème dans un ordre prédéfini. A chaque fois qu’une valeur est affectée à une variable, on évalue la validité de l’instanciation partielle obtenue. Si le test est positif, cette variable est figée, et ainsi de suite, jusqu’à ce que toutes les variables le soient. Si le test est négatif, on attribue une nouvelle valeur à la variable courante. Si tous les tests sur les valeurs d’une variable ont été des échecs, on revient à la variable précédente, pour tester une nouvelle valeur (c’est ce qu’on appelle un « backtrack »). S’il n’existe pas de solution pour toutes les valeurs possibles de la variable, on effectue à nouveau un backtrack. Le résultat est une instanciation de l’ensemble des variables tel qu’aucune contrainte ne soit violée [48].
II.4.2 Grid Search Cette méthode explore tout l’espace de solutions, afin de déterminer l’optimum. Cette méthode, également appelée « force brute », même si elle nécessite beaucoup de temps de calcul, représente néanmoins parfois la seule possibilité de trouver la solution optimale dans le cas de problèmes complexes, qui ne se prêtent pas à l’utilisation de méthodes dirigées. Elle n’est applicable qu’aux problèmes possédant un nombre de paramètres relativement faible avec des bornes étroites.
II.4.3 Divide-and-Conquer La méthode Divide-and-Conquer (diviser et régner) découpe le problème en plusieurs sous-problèmes, parmi lesquels il n’y a pas de recouvrement des espaces des solutions. Il s’agit d’une approche bottom-up, qui consiste à construire la solution globale à partir des solutions des sous-problèmes. Cette méthode ne peut être utilisée que s’il existe une stratégie pour le découpage de l’espace des solutions.
II.4.4 Programmation dynamique Cette méthode peut être vue comme une amélioration ou une adaptation du Divide-and-Conquer. Elle a été introduite par Bellmann en 1955. Tout comme la méthode Divide-and-Conquer, la programmation dynamique cherche d’abord la solution optimale des sous-problèmes, puis construit la solution globalement optimale. Les sous-problèmes peuvent se recouvrir ; leurs solutions sont calculées une seule fois, puis stockées dans des tables. Il existe deux implémentations algorithmiques [47] : •
La version itérative - On initialise les « cases » correspondant aux cas de base. On remplit ensuite la table selon un ordre précis : on commence par les problèmes de petite taille pour finir par la solution du problème principal. Il faut d’une part, qu' a chaque itération, on n' utilise que les solutions déjà calculées et d’autre part, que chaque élément soit calculé une et une seule fois.
•
La version récursive (tabulation, memoizing) - A chaque appel de cette méthode, on cherche dans la table si la valeur a déjà été calculée. Si c’est le cas, on ne la recalcule pas: on récupère la valeur mémorisée.
Dans le cas contraire, on la calcule et on stocke la valeur correspondante.
II.4.5 Branch-and-Bound L’algorithme Branch-and-Bound (exploration par partitionnement et évaluation de bornes) est une autre méthode conçue pour éviter le calcul exhaustif de l' espace de recherche. Le problème initial est séparé en plusieurs sous-problèmes (en général sans recouvrement mutuel) qui à leurs tours sont également partitionnées. Cela permet de construire un arbre de recherche, dont les branches seront successivement éliminées, en démontrant que la solution d’un sous-problème ne peut être meilleure (ou au moins aussi bonne) que la meilleure solution trouvée jusque là. Afin de tester la qualité d’une branche, des limites (en anglais « bounds ») sont calculées selon une méthode de relaxation, qui consiste à construire une nouvelle fonction à optimiser. Cette fonction englobe toutes les solutions faisables du problème initial (approximation extérieure) et sa fonction objective est inférieure à la fonction objective initiale (sous-estimation). Si le problème relaxé ne peut pas être résolu, le problème initial n’a pas de solution non plus et par conséquent, la branche est élaguée. Si par contre le problème possède une solution, celle-ci peut être considérée comme la nouvelle borne inférieure de la fonction objective. Si cette borne n’est pas meilleure ou aussi bonne que la meilleure solution déjà trouvée (stockée dans une liste des meilleurs résultats), on peut en conclure que le sous-problème n’apporte pas d’amélioration au problème et la branche est également éliminée [51].
II.4.6 Propagation de contraintes Souvent, la propagation de contraintes peut servir à réduire la taille des sous-problèmes dans les branches de l’arbre de recherche. Les contraintes existantes peuvent être utilisées pour la détermination de nouvelles contraintes. Dans le cas de l’ordonnancement d’activités, on trouve souvent des contraintes du type « l’instant d’activation de la tâche 3 doit être supérieur à l’instant de terminaison de la tâche 2, qui à son tour doit finir après la tâche 1 ». On peut en déduire qu’il existe une contrainte implicite « la tâche 3 doit commencer après la tâche 1 ». Cette contrainte peut servir à éliminer certains sous-problèmes de l’arbre de recherche de solutions.
II.4.7 Ordonnancement en présence d’incertitudes Si un ordonnancement globalement optimal peut être établi avant le début de l’exécution des tâches, ce n’est qu’en fonction des paramètres connus. Or, en réalité, certaines données ne peuvent être déterminées avec certitude. Il s’agit des aléas internes (pannes de machines, rebuts, accidents) et externes (retards d’approvisionnement, modifications des demandes des clients), ainsi que des données ne pouvant être évaluées qu’à travers des estimations (durée d’une tâche de diagnostic, volume de production) [59]. Ces considérations font que l’ordonnancement initial doit être adapté dynamiquement, en fonction des réalités rencontrées « sur le terrain ». Le Problème de Satisfaction de Contraintes Stochastiques (en anglais « stochastic CSP ») apporte une solution à la modélisation et à la résolution de problèmes d’optimisation en présence d’incertitude. Concernant les ordonnancements dans le monde réel, en présence de contraintes multiples, la certitude absolue n’existe pas. Par exemple, la disponibilité d’une ressource peut changer de façon imprévisible. De même, l’état des tâches liées par des contraintes de précédence peut être difficile à connaître, surtout dans des environnements distribués. Plutôt que d’utiliser des valeurs exactes, il est parfois utile de baser l’optimisation sur des estimations, en attribuant aux valeurs incertaines une distribution probabiliste [60]. Les solutions du problème de satisfaction de contraintes ne sont plus alors déterminées de façon binaire (valide ou non valide), mais par rapport à une valeur d’utilité ou un coût. Les méthodes d’optimisation habituellement utilisées en environnement certain (Branch-and-Bound, propagation de contraintes, etc.) peuvent être appliquées à des problèmes stochastiques [61].
II.5 Méthodes approchées Les méthodes approchées, aussi appelées heuristiques, permettent de trouver une solution acceptable, en réduisant le temps de calcul nécessaire, sans pour autant garantir que cette solution soit la meilleure.
II.5.1 Recherche de voisinage Une recherche d’optimum local est effectuée autour des points de départ (en anglais « seeds »). Les solutions voisines des points initiaux sont comparées, puis la recherche est dirigée en direction de la meilleure solution voisine. L’implémentation la plus simple consiste à choisir des points de départ aléatoires, mais un choix judicieux peut sensiblement augmenter la vitesse de convergence, et réduire le risque de ne trouver qu’un optimum
local.
II.5.2 Recuit simulé Une autre approche basée sur l’exploration du voisinage de points de départ est le recuit simulé [52]. Il s’agit d’une technique qui s' inspire d' un mécanisme naturel observé dans les aciéries : lors du refroidissement d' une pièce, les atomes de la matière s' organisent de façon optimale. En imitant ce mécanisme, on espère trouver une solution acceptable à un problème d' optimisation. La « température » permet de franchir des barrières entre les minima locaux, selon une probabilité donnée par la loi de Boltzmann. La méthode du recuit simulé est rarement utilisée pour des problèmes d’ordonnancement. Cependant, une algorithmique d’ordonnancement par cette méthode est exposée dans [53].
II.5.3 Algorithmes génétiques D’un point de vue général, l’optimisation basée sur les Algorithmes Génétiques (AG) est une méthode de recherche stochastique, impliquant la génération aléatoire de solutions potentielles. Ces solutions sont ensuite évaluées et affinées, jusqu’à ce qu’un critère d’arrêt soit satisfait. Les solutions potentielles sont représentées par des « gènes » et en simulant un mécanisme de reproduction et de croisement de ces gènes, on ne retient que les solutions ayant les meilleurs « gènes ». Ces solutions remplacent les solutions antérieures, jusqu’à ce qu’une solution satisfaisante soit trouvée. Le croisement entre solutions trouvées permet de quitter la zone d’attrait d’optima locaux, mais peut être handicapant si la nouvelle génération de solutions ne produit pas avec une grande probabilité d’aussi bonnes solutions que les « parents ». Par conséquent, contrairement à la méthode du recuit simulé, l’utilisation d’algorithmes génétiques demande une plus grande compréhension de la nature du problème à optimiser [51]. Les algorithmes génétiques ont souvent été utilisés pour des problèmes d’ordonnancement, tels que celui développé dans [50].
II.5.4 Recherche tabou La méthode de recherche tabou est une métaheuristique fondée sur le principe de la recherche locale. Comme les méthodes citées ci-dessus, son principe consiste à explorer l’espace de recherche composé de toutes les solutions réalisables dans le but d’aboutir à la solution optimale. A partir d’une solution initiale réalisable, le processus consiste, à chaque itération, à choisir la meilleure solution dans le voisinage de la solution courante. Afin d’éviter les optima locaux ou des comportements cycliques, la recherche tabou utilise une structure de mémorisation temporaire dans laquelle elle sauvegarde les dernières solutions visitées : la liste tabou. Une solution reste interdite pendant un nombre d’itérations égal à la taille de cette liste. Par la suite, le meilleur voisin non tabou sera choisi pour la prochaine itération [54]. Un exemple d’application de la recherche tabou à un problème d’ordonnancement est développé dans [55].
II.6 Ordonnancement à l’aide de systèmes multi-agents Dans ce type d’approche, des entités logicielles indépendantes, appelées « agents », coopèrent pour trouver une solution à un problème d’ordonnancement. Ces agents sont dotés de la capacité à percevoir leur environnement (par exemple l’espace de recherche du problème d’ordonnancement), d’une certaine intelligence pour le comprendre et de moyens de communication. Les avantages de l’approche multi-agents pour traiter le problème de l’ordonnancement sont : •
La robustesse - Les agents peuvent réagir dynamiquement aux perturbations rencontrées.
•
La possibilité de mise à l’échelle - Les systèmes multi-agents, par leur nature distribuée, se prêtent bien à des problèmes de taille variable (en anglais : « scalability »)
•
Le parallélisme - Dans certaines situations, les agents, grâce à leur nombre élevé, peuvent traiter un problème vaste ou un problème distribué plus rapidement qu’une unité monolithique.
•
L’accès aux données distribuées - Les agents peuvent accéder à des informations géographiquement distribuées ou même cachées, qui ne pourraient pas être collectionnées par un ordonnanceur central.
•
La capacité de confidentialité - Une partie des données d’un problème distribué peut être soumise à des contraintes de confidentialité, ce qui rend les approches centralisées inapplicables. Un agent peut analyser localement une partie confidentielle du problème et ne communiquer que les données « neutres », c’est à dire non-confidentielles ou anonymisées. Nous avons identifié trois cas où une approche multi-agents constitue une solution bien adaptée :
•
Un espace de recherche de grande dimension - Les agents ratissent de façon indépendante des parties de l’arbre des solutions et communiquent sporadiquement leurs résultats.
•
La solution d’un problème étant partitionnable - La solution globale se construit de façon incrémentale à partir des solutions partielles. Chaque agent cherche une solution localement faisable et négocie avec ses voisins, afin de la rendre globalement cohérente.
•
La solution à un problème géographiquement distribué - Chaque agent se situe à un endroit différent et communique des paramètres aux autres agents ou à une entité centrale dédiée à la résolution du problème. Un quatrième cas où l’emploi d’un système multi-agents constitue souvent la seule possibilité pour trouver
la solution à un problème d’ordonnancement est celui des systèmes très complexes, non modélisables explicitement. Dans ce cas, un agent modélise un aspect partiel et le comportement global du système émerge de l’interaction des agents individuels. Cependant, il subsiste toujours la difficulté de la preuve formelle de la validité de la solution ainsi trouvée. Dans ce qui suit, nous présentons quelques exemples pour chacun des trois cas énumérés ci-dessus.
II.6.1 Agents coopérants pour l’exploration de l’espace de recherche
Les approches basées sur des agents qui coopèrent pour l’exploration d’un espace de recherche très vaste, ont été inspirées par l’observation de phénomènes naturels. On y trouve notamment les méthodes imitant le comportement des colonies de fourmis et celle de l’optimisation par essaim particulaire (OEP). Il s’agit de deux métaheuristiques basées sur l’interaction à bas niveau entre une multitude d’agents coopérants. Les colonies de fourmis et l’OEP sont fondées sur la notion de coopération entre des agents (les fourmis ou particules) qui peuvent être vus comme des « animaux » aux capacités limitées (peu de mémoire et de faculté de raisonnement). Ces agents travaillent de façon indépendante et ne collaborent que sporadiquement. L' échange d' informations entre les entités conduit en général à résoudre des problèmes difficiles, comme c' est le cas, par exemple, chez les abeilles vivant en essaim et qui collaborent pour l’exploitation de sources de nourriture difficiles à trouver. Dans le domaine de l’ordonnancement, chaque agent élabore une solution individuelle pour un nombre de tâches à ordonnancer. Ces solutions individuelles sont ensuite réunies à un niveau central, puis validées ou rejetées, en utilisant des techniques d’assemblage de plans (en anglais « plan merging »), telles que la méthodologie décrite dans [56].
II.6.2 Agents élaborant itérativement des solutions partielles Dans ce type d’approche, la recherche de solutions est un processus incrémental, qui peut nécessiter un « backtrack ». Dans le cas de l’ordonnancement, les agents construisent leurs solutions locales de façon incrémentale, en considérant plusieurs activités et leurs contraintes, sans toutefois traiter le problème global. La solution complète pour l’ordonnancement optimal est obtenue en réunissant les ordonnancements locaux. La méthodologie est semblable à celle de l’ordonnancement centralisé, mais la recherche des sous-solutions est distribuée entre des unités indépendantes. Les problèmes d’ordonnancement constituent une sous-classe de la classe des problèmes de satisfaction de contraintes (CSP). Certains CSP, naturellement partitionnés, sont connus sous le nom de problèmes de satisfaction de contraintes distribués (DCSP). La solution d’un DSCP peut être construite à partir des solutions des sousproblèmes distribués. Les différents sous-problèmes sont liés par des contraintes. Il est alors possible d’associer un agent à chacun des sous-problèmes et de trouver la solution globale, par communication et négociation entre ces agents. Souvent, le choix du partitionnement du problème global et l’allocation des sous-problèmes aux agents, sont soumis à des considérations diverses : techniques, sociales ou d’ordre confidentiel. Un critère de qualité pour le découpage du problème global, appelé configuration, a été proposé dans [62]. La construction d’une solution globalement optimale, à partir des solutions trouvées par chacun des agents, a été utilisée pour le réordonnancement dynamique des plannings temporels des participants d’un même processus de travail, en attribuant un coût à tout accord entre agents [63]. Ce coût peut ensuite être transféré entre agents, afin de compenser des solutions locales sous-optimales. L’ordonnancement optimal est atteint quand tous les agents ont fini leurs échanges de coûts compensatoires.
II.6.3 Agents négociants Les agents négociants peuvent représenter une tâche ou une entité physique, comme une cellule de production, une machine, un outil etc. Les agents négocient afin de trouver un ordonnancement acceptable pour tous. La vente aux enchères de créneaux horaires est une approche bien connue pour l’ordonnancement de tâches, basée sur un système multi-agents. La variante la plus employée de la vente aux enchères est le « Contract Net » [71]. Les agents annoncent leurs tâches dans une mise aux enchères publiques. D’autres agents, chargés de la gestion des ressources répondent par des enchérissements (en anglais : « bids »). Les premiers agents choisissent alors parmi les seconds la ressource la plus avantageuse. Ce protocole a souvent été utilisé pour des systèmes d’ordonnancement distribués [72][73][74][75]. Le problème récurrent des approches basées sur la vente aux enchères est celui de la détermination du nombre optimal d’enchérissements. Trop peu d’enchérissements conduit à un ordonnancement sous-optimal et trop d’enchérissements risque de surcharger le vendeur. Une solution à ce problème, basée sur la théorie de l’utilité espérée (en anglais « Expected Utility Theory ») est proposée dans [64]. Un agent souhaitant faire exécuter une tâche par d’autres agents, calcule d’abord l’ordonnancement dont le bénéfice est estimé maximal, avant de soumettre ses tâches à une vente aux enchères, en ne considérant que les créneaux horaires estimés optimaux.
II.6.4 Auto-ordonnancement par agents L’auto-ordonnancement (en anglais : « self-scheduling ») signifie qu’aucun ordonnancement global n’est établi à l’avance et que la planification de l’ordre d’exécution des tâches s’effectue au fur et à mesure de l’avancement de l’exécution. Les systèmes d’auto-ordonnancement sont en général composés d’un ensemble d’agents, interagissant pour la prise de décisions locales. Le comportement global du système apparaît alors comme une conséquence émergeante des interactions locales. L’auto-ordonnancement fait partie des méthodes basées sur la négociation d’agents, présentées dans la section précédente. Dans ce qui suit, nous présentons quelques exemples de systèmes multi-agents pour l’autoordonnancement, que nous estimons intéressants dans le cadre du workflow.
Routage de tâches par collaboration de « guêpes » Une approche d’ordonnancement distribuée basée sur l’imitation du comportement collaboratif d’une colonie de guêpes est décrite dans [66]. Ella a été appliquée pour l’allocation de ressources (machines outils) aux tâches dans un problème du type « job shop scheduling ». La priorité des tâches et établie à partir d’un mécanisme du type stimulus - réponse (cf. Figure 12). Chaque nouvelle tâche entrant dans le système émet un stimulus, dont l’intensité augmente proportionnellement à son temps d’attente. Dans un premier temps, chaque agent « guêpe » représente une machine. Les agents élisent une tâche parmi celles en attente, pour l’exécuter à l’aide de leurs ressources. Leurs seuils de réaction aux stimuli émis par les tâches en attente, sont adaptés dynamiquement. Un coefficient de force est introduit pour résoudre les conflits lors d’une tentative d’élection parallèle de la même tâche par deux agents. Dans un deuxième temps, les « guêpes » représentent non plus les ressources, mais les tâches à exécuter.
Les agents disputent l’accès aux ressources par calcul d’un coefficient de force qui leur permet d’avancer dans la file d’attente. Les deux dernières « guêpes » dans la file d’attente s’engagent dans une compétition et celle qui gagne, s’engage dans une compétition avec la prochaine « guêpe » et ainsi de suite, tout le long de la file. L’agent associé à la première tâche dans la file d’attente est ensuite élu et la tâche peut être exécutée.
Figure 12 : Système de routage de tâches par collaboration de « guêpes » Système multi-agents pour la planification de transports militaires L’approche multi-agents pour l’ordonnancement de transports militaires variés (navals, aériens, terrestres) proposée dans [67], est basée sur des « clusters » (des amas) d’agents. Un cluster est responsable d’un certain type de transports. Par exemple, le cluster aérien s’occupe de la gestion des avions et leurs équipages. Les agents de chaque cluster communiquent via une zone mémoire partagée et établissent leurs ordonnancements locaux à l’aide d’algorithmes génétiques ou d’heuristiques simples. La communication entre clusters s’effectue par envoi de messages explicites. Nous classons cette approche plutôt dans la catégorie des méthodes de coopération par élaboration de solutions partielles (Section II.6.2). En effet, il s’agit essentiellement d’un découpage du problème global en sousproblèmes pouvant être résolus indépendamment, où ayant des interdépendances limitées.
Agents réactifs coordonnés L’architecture d’ordonnancement distribué CORA (« COordinated Reactive Agents »), basée sur des agents réactifs, est décrite dans [68]. L’environnement des agents (les tâches et leurs contraintes) est exprimé sous forme d’objets, faisant partie d’un problème de satisfaction de contraintes (CSP). Chaque agent est responsable d’une partie du problème global et peut apercevoir ou modifier seulement les variables de cette partie. Un même
agent ne peut être associé à des contraintes de différents types (cf. Figure 13). Lorsqu’un agent détecte des violations de contraintes sur ses variables, il essaie d’abord de trouver localement une solution au conflit. Si cette tentative échoue, une stratégie de coordination est alors mise en œuvre. Celle-ci est basée d’une part, sur la minimisation des perturbations globales à partir de modifications locales et d’autre part, sur la construction d’« îlots de confiance ». Ces derniers sont constitués d’ensembles de variables fortement contraintes, dont l’algorithme de négociation de l’approche CORA cherche à préserver une même instanciation valide. Un cycle d’itérations consiste en l’activation successive de tous les agents, jusqu’à ce qu’une solution satisfaisant toutes les contraintes soit trouvée.
Figure 13 : Perception d’un CSP selon le modèle CORA [68] Résolution Coopérative et distribuée d’un problème d’ordonnancement L’approche RCDP (résolution coopérative et distribuée de problèmes) [69] a été utilisée dans le contexte d’un atelier de production organisé selon plusieurs niveaux décisionnels hiérarchiques. Au niveau le plus bas, les machines-outils sont regroupées en cellules. L’approche RCDP est employée pour limiter l’impact d’une perturbation au niveau décisionnel où elle se produit. Elle empêche ainsi sa propagation aux niveaux décisionnels supérieurs. Les perturbations sont gérées en six étapes (cf. Figure 14). L’échec de la résolution du problème à une étape induit automatiquement une tentative de réparation à l’étape suivante.
Figure 14 : Réordonnancement en 6 étapes selon la méthode RCDP [69] La coopération entre les machines, pour l’élaboration d’une solution incluant les nouvelles contraintes dues à la perturbation, prend la forme de négociations de contraintes, de transferts ou de permutations de tâches.
Ordonnancement par système multi-agents dans le contexte de calcul partagé Le calcul partagé, où « grid computing », consiste à exploiter pleinement les ressources de l' intégralité d' un parc informatique (serveurs et PC) afin de réaliser rapidement des calculs complexes qui prendraient plusieurs mois voire plusieurs années avec des supercalculateurs classiques. L’allocation de tâches aux machines disponibles représente un problème complexe, du fait que la disponibilité des postes informatiques et la persistance des connexions, ne sont pas souvent connues avec certitude. Un système d’auto-ordonnancement s’impose pour deux raisons : Premièrement, un tel système respecte la nature distribuée et dynamique du calcul partagé, sans dépendre de la disponibilité d’un accès à un serveur centralisé. Deuxièmement, dans les très grandes grilles (« grids ») avec un seul ordonnanceur centralisé, apparaissent des problèmes d’échelle (« scalability »), du
fait que celui-ci ne peut traiter qu’un nombre limité de tâches en un temps donné. L’architecture ARMS (Agent-based Resource Management System for grid computing) [70] est une méthodologie permettant de créer des systèmes logiciels distribués à grande échelle. Elle est basée sur l’idée d’agents coopérants, et comporte un modèle hiérarchique, un modèle de découverte de services et un modèle de coordination. Les agents sont considérés comme des fournisseurs de service, offrant des capacités de calcul. Les agents passent des annonces pour offrir leurs services et sont capables de collaborer pour la découverte de ressources disponibles. Le contexte du calcul partagé n’est pas exactement le même que celui du workflow inter-organisationnel, mais la nature des contraintes sur les tâches (temporelles et ressources) reste la même. A notre avis, les concepts du workflow et du calcul partagé se rejoignent in ultimo, et pourront donner lieu à des systèmes de gestion semblables.
II.6.5 Discussion Nous avons montré dans les sections précédentes que les systèmes basés sur le paradigme de la collaboration entre agents constituent une solution au problème d’ordonnancement. Premièrement, nous avons présenté la méthodologie d’agents coopérants pour l’exploration de l’espace des solutions. Simple à comprendre, à programmer et à utiliser, ces techniques se révèlent particulièrement efficaces pour les problèmes d' optimisation non linéaire, à variables continues, entières ou mixtes [57][58], mais trouvent leurs limites pour des problèmes caractérisés par une forte interdépendance, comme un workflow inter-organisationnel. Les méthodes basées sur le principe de l’élaboration itérative de solutions partielles ressemblent à celles faisant appel aux agents négociants, mais leur mécanisme de coopération suit des règles ou des algorithmes rigides, ne laissant aucun degré de liberté décisionnel aux agents. Ce manque de souplesse simplifie la validation formelle du système, mais ne permet pas de faire face à des situations imprévues, comme c’est souvent le cas lors de l’exécution d’un workflow. Les méthodes basées sur la négociation ne sont en général pas déterministes. Ces approches ont l’avantage d’être robustes, mais elles ne peuvent pas garantir la performance globale du système. Elles ont même souvent des tendances chaotiques. [65] Les quatre projets présentés dans la Section II.6.4 illustrent quelques uns des travaux sur le sujet et montrent la variété des choix retenus par les différentes équipes de recherche. Les méthodes proposées ont en commun l’autonomie des agents et la place importante qu’elles accordent à l’échange de messages pour la résolution de conflits. Cependant, à notre connaissance, aucune méthodologie ne tient compte explicitement des restrictions d’observabilité de l’état global du système. Ces restrictions sont pourtant réelles et nécessaires dans un contexte de collaboration inter-organisationnel, comme nous l’avons argumenté dans la Section I.4.2.
II.7 Conclusion Ce chapitre, consacré à la problématique de l’ordonnancement de tâches sous contraintes, a montré qu’il existe une grande variété de méthodologies pour solutionner ce type de problèmes. On distingue principalement
entre méthodes exactes et méthodes approchées. Les premières calculent la solution globalement optimale, mais nécessitent souvent un temps de calcul croissant exponentiellement avec la dimension du problème. Les seconds se contentent d’une solution approximative, obtenue en général en un temps borné. Dans le contexte d’un workflow inter-organisationnel, la recherche s’est naturellement orientée vers des systèmes d’auto-ordonnancement (« self-scheduling »), où l’ordonnancement s’effectue en fonction de l’état d’avancement de l’exécution. Les méthodologies basées sur les systèmes multi-agents sont particulièrement bien adaptées à ce mode d’ordonnancement, du fait qu’elles permettent la négociation distribuée et dynamique entre entités indépendantes. En conclusion, on peut dire qu’il existe des solutions variées aux différents aspects du problème de l’ordonnancement des tâches d’un workflow inter-organisationnel, à savoir l’incertitude concernant l’état de l’environnement, la nature distribuée et l’observabilité limitée du système. Cependant, nous avons constaté la nécessité de concevoir un système d’ordonnancement distribué et dynamique, prenant en compte l’ensemble des contraintes énumérées ci-dessus. Dans le chapitre suivant, nous proposons une approche méthodologique et algorithmique probabiliste pour traiter cette problématique, inspirée par les systèmes d’auto-ordonnancement par agents, permettant de gérer l’incertitude et la limitation de l’observabilité de l’état global.
Chapitre III
Modèles d’organisation et d’architecture d’agents
III.1 Introduction Nous avons montré dans le Chapitre I que les outils de gestion de workflow pour une entreprise virtuelle doivent posséder des caractéristiques spécifiques, compte tenu de la nature distribuée et concurrentielle des processus de travail. Dans ce contexte, nous avons vu que les outils présentés dans les divers travaux de recherche s’appuient souvent sur des technologies récentes et notamment sur le paradigme multi-agents. Dans le Chapitre II, nous avons présenté un aperçu des méthodologies d’ordonnancement pour des tâches soumises à des contraintes discrètes. Nous avons montré là aussi, que les approches basées sur le concept multiagents peuvent constituer des solutions intéressantes au problème d’ordonnancement distribué. L’ordonnancement est l’une des fonctionnalités fondamentales d’un système de gestion de workflow. Il est donc intéressant de concevoir une approche qui s’appuie sur le principe de la coopération entre des agents logiciels pour l’ordonnancement distribué de tâches dans le contexte d’une collaboration inter-organisationnelle. Les travaux décrits dans ce mémoire, concernent une nouvelle approche pour l’ordonnancement de tâches associées à des entreprises différentes. Une des idées fondamentales du concept proposé est le respect de la confidentialité sur l’état interne de l’instance de workflow, de chaque participant. Seules les informations probabilistes sont communiquées aux participants ayant en charge des tâches liées par des contraintes directes. La deuxième idée fondamentale réside dans le développement d’une méthodologie permettant le réordonnancement des tâches, en traitant implicitement l’occurrence de perturbations. Le modèle proposé repose sur une négociation entre plusieurs types d’agents, responsables de l’exécution de tâches, de la gestion des ressources ou encore de la supervision. Pour traiter le problème de l’ordonnancement dynamique, nous développons deux métaheuristiques. La première a pour objectif de partitionner les tâches en groupes puis de les allouer aux agents distribués. La deuxième, consiste, quant à elle, à établir des solutions pour l’ordonnancement de ces tâches. Dans ce qui suit, nous exposons le modèle de l’organisation multi-agents proposé et nous détaillons le modèle comportemental de chaque agent collaboratif.
III.2 Définition des objectifs Le premier objectif de ces travaux est la proposition d’une architecture pour l’exécution d’un workflow dans un contexte d’entreprises caractérisé par : 9. Une collaboration entre partenaires géographiquement distribués, travaillant sur un même projet (paradigme de l’entreprise virtuelle), mais pouvant en même temps être concurrents dans le cadre d’autres projets. 10. La présence de liens dynamiques de collaboration sous forme de partenariats ad hoc. 11. Une forte intégration des différents partenaires dans le même processus (sous-traitance, collaborations). 12. Un besoin de réactivité dynamique lors de l’occurrence de modification ou des perturbations pendant l’exécution d’un processus distribué. 13. Un haut degré d’interconnexion des réseaux informatiques entre les participants. 14. Un besoin de confidentialité concernant l’état d’exécution d’une instance de workflow. Le second objectif que nous nous sommes fixés concerne l’optimisation de l’exécution d’un workflow distribué par rapport à quatre types de contraintes : La disponibilité des ressources nécessaires pour l’exécution d’une tâche, l’ordre d’exécution des tâches (contrainte de précédence), le temps d’exécution d’une tâche et enfin le respect de confidentialité de chacun des partenaires. Notre but est de développer une solution méthodologique et algorithmique pour l’optimisation multicritères de la gestion informatique de workflows, basée sur le concept agent, avec deux critères à optimiser : le premier concerne la minimisation du temps d’exécution du workflow et le second, la minimisation du nombre de messages échangés entre agents, lors de l’élaboration de l’ordonnancement. Dans la suite du manuscrit, nous développons une approche décentralisée pour la gestion distribuée de workflows. Nous présentons une méthodologie pour l’ordonnancement dynamique distribué dans un environnement incertain : les différents agents échangent des messages contenant des valeurs probabilistes associées à l’exécution de leurs tâches. L’ordre d’exécution est établi au fur et à mesure, en fonction de priorités calculées à partir de deux paramètres : les probabilités d’exécution des autres tâches et les disponibilités estimées des ressources nécessaires.
III.3 Hypothèses Avant de développer cette approche, nous formulons les conditions et hypothèses suivantes : 15. Le temps d’exécution d’une instance de workflow est discrétisé en créneaux horaires chacun ayant une durée fixe. A l’échelle de workflows inter-organisationnels on pourrait par exemple choisir une durée d’un quart d’heure, voire même d’une heure ou plus. Tous les participants au workflow sont synchronisés sur la même horloge globale pour la détermination de ces créneaux. En général, il s’agit tout simplement de l’heure du jour. Cette contrainte est de toute façon présente dans les collaborations humaines, comme par exemple lors de la
négociation de l’heure pour une réunion de travail. 16. L’ordonnancement distribué pour la tâche à effectuer a lieu au début de chacun de ces créneaux. Le temps nécessaire pour la détermination de l’ordonnancement est négligeable par rapport à la durée du créneau. Nous supposons que ce temps représente moins de 1% de la durée d’un créneau horaire. Dans le cas de l’exécution d’un workflow, la durée d’une tâche se mesure habituellement en minutes ou en heures. Le calcul nécessaire pour déterminer la priorité des tâches ne devrait pas dépasser quelques secondes, ce qui paraît raisonnable compte tenu de la puissance de calcul des ordinateurs actuels. 17. Afin de valider l’approche d’ordonnancement proposée, nous avons retenue comme hypothèse de travail qu’une tâche s’exécute en un seul créneau horaire. Pour la mise en œuvre dans le contexte d’un workflow réel, il est tout à fait envisageable de lever une telle hypothèse, en considérant que la durée d’une tâche est un multiple de la durée d’un créneau horaire. Par conséquent, elle est décomposable en une séquence de « sous tâches », liées entre elles par des contraintes de précédence ; la durée de chaque « sous - tâche » correspond à une unité de temps. 18. Les tâches ne peuvent pas être interrompus pendant leur exécution (hypothèse de non-préemption). 19. Une ressource ne peut servir qu’à une tâche à la fois et une tâche ne peut s’exécuter qu’à l’aide d’une seule ressource (contrainte disjonctive). Dans le cas d’un workflow, les ressources sont le plus souvent des ordinateurs personnels. De plus, dans la réalité, il est peu probable que plusieurs personnes travaillent sur le même poste ou qu’une personne travaille parallèlement sur plusieurs ordinateurs. Cette hypothèse pourrait être assouplie, mais il faudrait alors considérer le risque de voir apparaître des situations de blocage (cf. Section II.3). Dans le cadre du travail présenté, nous considérons qu’à chaque activité est associée une ressource définie a priori. 20. L’état global de l’instance du workflow ne peut être observé qu’à travers des vues localement limitées. Il s’agit là d’une hypothèse essentielle, car la collaboration inter-organisationnelle exige le respect de la confidentialité de l’état interne du workflow de chaque participant, comme nous l’avons souligné dans la Section I.4.2. 21. Il existe un canal de communication fiable et persistant entre les lieux d’exécution de deux tâches ayant une interdépendance directe (par exemple une contrainte de précédence ou un besoin de la même ressource). Néanmoins, il suffit que ce canal de communication soit actif au début de chaque créneau horaire, pendant toute la durée de la négociation. 22. Pour l’ordonnancement de tâches, nous privilégions la recherche d’une solution localement optimale. Par conséquent, la solution globale qui en résulte ne correspond pas toujours à l’optimum global, puisque chaque participant cherche à optimiser l’exécution de ses tâches en se basant sur des observations limitées du système global. Cette limitation est imposée par la nature des relations inter-organisationnelles, qui ne permettent pas de centraliser les informations de l’état de tous les participants du workflow. Dans ce qui suit, nous présentons le modèle comportemental, c’est à dire la typologie et le rôle de chaque agent au sein de l’organisation. Le modèle de collaboration entre les différents agents lors de l’exécution d’une instance d’un workflow, fera objet du chapitre suivant.
III.4 Modèle comportemental des agents Dans la section I.7, nous avons énuméré plusieurs types d’agents, dont deux présentent un intérêt particulier pour le workflow : il s’agit des agents réactifs et des agents mobiles. Compte tenu des avantages respectifs de ces types d’agents, nous avons opté pour une approche mixte, mettant en œuvre à la fois des agents réactifs et des agents mobiles. Ainsi, nous avons développé une architecture basée sur trois types d’agents : 1. Des agents mobiles, ayant la responsabilité d’une partie des tâches du workflow instancié. Ils migrent de ressource en ressource en transférant leurs tâches. Ils connaissent les ressources dont ils ont besoin, ainsi que les contraintes de précédence liant directement leurs tâches à celles d’un autre agent mobile. Nous appellerons ces agents par la suite des « agents WF ». 2. Des agents gérant l’accès aux ressources. Chacun a pour rôle de gérer une ressource et les demandes d’accès des agents WF. Nous considérons comme ressource tout poste informatique (relié au moins temporairement à un réseau informatique) avec un opérateur humain (bien que ce dernier ne soit pas toujours indispensable). On parle dans ce cas d’« agent de ressources ». 3. Les agents chargés du démarrage et de la supervision. Ils initient l’instanciation des autres agents et contrôlent l’exécution des tâches. Un agent de ce type est appelé « agent manager ». Le Tableau 1 résume les trois types d’agents employés dans notre approche. La Figure 15 représente un exemple d’instanciation d’un workflow à 11 tâches, nécessitant trois ressources distinctes.
Nom Agent manager
Type
Créé par
Description
proactif
Lancement de l’application
Crée les
autres agents, alloue les tâches à effectuer aux agents workflow, surveille l’exécution des tâches élues par les agents de ressources Agent de ressources
réactif
Agent manager
Gère l’accès
à une ressource en choisissant l’agent WF ayant la tâche la plus prioritaire Agent workflow
mobile,réactif
Agent manager
Est responsable d’une séquence de tâches. Essaye de s’imposer auprès des agents de ressources, afin d’exécuter ses tâches
Tableau 1 : Les trois types d’agents de l’approche proposée
Figure 15 : Exemple d’une instance de workflow
III.4.1 Modèle de l’agent WF L’agent migrant, baptisé « agent WF », est chargé d’exécuter une séquence de tâches en sollicitant les ressources nécessaires pour cette exécution. Il s’occupe exclusivement de la séquence de tâches qui lui a été allouée, sans tenir compte de l’exécution des tâches des autres agents WF. La résolution de conflits lors d’accès concurrents à une même ressource (et ainsi la définition de l’ordre d’exécution) est assurée en utilisant la priorité des tâches. Un agent WF calcule dynamiquement la priorité de chacune de ses tâches, en se basant sur des informations issues des agents de ressources et des autres agents WF. Les détails de ces calculs sont développés dans le Chapitre IV.
Figure 16 : Architecture d’un agent WF Le nombre d’agents WF exécutant les tâches d’une instance de workflow n’est pas défini à l’avance. Il est établi à partir du constat suivant : Le besoin de négociation entre agents est inversement proportionnel à la taille de l’agent : un « petit » agent (ne s’occupant que d’une seule ou d’un petit nombre de tâches), doit échanger beaucoup de messages avant que le système n’aboutisse à un ordonnancement global satisfaisant. De plus, il subsiste toujours le risque d’aboutir à des solutions sous-optimales, étant donnée la vue limitée de chacun des agents par rapport à l’état global (cf. Figure 17). A l’opposé, un « grand » agent, bien qu’ayant une vue plus complète sur
l’état du système, a l’inconvénient de consommer beaucoup de ressources, en termes de bande passante lors de la migration et de capacité de stockage des postes informatiques sur lesquels il réside. Pour la détermination du nombre de tâches gérées par un agent, nous nous sommes fixés deux objectifs. Premièrement, il s’agit de minimiser les interdépendances temporelles entre les tâches gérées par différents agents, pour minimiser le nombre de messages échangés nécessaires au respect des contraintes de précédence. Dans le cas extrême, si un agent n’est responsable que d’une seule tâche, toutes les contraintes de précédence deviennent des contraintes « inter-agents », induisant un nombre de messages conséquent. Le second objectif concerne la minimisation de la durée globale de l’exécution d’une instance de workflow, en parallélisant l’exécution des tâches et en optimisant ainsi l’utilisation des ressources. Un agent ne pouvant pas être à deux endroits en même temps, pour des raisons de cohérence spatio-temporelle, nous excluons l’exécution simultanée de deux tâches par un même agent. Par conséquent, dans le cas extrême, lorsqu’on ne crée qu’un seul agent pour la gestion de toutes les tâches, la durée globale de l’exécution de bout en bout du workflow correspond à la somme des durées de toutes les tâches. Dans la section
, nous présentons la solution algorithmique que nous proposons pour la détermination
des séquences de tâches et leur allocation aux agents WF. L’architecture interne d’un agent WF est illustrée Figure 16. Ce type d’agent réagit aux messages arrivant par le module de communication, en fonction de ses connaissances internes. Ces connaissances d’une part, sont liées au fonctionnement général du système multi-agents, il s‘agit de « capacités sociales » et d’autre part, représentent l’état courant de l’agent et de son environnement, perçu à travers les messages reçus. Ce deuxième type de connaissance est aussi appelé « croyances individuelles ». De plus, un agent WF dispose d’un module de migration, lui permettant de sauvegarder son état courant et d’être transféré (« cloné ») à un endroit distant.
Figure 17 : Influence de la « taille » des agents sur le nombre de communications Le diagramme d’état d’un agent WF, illustré Figure 18, montre que le comportement d’un agent WF est organisé autour d’une boucle d’attente de messages. Lorsque cet agent reçoit une séquence de tâches à exécuter (message
), il interroge chacun des agents chargés de l’exécution des tâches prédécesseurs, afin d’en obtenir la probabilité d’exécution pour la fenêtre temporelle considérée (messages et ). Le scénario représenté Figure 19 comporte quatre agents WF. Les Agents WF 1, 2 et 3 gèrent des tâches précédant celles gérées par l’agent WF 4. Ils transmettent à ce dernier les probabilités P d’avoir terminé l’exécution de leurs tâches avant les instants t1, t2 et t3. Parallèlement, un agent WF réserve des créneaux horaires auprès des agents de ressources (message ). Ces derniers répondent à cette requête en lui communiquant les taux d’occupation pour tous les créneaux horaires que l’agent souhaite réserver (message ). En fonction des réponses reçues (probabilités des tâches prédécesseurs et taux d’occupation des ressources), il calcule la priorité de chacune de ses tâches. Cette valeur est ensuite utilisée pour modifier sa demande de réservation de ressources, car les tâches dont la probabilité reste en dessous d’un seuil donné ne feront plus objet d’une réservation. Par ailleurs, les agents en charge des tâches successeurs reçoivent une notification de la modification des probabilités d’exécution des tâches gérées par cet agent (message ).
Figure 18 : Diagramme d’état de l’agent WF
Figure 19 : Propagation des probabilités d’exécution des prédécesseurs
Ce mécanisme est réitéré jusqu’à ce que les valeurs de priorité n’entraînent plus de changement dans la réservation. Si à la fin d’un cycle de négociations, une des tâches a été élue pour exécution, l’agent WF correspondant reçoit un message . Dès lors, l’agent WF peut accéder à la ressource et exécuter sa tâche, pendant l’unité de temps indivisible qui lui est allouée. Au début de chaque créneau horaire, l’agent doit ré-négocier l’accès aux ressources selon le modèle décrit ci-dessus.
III.4.2 Modèle de l’agent de ressources Le rôle d’un agent de ressources se décline sous la forme de trois fonctionnalités. D’abord, il gère l’accès des agents WF aux ressources, selon les valeurs de priorité. Ensuite, il informe ces derniers du taux d’occupation estimé de sa ressource, leur permettant ainsi d’établir un ordonnancement prévisionnel des tâches à exécuter. Finalement, il notifie son état à l’agent manager, qui se charge de synchroniser les activités des différents agents et de détecter des blocages éventuels. La Figure 20 illustre l’architecture d’un agent de ressources. Ce dernier réagit à deux types d’événements externes. Le premier concerne la réception de messages des autres agents pour la réservation de la ressource et de messages pour la synchronisation des négociations. Le second type d’événement est lié à la disponibilité de sa ressource, ce qui permet d’informer les autres agents de toute modification survenue. Un agent de ressources répond aux événements externes en fonction de ses connaissances internes. Ces dernières peuvent être différenciées, tout comme chez un agent WF, en capacités sociales, liées à l’environnement multi-agents et en croyances individuelles, mises à jour en fonction de l’observation de l’état courant du système à travers les événements détectés.
Figure 20 : Architecture d’un agent de ressources La Figure 21 illustre le diagramme d’état d’un agent de ressources. Typiquement, le comportement de l’agent consiste d’abord à recevoir les réservations de créneaux horaires d’un agent WF, comportant les identificateurs et les valeurs de priorité des tâches que ce dernier souhaite exécuter (message ). L’agent de ressources renvoie des valeurs qualifiant le taux d’occupation de sa ressource (message ), ce qui permet à l’agent WF d’adapter les priorités et de modifier ses réservations. La Figure 22 montre un exemple comportant un agent WF et un agent de ressources : (1) L’agent WF réserve une ressource pour trois créneaux horaires t1, t2 et t3. (2) Pour la réservation, il tient compte des probabilités d’exécution des prédécesseurs de ses tâches. Lorsqu’une probabilité d’exécution est égale à 0, pour un créneau horaire tx, l’agent n’effectue pas de réservation. (3) L’agent de ressources reçoit les nouvelles réservations et répond par l’envoi de ses nouveaux taux de disponibilité pour les instants t1, t2 et t3. (4) Le taux de disponibilité est égal à 1 divisé par le nombre de réservations effectuées par les différents agents WF pour un instant tx, ou à 1, au cas où aucune réservation n’a été effectuée. (5) Ensuite, l’agent WF intègre les taux de disponibilité dans ses calculs de probabilité d’exécution. Lorsqu’il n’y a plus de modification des réservations, l’agent WF informe l’agent de ressources que ses réservations sont validées (message Finished). Une fois que l’agent de ressources a reçu les messages de validation de tous les agents workflow souhaitant réserver des créneaux horaires, il détermine la tâche ayant la plus grande priorité et en informe l’agent WF concerné (message ). Il informe également l’agent superviseur de la fin de l’ordonnancement (message Finished).
Figure 21 : Diagramme d’état de l’agent de ressources
Figure 22 : Mécanisme de réservation pour une ressource
III.4.3 Modèle de l’agent manager L’agent manager démarre une instance du workflow en instanciant des agents et en leur affectant des tâches à exécuter. Il contrôle l’exécution de ces tâches et synchronise les négociations entre les agents WF et les agents de ressources. Il peut y avoir un seul agent manager ou bien plusieurs, selon le contexte de l’application. Dans le cas d’un workflow comportant des participants appartenant à des entreprises différentes, au moins un agent manager par entreprise est nécessaire. Ces agents doivent gérer de façon hiérarchique la progression et la cohérence globale du workflow. Le découpage hiérarchique des systèmes multi-agents est une approche bien adaptée au traitement de problèmes complexes. Elle correspond bien à l’organisation humaine et offre un moyen efficace de contrôle et de remontée d’informations [78]. L’architecture interne de l’agent manager, représentée Figure 23, diffère de celle des agents WF et des agents de ressources du fait de sa nature proactive. Le module réactif a été remplacé par un module d’intentions. Ce type d’agent vérifie régulièrement à l’aide de son module de supervision l’état de l’instance de workflow dont
il est responsable et prend des mesures correctives lorsqu’il détecte un problème. Son module de connaissances contient à la fois des capacités génériques, du « savoir-faire », comme les mesures à prendre lors de la détection d’erreurs et des connaissances liées à l’état courant de l’instance de workflow. L’agent manager connaît l’état courant des négociations en cours, à travers des messages d’information, émis par les agents négociants.
Figure 23 : Architecture de l’agent manager L’agent manager a trois rôles : Le premier concerne le démarrage d’une instance de workflow, basé sur les données d’un schéma workflow, en général disponible sous forme de fichier. Après lecture et analyse de ce fichier, il initie la création d’agents de ressources et répartit les tâches en séquences qu’il alloue aux agents WF. Le deuxième rôle de l’agent manager est la synchronisation de la négociation entre les différents agents. Nous faisons l’hypothèse que le temps de négociation est négligeable par rapport au temps que nécessite l’exécution des tâches ; néanmoins, il est nécessaire de le borner. L’agent manager donne un « top d’horloge » quand un cycle de négociation est terminé, signifiant ainsi que l’exécution d’une tâche peut commencer. Le mécanisme employé pour la synchronisation est le suivant : L’agent manager reçoit des messages des agents de ressources, faisant état d’une négociation avec des agents WF (message NodeBusy). L’agent superviseur tient ainsi une liste interne des agents de ressources en cours de négociation. Après réception du message indiquant que le dernier des agents de ressources vient de terminer la communication avec les agents WF (message Finished), l’agent manager se met en latence pendant un temps prédéfini afin d’éviter des « race conditions ». De telles situations peuvent survenir lorsqu’un agent de ressources suppose que sa négociation est terminée, alors qu’un message qui lui est destiné est encore « en route » (c' est-à-dire qu’il est encore dans la file d’attente des messages). Pour exclure la perte d’un tel message, l’agent manager ne déclenche la fin du cycle de négociation et le début de l’exécution des tâches, que s’il ne reçoit plus aucun message pendant le temps de latence. Le message pour cette synchronisation (message TIME_STEP) est diffusé à tous les agents (en anglais : « broadcast »). Le dernier rôle de l’agent manager consiste à contrôler la progression générale du workflow. Lorsque, pour une raison quelconque, un agent de ressources reste bloqué pendant un temps supérieur à un seuil donné, l’agent manager déclenche un traitement d’exception : il rétablit le dernier état stable et initie la reprise de l’exécution de l’instance du workflow à partir de ce point. Dans ce mémoire, cette fonctionnalité n’est pas détaillée. Des mécanismes de gestion d’exceptions et de reprise ont fait objet de plusieurs travaux de recherche. A titre d’exemples, on peut citer le mécanisme générique de reprise du dernier état stable décrit dans [76] et le traitement d’exceptions dans un workflow développé dans [77]. La Figure 24 illustre le diagramme d’état d’un agent manager. On y retrouve les messages nécessaires pour la synchronisation de l’exécution d’une instance de workflow (Busy, NodeBusy, Finished et TIME_STEP). La partie concernant la supervision n’est pas représentée.
Figure 24 : Diagramme d’état de l’agent manager
III.5 Conclusion Il existe actuellement deux concepts fondamentaux pour l’application des systèmes multi-agents pour la gestion de workflows : Le premier concerne l’emploi d’agents mobiles, chargés de l’exécution d’une partie des tâches d’une instance de workflow et le second, la gestion réactive des ressources pour l’ordonnancement dynamique des tâches. Les approches présentées dans les chapitres I et II, adoptent chacune l’un ou l’autre des deux concepts. En intégrant les deux dans une architecture multi-agents, nous avons proposé, dans ce chapitre, une approche hybride, répondant à l’ensemble des contraintes de l’ordonnancement dans le cadre d’un workflow inter-organisationnel. Le modèle d’organisation proposé s’appuie sur trois types d’agents : 1.
Des agents migrants, ayant la responsabilité d’une partie des tâches du workflow instancié. Ils migrent de ressource en ressource en transférant leurs tâches. Ils connaissent les ressources dont ils ont besoin, ainsi que les contraintes de précédence liant directement leurs tâches à celles d’un autre agent migrant.
2.
Des agents réactifs, gérant l’accès aux ressources. Chacun a pour rôle de gérer une ressource et les demandes d’accès par des agents migrants. Nous considérons comme ressource tout poste informatique (relié au moins temporairement à un réseau informatique) avec un opérateur humain (bien que ce dernier ne soit pas toujours indispensable).
3.
Les agents chargés du démarrage et de la supervision. Ils initient l’instanciation des autres agents et contrôlent l’exécution des tâches. Un agent de ce type est appelé « agent manager ».
Dans le chapitre qui suit, nous développons les solutions méthodologique et algorithmique que nous proposons pour la gestion des interactions entre les agents définis ci-dessus.
Chapitre IV
Modèle de collaboration
IV.1 Introduction Ce chapitre a pour objectif de définir le modèle de collaboration des agents pour l’exécution distribué d’une instance de workflow. Nous proposons une approche qui divise la gestion d’un workflow interorganisationnel en deux étapes. L’intérêt de ce découpage en deux phases est de séparer dans le modèle, grâce au rôle de l’agent manager, une première phase de pré-analyse d’allocation structurelle, qui servira ensuite à piloter le contrôle, d’une seconde phase de résolution dynamique, reposant sur un processus de négociation entre les agents workflow et les agents ressource. L’idée consiste donc à séparer les entités en fonction de la nature (prévisibilité) des connaissances qu’elles manipulent. •
L’étape d’allocation de tâches - l’agent manager, analyse la description d’un schéma de workflow. Ce schéma définit les propriétés inhérentes, fixées avant toute exécution. Il inclut des spécifications sur les ressources existantes, la liste des tâches à exécuter, ainsi que les liens de précédence entre ces tâches. Il s’agit ici d’établir un ordonnancement préliminaire et une allocation des tâches aux agents à partir d’une analyse des contraintes définies dans le schéma. L’heuristique développée minimise le nombre de contraintes de précédence entre les tâches gérées par des agents différents et maximise la possibilité d’exécution parallèle de différentes tâches par des agents différents. Par ailleurs, elle exclut l’allocation à un même agent de deux tâches pouvant s’exécuter en parallèle. Durant cette étape, la disponibilité effective des ressources n’est pas prise en considération, puisque celle-ci ne sera connue qu’au moment de l’exécution du workflow.
•
L’étape d’exécution du workflow - celle-ci repose sur une méthodologie d’ordonnancement dynamique. En plus des contraintes temporelles, la disponibilité réelle des ressources est également prise en compte. Durant cette étape, les tâches sont ordonnancées selon des priorités calculées au fur et à mesure de l’exécution du workflow. Nous allons expliquer en détail la détermination des priorités dans la section IV.8.3.
IV.2 Etape 1 : Création d’agents et allocation de tâches Le concept d’agents migrants pour workflow stipule que chaque agent est responsable d’une partie des tâches du workflow, qu’il transfère avec lui d’une ressource à l’autre. Dans notre système, l’allocation des tâches aux agents WF doit d’une part, respecter les contraintes de confidentialité propres à l’entreprise (en général, un agent mobile n’est pas autorisé à migrer vers une autre entreprise) et d’autre part, l’allocation doit être faite de manière à minimiser les échanges de messages entre agents et du temps d’exécution d’une instance de workflow, comme nous l’avons indiqué dans la définition des objectifs en section III.20. Examinons les deux cas extrêmes : S’il n’y a qu’un seul agent chargé de l’exécution de tout le workflow, nous nous retrouvons dans la situation du moteur centralisé. Il n’y a pas d’échange de messages entre agents et le concept « multi-agents » n’a plus de sens. L’autre extrême correspond à l’allocation d’une tâche unique à un agent. Dans ce cas, pour garantir la cohérence globale du workflow et notamment le respect des contraintes de précédence, de très nombreux messages doivent être échangés. A cela vient s’ajouter le problème de l’ordonnancement étant donné que chaque agent n’a qu’une vue limitée de l’ensemble de tâches. La solution pour l’allocation de tâches aux agents est par conséquent un compromis entre les deux cas. Afin de minimiser le nombre de messages nécessaires pour l’établissement d’un ordonnancement acceptable, il convient d’examiner les types de messages échangés. On distingue principalement deux classes : •
Les messages liés à la réservation de ressources ;
•
Les messages liés à la vérification du respect de contraintes de précédence. En analysant l’occurrence des deux types de messages il s’avère que les premiers dépendent
essentiellement du nombre de tâches et de ressources et non de l’allocation des tâches aux agents WF. En effet, selon nos hypothèses, une tâche a toujours besoin d’une seule ressource à un instant donné : le nombre de messages nécessaires pour les réservations est donc peu variable. Seuls le nombre des messages lié à la vérification du respect des contraintes de précédence varie en fonction de l’algorithme d’allocation des tâches aux agents WF. Si un tel algorithme minimise le nombre de contraintes de précédence entre agents, il minimise en même temps le besoin d’échange de messages associés à la vérification du respect des contraintes de précédence. Un agent ne pouvant pas être à deux endroits différents en même temps, il est par conséquent exclu qu’un agent WF gère simultanément deux tâches sur deux ressources. Ce raisonnement implique que pour une utilisation optimale des ressources et une minimisation du temps global d’exécution, il est nécessaire d’allouer à des agents différents des tâches qui s’exécutent parallèlement à l’aide de ressources différentes. Nous allons même plus loin, en excluant aussi qu’un agent WF soit responsable de deux tâches susceptibles de s’exécuter parallèlement et d’utiliser la même ressource. Il s’agit d’un cas pertinent, malgré l’hypothèse de l’indivisibilité des ressources : Si par exemple deux tâches A et B ont besoin de la même ressource au même moment, il se pose alors un problème d’ordonnancement. Faut-il exécuter d’abord A puis B, ou l’inverse ? Dans l’approche proposée, un tel conflit est résolu à partir d’une négociation entre agents. Dans un souci de cohérence, il n’est donc pas souhaitable qu’un seul agent gère à la fois les tâches A et B. Seules les tâches liées par des contraintes de précédence n’ont pas de conflit potentiel lors de l’ordonnancement.
Par ailleurs, nous introduisons une classe de contraintes que nous appelons « contraintes d’exclusion confidentielle », permettant d’exclure qu’un même agent gère deux tâches soumises mutuellement à une exigence de confidentialité. Dans la Section IV.8.2, nous développons l’algorithmique d’allocation de tâches aux agents WF, minimisant le nombre de contraintes de précédence entre tâches gérées par différents agents. Une fois le nombre optimal d’agents WF déterminé, l’agent manager procède à l’instanciation de ces agents puis transmet à chacun les informations suivantes : •
L’identificateur de chacune des tâches du groupe dont l’agent sera responsable ;
•
Les identificateurs des agents responsables des ressources nécessaires pour chacune de ces tâches ;
•
L’ordre d’exécution des tâches du groupe ;
•
Pour chaque tâche liée par des contraintes de précédence à des tâches appartenant à d’autres groupes, et donc sous la responsabilité d’un autre agent WF, l’agent WF est informé de l’identificateur de la tâche liée, de la nature de la contrainte (prédécesseur ou successeur) et de l’identificateur de l’agent responsable de la tâche.
IV.3 Etape 2 : Exécution d’une instance de workflow Lors de l’exécution du workflow, un cycle de négociations est démarré au début de chaque créneau horaire, afin de déterminer les tâches à exécuter. Chaque ressource peut exécuter une tâche pendant ce créneau horaire. Il s’agit donc d’un ordonnancement au fur et à mesure où les tâches à exécuter sont élues dynamiquement, juste avant le début de leurs exécutions. Une fenêtre prévisionnelle pour chaque agent de ressources a été introduite. Elle commence à l’instant courant et va jusqu’à la limite de l’horizon prévisionnel. Ce mécanisme améliore la qualité de l’ordonnancement, grâce à la prise en compte des tâches à exécuter ultérieurement. Les planifications établies pour ces créneaux futurs n’ont pas de caractère obligatoire et peuvent être modifiées par les agents WF d’un pas à l’autre. Durant le cycle de négociations, chaque agent WF envoie une requête pour demander les valeurs des probabilités d’exécution des tâches liées aux siennes par des contraintes de précédence, mais gérées par d’autres agents WF. Ces derniers transmettent en réponse les listes des probabilités d’exécution des tâches spécifiées lors de la requête. Ces listes peuvent également être envoyées sans qu’il n’y ait eu de requête explicite, suite à une modification de la liste des probabilités d’exécution préalablement transmise. C’est la raison pour laquelle un agent WF garde en mémoire toute information envoyée pendant un cycle de négociation. Ainsi il lui est possible de savoir quels agents doivent être informés suite à une modification des probabilités d’exécution. Chaque agent WF communique également avec les agents de ressources, pour réserver des créneaux horaires pour l’exécution de ses tâches. Cette réservation concerne tous les créneaux horaires d’une fenêtre temporelle donnée, commençant à partir du créneau horaire suivant. Chaque réservation doit inclure les identificateurs et les priorités des tâches préalablement calculées par l’agent WF. Tous les agents WF reçoivent en échange une liste des taux d’occupation pour chacun des créneaux horaires sollicités. A la fin d’un cycle de négociations, marquée par un message diffusé par l’agent manager, les agents de ressources sélectionnent la tâche ayant la plus grande probabilité, pour exécution au créneau horaire courant. Ils en informent l’agent WF responsable, qui peut ensuite accéder à la ressource pour la durée d’exécution de cette tâche. Les autres agents sont également informés de la non satisfaction de leurs demandes de réservation. Une fois l’exécution d’une tâche terminée, l’agent WF en informe l’agent manager, puis sollicite la ressource suivante dont il a besoin. Deux situations peuvent conduire un agent à ne pas avancer dans l’exécution de sa séquence de tâches, soit il n’a pas été élu pour l’accès à une ressource, soit il attend la fin d’exécution des tâches qui précédent les siennes. Dans ce cas, il attend la libération des ressources et la terminaison des prédécesseurs. Un agent n’ayant plus de tâches à effectuer est éliminé du système.
IV.4 Communication entre agents Dans le modèle de communication proposé, les différents agents communiquent à travers des messages en XML, respectant un schéma XSD que nous avons développé (cf. Tableau 2). Le schéma XSD est reproduit entièrement dans l’Annexe II. Le Tableau 3 décrit les messages non XML, servant seulement à synchroniser la négociation entre agents.
/Niveau hiérarchique (imbriquée dans)
Attributs
Provenance
Destination
Description /1er
maxdur1
Fichier scénario
Agent manager Contient les données
d’un scénario pour un workflow à exécuter /2nd (agentdata)
name
Fichier scénario
Agent manager
Décrit une ressource qui sert à effectuer des tâches /3e (node)
name, length, resourcereq2
Fichier scénario
Agent manager
Décrit une tâche qui doit être effectuée à l’aide de la ressource /4e (task) manager /1er
node_name, task_name
Fichier scénario
Agent
Définit un lien de précédence entre la tâche et son successeur ordered3, time_step4
Agent manager Agent WF
Message
d’allocation d’une séquence de tâches à effectuer par un agent WF /2nd (tasklist)
name, resource_node, sequence_ number5 Agent WF
/3e (task)
/1er
Agent manager
Description des tâches de la séquence agent_name, sequence_ number
Agent WF
Prédécesseurs et successeurs de la tâche
time_step
Agent WF
Agent WF
Agent manager
Requête des probabilités d’exécution des
tâches gérées par différents agents WF /2nd (requestProba)
sequence_ number
Agent WF
Agent WF
Désignation des tâches dont la probabilité est demandée /1er
time_step
Agent WF
Agent WF
Réponse à la requête des valeurs des
probabilités d’exécution /2nd (probaValues) Agent WF /3e (task)
sequence_ number, doesn’t_exist6
Agent WF
Désignation des tâches dont la probabilité d’exécution est communiquée time_slot7, value
Agent WF
Agent WF
Les valeurs de probabilité d’exécution des tâches /1er
time_step
Agent WF
Agent de ressources Requête de
réservation de ressources /2nd (reserveResources) ressources
time_slot, task, utility8
Agent WF
Agent de
Désignation de la tâche et du créneau horaire pour la réservation
/1er
time_step
Agent de ressources
Agent WF
Message caractérisant la disponibilité d’une ressource /2nd (resAvailability)
time_slot, value
Agent de ressources Agent WF
Créneau horaire et disponibilité de la ressource
Remarques 1
Durée maximale de l ‘exécution du scénario 2 L’identificateur (name), la durée (length) et le besoin en ressources
(resource_req) de la tâche 3 Des tâches d’une liste non ordonnée peuvent être exécutées dans n’importe quel ordre 4 L’attribut time_step est l’unité de temps global au moment de l’envoi d’un message 5 Les agents WF et les agents de ressources n’utilisent pas l’identificateur unique des tâches, mais seulement un numéro de séquence, lorsqu’ils communiquent entre eux 6 Une requête pour les valeurs de probabilité d’exécution d’une tâche qui n’existe pas/plus a été effectuée 7 time_slot désigne un créneau horaire 8 « utility » n’est rien d’autre que la priorité de la tâche pour laquelle l’agent WF souhaite effectuer une
réservation
Tableau 2 : Messages XML pour la communication entre agents
Message
Emetteur
Destinataire
Description
Hello
Agent WF
Agent manager
Indique qu’un agent WF est opérationnel
NodeBusy
Agent de ressources
Agent manager
Un agent de
ressources est entré en négociation avec un ou plusieurs agents WF Finished
Agent WF
Agent de ressources
Un agent WF a terminé ses requêtes de
réservation avec l’agent de ressources Finished
Agent de ressources
Agent manager
Envoyé après que
tous les agents WF concernés aient terminé leurs réservations Finished
Agent WF
Agent manager
Un agent WF n’a plus de tâches à exécuter
TERMINATED
Agent manager
broadcast
Envoyé après que tous les agents WF aient fini
Agent manager
broadcast
Message diffusé après la terminaisun d’un cycle
toutes leurs tâches TIME_STEP
de négociation entre les agents WF et les agents de ressources
Tableau 3 : Messages pour la synchronisation des négociations
IV.5 Traitement de points de décision dans un schéma workflow Généralement, le schéma d’un workflow comporte de nombreux points de décision, où la suite des tâches à exécuter est déterminée en fonction des résultats des tâches précédentes Les points de décision sont souvent représentés graphiquement par des losanges, comme sur la Figure 2, ou textuellement par le terme branchement multiple, selon la WfMC. A titre d’exemple, il existe des tâches de validation pouvant mener soit à une poursuite de l’exécution des tâches, soit à un retour à la tâche antérieure. Lors de l’allocation initiale des tâches aux agents WF, on distingue trois possibilités de traitement de ces « interruptions ». Premièrement, les points de décision peuvent être considérés comme des points de terminaison d’une instance de workflow. Dans ce cas, l’exécution s’arrête et une nouvelle instance est créée, en fonction de la décision prise par l’agent manager. Une deuxième solution au problème des points de décision consiste à classer et à allouer les tâches aux agents WF selon les issues probables de ces décisions. L’instance du workflow est créée en ne considérant que les séquences de tâches les plus probables. Par exemple, si la validation d’une facture est positive à 90%, on ne garde que la branche « validation positive » du workflow. Une décision qui conduirait à la poursuite de l’exécution du workflow selon la séquence la moins probable, serait considérée comme une perturbation. Cette décision engendre alors un traitement d’exception qui se traduit par une reprise de contrôle de l’agent manager et un redémarrage de l’exécution à partir de l’étape précédant la prise de décision.
Une troisième alternative au problème précédent consiste en l’instanciation parallèle de toutes les branches de l’arbre de décision lors du démarrage de l’exécution du workflow. Les agents WF responsables des branches dont les conditions d’activation ne sont jamais validées, restent dans le système sans jamais exécuter leurs tâches. Cette approche présente l’inconvénient d’alourdir le système à cause de la communication et la consommation de ressources des agents inactifs. Dans le cadre du présent travail, nous n’avons pas pu trancher entre les trois alternatives énumérées. Le choix d’une solution dépend fortement du contexte spécifique du workflow traité. Des analyses plus approfondies seront certainement nécessaires pour l’évaluation des avantages et des inconvénients de chacune de ces approches pour une application donnée.
IV.6 Cohérence globale et comportement cyclique Tout système de gestion de workflow distribué est confronté à deux difficultés majeures : •
Le respect de la cohérence globale - Les tâches à exécuter à des endroits différents sont liées par des contraintes. La décision d’exécution d’une tâche est prise en fonction de la vue de chaque participant. Pour que le respect de ces contraintes soit garanti, il est nécessaire de communiquer l’état des tâches aux différents lieux d’exécution. La conformité d’une décision par rapport aux contraintes imposées ne peut être assurée que si les paramètres nécessaires sont disponibles à l’instant et à l’endroit appropriés.
•
L’occurrence de comportements cycliques - Lors de la négociation entre les agents, l’état de chaque agent est modifié en fonction des informations reçues. Cette modification peut avoir une influence sur la suite de la négociation, ce qui modifie à nouveau l’état d’un agent. Ainsi, la négociation peut présenter des comportements oscillants. Dans cette section, nous analysons les deux problématiques évoquées ci-dessus et présentons les solutions
pour y remédier.
IV.6.1 Respect de la cohérence globale Un des problèmes liés à la nature distribuée de l’approche proposée est celui de l’asynchronisme des propagations des valeurs probabilistes pour la prise en compte des contraintes de précédence. Si on considère que le temps de négociation entre les agents est négligeable par rapport à la durée d’un créneau horaire, il n’existe aucun risque d’atteindre un état ne satisfaisant pas les contraintes de précédence, car l’information relative à l’état des prédécesseurs est dans tous les cas transmise avant le début de l’exécution des successeurs. La Figure 25 illustre un scénario où les contraintes de précédence sont validées avant le début du processus d’élection de la tâche à exécuter.
Figure 25 : Validation des contraintes de précédence en fonction de l’état des tâches Même si la période de négociation est très courte, il subsiste toujours une difficulté pour détecter la fin de cette période. Pratiquement, la solution retenue passe par l’emploi d’une heuristique : l’agent manager fait attendre les agents un certain temps après l’envoi du dernier message de réservation de ressources ou de propagation de valeurs probabilistes, avant de déclencher le processus d’exécution d’une tâche (cf. modèle comportemental d’un agent manager en Section III.4.3). Ainsi, d’éventuels messages en cours de transmission ou de traitement peuvent être pris en compte.
IV.6.2 Traitement des oscillations Les agents WF réservent les ressources selon la probabilité estimée pour l’exécution de leurs prédécesseurs. Or, cette estimation est basée sur les probabilités d’exécution des prédécesseurs, qui eux aussi peuvent avoir besoin de cette ressource. Le système peut donc se retrouver dans un état oscillant. Pour illustrer ce problème, considérons l’exemple d’un agent « x » qui réserve une ressource pour une tâche dont la probabilité d’exécution se situe au-dessus du seuil nécessaire pour la réservation, diminuant ainsi la disponibilité de cette ressource. L’agent responsable de la ressource informe alors les autres agents ayant effectué des demandes de réservations de cette nouvelle disponibilité. En conséquence, ces agents re-estiment leurs probabilités et en informent leurs successeurs, qui adaptent leurs estimations à leurs tours. Si l’agent « x » fait partie des successeurs, la probabilité d’exécution de sa tâche peut tomber en dessous du seuil nécessaire pour la demande d’une réservation, ce qui l’amène à l’annuler. L’agent de ressources informe alors les autres agents WF de l’augmentation de sa disponibilité et le cycle recommence de nouveau. Pour traiter ce problème d’oscillations, nous introduisons un coefficient d’amortissement, réduisant progressivement l’impact de nouvelles réservations sur l’estimation des disponibilités des ressources, jusqu’à l’obtention d’un état stable. Bien entendu, ce mécanisme ne garantit pas que cet état soit optimal par rapport à notre objectif multi-critères.
IV.7 Exemple d’exécution d’un workflow La Figure 26 illustre un exemple de diagramme de collaboration selon le standard UML. Le scénario comporte deux agents WF, un agent de ressources et un agent manager. Après analyse du fichier décrivant le schéma de workflow (message 1 dans Figure 26), l’agent manager instancie l’agent de ressources (message 2), calcule le nombre optimal d’agents WF (deux dans notre exemple), puis alloue à ces agents des séquences de tâches (messages 3-6). Les agents WF réservent des créneaux horaires pour l’exécution de leur tâches (messages 7, 12) et obtiennent en échange les informations relatives à la disponibilité de la ressource (messages 9, 13, 14), pour la mise à jour des probabilités d’exécution et des priorités des tâches. Cette mise à jour est ensuite propagée aux autres agents WF (messages 10, 11, 15, 16). Une fois le cycle de propagation/réservation terminé, l’agent manager procède à la synchronisation de la fin du cycle de négociation (messages 20-22). Pour le premier créneau horaire, l’agent de ressources autorise alors l’accès à sa ressource à la tâche de plus grande priorité (message 23).
Figure 26 : Diagramme de collaboration pour l’exécution d’un scénario modèle
IV.8 Formulation algorithmique IV.8.1 Définitions Soit un ensemble de tâches T={T1 ; T2 ; … ; Tn}. A chaque tâche Ti sont associés une contrainte de ressources Cres(Ti), un temps de démarrage Tstart(Ti) et une durée D(Ti). Les tâches sont liées par un ensemble de contraintes de précédence Cpr={Cpr1 ; Cpr2 ;…; Cprm} et par un ensemble de contraintes d’exclusion confidentielle Cex={Cex1 ; Cex2 ;…; Cexn}. Les contraintes de précédence et d’exclusion confidentielle sont chacune caractérisées par deux tâches Ti et Tj. Un ordonnancement valide doit respecter l’équation Tstart(Ti) + D (Ti) < Tstart(Tj) pour toutes les Cpr(Ti,Tj)∈Cpr. L’allocation de deux tâches à un même agent WF n’est autorisée que s’il n’existe pas de contrainte d’exclusion confidentielle entre les deux :
∃ Cex (Tx , Ty ) ∀ Tx , Ty ∈T
Par ailleurs, la contrainte d’exclusion mutuelle sur l’utilisation d’une ressource impose que Cres(Tx)≠Cres (Ty) doit être valable à tout instant t pour toutes les Tx,Ty∈T et x≠y.
IV.8.2 Algorithme d’allocation de tâches aux agents WF La classification des tâches en groupes s’effectue avant l’exécution d’une instance de workflow. L’approche que nous avons retenue consiste à allouer à chaque agent WF une séquence de tâches liées entre elles par des contraintes de précédence directes. Cette procédure assure qu’aucun agent WF ne sera chargé de l’exécution parallèle de deux tâches. Par ailleurs, l’algorithme minimise le nombre de contraintes de précédence entre tâches gérées par des agents différents. Plus formellement, l’allocation de tâches à des agents consiste à trouver une partition Part={G1 ; G2 ; … Gm} de T en m ensembles (ou groupes) disjoints, tels que ∃ Cpri(Tj,Tk) pour toutes les tâches Tj,Tk∈Gx, avec j ≠ k et {Groupe1 ∪ Groupe2 ∪ … ∪ Groupem} ↔ T. Une répartition optimale Part* minimise |({Cpri(Tj,Tk) | Tj∈Groupex ; Tk∈Groupey ; x≠y ; i≠k}| .
La solution proposée pour le partitionnement comprend deux étapes :
Première étape : Déterminer un ordonnancement valide, basé sur l’hypothèse qu’il existe des ressources illimitées Durant cette étape, un numéro d’ordre Nor est alloué à chaque tâche Tx, en fonction des contraintes de précédence : D’abord, le numéro « 0 » est attribué à l’ensemble des tâches T. Ensuite, toutes les tâches qui n’ont pas de prédécesseur sont numérotées « 1 ». Finalement, les tâches qui n’ont pas de prédécesseurs sans numéros sont numérotées « 2 », etc. Cette procédure est réitérée jusqu’à ce que toutes les tâches soient numérotées. De façon formelle, on écrit :
N or (Ty ) :=
{
}
Max({ N or (Tx )}) + 1, si Cpr (Tx ,Ty ) N or (Tx ) = 0 = ∅ ; ∀Tx ,Ty ∈ T ; x ≠ y 0,sinon
Nous déterminons ainsi un ordonnancement conforme aux contraintes de précédence, mais ne prenant pas en compte les contraintes de ressources, qui ne seront connues que lors de l’exécution du workflow (cf. Section IV.3).
Deuxième étape : Partitionner l’ensemble des tâches Cette étape détermine l’ensemble « Part » des groupes Gx. Le nombre de groupes |Part| définit le nombre d’agents WF devant être instanciés. L’algorithme suivant est exécuté jusqu’à ce que toutes les tâches aient été attribuées à un groupe : b) Un compteur c est initialisé à 1. c) On crée autant d’ensembles (groupes) Gi qu’il y a de tâches Tx ayant le numéro d’ordre Nor(Tx)=c. Chaque ensemble contient au départ une seule de ces tâches :
G i = {Tx N or (Tx ) = 1} ∧ G i = 1 ∧ G i ∩ G j = ∅ ∀G i , G j ∈ Part ; i ≠ j Les nouveaux groupes sont ajoutés à l’ensemble des partitions : Part = {Part ∪ Gi} d) Chaque groupe Gk ∈ Part se voit affecté une tâche supplémentaire Ty, choisie parmi les tâches non attribuées. Ty est élue selon les critères suivants : •
Elle doit être le successeur de la dernière tâche affectée au groupe, autrement dit, il existe une contrainte de précédence Cpr(Tx,Ty)
•
Il n’y a pas de contrainte d’exclusion confidentielle entre Ty et une des tâches affectées auparavant au groupe :
•
∃Cex (Tx , Ty ) ∀ Tx ∈G k
Si plusieurs tâches satisfont au critère précédent, celle ayant le numéro d’ordre minimal est élue.
•
Dans le cas où il y aurait plus d’une tâche avec le même numéro d’ordre minimal, celle qui nécessite la même ressource que son prédécesseur Cres(Tx)=Cres(Ty), est choisie. Un tel critère permet de minimiser les migrations des agents WF lors de l’exécution.
Le groupe est considéré comme complet quand la dernière tâche qui lui est affectée n’a plus de successeurs :
∃ Cpr (Ty , Tz ) ∀ Tz ∈T
.
e) Tant qu’il reste des tâches non affectées, le compteur c est incrémenté et le processus reprend à l’étape b) La Figure 27 illustre un exemple d’application de cet algorithme à un scénario comportant 6 tâches et une seule ressource. Les étapes représentées sont : 1.
Le scénario avec les tâches et leurs contraintes de précédence ;
2.
l’attribution des numéros d’ordre ;
3.
instanciation de deux groupes à l’initialisation ;
4.
instanciation du troisième groupe ;
5.
allocation de la dernière tâche.
Figure 27 : Etapes de l’algorithme d’allocation de tâches aux agents WF La Figure 28 illustre un scénario généré aléatoirement. Les tâches sont représentées par des cercles, le besoin de ressources par différentes hachures et les contraintes de précédence par des flèches. Chaque tâche dure une unité de temps discret. La Figure 29 représente le même scénario qu’en Figure 28, mais après allocation des tâches aux agents WF. Dans cet exemple, neuf agents WF sont chargés de l’exécution du workflow.
Figure 28 : Etape 1 - Ordonnancement avec ressources illimitées
Figure 29 : Etape 2 - Répartition des tâches en groupes disjoints
IV.8.3 Algorithme de calcul des priorités des tâches Le calcul de la priorité de la tâche Tx passe par l’estimation des occupations futures des ressources dans
une fenêtre temporelle, commençant à l’instant courant et se terminant à la fin de l’horizon prévisionnel. Cette fenêtre est discrétisée en créneaux horaires de taille fixe [t0, t1, … , tend]. Dans , la priorité d’exécution estimée Ux au moment t0 d’une tâche Tx, pour l’intervalle [t0;tn] est donnée par :
U x ([t0 , tn ]) :=
1 ∆t
Tx successor
(tn )
Tx ⋅ Pexecution ([t0 ; tn ]) ; t0 ≤ tn ≤ tend
∆tsuccessor est le délai entre l’instant tn et l’instant où l’activation du successeur de la tâche Tx , géré par le même agent WF, devient probable. Pexecution représente la probabilité de terminer l’exécution d’une tâche dans l’intervalle [t0;tn], respectant les deux contraintes suivantes : (1) toutes les tâches antérieures à l’exécution de la tâche Tx se terminent avant l’instant tn (contraintes de précédence) (2) la ressource nécessaire à l’exécution de la tâche est disponible au même instant tn (contrainte de ressource). Dans le cas de ressources unaires, hypothèse retenue dans le cadre de ce mémoire, la valeur de disponibilité des ressources est la même pour toutes les tâches sollicitant une même ressource. Par conséquent, ce paramètre ne modifie pas l’ordre des priorités. Dans l’optique de l’assouplissement de nos hypothèses, nous le conservons quand même dans le calcul des priorités. Par ailleurs, ce terme intervient dans le calcul des probabilités d’exécution des tâches successeurs. Il peut modifier l’ordre des tâches, par le biais de la variable ∆tsuccessor, car les différentes tâches successeurs nécessitent des ressources différentes. Le calcul de cette valeur de probabilité repose sur deux paramètres : •
La probabilité de disponibilité d’une ressource dans un créneau horaire tn : Pavailable(tn)
•
La probabilité d’exécution préalable des prédécesseurs de la tâche : Pexecution([t0;tn-1]) Tx resourcek Pexecution ( tn ) := Pavailable ( tn )
ΠP
Ty ∈Tpr
Ty execution
([t ; t ]) 0
n −1
L’ensemble Tpr contient les prédécesseurs non exécutés à l’instant t0, de la tâche Tx : Tpr ={Ti| ∃Cpr(Ti,Tx)}. En réalité, ce qui nous intéresse n’est pas seulement la probabilité que la tâche soit exécutée précisément dans le créneau horaire tn, mais plutôt sa probabilité cumulée d’être exécutée dans l’intervalle [t0;tn]. Il convient donc de cumuler les probabilités que la tâche ait été exécutée auparavant avec la probabilité Pexecution(tn) pour obtenir Pexecution([t0;tn]) :
Tx Tx Pexecution ( tn ) ([t0 ; tn ]) := 1 − 1 − Pexecution
tn−1
∏ t =t0
Tx 1 − Pexecution ( [ t0 ; t ] )
Cette formulation représente l’inverse de la probabilité que la tâche ne soit exécutée à aucun moment de l’intervalle [t0;tn].
Ainsi, les probabilités Pexecution des tâches gérées par le même agent WF sont calculées par l’agent luimême, alors que celles des tâches gérées par d’autres agents WF sont obtenues, à partir d’une requête envoyée aux agents responsables de ces tâches. Après estimation des priorités d’accès aux ressources pour le créneau horaire courant, les agents WF transmettent ces valeurs aux agents de ressources, pour l’élection de la tâche autorisée à utiliser la ressource. En plus de la réservation pour le créneau horaire courant, chaque agent WF réserve des créneaux horaires pour le futur (à partir de l’instant t0+1 jusqu’à tend), en fonction des priorités de ses tâches. Si pour un créneau horaire, la priorité calculée est supérieure à un seuil donné, l’agent WF transmet à l’agent de ressources sa demande de réservation. Un agent de ressources peut accepter plusieurs réservations pour le même créneau, pour des tâches différentes. Cependant, une seule tâche pourra s’exécuter, les autres réservations seront annulées. Selon le nombre de réservations reçues de tous les agents WF, l’agent de ressource calcule son occupation Toccupation pour un créneau horaire tn : ressource
Toccupationy (tn ) :=
tn reservationsressource y
En ce qui concerne le calcul de la disponibilité d’une ressource Pavailable, nous proposons une estimation de la probabilité d’accès à une ressource, basée sur l’occupation. Pour un créneau horaire donné, on peut estimer que la probabilité pour une tâche d’être admise à une ressource donnée est inversement proportionnelle à son occupation Toccupation , ou maximal, s’il n’y pas de réservation pour l’instant considéré : ressource
1 ,si Toccupationy (tn ) = 0 resource
Pavailable y (tn ) :=
1 ressource y occupation
T
(tn )
,sinon
Pour le calcul de la priorité d’une tâche x au moment tn selon l’équation , il reste à déterminer le terme ∆tsuccessor. Il s’agit de la distance temporelle entre l’instant d’exécution d’une tâche x et celui de son successeur y. Lors de la détermination de ∆tsuccessor, un agent WF ne considère que les successeurs dont il à la charge. Ainsi, il analyse les probabilités d’exécution Pexecution de sa tâche y à partir du moment tn jusqu’à la fin de la fenêtre temporelle. Au premier créneau tm (avec m > n) où la valeur probabiliste Pexecution de la tâche y dépasse un seuil donné (à titre d’exemple, dans nos expérimentations, ce seuil était fixé à 5%), nous estimons que la tâche y devient exécutable. Dans ce cas, ∆tsuccessor n’est donc rien d’autre que la différence tm-tn. Dans le cas où la probabilité d’exécution de la tâche y ne dépasse pas le seuil imposé jusqu’à la fin de la fenêtre temporelle, ou si la tâche x n’a aucun successeur, nous posons tm := tend (le dernier créneau de la fenêtre). Si la tâche a des successeurs gérés par d’autres Agents WF, ∆tsuccessor est mis à « 1 ». L’agent WF peut ainsi déterminer successivement la priorité de toutes les tâches pour tous les créneaux horaires de la fenêtre temporelle. Cependant, il faut prendre en considération que les paramètres calculés pour une tâche peuvent influer sur les paramètres d’autres tâches du même agent. Le calcul des priorités et des probabilités s’effectue donc de façon itérative, jusqu’à l’obtention d’un état où les valeurs calculées restent stables. Pour détecter un état stable, les dernières valeurs calculées sont mémorisées, puis comparées aux nouvelles valeurs
calculées. Le calcul est arrêté lorsque plus aucune modification n’est détectée. Pour éviter les problèmes d’oscillations décrits dans la section IV.6, nous introduisons un coefficient de pondération de l’influence des modifications γressource. Le coefficient est fixé à 1 au départ d’un cycle de négociation. Il est diminué d’un pas ε fixe à chaque nouvelle réservation, jusqu’à ce qu’il atteigne 0. La mise à jour des taux d’occupation d’une ressource se calcule de la façon suivante :
Toccupationy (tn ) new := γ Toccupationy (tn )new + (1 − γ ) Toccupationy (tn )old ressource
ressource
ressource
IV.8.4 Complexité algorithmique La complexité algorithmique constitue un indicateur du coût de l’exécution d' un algorithme, ou plus précisément, sa consommation en terme de ressources. Elle mesure le nombre d' opérations élémentaires et parfois aussi le besoin en espace mémoire pour le scénario « pire cas », c’est-à-dire la borne supérieure de la fonction de coût associée à l’exécution de l’algorithme. Dans notre cas, on dénombre deux ressources nécessaires pour l’ordonnancement de tâches : la capacité de calcul des postes informatiques participants et la capacité du réseau informatique qui les relie. La première ressource, la capacité de calcul, est utilisée lors de la détermination des paramètres caractérisant les tâches, notamment les probabilités d’exécution et les priorités. La deuxième ressource, le réseau informatique, est sollicitée lors de l’échange de messages entre les différents agents. La complexité algorithmique du système complet est composée des coûts calculatoires des algorithmes des différents agents, ainsi que du coût d’utilisation du réseau informatique pour l’échange de messages. Nous ne considérons ici que les agents WF et les agents de ressources. L’agent manager n’intervient en cours d’exécution que pour la synchronisation des échanges, nous jugeons le volume du trafic généré par ses messages négligeable par rapport à ceux des autres agents. Dans ce qui suit, nous n’analysons donc que la complexité algorithmique des agents WF, des agents de ressources et du protocole de négociation.
Complexité algorithmique des agents WF Tout d’abord nous analysons le besoin calculatoire des agents WF : Les équations - de la section IV.8.3 montrent que la détermination des valeurs de probabilité d’exécution et de priorité des tâches est basée sur le calcul des probabilités d’exécution des prédécesseurs et sur l’évaluation des taux d’occupation des ressources. La complexité algorithmique de ce calcul dépend des paramètres suivants : 1.
Le nombre d’agents WF dans le système, Na.
2.
Le nombre de tâches gérées par un agent WF, Nt.
3.
Le nombre de prédécesseurs des tâches considérées, c' est-à-dire le nombre de contraintes de précédence inter-agents, Np.
6.
Le nombre de créneaux horaires discrets de la fenêtre temporelle, Nc.
Figure 30 : Pseudo-code pour la détermination de la priorité d’une tâche La complexité de calcul de la priorité et de la probabilité d’exécution des tâches d’un agent WF peut être déterminée en analysant le pseudo-code de l’algorithme (Figure 30). Il s’agit de trois niveaux de boucles imbriquées et invoquées itérativement. Si l’on considère que chaque calcul a le même coût χ, on obtient pour un nombre d’itérations I :
(
CagentWF := I χ N t N c 2 + N c ( N p + 5 )
)
Complexité algorithmique des agents de ressources La complexité algorithmique des agents de ressources se définit en fonction des paramètres suivants : Nm - le nombre de messages de réservation reçus Nr - le nombre de réservations effectuées à l’aide d’un seul message Nc - le nombre de créneaux horaires de la fenêtre temporelle considérée Na - Le nombre d’agents ayant effectué des réservations
Figure 31 : Pseudo-code pour le calcul de la disponibilité d’une ressource Dans le pire cas, tous les agents WF ont effectué une réservation auprès de l’agent de ressources considéré.
Ainsi, la complexité algorithmique de cet agent se définit comme suit :
CagentRes := χ N m ( N r + N a N c )
Complexité algorithmique du protocole de négociation Il y a deux types de messages échangés lors de la négociation entre agents : Les uns servent à la propagation des probabilités d’exécution des tâches ; leur nombre maximal est proportionnel aux contraintes de précédence inter-agents (Np). Les autres sont utilisés pour la propagation des priorités des tâches et la modification des réservations ; leur nombre maximal est proportionnel au nombre de tâches (Nt) multiplié par le nombre d’agents WF (Na). Le nombre total de messages doit être multiplié par deux, puisque tout message envoyé implique une réponse. La négociation et le re-calcul des réservations sont effectués de façon répétitive, pour le créneau horaire courant et pour un nombre de créneaux futurs. La taille de la fenêtre prévisionnelle est représentée par la variable Nc. L’intégration des nouveaux paramètres dans le calcul se poursuit jusqu’à ce qu’il n’y ait plus de modification des valeurs. Dans le pire cas, le cycle de négociation se poursuit jusqu’à ce que le coefficient d’amortissement γ atteigne 0. Ce coefficient diminue d’un pas fixe ε, à chaque échange de messages. En définissant le coût d’un message par la variable ξ, la complexité algorithmique de la négociation s’écrit :
Cnegotiation :=
2 Nc
ε
ξ ( N p + Nt N a )
Le calcul représente la borne supérieure du nombre de messages envoyés durant l’exécution d’une instance de workflow, sans tenir compte des messages nécessaires pour la synchronisation et la supervision. Ce résultat théorique a été vérifié expérimentalement dans la Section V.3.2.
IV.9 Conclusion Nous avons présenté dans ce chapitre, un modèle de collaboration, pour l’allocation et l’ordonnancement dynamique des tâches dans le contexte d’un workflow inter-organisationnel. Nous avons ainsi développé une méthodologie d’ordonnancement préliminaire et d’allocation des tâches aux agents selon un principe basé sur une analyse des contraintes définies dans le schéma du workflow. Cet algorithme ne prend pas en considération la disponibilité effective des ressources, car celle-ci n’est pas connue à l’avance. L’heuristique proposée minimise le nombre de contraintes de précédence entre les tâches gérées par des agents différents, en excluant l’allocation à un même agent de deux tâches susceptibles de s’exécuter en parallèle. Pour l’ordonnancement dynamique des tâches, nous proposons une méthodologie prenant en compte, en plus des contraintes temporelles, la limitation de la disponibilité réelle des ressources. Durant cette étape, les tâches sont ordonnancées selon des priorités calculées au fur et à mesure de l’avancement du workflow. Le calcul tient compte des probabilités d’exécution des tâches prédécesseurs et des taux estimés d’occupation des ressources. Enfin, nous avons étudié la complexité algorithmique du modèle proposé, et notamment les coûts calculatoires des algorithmes associés aux agents WF et de ressources. Pour caractériser la complexité du protocole de négociation, nous avons établi la borne supérieure du nombre de messages échangés entre agents.
Chapitre V
Test et validation
V.1 Introduction L’objet de ce chapitre est d’une part, de présenter l’implémentation de l’approche multi-agents pour la gestion de workflows dans une application logicielle et d’autre part, d’étudier les performances du modèle de collaboration proposé. Dans la première partie du chapitre, nous décrivons les caractéristiques du simulateur d’agents, que nous avons développé pour la validation de l’approche proposée. Nous expliquons en particulier les concepts utilisés pour la mise en œuvre des mécanismes de concurrence et de communication. Dans la deuxième partie, nous étudions les résultats de l’implémentation des algorithmes d’allocation de tâches et d’exécution des instances de workflow, à partir d’un ensemble de scénarii générés aléatoirement. Chaque scénario est caractérisé par un nombre de tâches, de ressources et de contraintes de précédence. Les résultats obtenus sont statistiquement évalués et comparés aux solutions optimales d’ordonnancement de tâches.
V.2 Présentation du simulateur d’agents L’implémentation et la validation des modèles présentés dans les chapitres III et IV ont nécessité l’utilisation d’un environnement logiciel de simulation. Il existe plusieurs plates-formes multi-agents, telles que ZEUS, SWARM ou MADKIT, pour n’en citer que quelques unes. Une analyse exhaustive des environnements multi-agents disponibles dépasserait le cadre de ce mémoire. Dans [88], on trouve une liste recensant déjà plus de 120 différentes plates-formes. Les plates-formes disponibles offrent des services variés, comme par exemple des gestionnaires de messages, des moteurs de coordination, des outils de planification de tâches et des bases de données. La communication s’effectue en général par des messages dont l’ontologie est normalisée selon des standards comme FIPA [86]. La plate-forme multi-agents la plus utilisée est probablement JADE (Java Agent Development Framework) [87], développée en Java par CSELT (Groupe de recherche de Gruppo Telecom, Italie). Elle permet la mise en œuvre d' applications conformes à la norme FIPA. JADE comprend deux composants de base : une plate-forme d’agents et des logiciels pour le développement des agents en Java. Pour l’implémentation de l’approche proposée dans ce mémoire, nous avons fait le choix de développer notre propre logiciel de simulation pour plusieurs raisons. Premièrement, nous avons souhaité faciliter l’intégration de modules existants, notamment la suite logicielle ILOGTM Solver/Scheduler pour la résolution de problèmes sous contraintes (cf. Section V.2.3). Ensuite, nous avons voulu gagner en rapidité d’exécution en nous affranchissant de la couche logicielle « portabilité » (Machine Virtuelle ou tout autre « middleware »). Cette couche est nécessaire pour la flexibilité de toute plate-forme multi-agents générique, mais n’apporte rien au niveau de la validation de nos algorithmes. Enfin, l’utilisation d’ontologies standardisées alourdit les protocoles de communication, ce qui est inutile dans le cadre de la validation de notre approche. Une partie importante du travail de mise en œuvre a été consacrée à la conception et à la réalisation du logiciel de simulation. L’allocation des tâches aux agents, l’instanciation d’agents, l’ordonnancement des tâches et
leur exécution ont été simulés dans cet environnement de test, afin de valider les algorithmes développés dans ce mémoire. La technologie retenue est la programmation orientée objet en C++. L’approche objet permet en particulier d’encapsuler et de protéger des données vis-à-vis du reste du système. Le concepteur de l’application n’a pas à connaître les détails de chaque type d’objet et peut facilement améliorer ou changer ces derniers. Par ailleurs, une nouvelle classe peut être facilement construite à partir d’une classe existante en utilisant le principe de l’héritage. La maintenance et l’évolutivité du système se trouvent par conséquent simplifiées par ce concept. Si la modularité et les avantages du concept de l’orienté objet sont intéressants pour la conception et la réutilisabilité du logiciel, la concurrence et la réactivité nécessaires aux différents comportements nécessitent la mise en place de certains mécanismes. Il devient alors nécessaire de définir des unités de traitement pouvant être exécutées de manière autonome, et parallèle. Nous avons ainsi décidé de simuler les différents agents par des threads parallèles asynchrones. L’environnement du développement est l’outil Visual C++ de MicrosoftTM, sur un système d’exploitation Windows. L’environnement de simulation comporte trois modules indépendants (cf. Figure 32). Le premier est le « Générateur de scénarii ». Il s’agit d’un logiciel non interactif, invoqué à l’aide d’une ligne de commande avec des paramètres spécifiant les conditions générales pour la génération aléatoire d’un scénario de test. Ce scénario est enregistré dans un fichier qui est lu par le deuxième module : le module « Exécution », permettant de simuler l’évolution d’un ensemble d’agents autonomes, en fournissant les mécanismes de communication et d’action nécessaires. C’est dans ce module que nous avons implémenté nos algorithmes d’allocation de tâches et d’ordonnancement distribué. Les résultats de l’exécution sont visualisés sous forme graphique et enregistrés sous forme de texte dans un fichier journal. Le dernier module, que nous appelons « Solveur optimal », fait appel à la suite logicielle ILOGTM Solver/Scheduler, permettant de solutionner un problème d’ordonnancement de manière centralisé, en effectuant une recherche exhaustive. Elle fournit la solution optimale de l’ordonnancement par rapport au critère du temps d’exécution de bout en bout du workflow. Enfin, nous avons utilisé des outils statistiques pour l’analyse des résultats obtenus.
Figure 32 : Modules du simulateur
V.2.1 Module « Générateur de scénarii » Pour la validation de l’approche proposée, un générateur de scénarii aléatoires a été mis en œuvre. Chaque scénario est caractérisé par •
le nombre de ressources ;
•
le nombre moyen de tâches à exécuter sur chaque ressource,
•
la probabilité que deux tâches soient liées par des contraintes de précédence.
Le nombre de ressources et le nombre moyen de tâches sont obtenus à l’aide d’un générateur de variables aléatoires, distribuées selon une gaussienne. Pour déterminer l’existence ou non d’une contrainte de précédence entre deux tâches, nous proposons l’algorithme suivant : 1.
Prendre une paire de tâches {Tx;Ty} ; x,y ∈ [1..nombre de tâches]; x ≠ y ;
2.
Générer une valeur équidistribuée entre 0 et 1 ;
3.
Si la valeur générée est plus petite que la probabilité fixée, introduire une contrainte de précédence entre Tx et Ty ;
4.
Vérifier que la contrainte introduite n’est pas en contradiction avec d’autres contraintes de précédence (par exemple Tx commence avant Ty ; Ty commence avant Tz et Tz commence avant Tx) ;
5.
Si une telle contradiction est détectée, retirer la contrainte entre Tx et Ty. Le scénario ainsi généré est enregistré dans un fichier au format XML, où figure le nom de chaque tâche,
le nom de la ressource et des successeurs qui lui sont associés.
V.2.2 Module « Exécution » Le module « Exécution » est une application qui simule les actions et les interactions d’un ensemble d’agents logiciels. Les agents sont implémentés sous forme de threads (fils d’exécution parallèles), appelés aussi processus légers. Contrairement aux processus classiques, les threads partagent le même espace mémoire. Dans le cas de notre simulateur, la communication entre les threads s’effectue à travers un objet « queue de messages ». Cet objet n’est rien d’autre qu’une zone mémoire partagée entre les threads, protégée par des méthodes restreignant l’accès. Le thread principal, qui gère le démarrage d’une simulation ainsi que l’interaction avec l’utilisateur à travers une interface graphique, est implémentée selon le modèle MFC (Microsoft Foundation Classes). Chaque agent est associé à son propre thread d’exécution, ainsi qu’à une fenêtre graphique lui permettant d’afficher des messages et des alertes. Tous les messages échangés sont codés dans le format XML et parsés à l’aide du composant MSXML de MicrosoftTM. Dans ce mémoire, nous ne présentons que les grandes lignes du modèle de classes et en particulier les principales classes et méthodes. Le modèle de classes détaillé ainsi que le code source sont disponibles dans [82].
Les classes du simulateur sont les suivantes (cf. Figure 33) : •
CWFAgentApp - La classe de l’application
•
CMessageQueue et CStructMessage - Les classes pour la communication en XML entre les threads
•
CAgentManagerThread, CWFAgentThread,et CResAgentThread - Les threads simulant le comportement des différents agents d’un workflow
•
Des classes auxiliaires
Figure 33 : Hiérarchie des classes principales du simulateur d’agents La classe CWFAgentApp CWFAgentApp, dérivée de la classe CAgentApp, est utilisée pour instancier l’objet principal de l’application. Il ne peut y avoir qu’un seul objet de ce type pour toute l’application. La classe CAgentApp, ellemême dérivée de la classe CWinApp de la MFC, assure la fonctionnalité classique d’une application Windows, en fournissant notamment une pompe de messages pour la gestion des événements liés à l' interface utilisateur. Lorsqu’un objet de la classe CAgentApp où d’une de ses classes dérivées est instancié, la fenêtre principale de l’application est créée (cf. Figure 34) et la messagerie, permettant la communication entre différents agents est initialisée. Cette classe possède également des méthodes facilitant la gestion des threads d’agents, comme par exemple la méthode CreateNewThread() pour la création d’un agent. La classe CWFAgentApp est dérivée de la classe CAgentApp, afin de personnaliser le comportement de l’application en surchargeant notamment la méthode OnLoadSimulation(). Cette méthode présente à l’utilisateur une boîte de dialogue permettant de sélectionner le fichier décrivant le scénario à exécuter.
Figure 34 : Affichage de la fenêtre principale après instanciation d’un objet du type CAgentApp Les classes CMessageQueue et CStructMessage La classe CMessageQueue permet la communication explicite entre agents. Un seul objet de ce type est
créé, auquel tout agent doit s’abonner par appel à la méthode addSubscriber(). La communication entre agents s’effectue par la méthode add(), dont le paramètre est un objet du type CStructMessage, représentant le message à transmettre. Chaque objet message comporte les noms du destinataire et de l’expéditeur, le message et éventuellement un objet binaire quelconque attaché. Pour chaque message envoyé, il est possible de définir le nombre maximum de tentatives de transmission, ainsi qu’un délai de validité. Un accusé de réception peut être généré automatiquement, lorsque le destinataire reçoit le message. La queue de messages est un objet partagé et non un thread. Etant donné la nature passive de cet objet, les threads d’agents doivent eux-mêmes vérifier régulièrement la présence de messages. Pour éviter aux agents une vérification continuelle de l’arrivée de nouveaux messages, la méthode getThreadsToNotify() a été implémentée. Elle permet à un agent de récupérer les pointeurs sur tous les objets d’agents pour lesquels il y a des messages en attente. Ainsi, il peut les informer directement en utilisant le mécanisme de notification de threads, fourni par le système d’exploitation Windows (cf. Figure 35).
Figure 35 : Synoptique du mécanisme de notification d’arrivée de messages La classe CAgentThread et ses dérivées Les agents de l’application sont simulés par des instances des classes CAgentManagerThread, CWFAgentThread, CResAgentThread et CGraphicsAgentThread. Toutes ces classes sont dérivées de la classe CAgentThread, qui hérite de CThread [79], elle-même héritière de la classe CWinThread de la MFC. La classe CThread a pour avantage d’encapsuler non seulement les mécanismes d’initialisation et de terminaison des threads de système Windows, mais aussi d’offrir un mécanisme de notification entre des threads de même type. La classe CAgentThread est à la base un simple « message handler » (pompe à messages). L’implémentation d’un objet de cette classe se résume à un affichage dans sa fenêtre graphique des messages reçus. Afin de personnaliser le comportement d’un agent, les méthodes énumérées dans le Tableau 4 peuvent être surchargées par des implémentations individuelles. Les classes dérivées utilisées dans le simulateur d’agents sont
détaillées dans l’Annexe I. CAgentThread::OnInitThread
Appelée avant le démarrage du gestionnaire des commandes
du thread. L’implémentation par défaut abonne l’agent à la queue de messages et le connecte avec l’objet gérant sa fenêtre graphique en mode texte. CAgentThread::OnExitThread
Appelée après l’arrêt du gestionnaire de commandes du
thread. L’implémentation par défaut désabonne l’agent de la queue de messages. CAgentThread::OnPause
Appelée lors de l’occurrence de la commande “PAUSE”
CAgentThread::OnRun
Appelée lors de l’occurrence de la commande “RUN”
CAgentThread::OnStop
Appelée lors de l’occurrence de la commande “STOP”
CAgentThread::OnMessage
Appelée lorsqu’un message arrive
CAgentThread::OnTimeout
Appelée lorsqu’il n’y pas d’occurrence de commandes
pendant un certain lapse de temps CAgentThread::OnUserCommand
Appelée lors de la réception d’une commande autre que
l’une de celles énumérées ci-dessus
Tableau 4 : Liste des méthodes surchargeables pour la personnalisation du comportement d’un agent
Les classes auxiliaires Un certain nombre de classes auxiliaires, ont été développées ou adaptées, pour assurer les fonctionnalités suivantes : visualisation graphique :
l’état de l’exécution et les résultats finaux d’un scénario sont visualisés
graphiquement (classes CAgentAppView, CGraphicsAgentWnd, CGraphicsAgentThread, CUniqueColors). stockage :
la manipulation des listes chaînées pour la gestion des objets représentant des tâches (classes KPList et ses dérivées, KPIterator, CGraphicTask), et la gestion des chaînes de caractères (classe KPString) [80].
journal d’évènements : chaque agent dispose d’un objet du type CEditLog [81], lui permettant d’écrire du texte dans sa fenêtre associée. traitement d’exceptions : pour permettre de reprendre l’exécution en cas d’erreurs imprévues (class CThreadException). Toutes les classes développées sont listées dans la Figure 36, sauf celles fournies par la MFC. La Figure 37 montre une copie d’écran du simulateur exécutant un scénario de workflow distribué. La fenêtre intitulée « Graphics PopUp » sert à visualiser le progrès de l’ordonnancement dynamique en cours d’une simulation. On peut y apercevoir des tâches représentées par des cercles dont la couleur varie selon la ressource nécessaire pour leur exécution. Les contraintes de précédence sont représentées par des flèches. Les autres fenêtres montrent l’activité des agents impliqués dans la négociation. On y trouve également un agent « sniffer » qui affiche le journal des échanges entre agents. CAgentApp ‘---CWFAgentApp
CAgentAppException CAgentAppView CGraphicsAgentWnd CGraphicTask
CMessageQueue CStructMessage CMessageReflector
CSubclassWnd |---CEditLog ‘---
CThread ‘---CAgentThread
CGraphicsAgentThread
|---CLogAgentThread
|---CAgentManagerThread |---CResAgentThread
|--‘---CWFAgentThread
CThreadException CUniqueColors KPIterator KPReadOnlyIterator ‘---KPComparableList
‘---KPSortableList
KPString
Figure 36 : Classes du simulateur d’agents
KPList
Figure 37 : Simulation d’un scénario
V.2.3 Module « Solveur optimal » Pour quantifier les performances de l’approche proposée, nous comparons les résultats obtenus avec la solution globalement optimale. Cette dernière représente un ordonnancement de toutes les tâches, dont le temps d’exécution de bout en bout est minimal. Elle ne peut être établie que lorsque le système est entièrement observable, c’est-à-dire en traitant l’ensemble des tâches et leurs contraintes de manière centralisée. Pour la recherche de la solution optimale, nous avons implémenté une analyse exhaustive de l’espace des solutions à l’aide du logiciel ILOGTM Solver/Scheduler [46]. Il s’agit d’une bibliothèque de classes C++ pour la résolution de problèmes de satisfaction de contraintes (CSP) discrets. La programmation par contraintes est un paradigme issu de la programmation logique et de la Recherche Opérationnelle (RO). Cette technique permet de séparer la présentation d’un problème de sa solution, en spécifiant les contraintes par un formalisme proche du langage naturel, sans avoir à établir un modèle. Le problème est formulé de façon déclarative, à l’aide de variables et de contraintes que ces variables doivent satisfaire. Le logiciel ILOGTM permet d’exprimer les variables et leurs
contraintes par des objets selon la méthodologie de la programmation orientée objet (POO). Les objets possèdent des méthodes permettant de définir le domaine de chaque variable, c’est-à-dire l’ensemble des valeurs autorisées pour cette variable. La classe principale pour la recherche de solutions est appelée IlcManager. Un objet de cette classe est responsable de l’allocation de mémoire, de la gestion des entrées/sorties et de la recherche de solutions. « ILOGTM Scheduler » fournit des classes pour la définition d’un problème d’ordonnancement à un haut niveau syntaxique. Les activités sont représentées par des objets de la classe IlcActivity et les ressources peuvent être modélisées par des objets de la classe IlcResource. La déclaration de contraintes temporelles est largement simplifiée par des méthodes dédiées de la classe IlcActivity, telles que « activity_x.StartsAfterEnd(activity_y) » pour définir que la tâche x est un successeur de la tâche y. Les étapes nécessaires pour la recherche de la solution optimale peuvent se résumer ainsi : 1.
Créer un objet m du type IlcManager
2.
Ajouter des objets du type IlcActivity et IlcResources à l’objet manager (méthode add() de l’objet manager)
3.
Définir une variable du type « nombre entier » représentant le critère à optimiser, en l’occurrence le temps d’exécution de bout en bout, soit makespan = lastActivity.getEndVariable()
4.
Déclarer le critère à minimiser auprès du manager ( m.setObjMin(makespan) ). Cette déclaration l’amène à s’imposer une nouvelle contrainte pour chaque itération, spécifiant que la valeur de la variable makespan doit être inférieure à la dernière solution trouvée. La solution optimale est atteinte, quand la nouvelle contrainte ne peut plus être satisfaite.
5.
Définir une heuristique pour l’ordre d’instanciation des variables. A priori, n’importe quel ordre conduit à la solution optimale, mais il est possible d’accélérer cette recherche en l’orientant vers la bonne direction. ILOGTM Scheduler propose l’algorithme suivant : a)
Sélectionner une ressource parmi celles qui servent à des tâches ayant un certain degré de liberté dans l’ordonnancement, c’est-à-dire celles qui ne sont pas encore ordonnées.
b)
Choisir une tâche à exécuter en premier parmi celles nécessitant la ressource sélectionnée. Propager les nouvelles contraintes ainsi trouvées. Garder les autres alternatives pour le « backtrack » (cf. Section II.4.1).
c)
Répéter b. jusqu’à ce que toutes les tâches nécessitant la ressource sélectionnée en a. soient ordonnées.
d) 6.
Répéter a. - c. pour toutes les ressources sollicitées par plusieurs tâches.
Appeler la méthode m.nextSolution() en boucle, jusqu’à ce que la solution optimale soit trouvée.
V.3 Evaluation des performances Dans cette partie, nous étudions les performances des algorithmes d’allocation de tâches et d’ordonnancement dynamique, à travers un ensemble de scénarii générés aléatoirement. Pour chaque scénario, les
résultats obtenus sont présentés puis analysés en vue de déterminer leur qualité par rapport aux critères suivants : •
Le comportement vis-à-vis des problèmes d’échelle ;
•
La minimisation de l’interdépendance entre agents et du nombre de messages échangés ;
•
L’obtention d’un ordonnancement minimisant le temps d’exécution du workflow. Ainsi, à l’aide du module « Générateur de scénarii », nous avons généré aléatoirement 100 scénarii
différents. Nous avons fait varier le nombre de ressources de 4 à 8 et la probabilité d’existence d’une contrainte de précédence de 5% à 50%. Le nombre moyen de tâches à exécuter a été fixé à 10 par ressource, avec une variance de 1. Les scénarii ainsi obtenus comportent entre 32 et 89 tâches et entre 14 et 131 contraintes de précédence.
V.3.1 Allocation de tâches Dans un premier temps, nous analysons le comportement de l’algorithme d’allocation de tâches aux agents WF, décrit dans la Section IV.8.2. Nous étudions notamment le rapport entre le nombre total de contraintes de précédence et le nombre de contraintes de précédence, liant des tâches gérées par des agents WF différents (contraintes inter-agents). La Figure 38 illustre les résultats de l’étape d’allocation de tâches pour les 100 scénarii créés aléatoirement. Pour chaque scénario, sont représentés sur l’axe des ordonnées : •
Le nombre total de contraintes de précédence entre les tâches.
•
Le nombre de contraintes de précédence entre tâches allouées à des agents WF différents (contraintes de précédence inter-agents).
•
Le nombre d’agents workflow. Les scénarii sont triés par nombre total de contraintes croissant. Ce nombre représente la borne supérieure
pour le nombre de contraintes de précédence inter-agents. Cette limite est atteinte, quand un agent WF s’occupe d’une seule tâche. Nous constatons que l’application de l’algorithme proposé conduit à un nombre de contraintes inter-agents qui reste bien en dessous de cette borne supérieure.
Figure 38 : Résultats de l’allocation de tâches pour 100 scénarii aléatoires La Figure 39 illustre le rapport entre le nombre total de contraintes entre toutes les tâches d’un scénario et le nombre de contraintes entre les tâches gérées par des agents WF différents. Nous pouvons constater que le nombre de contraintes inter-agents évolue quasi-linéairement en fonction du nombre total de contraintes de précédence entre tâches. La droite approximant cette évolution par la méthode des moindres carrés a une pente de 0,5. On peut conclure, que l’algorithme proposé réduit de moitié le nombre de contraintes de précédence entre les agents, par rapport au nombre total de contraintes d’un scénario. Le coefficient de détermination ρ2 (le carré de la corrélation) est égal à 0,9. Ce coefficient de détermination proche de 1 signifie que nous pouvons faire confiance à cette dépendance linéaire entre le nombre total de contraintes et le nombre de contraintes de précédence interagents. Ce résultat confirme que l’approche l’algorithmique proposée se comporte bien pour les scénarii considérés, l’objectif ayant été de minimiser le nombre d’interdépendances entre agents.
Figure 39 : Rapport entre le nb. total de contraintes de précédence et le nb. de contraintes de précédence inter-agents
V.3.2 Exécution des instances de workflow : ordonnancement dynamique Il s’agit ici d’évaluer les performances de l’algorithme présenté dans la Section IV.8.3, pour l’ordonnancement dynamique des tâches. Pour ce faire, nous avons analysé 16 scénarii aléatoires afin de déterminer la taille de la fenêtre prévisionnelle à utiliser. La Figure 40 illustre les résultats obtenus : chaque scénario a été exécuté 5 fois, avec une taille de la fenêtre prévisionnelle variant entre une et 5 unités de temps. L’exécution distribuée s’effectue selon le modèle décrit dans le Chapitre IV, de manière dynamique par négociation entre agents et sans connaissance de l’état global du système par un agent. Nous avons ensuite comparé le makespan (le temps d’exécution de bout en bout des tâches dans l’ordre déterminé) des solutions trouvées à celui de la solution globalement optimale, calculée par le module « Solveur optimal ».
Figure 40 : Influence de la taille de la fenêtre prévisionnelle sur 16 solutions trouvées
Pour une exécution avec une fenêtre prévisionnelle à une seule unité de temps, c' est-à-dire sans estimation de l’état futur du système, les solutions obtenues ne sont que rarement optimales et dépassent souvent la solution optimale de plus de 10%. L’augmentation de la taille de la fenêtre prévisionnelle améliore la qualité des solutions déterminées, jusqu’à la taille de 4 unités de temps, à l’exception des scénarii no. 13 et 15, qui trouvent leurs meilleurs résultats pour une fenêtre prévisionnelle à 2 unités de temps. Par contre, au delà d’une taille de 4 unités de temps, l’algorithme se comporte en général moins bien. La qualité des solutions trouvées diminue. Ce phénomène est du au fait qu’une taille trop grande de la fenêtre prévisionnelle rend l’estimation des états futurs du système peu fiable, ce qui conduit à une évaluation erronée des priorités des tâches. Dans ce qui suit, nous nous intéressons au nombre de messages échangés, en fonction des paramètres des scénarii générés. Pour ce faire, nous avons créé 60 scénarii aléatoires, chacun ayant été évalué deux fois : Lors de la première exécution, nous avons limité la fenêtre prévisionnelle à une seule unité de temps, la deuxième exécution est basée sur une fenêtre prévisionnelle à quatre unités de temps. Le nombre de messages a été mis à l’échelle en le divisant par 100.
Figure 41 : Nombre de messages échangés lors de l’exécution de 60 scénarii Nous avons représenté le rapport entre les paramètres des scénarii et le nombre de messages Figure 42. L’axe des ordonnées représente le nombre de messages échangés et celui des abscisses le nombre de contraintes de précédence, d’agents et de tâches. Nous avons également tracé les droites approximatives au sens des moindres carrés, ainsi que le coefficient de confiance ρ2 relatif à cette approximation. Par ailleurs, le Tableau 5 illustre les coefficients de corrélation d’une part, entre le nombre de messages et le nombre de tâches et d’autre part, entre le nombre de messages et le nombre global de contraintes de précédence, pour différentes tailles de la fenêtre prévisionnelle. Ces résultats montrent qu’il existe une relation quasi-linéaire (ρ ~ 0,95) entre le nombre de messages échangés et le nombre de contraintes de précédence. Il en va de même pour la relation entre le nombre de tâches dans un scénario et le nombre de messages échangés. Cette relation quasi-linéaire signifie que l’algorithmique proposée est bien adaptée au dimensionnement à grande échelle (en anglais : « scalability »).
Figure 42 : Rapport entre les paramètres des scénarii et le nb. de messages
Ensemble Y
ρ(X,Y) (1 pas / 4 pas)
Nombre total de contraintes de précédence
Nombre total de messages
0,936/0,950
Nombre total de tâches
Nombre total de messages
0,918 / 0,955
Ensemble X
Tableau 5 : Corrélation de deux ensembles de données résultant de 100 scénarii Le coefficient de corrélation a été calculé selon la formule suivante :
ρ X ,Y :=
Cov( X , Y ) ; avec − 1 ≤ ρ X ,Y ≤ 1 σ x ⋅σ y
Le numérateur Cov(X,Y) représente la covariance entre deux ensembles de données (cf. Eq. ) et le dénominateur le produit des déviations standard σ des deux ensembles X et Y.
Cov( X , Y ) :=
1 n
n i =1
( xi − µ X )( yi − µY )
Il s’agit ici de la somme des produits des écarts de la moyenne µ des deux ensembles X et Y pour chaque élément de xi ∈X et de yi ∈Y.
V.3.3 Mesure de la borne supérieure du nombre de messages Dans la Section IV.8.4, nous avons établi la complexité algorithmique du système multi-agents proposé et notamment la borne supérieure pour le nombre de messages échangés lors de l’exécution d’une instance de workflow. Pour les 100 scénarii considérés, nous avons comparé la borne calculée au nombre réel de messages échangés. Les figures 43 et 44 illustrent les résultats de cette comparaison pour deux tailles différentes de la fenêtre prévisionnelle. En abscisse, on trouve les numéros des scénarii, triés par ordre croissant selon le résultat des bornes calculées. L’ordonné représente le nombre de messages calculé ou mesuré. Les résultats obtenus montrent que, pour les scénarii analysés, la borne supérieure n’est jamais dépassée.
Figure 43 : Comparaison de la borne calculée avec le nombre de messages échangés pour une fenêtre prévisionnelle de taille 1
Figure 44 : Comparaison de la borne calculée avec le nombre de messages échangés pour une fenêtre prévisionnelle de taille 4
V.3.4 Comparaison avec la solution optimale Pour les 100 scénarii générés, nous avons réalisé une évaluation exhaustive de tous les ordonnancements possibles. Un ordonnancement possible est un ordonnancement qui trouve une solution pour l’allocation de ressources aux tâches, respectant les contraintes de précédence entre tâches. Nous avons ainsi trouvé une solution optimale par rapport au temps d’exécution de bout en bout de toutes les tâches (le makespan). Ensuite, nous avons exécuté chaque scénario deux fois : La première exécution correspond à une fenêtre prévisionnelle à 4 unités de temps et la seconde à une fenêtre prévisionnelle à une unité de temps. La qualité de la solution d’ordonnancement trouvée est représentée Figure 45. Les 100 scénarii exécutés y sont repartis en 5 classes : La première concerne tous les cas où le makespan correspond à celui de la solution optimale. Les autres classes correspondent aux cas où le makespan des ordonnancements trouvés dépasse l’optimum d’un facteur pouvant atteindre 10, 20, 30 ou plus de 30 pour cent.
Figure 45 : Qualité de l’ordonnancement par rapport à la solution optimale L’analyse des scénarii exécutés montre statistiquement qu’une fenêtre temporelle de prévision à 4 unités de temps permet de trouver une solution optimale (par rapport au critère d’optimisation makespan) ou proche de l’optimum plus souvent qu’une fenêtre temporelle limitée à un pas de prévision dans le futur.
V.4 Conclusion Dans ce chapitre, nous avons exposé l’implémentation et la validation des modèles proposés dans le Chapitre IV. Pour ce faire, un environnement de test a été développé. Il est basé sur une architecture « multi-thread », simulant l’exécution d’un workflow distribué par des agents autonomes. Les résultats issus de l’exécution de scénarii générés aléatoirement montrent que l’algorithme de répartition de tâches trouve effectivement des allocations réduisant les interdépendances entre agents, où leur nombre évolue quasi-linéairement en fonction du nombre total de contraintes de précédence. L’algorithme d’ordonnancement dynamique, basé sur la négociation d’accès aux ressources conduit à des résultats proches de la solution optimale, tout en étant de complexité limitée. En effet, nous avons obtenu un temps d’exécution proche de l’optimum (<10% de dépassement) dans 86% des scénarii exécutés. Le nombre de messages échangés évolue quasi-linéairement en fonction du produit du nombre de contraintes de précédence par le nombre de tâches. Les résultats obtenus prouvent que l’approche proposée répond bien aux objectifs fixés. Elle établit une
solution proche de la solution optimale, à partir d’une vue limitée aussi bien dans le temps (l’ordonnancement dynamique ne tient compte que d’une fenêtre prévisionnelle prédéfinie) que dans l’espace (un agent ne voit qu’une partie des autres agents).
Conclusion générale
Résumé La gestion de workflows inter-organisationnels est soumise à des contraintes particulières. Sa nature distribuée exclut toute approche centralisée, autant pour des raisons de confidentialité que pour des problèmes d’échelle (« scalability »). Les approches distribuées sont confrontées aux limitations de la visibilité de l’état global du système. Un autre problème se pose du fait que cet état évolue souvent de manière imprévisible, en fonction de perturbations, qui, au mieux, peuvent être modélisées à l’aide de variables probabilistes. Dans ce mémoire, nous avons développé une approche méthodologique et algorithmique répondant au problème d’ordonnancement distribué dynamique de tâches assujetties à des contraintes temporelles et de ressources, dans le cadre d’un workflow inter-organisationnel. Cette approche est basée sur le paradigme multiagents, mettant en œuvre un modèle de collaboration pour l’ordonnancement dynamique de tâches, négociant en fonction des informations limitées dont elles disposent, pour définir dynamiquement la priorité des tâches lors de l’exécution d’une instance de workflow. Il s’agit d’une architecture hybride, s’appuyant sur deux principes fondamentaux, à savoir la mobilité des agents chargés de l’exécution d’une partie des tâches et la gestion réactive des ressources pour l’ordonnancement dynamique. Ainsi, nous avons développé trois types d’agents : 1.
Des agents mobiles, migrant de ressource en ressource en transférant leurs tâches.
2.
Des agents réactifs, gérant l’accès aux ressources.
3.
Les agents de supervision.
La deuxième contribution de cette thèse concerne la proposition d’un modèle de collaboration, définissant les interactions entre agents, le protocole de négociation et deux métaheuristiques pour l’allocation et l’ordonnancement dynamique des tâches : 1.
Allocation de tâches : Nous avons développé une méthodologie d’ordonnancement préliminaire et d’allocation des tâches aux agents selon un principe basé sur une analyse des contraintes définies dans le schéma du workflow. Cet algorithme ne prend pas en considération la disponibilité effective des ressources, car celle-ci n’est pas connue à l’avance. L’heuristique proposée minimise le nombre de contraintes de précédence entre les tâches gérées par des agents différents, en excluant l’allocation à un même agent de deux tâches susceptibles de s’exécuter en parallèle.
2.
Ordonnancement : Nous proposons une méthodologie d’ordonnancement dynamique des tâches, qui prend en compte en plus des contraintes temporelles, la limitation de la disponibilité réelle des ressources. Durant cette étape, les tâches sont ordonnancées selon des priorités calculées au fur et à mesure de l’avancement du workflow. Le calcul tient compte des probabilités d’exécution des tâches prédécesseurs et successeurs, ainsi que des taux estimés d’occupation des ressources. Grâce au principe du calcul distribué et dynamique de la détermination des priorités des tâches,
d’éventuelles perturbations lors de l’exécution d’un workflow sont absorbées de façon implicite. Par ailleurs, l’approche proposée respecte la contrainte de confidentialité de l’état du workflow au niveau des autres participants, en limitant les informations échangées aux seules valeurs probabilistes. Finalement, une bonne partie de ce travail de thèse a été consacrée à la validation des modèles proposés, pour laquelle un simulateur multi-agents à été développé. L’analyse statistique des résultats de l’exécution d’un
nombre de scénarii aléatoires montre que des agents logiciels employant les algorithmes développés sont capables d’ordonnancer dynamiquement et sans visibilité globale de l’état du système, des tâches soumises à des contraintes de précédence et de ressources. En effet, l’algorithme de répartition de tâches trouve effectivement des allocations réduisant les interdépendances entre agents, où leur nombre évolue quasi-linéairement en fonction du nombre total de contraintes de précédence. Les résultats obtenus pour l’exécution de bout en bout d’un scénario sont dans la plupart des cas très proches de la solution optimale que nous avons déterminée à l’aide d’une recherche exhaustive dans l’espace des solutions (<10% de dépassement dans 86% des cas). Nous avons également étudié et validé expérimentalement la complexité algorithmique du modèle proposé. Cette complexité concerne les coûts calculatoires des algorithmes associés aux agents, ainsi que le nombre de messages échangés entre agents, dans le protocole de négociation. Le nombre de messages échangés évolue quasi-linéairement en fonction du produit du nombre de contraintes de précédence par le nombre de tâches.
Perspectives Compte tenu des différents points que nous avons abordés au cours de ce mémoire, nous proposons dans un cadre de travaux futurs d’approfondir certains points. Premièrement, il s’agit de lever certaines hypothèses retenues dans le cadre de l’algorithmique présentée. L’hypothèse la plus contraignante est celle qui concerne l’allocation d’une seule ressource à une tâche à la fois. Dans un workflow inter-organisationnel complexe, une tâche peut nécessiter plusieurs ressources en même temps. Ainsi, il nous semble intéressant de généraliser l’algorithme présenté au cas de systèmes multi-ressources. Deuxièmement, il nous reste à valider expérimentalement la méthodologie du point de vue de la migration des agents. La mobilité de code et la transmission de l’état courant du système peuvent être mises en œuvre à l’aide de plates-formes multi-agents existantes. Nous prévoyons à court terme une implémentation de notre architecture dans un environnement multi-agents tel que par exemple JADE/FIPA, ce qui permettra d’aboutir à un système complet répondant aux normes courantes. La dernière perspective porte sur l’application de l’approche développée à la gestion du calcul partagé (« grid computing »). Dans ce type d’application, la distribution et l’ordonnancement des tâches se font à l’aide de graphes dirigés acycliques et on y retrouve les mêmes types de contraintes que dans les workflows industriels classiques.
Bibliographie 1 2 3 4
Ader, M., “Technologies for the Virtual Enterprise”, Workflow & Groupware Strategies, France, 2001 Beizer, M., “Interesting Times For Workflow Technology”, AIIM Accreditation Workflow Subcommittee, 1997 E-Workflow - The Workflow Portal, “The Key Benefits of Workflow”, www.e-workflow.org The Workflow Management Coalition “Terminology & Glossary”, Document Number WFMC-TC-1011, 1999
5 6 7 8 9 10 11 12 13 14 15 16 17
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
33 34
Hales, K., “Workflow Management Products”, SODAN Business Process & Workflow Management Products report, cité par [89] Boissier, O., “Systèmes Multi-Agents”, Cours du DEA “Communication et Coopération dans les Systèmes à Agents” (CCSA), Université de Savoie, 1999 Stormer, H., “Ein flexibles und sicheres agentenbasiertes Workflow Management System”, Ph.D. Thesis, Universität Zürich, 2003 The Workflow Management Coalition “Terminology & Glossary”, Document Number WFMC-TC-1011, 1999 zur Mühlen M., Zhao J.L., “Workflow Tutorial” , presenté à la HICSS-35 Conference, Hawaii 7 Jan. 2002 Kamath, M.U., “Improving Correctness and Failure Handling in Workflow Management Systems”, Ph.D. Thesis, University of Massachusetts, Amherst, Mai 1998 Khelifi, K., “Systèmes informatiques répartis”, Cours à l’université Laval, QC, Canada, 2004 University of Pennsylvania, “Linking Help Desks” http://www.upenn.edu/computing /group/penntips/, McCready, S., “There is more than one kind of workflow software”, Computerworld, November 2, pp 86-90, 1992 Allen, R., “Workflow: An Introduction”, dans “The Workflow Handbook 2001”, Ed. L. Fischer, Future Strategies Inc., Lighthouse Point, FL, USA, 2001 Plesums, C., “An Introduction to Workflow”, dans “The Workflow Handbook 2002”, Ed. L. Fischer, Future Strategies Inc., Lighthouse Point, FL, USA, 2002 Ellis, C., “Workflow Technology”, Computer Supported Cooperative Work, Ed. Beaudouin-Lafon, M., Wiley, Chichester, USA, 1999 Gronemann, B., Joeris, G., Scheil, S., Steinfort, M., Wache, H., “Supporting Cross-Organizational Engineering Processes by Distributed Collaborative Workflow Management - The MOKASSIN Approach”, 3rd Int. Conf. on Global Engineering Networking (GEN), Bremen, 1999 van der Aalst, W.M.P., “Process-Oriented Architectures For Electronic Commerce and Interorganizational Workflow”, Information Systems, 24(8), pp. 639-671, 2000 van der Aalst, W.M.P., Weske, M., “The P2P approach to Interorganizational Workflows”, Proc. of the 13th Intl. Conf. on Advanced Information Systems Engineering (CAiSE' 01), Berlin, 2001 Martinez, M.T., Fouletier, P., Park, K.H., Favrel, J., “Virtual Enterprise - organization evolution and control”, Int. Journal of Production Economics, 74 (2001), pp. 225-238, Elsevier, 2001 Lumbroso, L., “Glossaire”, Journal en ligne 01net, Ed. : Groupe TEST, Paris, France, 2004 Anderson, M., Allen, R., “Workflow Interoperability - Enabling E-Commerce”, WfMC White Paper, April 1, 1999 Zhuge, H., “Component-based workflow systems development”, Decision Support Systems 35 (2003), pp. 517536, Elsevier, 2003 Object Management Group (OMG), “Common Object Request Broker Architecture: Core Specification”, http://www.omg.org/, 2004 Sun Microsystems, “JavaBeans for Java Studio Architecture and API”, White paper, 1997 Microsoft Corporation, “The Component Object Model Specification”, http://www.microsoft.com/Com/resources/comdocs.asp, 2004 Oracle Corporation, “Oracle Workflow with J2EE”, White Paper, 2003 Jennings, N., Wooldridge, M. “Agent-Oriented Software Engineering”, dans : “Handbook of Agent Technology”, Ed. Bradshaw, J., AAAI/MIT Press, 2001 Ferber, J., “Les sytèmes multi-agents. Vers une intelligence collective”, Editions InterEditions, 1995 Nwana, H., “Software Agents: An Overview”, Knowledge Engineering Review, 11(3), pp.1-40, Cambridge University Press, R.U.,1996 Joeris, G.: “Decentralized and Flexible Workflow Enactment Based on Task Coordination Agents”, Proceedings of the Conference Workshop on Agent-Oriented Information Systems, AOIS, 2000 Jennings, N. Faratin, P., Johnson, M., O' Brien, P., Wiegand M., “Using intelligent agents to manage business processes”, Proceedings of the First International Conference on The Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM96), pp. 345-360, London, UK, 1996 J. Miller, J., Palaniswami, D., Sheth, A., Kochut, K., Singh, H., “WebWork: METEOR2’s Web-based workflow management system”, Technical Report, University of Georgia, USA, 1997 Das, S., “ORBWork: A distributed, CORBA-based runtime for the METEOR2 workflow management system”,
35 36 37
38 39 40
41
42
43
44
45
46 47 48 49 50 51 52 53
54
55 56 57 58
Master’s Thesis, University of Georgia, USA, 1997 Sheth, A., “METEOR Workflow Management System”, Présentation, University of Georgia, USA Wang, X., “NEOWork: A Reliable CORBA-Based Workflow Enactment System for METEOR2”, Masters Thesis, University of Georgia, USA, Sept. 1997 Marazakis, M., Nikolaou, C., Papadakis D. “Workflow Management Systems: State-of-the-Art”, Working Paper, Institute of Computer Science (ICS) of the Foundation for Research and Technology - Hellas (FORTH), Grèce, 1997 CrossFlow, “Cross-Organizational Workflow Support in Virtual Enterprises”, ESPRIT Project 28635, site en ligne : http://www.crossflow.org, 2004 Hoffner, Y., Ludwig, H., Grefen, P. Aberer, K., “CrossFlow: Integrating Workflow Management and Electronic Commerce”, ACM SIGecom Exchanges, 2(1), pp. 1-10, 2001 Grefen, P., Aberer, K., Hoffner, Y., Ludwig H., “CrossFlow: cross-organizational workflow management in dynamic virtual enterprises”, International Journal of Computer Systems Science & Engineering (2000) 15(5), pp. 277-290, UK, 2000 Geppert, A., Tombros, D, “Event-based Distributed Workflow Execution with EVE”, Proceedings IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing Middleware 98, Eds.: Davies, N., Raymond, K., Seitz, J., Springer, 1998 Filho R. S., Wainer J., Madeira E. R. M., “A Fully Distributed Architecture for Large-scale Workflow Enactment”, International Journal of Cooperative Information Systems (IJCIS). Vol. 12, No. 4 (2003), pp. 411-440, Dec. 2003. Ting Cai, T., Gloor, P., Nog, S., “DartFlow: A Workflow Management System on the Web, Using Transportable Agents”, Technical Report, Department of Computer Science, Dartmouth College, Hanover, NH, USA, 1996 Gray, R., “Agent Tcl: A Transportable Agent System”, Proceedings of the CIKM Workshop on Intelligent Information Agents, Fourth International Conference on Information and Knowledge Management (CIKM), Eds. : Mayfield, J., Finnin, T., December, 1995 Dogac, A., Gokkoca, E., Arpinar, S., Koksal, P., Cingil, I., Arpinar, I.B., Tatbul N., Karagoz, P., Halici, U., Altinel, M., “Design and Implementation of a Distributed Workflow Management System: METUFlow”, NATO ASI Advances in Workflow Management Systems and Interoperability, Eds. : Dogac, A., Kalinichenko, L., Ozsu, M.T., Sheth, A., Istanbul, 1997 ILOG, “ILOG Scheduler - Users Manual”, ILOG S.A., Gentilly, France, 1998 Tison, S., “Résumé du Cours”, Maîtrise Informatique U.S.T.L, Oct. 2002 Petit, T., “Modélisation et Algorithmes de Résolution de Problèmes Sur-Contraints”, Ph.D. Thesis, Université de Montpellier II, 2002 Goldberg, D. E., “Genetic Algorithms in Search, Optimization, and Machine Learning”, Addison-Wesley, Reading, Mass., USA, 1989 Davis, L., “Job Shop Scheduling with Genetic Algorithms”, Proceedings of the 1st International Conference on Genetic Algorithms, pp.136-140, 1985 Neumaier, A., “Complete Search in Continuous Global Optimization and Constraint Satisfaction”, dans “Acta Numerica 2004”, Ed.: A. Iserles, Cambridge University Press 2004 Kirkpatrick, S., Gelatt, C., Vecchi, M., “Optimisation by Simulated Annealing”, Science, No. 220, pp. 671680, 1983 Matsuo, H., Suh, C.J., Sullivan, R.S., “A controlled search simulated annealing method for the general job shop scheduling problems”, White Paper, Dept. of. Management, Graduate School of Business, University of Texas, Austin, USA, 1988 Ennigrou, M., Ghédira, K., “Approche Multi-Agents basée sur la Recherche Tabou pour le Job Shop flexible”, 14ème congrès francophone de Reconnaissance des formes et d' Intelligence artificielle (RFIA), Toulouse, 2004 Mooney, E., Rardin, R.L., “Tabu search for a class of scheduling problems”, Annals of Operations Research, 41, pp. 253-278, 1993 Durfee, E. “Distributed Problem-Solving and Planning”, AgentLink' s Third European Agent Systems Summer School (EASSS 2001), pp. 118-149, Springer-Verlag Lecture Notes in AI 2086, Berlin, 2001 Dorigo M., Di Caro, “The Ant Colony Optimization Meta-Heuristic”, “ New Ideas in Optimization, Ed.: D. Corne, M. Dorigo et F. Glover, McGraw-Hill, 1999 Clerc, M., “Optimisation par Essaim Particulaire”, Tutoriel, Premier séminaire francophone sur le thème de
59 60 61 62 63 64 65 66
67 68 69 70 71 72
73
74
75 76 77 78
79 80 81 82 83 84
l' optimisation par essaim particulaire (OEP), Paris 2003 Rossi, A., “Ordonnancement en milieu incertain, mise en œuvre d’une démarche robuste”, Ph.D. Thesis, Institut Polytechnique National de Grenoble, 14. oct. 2003 Fargier, H., Lang, J. Martin-Clouaire R., Schiex, T., “Traitement de problèmes de décision sous incertitude par des problèmes de satisfaction de contraintes”, Revue d' Intelligence Artificielle. Vol. 11 - n. 3/1997 Walsh, T., “Stochastic constraint programming”, Proceedings of the 15th ECAI. European Conference on Artificial Intelligence, IOS Press, 2002 Hannebauer, M., “A Formalization of Reconfiguration in Distributed Constraint Satisfaction”, Fundamenta Matematicae 43 (2000), IOS Press, 2000 Kim, K., Paulson Jr., B., Petrie Jr., C., Lesser, V., “Compensatory Negotiation for Agent-Based Project Schedule Optimization and Coordination”, CIFE Working Paper #55, Stanford University, 2000 Babanov, A., Collins, J., Gini, M., “Scheduling Tasks with Precedence Constraints to Solicit Desirable Bid Combinations”, AAMAS’03, July 14-18, Melbourne, Australia, 2003 Smith, F., “Is scheduling a solved problem?”, Proceedings of the First MultiDisciplinary International Conference on Scheduling: Theory and Applications (MISTA), Nottingham, UK, 2003 Cicirello, V., Smith, S., “Distributed Coordination of Resources via Wasp-Like Agents”, Innovative Concepts for Agent-Based Systems: First International Workshop on Radical Agent Concepts (WRAC), Ed.: McLean, VA, USA, January 16-18, 2002 Montana, D., Herrero, J., Vidaver, G., Bidwell, G., “A Multiagent Society for Military Transportation Scheduling”, Journal of Scheduling, 3(4). 2000 Liu, J.-S., “Coordination of Multiple Agents in Distributed Manufacturing Scheduling”, Ph.D. Thesis, Robotics Institute, Carnegie Mellon University, avril 1996 Tranvouez, E., “IAD et Ordonnancement : une approche coopérative du réordonnancement par systèmes multi-agents”, PhD. Thesis, Univ. Aix-Marseille III, mai 2001 Cao, J., Jarvis, S., Saini, S., “ARMS: An agent-based resource management system for grid computing”, Scientific Programming 10(2), pp. 135-148, 2002 Smith, R.G., “The Contract Net protocol: high-level communication and control in a distributed problem solver”, IEEE Transactions on Computers, Vol. c-29, No. 12, pp. 1104 - 1113, 1980 Ouelhadj, D., Cowling, P., Petrovic, S., “Contract Net Protocol for Cooperative Optimisation and dynamic Scheduling of Steel Production”, Book of Intelligent Systems Design and Applications, Springer-Verlag, Eds. Ajith A., Katrin F., Mario K, pp. 457-470, 2003 Tönshoff, H.-K.; Seilonen, I., Teunis, G., Leitão, P., “A Mediator-based approach for decentralised Production Planning, Scheduling and Monitoring”, Proceedings of CIRP International Seminar on Intelligent Computation, Manufacturing Engineering, 21-23 June, Capri, Naples, Italy, 2000 Saad, A., Kawamura, K., and Biswas, G., “Performance Evaluation of Contract Net-Based Heterarchical Scheduling for Flexible Manufacturing Systems”, Intelligent Autonomous and Soft Computing, 3(3), pp. 229248, 1997 Shaw, J.M., “Dynamic Scheduling in Cellular Manufacturing Systems: A Framework for Network Decision Making”, Journal of Manufacturing Systems, 7(2), pp. 83-94, 1998 Strasser, M., Rothermel, K., “System Mechanisms for Partial Rollback of Mobile Agent Execution”, 20th International Conference on Distributed Computing Systems (ICDCS), Taipei, Taiwan, April 10 - 13, 2000 Kamath, M. U., “Improving Correctness and Failure Handling in Workflow Management Systems”, Ph.D. Thesis, University of Massachusetts Amherst, 1998 Tianfield, H., Tian, J., Yao, X., “On the Architectures of Complex Multi-Agent Systems”, Proceedings of the Workshop on “Knowledge Grid and Grid Intelligence”, IEEE/WIC Int. Conference on Web Intelligence/Intelligent Agent Technology, Halifax, CA, pp. 195-206., Oct. 2003 Filipp, D., “CThread - a Worker Thread wrapper class”, http://www.codeproject. com/threads/cthread.asp Pomakis, K., “KP Libraries”, http://www.pomakis.com/kplib/ Lohmann, D., “CEditLog - fast logging into an edit control with cout”, http://www.codeproject.com/editctrl/editlog.asp Kanzow, S. “Multithreaded GUI Agent Testbed”, http://www.liia-paris12. net/index.php? chemin=./thematiques/siad/qualite_serv_m-a/these_kanzow/HTMLDocu /index.html Nwana, H., Ndumu, D., Lee, L., Collis, J., “ZEUS: A Tool-Kit for Building Distributed Multi-Agent Systems”, Applied Artifical Intelligence Journal, Vol 13 (1), p129-186., 1999 Burkhart, R., “The Swarm Multi-Agent Simulation System”, Object-Oriented Programming Systems:
85 86 87
88 89
I
Languages and Applications (OOPSLA), 1994 Gutknecht, O., Ferber, J., “The MADKIT Agent Platform Architecture”, Revised Papers from the International Workshop on Infrastructure for Multi-Agent Systems, pp. 48-55, 2001 Foundation For Intelligent Physical Agents, “FIPA Abstract Architecture Specification”, http://www.fipa.org, 2002 Bellifemine, F., Poggi, A., Rimassa, G., “JADE: a FIPA2000 compliant agent development environment”, International Conference on Autonomous Agents archive, Proceedings of the fifth international conference on autonomous agents, pp. 216-217, Montreal, Quebec, Canada, 2001 AgentLink, “Agent Software”, http://www.agentlink.org/resources/agent-software.php Putnik, Z., Budimac Z., “Software Agents As a Part Of a Workflow Technology”, 4th workshop on computational intelligence and information technologies, Faculty of Electronics, Niš, Serbia, October 13, 2003
Détails des classes d’agents
CAgentManagerThread Cet agent n’existe qu’une seule fois par scénario considéré. Il a pour rôle d’analyser le scénario, d’instancier les agents de ressources et les agents WF et de synchroniser les cycles de négociations entre ces agents. L’instanciation dynamique d’un objet du type CAgentManagerThread par le thread principal d’application, se traduit par le démarrage d’un nouveau thread, après réception de la commande CMD_RUN, envoyée par l’application. Sa méthode OnRun() ouvre alors le fichier contenant une description du scénario en XML, puis déclenche la commande CMD_PARSE_FILES. Cette commande invoque le composant MicrosoftTM MSXML parseur pour lire le contenu du fichier. S’il n’y pas d’erreur formelle, l’agent envoie la commande CMD_USER_CREATENODES. Par la suite, l’objet principal de l’application est informé de la demande de création des objets du type CResAgentThread, correspondant aux ressources définies dans le scénario. La phase d’allocation de tâches est alors déclenchée par la commande CMD_CLASSIFY. Les tâches sont triées selon l’algorithme présenté dans la section IV.8.2. Une fois le nombre optimal d’agents WF calculé (ce sont des objets du type CWFAgentThread), l’objet principal de l’application est informé de la demande de création de ces agents. La synchronisation de la négociation entre les agents WF et les agents de ressources est assurée par l’agent manager par des messages échangés à travers une queue de messages globale. Les agents de ressources indiquent le début d’une négociation avec les agents WF par le message NodeBusy. L’agent manager tient une liste interne des agents de ressources occupés et attend que ces derniers lui envoient des messages Finished, à la fin de leur négociation avec les agents WF. Pour éviter des « race conditions » (cf. Section III.4.3), l’agent manager attend un lapse de temps après la réception du dernier message Finished, avant de diffuser en « broadcast » un message de synchronisation TIME_STEP. Ce lapse de temps recommence de nouveau, si jamais l’agent manager reçoit d’autres messages NodeBusy pendant ce temps d’attente. L’agent manager est également informé de la fin de l’exécution des tâches par des messages provenant des agents de ressources (message ). Ces messages contiennent des attributs spécifiant le nom de la tâche et son instant d’exécution.
CResAgentThread Chaque objet de la classe CResAgentThread, dérivée de la classe CAgentThread, sert à simuler le comportement d’un agent de ressources. Cet agent reste en attente de réservations, arrivant par le biais d’un message XML du type , provenant d’un agent WF. Les réservations sont effectuées pour un nombre de créneaux horaires ; elles sont stockées sous forme d’un tableau où chaque case contient une liste de réservations. La taille du tableau correspond au nombre de créneaux horaires considérés, c' està-dire à la taille de la fenêtre prévisionnelle. Lors de la réception d’un message de réservation, toutes les réservations antérieures du même agent WF sont effacées des listes et les nouvelles y sont ajoutées. Le nom de l’agent WF est ajouté à liste interne des agents à informer (m_informAgentsList). S’il s’agit de la première négociation dans le cycle courant, l’agent manager est informé du début de la négociation en lui envoyant le
message NodeBusy. Les nouvelles disponibilités de la ressource pour les créneaux considérés sont ensuite calculées (elles sont inversement proportionnelles à la taille de chacune des listes de réservation), en tenant compte d’un coefficient de pondération entre l’ancienne et la nouvelle valeur de disponibilité. Ces disponibilités sont diffusées à tous les agents WF dont les noms sont contenus dans la liste m_informAgentsList. La réception d’un message Finished d’un des agents WF provoque sa suppression de la liste informAgentsList. Si la liste est vide, l’agent de ressources envoie la commande CMD_SCHEDULE, retardée de quelques secondes, afin d’être sûr qu’il ne reste pas de réservations non traitées dans la queue de messages. S’il n’y a pas eu de nouvelles réservations pendant ce temps d’attente, la méthode OnUserCommand() de ce même agent capture CMD_SCHEDULE et déclenche ainsi le processus de sélection de la tâche ayant la plus grande priorité pour le premier créneau horaire. L’agent WF dont la tâche est sélectionnée en est informé et le message Finished est envoyé à l’agent manager.
CWFAgentThread Chaque agent WF est simulé par un objet de la classe CWFAgentThread, dérivée de CAgentThread. Après réception de la commande CMD_RUN de l’agent manager, l’agent WF répond par un message Hello. Quand l’agent WF reçoit un message XML contenant la balise , il parse son contenu à l’aide du parseur MSMXL et crée une liste incluant les contraintes des tâches : ses ressources et les dépendances (les liens de précédence et les identificateurs des agents WF associés). Les informations sont stockées dans des listes, dont la taille correspond au nombre de créneaux horaires considérés. Chaque tâche est représentée par un objet du type StructTask, décrit Figure 46.
Figure 46 : Structure StructTask pour le stockage des paramètres d’une tâche L’agent WF demande ensuite les probabilités d’exécution de tous les prédécesseurs de ses tâches aux autres agents WF (cf. Figure 47), puis communique les réservations à effectuer aux agents de ressources concernés. Une réservation doit être effectuée si la priorité d’une tâche dépasse un seuil donné pour le créneau considéré et la réservation n’a pas encore été effectuée. Elle doit être retirée pour un certain créneau horaire si la priorité de la tâche reste en dessous du seuil imposé.
Figure 47 : Extrait du code de la fonction handleXMLMessage() de l’agent WF Finalement, l’agent s’envoie la commande CMD_CALCULATE, afin de déclencher la mise à jour des probabilités d’exécution et des priorités de ses tâches. Quand un autre agent WF envoie une requête pour obtenir les probabilités d’exécution de certaines tâches (par un message ), l’agent répond par un message intitulé , contenant les valeurs demandées. Ce même message est envoyé à tous les agents WF concernés lorsque les probabilités d’exécution changent à la suite d’une modification quelconque des
paramètres des tâches de l’agent. Lorsqu’un agent WF reçoit les valeurs de probabilité d’exécution des tâches le concernant (en général des probabilités d’exécution des prédécesseurs), il les intègre dans ses paramètres et déclenche la commande CMD_CALCULATE. Il en va de même pour la réception d’un message incluant les valeurs de disponibilité de ressources pour ses tâches (message d’un agent de ressources). Lors de la réception de la commande CMD_CALCULATE par sa méthode OnUserCommand(), l’agent WF re-calcule les priorités de ses tâches comme décrit en Section IV.8.3.
I
Le schéma XSD des messages échangés entre agents
I
Un exemple d’un fichier de scénario
Résumé Les workflows inter-organisationnels sont soumis à des contraintes particulières : leur nature distribuée exclut toute gestion centralisée, pour des raisons de confidentialité et d’échelle. Nous développons une méthodologie multi-agents, pour l’ordonnancement distribué dynamique de tâches assujetties à des contraintes temporelles et de ressources. L’algorithme d’ordonnancement est basé sur un calcul dynamique de la priorité des tâches. La confidentialité est respectée, en limitant les informations échangées à des valeurs probabilistes. L’architecture s’appuie sur la mobilité d’agents chargés de l’exécution des tâches et sur la gestion réactive des ressources, où des perturbations sont absorbées implicitement. Nous définissons le protocole de négociation entre les agents et deux heuristiques pour l’allocation et l’ordonnancement de tâches. Mots-clés : workflow, systèmes multi-agents, ordonnancement dynamique distribué, auto-ordonnancement,
entreprise virtuelle
Abstract Inter-organizational workflows are particularly constrained: their distributed nature excludes centralized management, for confidentiality and scalability reasons. We develop a multi-agent methodology for distributed dynamic scheduling of tasks that are subject to temporal and resource constraints, based on a dynamic priority determination. Confidentiality is respected by limiting information exchange to probabilistic values. The proposed architecture relies on mobile agents for task execution and reactive resource management, where perturbations are absorbed implicitly. We define a negotiation protocol between agents and two heuristics for task assignment and scheduling. Keywords: workflow, multi-agent systems, dynamic distributed task scheduling, self-scheduling, virtual enterprise
