THÈSE DE DOCTORATde l’Université Paris XII - Val de Marne

présentée par

Sebastian KANZOWpour 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 1Motivation 2Contribution 3Organisation du mémoire 4

Chapitre I Gestion de workflows 5I.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 Collaboration inter-organisationnelle 13

I.4.1 Concept de l’entreprise virtuelle 13Cas No. 1 : La collaboration à court terme 14Cas No. 2 : L’entreprise étendue - Gestion de la chaîne logistique14Cas No. 3 : Gestion de développement de produit dans un consortium 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 23ADEPT 25METEOR2 25CrossFlow 27EvE 28METUFlow29WONDER 30DartFlow 31

I.7.3 Discussion 32

I.8 Conclusion 33

Chapitre II Ordonnancement 34II.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 49Routage de tâches par collaboration de « guêpes » 49Système multi-agents pour la planification de transports militaires 50Agents réactifs coordonnés 50Résolution Coopérative et distribuée d’un problème d’ordonnancement 51Ordonnancement par système multi-agents dans le contexte de calcul partagé 52

II.6.5 Discussion 53

II.7 Conclusion 54

Chapitre III Modèles d’organisation et d’architecture d’agents 55III.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 75

Chapitre IV Modèle de collaboration 76IV.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 89Première étape : Déterminer un ordonnancement valide, basé sur l’hypothèse qu’il existe des ressources illimitées 90Deuxiè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 96Complexité algorithmique des agents WF 97Complexité algorithmique des agents de ressources 98Complexité algorithmique du protocole de négociation 98

IV.9 Conclusion 99

Chapitre V Test et validation 100V.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 » 105La classe CWFAgentApp 106Les classes CMessageQueue et CStructMessage 107La classe CAgentThread et ses dérivées 108Les classes auxiliaires 110

V.2.3 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 123Résumé 124Perspectives 126

Annexe I Détails des classes d’agents ICAgentManagerThread IICResAgentThread IIICWFAgentThread 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 109

Tableau 5 : Corrélation de deux ensembles de données résultant de 100 scénarii 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 inter-

agents 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é Paris-

Dauphine, 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 sous-

traitance, 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’auto-

ordonnancement

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 IntroductionLes 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 inter-

organisationnelle 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éfinitionsLa « 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 workflowDans 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 inter-

organisationnel 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ésLes 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 communicantsUn 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 multi-

agents 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 ConclusionL’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 inter-

organisationnel, 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 IntroductionLes 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ésIl 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éfinitionsDans 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 exactesElles 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éesLes 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-agentsDans 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 sous-

problè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’auto-

ordonnancement, 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 sous-

problè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 ConclusionCe 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 IntroductionNous 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 multi-

agents 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 objectifsLe 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 multi-

critè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èsesAvant 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 agentsDans 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 Type Créé par Description

Agent manager 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 <agent:tasklist…>), 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

<agent:requestProba…> et <agent:probaValues…>). 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

<agent:reserveResources…>). 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

<agent:resAvailability…>). 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

<agent:probaValues…>).

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 <agent:taskExecution…>.

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

<agent:reserveResources…>). L’agent de ressources renvoie des valeurs qualifiant le taux d’occupation

de sa ressource (message <agent:resourceAvailability…>), 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 <agent:taskExecution…>). 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 ConclusionIl 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 IntroductionCe 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 inter-

organisationnel 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âchesLe 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.2 �0.

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 workflowLors 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 agentsDans 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.

<Balise>/Niveau hiérarchique (imbriquée dans) Attributs Provenance Destination

Description

<agentdata>/1er maxdur1 Fichier scénario Agent manager Contient les données

d’un scénario pour un workflow à exécuter

<node>/2nd (agentdata) name Fichier scénario Agent manager

Décrit une ressource qui sert à effectuer des tâches

<task>/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 <node>

<successor>/4e (task) node_name, task_name Fichier scénario Agent

manager Définit un lien de précédence entre la tâche et son successeur

<tasklist>/1er ordered3, time_step4 Agent manager Agent WF Message

d’allocation d’une séquence de tâches à effectuer par un agent WF

<task>/2nd (tasklist) name, resource_node, sequence_ number5 Agent manager

Agent WF Description des tâches de la séquence

<dependency>/3e (task) agent_name, sequence_ number Agent manager

Agent WF Prédécesseurs et successeurs de la tâche

<requestProba>/1er time_step Agent WF Agent WF Requête des probabilités d’exécution des

tâches gérées par différents agents WF

<task>/2nd (requestProba) sequence_ number Agent WF Agent WF

Désignation des tâches dont la probabilité est demandée

<probaValues>/1er time_step Agent WF Agent WF Réponse à la requête des valeurs des

probabilités d’exécution

<task>/2nd (probaValues) sequence_ number, doesn’t_exist6 Agent WF

Agent WF Désignation des tâches dont la probabilité d’exécution est communiquée

<probability>/3e (task) time_slot7, value Agent WF Agent WF

Les valeurs de probabilité d’exécution des tâches

<reserveResources>/1er time_step Agent WF Agent de ressources Requête de

réservation de ressources

<reserveSlot>/2nd (reserveResources) time_slot, task, utility8 Agent WF Agent de

ressources Désignation de la tâche et du créneau horaire pour la réservation

<resAvailability>/1er time_step Agent de ressources Agent WF

Message caractérisant la disponibilité d’une ressource

<availability>/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

toutes leurs tâches

TIME_STEP Agent manager broadcast Message diffusé après la terminaisun d’un cycle

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 workflowGé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 workflowLa 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 : exC (T ,T ) T ,T Tx y x y∃ ∀ ∈

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 :

{ } { }or pr oror

( N (T ) ) 1, si C (T ,T ) N (T ) 0 ; T ,T T;N ( ) :

0,sinon

x x y x x yy

Max x yT

� + = = ∅ ∀ ∈ ≠�= ���

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 :

{ }orG T N (T ) 1 G 1 G G G ,G Part ;i x x i i j i j 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 : exC (T ,T ) T Gx y x 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 :

prC (T ,T ) T Ty z z∃ ∀ ∈.

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 :

[ ]( ) [ ]( )T0 0 0T

1, : ; ;

( )x

xx n execution n n endsuccessor n

U t t P t t t t tt t

= ⋅ ≤ ≤∆

∆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])

( ) ( ) [ ]( )pr

TT0 1

T T

: ;yx k

y

resourceexecution n available n execution nP t P t P t t −

∈= Π

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]) :

[ ]( ) ( ) [ ]( )1

0

T T T0 0; : 1 1 1 ;

n

x x x

t

execution n execution n executiont t

P t t P t P t 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 lui-

mê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 :

( ) :y n

y

ressource toccupation n ressourceT t reservations=

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é :

1 ,si ( ) 0

( ) : 1,sinon

( )

y

y

y

ressourceoccupation n

resourceavailable n

ressourceoccupation n

T t

P t

T t

� =�

= ���

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 :

( )( ) : ( ) 1 ( )y y yressource ressource ressourcenew new oldoccupation n occupation n occupation nT t T t T tγ γ= + −

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 :

( )( )2: 5agentWF t c c pC I N N N Nχ= + +

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 :

: ( )agentRes m r a cC N N N Nχ= +

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 :

( )2: c

negotiation p t a

NC N N Nξ

ε= +

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 ConclusionNous 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 IntroductionL’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’agentsL’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, elle-

mê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 CSubclassWnd |---CEditLog ‘---

CMessageReflector CThread ‘---CAgentThread |---CAgentManagerThread |---

CGraphicsAgentThread |---CLogAgentThread |---CResAgentThread ‘---CWFAgentThread

CThreadException CUniqueColors KPIterator KPReadOnlyIterator KPList

‘---KPComparableList ‘---KPSortableList KPString

Figure 36 : Classes du simulateur d’agents

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) Répéter a. - c. pour toutes les ressources sollicitées par plusieurs tâches.

6. Appeler la méthode m.nextSolution() en boucle, jusqu’à ce que la solution optimale soit trouvée.

V.3 Evaluation des performancesDans 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 inter-

agents. 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 X 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

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 :

, ,

( , ): ; avec 1 1X Y X Y

x y

Cov 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.

( )( )1

1( , ) :

n

i X i Yi

Cov X Y x yn

µ µ=

= − −

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 ConclusionDans 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 multi-

agents, 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 Ader, M., “Technologies for the Virtual Enterprise”, Workflow & Groupware Strategies, France, 20012 Beizer, M., “Interesting Times For Workflow Technology”, AIIM Accreditation Workflow Subcommittee,

19973 E-Workflow - The Workflow Portal, “The Key Benefits of Workflow”, www.e-workflow.org4 The Workflow Management Coalition “Terminology & Glossary”, Document Number WFMC-TC-1011,

1999

5 Hales, K., “Workflow Management Products”, SODAN Business Process & Workflow Management Products report, cité par �[89]

6 Boissier, O., “Systèmes Multi-Agents”, Cours du DEA “Communication et Coopération dans les Systèmes à Agents” (CCSA), Université de Savoie, 1999

7 Stormer, H., “Ein flexibles und sicheres agentenbasiertes Workflow Management System”, Ph.D. Thesis, Universität Zürich, 2003

8 The Workflow Management Coalition “Terminology & Glossary”, Document Number WFMC-TC-1011, 1999

9 zur Mühlen M., Zhao J.L., “Workflow Tutorial” , presenté à la HICSS-35 Conference, Hawaii 7 Jan. 200210 Kamath, M.U., “Improving Correctness and Failure Handling in Workflow Management Systems”, Ph.D.

Thesis, University of Massachusetts, Amherst, Mai 199811 Khelifi, K., “Systèmes informatiques répartis”, Cours à l’université Laval, QC, Canada, 200412 University of Pennsylvania, “Linking Help Desks” http://www.upenn.edu/computing /group/penntips/, 13 McCready, S., “There is more than one kind of workflow software”, Computerworld, November 2, pp 86-90,

199214 Allen, R., “Workflow: An Introduction”, dans “The Workflow Handbook 2001”, Ed. L. Fischer, Future

Strategies Inc., Lighthouse Point, FL, USA, 200115 Plesums, C., “An Introduction to Workflow”, dans “The Workflow Handbook 2002”, Ed. L. Fischer, Future

Strategies Inc., Lighthouse Point, FL, USA, 200216 Ellis, C., “Workflow Technology”, Computer Supported Cooperative Work, Ed. Beaudouin-Lafon, M., Wiley,

Chichester, USA, 1999 17 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

18 van der Aalst, W.M.P., “Process-Oriented Architectures For Electronic Commerce and Interorganizational Workflow”, Information Systems, 24(8), pp. 639-671, 2000

19 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

20 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

21 Lumbroso, L., “Glossaire”, Journal en ligne 01net, Ed. : Groupe TEST, Paris, France, 200422 Anderson, M., Allen, R., “Workflow Interoperability - Enabling E-Commerce”, WfMC White Paper, April 1,

199923 Zhuge, H., “Component-based workflow systems development”, Decision Support Systems 35 (2003), pp. 517-

536, Elsevier, 200324 Object Management Group (OMG), “Common Object Request Broker Architecture: Core Specification”,

http://www.omg.org/, 200425 Sun Microsystems, “JavaBeans for Java Studio Architecture and API”, White paper, 199726 Microsoft Corporation, “The Component Object Model Specification”,

http://www.microsoft.com/Com/resources/comdocs.asp, 200427 Oracle Corporation, “Oracle Workflow with J2EE”, White Paper, 200328 Jennings, N., Wooldridge, M. “Agent-Oriented Software Engineering”, dans : “Handbook of Agent

Technology”, Ed. Bradshaw, J., AAAI/MIT Press, 200129 Ferber, J., “Les sytèmes multi-agents. Vers une intelligence collective”, Editions InterEditions, 199530 Nwana, H., “Software Agents: An Overview”, Knowledge Engineering Review, 11(3), pp.1-40, Cambridge

University Press, R.U.,199631 Joeris, G.: “Decentralized and Flexible Workflow Enactment Based on Task Coordination Agents”,

Proceedings of the Conference Workshop on Agent-Oriented Information Systems, AOIS, 200032 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

33 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

34 Das, S., “ORBWork: A distributed, CORBA-based runtime for the METEOR2 workflow management system”,

Master’s Thesis, University of Georgia, USA, 199735 Sheth, A., “METEOR Workflow Management System”, Présentation, University of Georgia, USA36 Wang, X., “NEOWork: A Reliable CORBA-Based Workflow Enactment System for METEOR2”, Masters

Thesis, University of Georgia, USA, Sept. 199737 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

38 CrossFlow, “Cross-Organizational Workflow Support in Virtual Enterprises”, ESPRIT Project 28635, site en ligne : http://www.crossflow.org, 2004

39 Hoffner, Y., Ludwig, H., Grefen, P. Aberer, K., “CrossFlow: Integrating Workflow Management and Electronic Commerce”, ACM SIGecom Exchanges, 2(1), pp. 1-10, 2001

40 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

41 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

42 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.

43 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

44 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

45 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

46 ILOG, “ILOG Scheduler - Users Manual”, ILOG S.A., Gentilly, France, 199847 Tison, S., “Résumé du Cours”, Maîtrise Informatique U.S.T.L, Oct. 200248 Petit, T., “Modélisation et Algorithmes de Résolution de Problèmes Sur-Contraints”, Ph.D. Thesis, Université

de Montpellier II, 200249 Goldberg, D. E., “Genetic Algorithms in Search, Optimization, and Machine Learning”, Addison-Wesley,

Reading, Mass., USA, 198950 Davis, L., “Job Shop Scheduling with Genetic Algorithms”, Proceedings of the 1st International Conference

on Genetic Algorithms, pp.136-140, 198551 Neumaier, A., “Complete Search in Continuous Global Optimization and Constraint Satisfaction”, dans “Acta

Numerica 2004”, Ed.: A. Iserles, Cambridge University Press 200452 Kirkpatrick, S., Gelatt, C., Vecchi, M., “Optimisation by Simulated Annealing”, Science, No. 220, pp. 671-

680, 198353 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

54 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

55 Mooney, E., Rardin, R.L., “Tabu search for a class of scheduling problems”, Annals of Operations Research, 41, pp. 253-278, 1993

56 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

57 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

58 Clerc, M., “Optimisation par Essaim Particulaire”, Tutoriel, Premier séminaire francophone sur le thème de

l'optimisation par essaim particulaire (OEP), Paris 200359 Rossi, A., “Ordonnancement en milieu incertain, mise en œuvre d’une démarche robuste”, Ph.D. Thesis,

Institut Polytechnique National de Grenoble, 14. oct. 200360 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/199761 Walsh, T., “Stochastic constraint programming”, Proceedings of the 15th ECAI. European Conference on

Artificial Intelligence, IOS Press, 200262 Hannebauer, M., “A Formalization of Reconfiguration in Distributed Constraint Satisfaction”, Fundamenta

Matematicae 43 (2000), IOS Press, 200063 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, 200064 Babanov, A., Collins, J., Gini, M., “Scheduling Tasks with Precedence Constraints to Solicit Desirable Bid

Combinations”, AAMAS’03, July 14-18, Melbourne, Australia, 200365 Smith, F., “Is scheduling a solved problem?”, Proceedings of the First MultiDisciplinary International

Conference on Scheduling: Theory and Applications (MISTA), Nottingham, UK, 200366 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

67 Montana, D., Herrero, J., Vidaver, G., Bidwell, G., “A Multiagent Society for Military Transportation Scheduling”, Journal of Scheduling, 3(4). 2000

68 Liu, J.-S., “Coordination of Multiple Agents in Distributed Manufacturing Scheduling”, Ph.D. Thesis, Robotics Institute, Carnegie Mellon University, avril 1996

69 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

70 Cao, J., Jarvis, S., Saini, S., “ARMS: An agent-based resource management system for grid computing”, Scientific Programming 10(2), pp. 135-148, 2002

71 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

72 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

73 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

74 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. 229-248, 1997

75 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

76 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

77 Kamath, M. U., “Improving Correctness and Failure Handling in Workflow Management Systems”, Ph.D. Thesis, University of Massachusetts Amherst, 1998

78 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

79 Filipp, D., “CThread - a Worker Thread wrapper class”, http://www.codeproject. com/threads/cthread.asp80 Pomakis, K., “KP Libraries”, http://www.pomakis.com/kplib/81 Lohmann, D., “CEditLog - fast logging into an edit control with cout”,

http://www.codeproject.com/editctrl/editlog.asp82 Kanzow, S. “Multithreaded GUI Agent Testbed”, http://www.liia-paris12. net/index.php?

chemin=./thematiques/siad/qualite_serv_m-a/these_kanzow/HTMLDocu /index.html83 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., 199984 Burkhart, R., “The Swarm Multi-Agent Simulation System”, Object-Oriented Programming Systems:

Languages and Applications (OOPSLA), 199485 Gutknecht, O., Ferber, J., “The MADKIT Agent Platform Architecture”, Revised Papers from the International

Workshop on Infrastructure for Multi-Agent Systems, pp. 48-55, 200186 Foundation For Intelligent Physical Agents, “FIPA Abstract Architecture Specification”, http://www.fipa.org,

200287 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

88 AgentLink, “Agent Software”, http://www.agentlink.org/resources/agent-software.php89 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

I 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 <agent:taskExecution…/>). 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 <agent:ReserveResources…>, 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 <agent:tasklist…/>, 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 <agent:requestProba…/>), l’agent répond par un message intitulé

<agent:probaValues…/>, 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 <agent:resAvailability…/> 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

<?xml version="1.0"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:agent="http://www.liia-paris12.net"targetNamespace="http://www.liia-paris12.net"

elementFormDefault="qualified"><xsd:element name="agentdata" type="agent:agentdata"/><xsd:element name="tasklist" type="agent:tasklist"/><xsd:element name="requestProba" type="agent:requestProba"/><xsd:element name="probaValues" type="agent:probaValues"/><xsd:element name="reserveResources" type="agent:reserveResources"/><xsd:element name="resAvailability" type="agent:resAvailability"/><xsd:element name="taskExecution" type="agent:taskExecution"/><xsd:complexType name="agentdata">

<xsd:sequence><xsd:element name="node" maxOccurs="unbounded"><xsd:complexType>

<xsd:sequence><xsd:element name="task" maxOccurs="unbounded"><xsd:complexType>

<xsd:sequence minOccurs="0"><xsd:element name="successor" minOccurs="0"

maxOccurs="unbounded"><xsd:complexType>

<xsd:attribute name="node_name" type="xsd:token"use="required"/>

<xsd:attribute name="task_name" type="xsd:token"use="required"/>

</xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="name" type="xsd:token"

use="required"/><xsd:attribute name="length" type="xsd:nonNegativeInteger"

use="required"/><xsd:attribute name ="resourcereq"

type="xsd:nonNegativeInteger" use="required"/></xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="name" type="xsd:token" use="required"/>

</xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="maxdur" type="xsd:nonNegativeInteger"

use="required"/></xsd:complexType>

<xsd:complexType name="tasklist"><xsd:sequence>

<xsd:element name="task" maxOccurs="unbounded"><xsd:complexType>

<xsd:sequence><xsd:element name="dependency" minOccurs="0"

maxOccurs="unbounded"><xsd:complexType>

<xsd:attribute name="agent_name" type="xsd:token"use="required"/>

<xsd:attribute name="sequence_number"type="xsd:nonNegativeInteger" use="required"/>

</xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="name" type="xsd:token" use="required"/><xsd:attribute name="resource_node" type="xsd:token"

use="required"/><xsd:attribute name="sequence_number"

type="xsd:nonNegativeInteger" use="required"/></xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="ordered" type="xsd:boolean" use="required"/><xsd:attribute name="time_step" type="xsd:nonNegativeInteger"

use="required"/></xsd:complexType>

<xsd:complexType name="requestProba"><xsd:sequence>

<xsd:element name="task" maxOccurs="unbounded"><xsd:complexType>

<xsd:attribute name="sequence_number"type="xsd:nonNegativeInteger" use="required"/>

</xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="time_step" type="xsd:nonNegativeInteger" use="required"/>

</xsd:complexType>

<xsd:complexType name="probaValues"><xsd:sequence>

<xsd:element name="task" minOccurs="0" maxOccurs="unbounded"><xsd:complexType>

<xsd:sequence><xsd:element name="probability" minOccurs="0"

maxOccurs="unbounded"><xsd:complexType>

<xsd:attribute name="time_slot"type="xsd:nonNegativeInteger" use="required"/>

<xsd:attribute name="value" type="xsd:float"use="required"/>

</xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="sequence_number"

type="xsd:nonNegativeInteger" use="required"/><xsd:attribute name="doesnt_exist" type="xsd:boolean"

use="optional"/></xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="time_step" type="xsd:nonNegativeInteger"

use="required"/></xsd:complexType>

<xsd:complexType name="reserveResources"><xsd:sequence>

<xsd:element name="reserveSlot" minOccurs="0"maxOccurs="unbounded">

<xsd:complexType><xsd:attribute name="time_slot" type="xsd:nonNegativeInteger"

use="required"/><xsd:attribute name="task" type="xsd:token" use="required"/><xsd:attribute name="utility" type="xsd:float" use="required"/>

</xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="time_step" type="xsd:nonNegativeInteger"

use="required"/></xsd:complexType>

<xsd:complexType name="resAvailability"><xsd:sequence>

<xsd:element name="availability" minOccurs="0"maxOccurs="unbounded">

<xsd:complexType><xsd:attribute name="time_slot" type="xsd:nonNegativeInteger"

use="required"/><xsd:attribute name="value" type="xsd:float" use="required"/>

</xsd:complexType></xsd:element>

</xsd:sequence><xsd:attribute name="time_step" type="xsd:nonNegativeInteger"

use="required"/></xsd:complexType>

<xsd:complexType name="taskExecution"><xsd:attribute name="time_step" type="xsd:nonNegativeInteger"

use="required"/><xsd:attribute name="task_name" type="xsd:token" use="required"/>

<xsd:attribute name="node_name" type="xsd:token" use="required"/></xsd:complexType>

</xsd:schema>

I Un exemple d’un fichier de scénario

<?xml version="1.0"?><!--########################################################################## Creating configuration test data. # Start time: Tue Dec 09 15:58:48.806 2003## Command line:# testgen# 4 10 1.5 4 3 1 0 0.1 t4_1 20## Parameters:# n_nodes: 4 (number of nodes)# mean_tasks: 10 (mean value of tasks per node)# dev_tasks: 1 (std. deviation of tasks per node)# mean_dur: 4 (mean value for task duration)# dev_dur: 3 (std. deviation for task duration)# mean_res: 1 (mean value for a task's resource requirement)# dev_res: 0 (std. deviation for resource requirement)# prob_prec: 10% (probability of precedence constraint between 2 tasks)# file_out: t4_1000.xml (output file name)#########################################################################--><agent:agentdata xmlns:agent="http://www.liia-paris12.net" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liia-paris12.net file://C://Documents%20and%20Settings/Seb/Mes%20documents/C++/AgentApp/AgentApp.xsd" maxdur="197">

<agent:node name="Node 0"><agent:task name="Task 0" length="9" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 4"/><agent:successor node_name="Node 2" task_name="Task 2"/><agent:successor node_name="Node 2" task_name="Task 6"/><agent:successor node_name="Node 3" task_name="Task 0"/><agent:successor node_name="Node 3" task_name="Task 3"/>

</agent:task><agent:task name="Task 1" length="6" resourcereq="1"/><agent:task name="Task 2" length="6" resourcereq="1"/><agent:task name="Task 3" length="13" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 4"/><agent:successor node_name="Node 1" task_name="Task 7"/><agent:successor node_name="Node 3" task_name="Task 4"/>

</agent:task><agent:task name="Task 4" length="4" resourcereq="1">

<agent:successor node_name="Node 3" task_name="Task 7"/><agent:successor node_name="Node 3" task_name="Task 8"/>

</agent:task><agent:task name="Task 5" length="4" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 3"/><agent:successor node_name="Node 1" task_name="Task 4"/><agent:successor node_name="Node 1" task_name="Task 6"/><agent:successor node_name="Node 2" task_name="Task 7"/><agent:successor node_name="Node 3" task_name="Task 7"/>

</agent:task></agent:node><agent:node name="Node 1">

<agent:task name="Task 0" length="1" resourcereq="1"><agent:successor node_name="Node 0" task_name="Task 2"/><agent:successor node_name="Node 1" task_name="Task 3"/><agent:successor node_name="Node 2" task_name="Task 9"/><agent:successor node_name="Node 3" task_name="Task 8"/>

</agent:task><agent:task name="Task 1" length="10" resourcereq="1">

<agent:successor node_name="Node 2" task_name="Task 11"/><agent:successor node_name="Node 3" task_name="Task 2"/><agent:successor node_name="Node 3" task_name="Task 7"/><agent:successor node_name="Node 3" task_name="Task 10"/>

</agent:task><agent:task name="Task 2" length="2" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 5"/><agent:successor node_name="Node 2" task_name="Task 2"/><agent:successor node_name="Node 2" task_name="Task 9"/><agent:successor node_name="Node 3" task_name="Task 0"/>

</agent:task><agent:task name="Task 3" length="4" resourcereq="1">

<agent:successor node_name="Node 0" task_name="Task 2"/>

<agent:successor node_name="Node 0" task_name="Task 4"/><agent:successor node_name="Node 1" task_name="Task 2"/><agent:successor node_name="Node 2" task_name="Task 0"/><agent:successor node_name="Node 2" task_name="Task 4"/><agent:successor node_name="Node 2" task_name="Task 9"/>

</agent:task><agent:task name="Task 4" length="10" resourcereq="1">

<agent:successor node_name="Node 0" task_name="Task 2"/></agent:task><agent:task name="Task 5" length="1" resourcereq="1">

<agent:successor node_name="Node 2" task_name="Task 7"/></agent:task><agent:task name="Task 6" length="4" resourcereq="1">

<agent:successor node_name="Node 2" task_name="Task 6"/><agent:successor node_name="Node 2" task_name="Task 8"/><agent:successor node_name="Node 2" task_name="Task 11"/><agent:successor node_name="Node 3" task_name="Task 2"/>

</agent:task><agent:task name="Task 7" length="1" resourcereq="1">

<agent:successor node_name="Node 0" task_name="Task 5"/><agent:successor node_name="Node 2" task_name="Task 1"/>

</agent:task></agent:node><agent:node name="Node 2">

<agent:task name="Task 0" length="7" resourcereq="1"><agent:successor node_name="Node 2" task_name="Task 2"/>

</agent:task><agent:task name="Task 1" length="6" resourcereq="1"/><agent:task name="Task 2" length="8" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 4"/><agent:successor node_name="Node 2" task_name="Task 3"/><agent:successor node_name="Node 2" task_name="Task 7"/><agent:successor node_name="Node 3" task_name="Task 6"/>

</agent:task><agent:task name="Task 3" length="8" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 5"/><agent:successor node_name="Node 3" task_name="Task 6"/>

</agent:task><agent:task name="Task 4" length="3" resourcereq="1">

<agent:successor node_name="Node 2" task_name="Task 6"/><agent:successor node_name="Node 3" task_name="Task 6"/>

</agent:task><agent:task name="Task 5" length="7" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 2"/><agent:successor node_name="Node 2" task_name="Task 10"/><agent:successor node_name="Node 3" task_name="Task 4"/><agent:successor node_name="Node 3" task_name="Task 8"/>

</agent:task><agent:task name="Task 6" length="6" resourcereq="1">

<agent:successor node_name="Node 3" task_name="Task 6"/></agent:task><agent:task name="Task 7" length="2" resourcereq="1">

<agent:successor node_name="Node 3" task_name="Task 7"/></agent:task><agent:task name="Task 8" length="8" resourcereq="1">

<agent:successor node_name="Node 2" task_name="Task 4"/><agent:successor node_name="Node 2" task_name="Task 10"/><agent:successor node_name="Node 3" task_name="Task 3"/><agent:successor node_name="Node 3" task_name="Task 10"/>

</agent:task><agent:task name="Task 9" length="6" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 1"/><agent:successor node_name="Node 3" task_name="Task 5"/><agent:successor node_name="Node 3" task_name="Task 9"/>

</agent:task><agent:task name="Task 10" length="1" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 0"/><agent:successor node_name="Node 1" task_name="Task 1"/><agent:successor node_name="Node 1" task_name="Task 2"/><agent:successor node_name="Node 1" task_name="Task 4"/><agent:successor node_name="Node 2" task_name="Task 1"/><agent:successor node_name="Node 3" task_name="Task 5"/><agent:successor node_name="Node 3" task_name="Task 9"/>

</agent:task>

<agent:task name="Task 11" length="6" resourcereq="1"><agent:successor node_name="Node 1" task_name="Task 5"/><agent:successor node_name="Node 2" task_name="Task 3"/><agent:successor node_name="Node 3" task_name="Task 0"/><agent:successor node_name="Node 3" task_name="Task 1"/>

</agent:task></agent:node><agent:node name="Node 3">

<agent:task name="Task 0" length="8" resourcereq="1"><agent:successor node_name="Node 3" task_name="Task 3"/><agent:successor node_name="Node 3" task_name="Task 5"/>

</agent:task><agent:task name="Task 1" length="4" resourcereq="1"/><agent:task name="Task 2" length="6" resourcereq="1">

<agent:successor node_name="Node 3" task_name="Task 10"/></agent:task><agent:task name="Task 3" length="4" resourcereq="1">

<agent:successor node_name="Node 2" task_name="Task 0"/><agent:successor node_name="Node 3" task_name="Task 2"/><agent:successor node_name="Node 3" task_name="Task 7"/>

</agent:task><agent:task name="Task 4" length="2" resourcereq="1">

<agent:successor node_name="Node 1" task_name="Task 4"/><agent:successor node_name="Node 1" task_name="Task 7"/><agent:successor node_name="Node 2" task_name="Task 0"/><agent:successor node_name="Node 2" task_name="Task 7"/>

</agent:task><agent:task name="Task 5" length="4" resourcereq="1">

<agent:successor node_name="Node 3" task_name="Task 8"/></agent:task><agent:task name="Task 6" length="1" resourcereq="1">

<agent:successor node_name="Node 0" task_name="Task 2"/></agent:task><agent:task name="Task 7" length="5" resourcereq="1">

<agent:successor node_name="Node 0" task_name="Task 1"/><agent:successor node_name="Node 2" task_name="Task 1"/>

</agent:task><agent:task name="Task 8" length="4" resourcereq="1">

<agent:successor node_name="Node 2" task_name="Task 4"/></agent:task><agent:task name="Task 9" length="6" resourcereq="1">

<agent:successor node_name="Node 0" task_name="Task 2"/></agent:task><agent:task name="Task 10" length="11" resourcereq="1">

<agent:successor node_name="Node 2" task_name="Task 0"/><agent:successor node_name="Node 2" task_name="Task 1"/>

</agent:task></agent:node>

</agent:agentdata>

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