une approche sémantique pour la description, …tata/pdf/these-nomane.pdfla démocratisation de la...

TELECOM & Management SudParis (ex INT) Université d’Évry Val d’Essonne

Thèse de doctorat de l’Institut National des Télécommunications dans le cadre de l’école

doctorale SITEVRY en co-accréditation avecl’Université d’Évry Val d’Essonne

spécialité informatique

Par :

Nomane OULD AHMED M’BARECK

Thèse présentée pour l’obtention du grade de Docteur de l’Institut Nationaldes Télécommunications

Une approche sémantique pour la description,l’abstraction et l’interconnexion de workflows dans

un contexte inter-organisationnel

Soutenue le 17 octobre 2008 devant le jury composé de :

Rapporteurs :M. Barkaoui, Kamel Professeur au Conservatoire National des Arts et MétiersM. Charoy, François HDR, Maître de Conférences à l’Université de Nancy

Examinateurs :M. Benslimane, Djamal Professeur à l’Université de LyonM. Vincent, Hugues Architecte Système à Thales Communications FranceM. Bernard, Guy Professeur à l’Institut TELECOM ; TMSP (ex. INT)M. Bruno DEFUDE Professeur à l’Institut TELECOM ; TMSP (Directeur de thèse)M. Samir TATA Maître de conférence à l’Institut TELECOM ; TMSP (Encadrant)

Thèse numéro : 05INT005

Résumé

La démocratisation de la technologie de l’information et des moyens de communication ouvrela voie aux entreprises pour réaliser, via la coopération, certaines tâches complexes qui n’étaientpas à leur portée, soit du fait de leur taille (il s’agit souvent des petites ou moyennes entreprises),soit du fait des compétences requises pour la réalisation des tâches en question.

L’objectif de cette thèse est de proposer une approche sémantique pour la coopération desworkflows. Cette approche doit supporter la description, l’abstraction et l’interconnexion de work-flows. Pour ce faire, nous proposons premièrement de décrire les sémantiques métiers et com-portementale des workflows. Une telle description permet le partage des données d’une part, etfacilite l’interconnexion automatique d’autre part. Deuxièmement, les workflows sont publiés dansun annuaire commun. Nous proposons dans cette thèse des structures de donnés permettant destocker efficacement les workflows dans l’annuaire. Troisièmement, afin de préserver le savoir-faire des différents partenaires participant à une coopération, nous proposons deux méthodesformelles pour l’abstraction des workflows. La première méthode se base sur des règles de ré-duction structurelle tandis que la deuxième se base sur la réduction du graphe représentant lecomportement. Enfin, après l’abstraction et la publication de workflows, nous procédons dans ladernière étape à leur interconnexion. Pour faciliter cette interconnexion nous proposons un ser-vice de courtage pour la découverte des workflows. Ce service prend en compte les sémantiquesmétier et comportemental des workflows. Nous avons validé les solutions proposées à l’aide d’unprototype permettant l’interconnexion dynamique des compositions de services Web BPEL.

Mots-clés : workflows interentreprises, description sémantique, abstraction, coopération, ser-vices Web.

Abstract

The democratization of information technology and the mean of communication opens the wayfor the companies to carry out, via the co-operation, certain complex tasks which were not withtheir range, either because of their size (they are often small or medium-sized companies), orbecause of competences necessary for the realization of the tasks in question.

The objective of this thesis is to propose a semantic approach for the workflows co-operation.This approach must support the description, the abstraction and the interconnection of workflows.To reach this end, we firstly propose to describe trade and behavioural semantics of workflows.Such a description allows sharing data on the one hand, and facilitates the automatic interconnec-tion on the other hand. Secondly, the workflows are published in a common registry. We proposein this thesis structures of data allowing to effectively store the workflows in the directory. Thirdly, inorder to preserve the know-how of the different partners taking part in a co-operation, we proposetwo formal methods for the abstraction of the workflows. The first method is based on structuralreduction rules while the second is based on the reduction of the graph representing the beha-viour. Lastly, after the abstraction and the publication of workflows, we proceed in the last stepto their interconnection. To facilitate this interconnection we propose a broker for the discovery ofthe workflows. This broker takes into account trade and behavioural semantics of the workflows.We validated the proposed solutions using a prototype allowing the dynamic interconnection ofthe compositions of Web services BPEL.

Keywords : semantic description, interorganizational workflows, abstraction, cooperation,Web services.

Table des matières

I Problématique et État de l’art 1

1 Introduction 3

2 Contexte et problématique 5

2.1 Contexte général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1.2 Les workflows vus par la WfMC . . . . . . . . . . . . . . . . . . . 8

2.1.1.3 Les workflows vus par l’OMG . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Approche ascendante vs approche descendante . . . . . . . . . . . . . . . 9

2.1.3 Principes à préserver par l’approche de la coopération choisie . . . . . . . 11

2.2 Coopération dans le cadre de l’approche CoopFlow . . . . . . . . . . . . . . . . . 12

2.2.1 Point de départ : L’approche CoopFlow . . . . . . . . . . . . . . . . . . . . 12

2.2.1.1 Abstraction et publication de workflow . . . . . . . . . . . . . . . . 12

2.2.1.2 Appariement et interconnexion de workflows . . . . . . . . . . . . 13

2.2.1.3 Coopération et surveillance de workflows . . . . . . . . . . . . . . 15

2.2.2 Limites de CoopFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Objectif de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Exemple support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Langages de description de workflows et de services Web 21

3.1 Description syntaxique de workflows . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 BPEL4WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2 YAWL (Yet Another Workflow Language) . . . . . . . . . . . . . . . . . . . . 22

3.1.3 XPDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

vii

viii TABLE DES MATIÈRES

3.2 Description sémantique de services Web . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 OWL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1.1 Motivations de OWL-S . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1.2 Ontologie supérieure de OWL-S . . . . . . . . . . . . . . . . . . . 27

3.2.2 SAWSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.2.1 Motivations de SAWSDL . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.2.2 Annotation sémantique . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.3 WSMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.3.1 Motivations de WSMO . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.3.2 Les facettes de WSMO . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Appariement comportemental de workflows 35

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Préliminaire sur les réseaux de Pétri . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 Séquence de franchissement et conflit . . . . . . . . . . . . . . . . . . . . . 37

4.2.3 Propriétés des réseaux de Pétri . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.3.1 Propriétés dynamiques . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.3.2 Propriétés structurelles . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 Agglomération structurelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3.1 Post-agglomération structurelle . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.1.1 Les propriétés de la réduction post-agglomération . . . . . . . . . 42

4.3.1.1.1 La propriété HF-interchangeabilité . . . . . . . . . . . . . 42

4.3.1.1.2 La propriété F-indépendance . . . . . . . . . . . . . . . . 43

4.3.1.1.3 La propriété F-continuation . . . . . . . . . . . . . . . . . 43

4.3.2 Pré-agglomeration structurelle . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.2.1 Les propriétés de la réduction pre-agglomération . . . . . . . . . . 45

4.3.2.1.1 La propriété H-indépendance . . . . . . . . . . . . . . . . 45

4.3.2.1.2 La propriété de non divergence structurelle . . . . . . . 45

4.3.2.1.3 La propriété de quasi-persistance structurelle . . . . . . 45

4.3.2.1.4 La propriété de H-similarité . . . . . . . . . . . . . . . . . 46

4.4 Appariement de workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

TABLE DES MATIÈRES ix

4.4.1 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4.2 Approches d’appariement comportemental des workflows . . . . . . . . . . 49

4.4.2.1 Types d’équivalence des workflows . . . . . . . . . . . . . . . . . 49

4.4.2.1.1 Equivalence des traces . . . . . . . . . . . . . . . . . . . 49

4.4.2.1.2 Equivalence par bissimulation . . . . . . . . . . . . . . . 49

4.4.2.1.3 Equivalence par simulation . . . . . . . . . . . . . . . . . 50

4.4.2.2 Utilisabilité des workflows . . . . . . . . . . . . . . . . . . . . . . . 50

4.4.2.3 Découverte de services en utilisant la spécification du comportement 51

4.4.2.3.1 Transformation de WSCL en graphe . . . . . . . . . . . . 53

4.4.2.3.2 La décomposition des interactions . . . . . . . . . . . . . 54

4.4.2.3.3 Règles de comparaison . . . . . . . . . . . . . . . . . . . 54

4.4.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

II Contributions 59

5 Description sémantique de workflows 61

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2 Exemple d’ontologie modélisant le domaine de l’assurance . . . . . . . . . . . . . 63

5.2.1 Comptabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.2 Interaction Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2.3 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.4 Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Annotation sémantique de XPDL (SAXPDL) . . . . . . . . . . . . . . . . . . . . . . 67

5.3.1 Principe de l’annotation sémantique . . . . . . . . . . . . . . . . . . . . . . 68

5.3.2 Les mécanismes d’annotation . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.2.1 L’attribut modelReference de SAXPDL . . . . . . . . . . . . . . . . 69

5.3.2.2 L’attribut schemaMapping de SAXPDL . . . . . . . . . . . . . . . . 69

5.3.3 Annotation des documents XPDL . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.3.1 Annotation des activités . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3.3.2 Annotation des types de données . . . . . . . . . . . . . . . . . . 73

5.3.4 Capacités des activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4 OWL-Ontologie pour les workflows inter-organisationnel . . . . . . . . . . . . . . . 75

x TABLE DES MATIÈRES

5.4.1 Limites du méta-modèle des workflows de WfMC . . . . . . . . . . . . . . . 76

5.4.2 Ontologie de workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.4.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.4.4 Inference sur l’ontologie des workflows . . . . . . . . . . . . . . . . . . . . 80

5.4.4.1 Règles générales . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.4.4.2 Règles métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5 Synthèse et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6 Abstraction structurelle et comportementale de workflows 87

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 Graphe de marquage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3 Abstraction structurelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3.1 Préservation de la trace du workflow projetée sur ses activités coopératives 91

6.3.2 Formalisation des règles d’abstraction définies dans [15] . . . . . . . . . . 91

6.3.3 Deuxième catégorie de règles d’abstraction . . . . . . . . . . . . . . . . . . 96

6.3.3.1 Propriété particulière des workflows . . . . . . . . . . . . . . . . . 96

6.3.3.2 Règles d’abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.4 Abstraction comportementale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.4.1 Construction des graphes d’observation symboliques . . . . . . . . . . . . 103

6.4.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.4.3 Préservation du langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7 Appariement métier et comportemental de workflows 117

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7.2 Appariement de la sémantique métier . . . . . . . . . . . . . . . . . . . . . . . . . 118

7.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

7.2.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7.2.3 Requête par l’exemple (QBE ) . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.2.4 Préférences utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.2.5 Différencier entre les entrées et les sorties lors de l’appariement . . . . . . 123

7.2.6 Algorithme d’appariement sémantique . . . . . . . . . . . . . . . . . . . . . 124

7.2.6.1 Appariement de concepts . . . . . . . . . . . . . . . . . . . . . . . 124

7.2.6.2 Impact des préférences utilisateur sur l’appariement . . . . . . . . 125

TABLE DES MATIÈRES xi

7.2.6.3 L’appariement global : calcul du résultat final . . . . . . . . . . . . 126

7.3 Appariement comportemental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

7.3.1 Propriété Candidat à la coopération . . . . . . . . . . . . . . . . . . . . . . 129

7.3.2 Algorithme d’appariement comportemental . . . . . . . . . . . . . . . . . . 132

7.3.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

7.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8 Mise en œuvre 139

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

8.2 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.2.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8.3 Structures de données pour le stockage des workflows . . . . . . . . . . . . . . . 142

8.3.1 Matrice d’adjacence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.2 Liste d’adjacence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.3.3 Diagramme de décision binaire . . . . . . . . . . . . . . . . . . . . . . . . . 145

8.3.3.1 Logique propositionnelle . . . . . . . . . . . . . . . . . . . . . . . 145

8.3.3.1.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

8.3.3.1.2 Expression Booléenne . . . . . . . . . . . . . . . . . . . 145

8.3.3.2 Forme normale If-Then-Else (INF) . . . . . . . . . . . . . . . . . . 146

8.3.3.3 Construction d’un diagramme de décision binaire . . . . . . . . . 146

8.3.3.4 Règles de réduction . . . . . . . . . . . . . . . . . . . . . . . . . . 147

8.3.3.5 Diagramme de décision binaire réduit . . . . . . . . . . . . . . . . 147

8.3.3.6 Représentation d’un graphe par un BDD . . . . . . . . . . . . . . 149

8.3.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

8.4 Abstraction et publication de workflow . . . . . . . . . . . . . . . . . . . . . . . . . 151

8.5 Appariement et interconnexion des workflows . . . . . . . . . . . . . . . . . . . . . 153

8.5.1 Interconnexion dynamique des services Web composés (BPEL) . . . . . . 153

8.5.1.1 L’annuaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

8.5.1.2 Abstracteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

8.5.1.3 Apparieur (MatchMaker) . . . . . . . . . . . . . . . . . . . . . . . 155

8.5.1.4 Parseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

8.5.1.5 Superviseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

8.5.2 Inférence sur les workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

8.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

xii TABLE DES MATIÈRES

9 Conclusions et perspectives 159

9.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

9.2.1 Amélioration de l’appariement . . . . . . . . . . . . . . . . . . . . . . . . . 161

9.2.2 Abstraction structurelle ou abstraction comportementale . . . . . . . . . . . 161

9.2.3 Cohérence de propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

9.2.4 Vérification de propriétés non fonctionnelles . . . . . . . . . . . . . . . . . . 161

A Code source de l’exemple 163

A.1 Code source de l’ontologie en OWL . . . . . . . . . . . . . . . . . . . . . . . . . . 163

A.2 Code source du workflow de l’assuré en XPDL . . . . . . . . . . . . . . . . . . . . 170

A Construction du graphe de marquage 177

Bibliographie 184

Table des figures

2.1 Abstraction d’activités internes séquentielles . . . . . . . . . . . . . . . . . . . . . 14

2.2 Les workflows d’un assuré et d’une société d’assurance . . . . . . . . . . . . . . . 18

3.1 Exemple de spécification de workflows de services en BPEL . . . . . . . . . . . . 23

3.2 description XPDL du l’activité devis . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 L’ontologie supérieure de OWL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Service OWL-S de l’assuré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Le profil de l’assuré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Le processus de l’assuré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.7 Opération devis de l’assuré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.8 Description de l’opération devis de l’assuré en SAWSDL . . . . . . . . . . . . . . . 30

3.9 Description d’un concept en WSMO . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.10 Description d’une instance en WSMO . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.11 Description en WSMO du service devis de l’assuré . . . . . . . . . . . . . . . . . 32

3.12 Description en WSMO du service devis de l’assuré . . . . . . . . . . . . . . . . . 32

3.13 Comparaison de OWL-S, SAWSDL et WSMO . . . . . . . . . . . . . . . . . . . . . 33

4.1 Exemple de réseau de Pétri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Principe de la post-agglomération . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3 Exemple illustrant le principe de la pre-agglomération . . . . . . . . . . . . . . . . 44

4.4 Description 1 : Workflows du service et celui de l’usager . . . . . . . . . . . . . . . 47



4.7 Graphe de marquages des workflows de l’usager (a) et du service (b) . . . . . . . 48

4.8 Graphe de communication de la description 1 du service . . . . . . . . . . . . . . 52

4.9 Graphe de communication de la description 2 du service . . . . . . . . . . . . . . 52

xiii

xiv TABLE DES FIGURES

4.10 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1 Ontologie supérieure d’une compagnie d’assurance . . . . . . . . . . . . . . . . . 63

5.2 Ontologie simplifiée de la comptabilité d’une compagnie d’assurance . . . . . . . . 64

5.3 Ontologie simplifiée de l’interaction client/compagnie d’assurance . . . . . . . . . 65

5.4 Ontologie simplifiée de ce que loue la compagnie d’assurance . . . . . . . . . . . 66

5.5 Ontologie simplifiée des domaines d’expertise de la compagnie d’assurance . . . 66

5.6 Annotation sémantique d’un type de message dans un workflow . . . . . . . . . . 68

5.7 Définition du schéma XML de de l’attribut modelReference . . . . . . . . . . . . . 69

5.8 Définition du schéma XML de l’attribut schemaMapping . . . . . . . . . . . . . . . 70

5.9 Workflow d’un assuré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.10 Noms XPDL des activités du workflow de l’assuré . . . . . . . . . . . . . . . . . . 71

5.11 Définition XPDL de l’activité Decl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.12 Annotation sémantique de l’activité Decl . . . . . . . . . . . . . . . . . . . . . . . . 72

5.13 Annotation sémantique de l’activité Acc . . . . . . . . . . . . . . . . . . . . . . . . 72

5.14 Définition du type de donné DeclarationInfo . . . . . . . . . . . . . . . . . . . . . . 73

5.15 Annotation sémantique du type de données DeclarationInfo . . . . . . . . . . . . . 73

5.16 Correspondance entre la structure du DeclarationInfo et le concept grâce à schemaMapping 74

5.17 Exemple d’ontologie de capacités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.18 Définition du schéma XML de de l’attribut capacity . . . . . . . . . . . . . . . . . . 75

5.19 Annotation sémantique de l’activité Acc . . . . . . . . . . . . . . . . . . . . . . . . 75

5.20 Méta-modèle des workflows XPDL . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.21 Ontologie des workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.22 Hiérarchie des propriétés de l’ontologie des workflows . . . . . . . . . . . . . . . . 79

5.23 Instance de l’ontologie : Workflow de l’assuré . . . . . . . . . . . . . . . . . . . . . 79

5.24 Instance de l’ontologie : les activités et leurs entrées . . . . . . . . . . . . . . . . . 80

5.25 Instance de l’ontologie : les activités et leurs sorties . . . . . . . . . . . . . . . . . 80

5.26 Règle exprimant la transitivité de la propriété estComposeDe . . . . . . . . . . . . 81

5.27 Règle définissant la symétrie entre la propriété estComposeDe . . . . . . . . . . . 81

5.28 Règles pour les propriétés estReliee et correspondA . . . . . . . . . . . . . . . . 82

5.29 Règles pour définir la disponibilité d’un workflow . . . . . . . . . . . . . . . . . . . 83

5.30 Règles conditionnant la validité d’un workflow . . . . . . . . . . . . . . . . . . . . 83

5.31 Exemple d’activités ne pouvant pas être coopératives dans le même workflow . . . 84

TABLE DES FIGURES xv

5.32 Règles conditionnant la validité d’un workflow . . . . . . . . . . . . . . . . . . . . 84

6.1 Les graphes de marquages de l’assuré (a) et d’une société d’assurance (b) . . . . 90

6.2 Le workflow de l’assuré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.3 Abstraction d’activités internes séquentielles . . . . . . . . . . . . . . . . . . . . . 92

6.4 Abstraction d’activités internes et coopératives séquentielles . . . . . . . . . . . . 94

6.5 Abstraction d’activités alternatives suivies d’une même activité interne . . . . . . . 94

6.6 Abstraction d’une activité interne suivie d’activités alternatives . . . . . . . . . . . 96

6.7 Union des traces des workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.8 Abstraction d’activités internes alternatives . . . . . . . . . . . . . . . . . . . . . . 99

6.9 Abstraction d’activités internes et sous workflow alternatives . . . . . . . . . . . . 100

6.10 Abstraction d’activités internes et coopératives alternatives . . . . . . . . . . . . . 101

6.11 Construction du graphe d’observation de la société d’assurance, étape 1 . . . . . 106







6.18 Graphe d’observation de l’assuré (a) et celui de la société d’assurance (b) . . . . . 113

6.19 (a) Séquence observé infinie (b) Séquence maximale finie (c) Séquence divergente 114

7.1 Exemple montrant l’utilité des préférences lors de l’appariement . . . . . . . . . . 119

7.2 Description sémantique de l’activité Offre1 . . . . . . . . . . . . . . . . . . . . . . . 119




7.6 Définition du schéma XML de de l’attribut modelReferenceProp . . . . . . . . . . . 121

7.7 Découverte des offres de bienvenue transmises par virement . . . . . . . . . . . . 121

7.8 Définition du schéma XML de l’attribut preference . . . . . . . . . . . . . . . . . . . 122

7.9 Découverte des offres de bienvenue transmises par virement . . . . . . . . . . . . 122

7.10 Découverte des offre de bienvenue payable en espèce ou autre . . . . . . . . . . . 123

7.11 Découverte des offres de bienvenue payable en espèce . . . . . . . . . . . . . . . 123

7.12 Difference entre les entrées et les sorties lors de l’appariement . . . . . . . . . . . 124

xvi TABLE DES FIGURES

7.13 Appariement des requêtes des assurés et des activités offertes . . . . . . . . . . . 128

7.14 Graphes d’observation symbolique de l’assuré (a) et de la compagnie d’assurance (b)130

7.15 Graphes d’observation symbolique renommés . . . . . . . . . . . . . . . . . . . . 131

7.16 Les occurrences d’une même transition coopérative sont exécutées exclusivement 131

7.17 Appariement des workflows de l’assuré et de la compagnie d’assurance-Etape1 . 134

7.18 Appariement des workflows de l’assuré et de la compagnie d’assurance-Etape2 . 136

7.19 Appariement des workflows de l’assuré et de la compagnie d’assurance-Dernière étape136

8.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.3 Représentation d’un graphe avec une matrice d’adjacence . . . . . . . . . . . . . 144

8.4 Représentation d’un graphe avec une liste d’adjacence . . . . . . . . . . . . . . . 144

8.5 Graphe de décision binaire avant réduction . . . . . . . . . . . . . . . . . . . . . . 147

8.6 Suppression des nœuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

8.7 Graphe de décision binaire réduit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

8.8 Un graphe G = (V, E) et un codage χ : E → {0, 1}2 . . . . . . . . . . . . . . . . . . 149

8.9 Le BDD représentant le graphe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

8.10 Workflows codés sur un nombre de bits différents . . . . . . . . . . . . . . . . . . . 152

8.11 Ontologie des workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

8.12 Codage des concept et nouveau codage des arcs . . . . . . . . . . . . . . . . . . 153

8.13 Diagramme de séquence montrant l’interaction entre deux BPEL . . . . . . . . . . 154

8.14 Interaction dynamique entre deux BPELs sous Orchestra . . . . . . . . . . . . . . 155

8.15 Le Builtin définissant la suppression d’une propriété d’un concept . . . . . . . . . . 157

A.1 Structures de données de l’algorithme de construction de graphe de marquage . . 178

A.2 Marquage accessible depuis la transition Declaration . . . . . . . . . . . . . . . . . 179

A.3 Marquage accessible depuis la transition Accuse . . . . . . . . . . . . . . . . . . . 179

A.4 Marquages accessibles depuis la transition Etablir Devis . . . . . . . . . . . . . . . 180

A.5 Marquages accessibles depuis la transition Devis . . . . . . . . . . . . . . . . . . . 180

A.6 Marquages accessibles depuis la transition Avis . . . . . . . . . . . . . . . . . . . 181

A.7 Marquage accessible depuis la transition Facture . . . . . . . . . . . . . . . . . . . 181

A.8 Marquages accessibles depuis les transitions Evaluation et Reparer . . . . . . . . 182

A.9 Marquage accessible depuis la transition Evaluation . . . . . . . . . . . . . . . . . 182

A.10 Marquage accessible depuis la transition Reparer . . . . . . . . . . . . . . . . . . 183

A.11 Marquage accessible depuis la transition Paiement . . . . . . . . . . . . . . . . . . 183

Liste des algorithmes

1 Opération de comparaison des nœuds (VertexMatch) . . . . . . . . . . . . . . . . 552 Construction du graphe de marquage . . . . . . . . . . . . . . . . . . . . . . . . . 893 La cloture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034 Construction du graphe d’observation . . . . . . . . . . . . . . . . . . . . . . . . . 1045 MatchPref(Rqtpref ,Matchres) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256 MatchActivity(rqtAct, advAct) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277 (Rename(SOG1(s0, S1, T1), SOG2(s′0, S2, T2))) . . . . . . . . . . . . . . . . . . . . . 1298 (L(SOG1 = 〈s0, S1, E1〉) ⊆ L(SOG2 = 〈s′0, S2, E2〉)) ? . . . . . . . . . . . . . . . . . 133

xvii

xviii LISTE DES ALGORITHMES

Première partie

Problématique et État de l’art

Chapitre 1

Introduction

La démocratisation de la technologie de l’information et des moyens de communication ouvrela voie aux entreprises pour réaliser, via la coopération, certaines tâches complexes qui n’étaientpas à leur portée, soit du fait de leurs tailles (il s’agit souvent des petites ou moyennes entre-prises), soit du fait des compétences requises pour la réalisation des tâches en question. Si lacoopération offre aux entreprises de nouvelles opportunités, elle fait également augmenter lapression sur ces entreprises pour qu’elles soient plus compétitives. Pour ce faire, les entreprisesmodélisent leurs activités industrielles par des processus (procédés) métier [97] et coopèrentensuite électroniquement via un nouveau concept appelé entreprises virtuelles [75]. Une en-treprise virtuelle permet, en fait, l’association, autour d’un projet, d’un ensemble de partenairesdistribués dans le temps et/ou dans l’espace.

La coopération dans le cadre des entreprises virtuelles peut être abordée à travers une ap-proche ascendante ou une approche descendante. L’approche descendante consiste à définirun procédé métier commun réunissant les différents partenaires. Le procédé métier communest divisé ensuite en plusieurs sous procédés métier. Chaque participant se porte responsablede l’exécution d’un ou de plusieurs sous procédés métier. Ce type d’approche est plus adaptéaux cas des coopérations de longue durée. L’approche ascendante consiste, quant à elle, àconstruire de façon incrémentale le procédé métier global à partir des procédés métier locauxdéjà établis au sein des entreprises. Dans ce cas, peu de contraintes sont imposées aux entre-prises participantes et chacune d’elles a la possibilité de joindre ou quitter la coopération quandelle veut. Ce type d’approche est plus adapté pour une coopération de courte durée.

L’approche CoopFlow pour la coopération ascendante a été proposée dans la thèse de IssamCHEBBI [15]. CoopFlow est composée de trois étapes : (1) publication et abstraction de partiesde procédés métier d’entreprises pouvant être exploitées par d’autres entreprises, (2) apparie-ment et interconnexion de procédés métier et (3) coopération et contrôle de procédés métier.Cependant, l’approche CoopFlow présente quelques limites. D’une part, la procédure d’abstrac-tion de CoopFlow est entièrement informelle. D’autre part, l’appariement proposé dans CoopFlowest syntaxique.

Partant des travaux réalisés dans CoopFlow (l’abstraction et la publication, l’appariement etl’interconnexion, et la coopération et le contrôle), l’objectif de cette thèse est triple. Le premierobjectif est de fournir une méthode d’abstraction formelle pour les procédés métier. Le secondobjectif consiste à décrire les sémantiques métier et comportementale des procédés métier. Unetelle description permet, entre autres, le partage des données et facilite l’appariement. Le troi-

3

4 Introduction

sième et dernier objectif concerne l’amélioration de la qualité de l’appariement et la propositiond’une structure pour le stockage des procédés métier.

De ces trois objectifs découlent naturellement l’organisation de ce mémoire qui est structuréen deux parties. Dans la première partie (chapitre 2, 3 et 4), nous présentons le contexte de nostravaux ainsi que la problématique de la coopération interentreprises. La deuxième partie de cettethèse est consacrée à nos contributions (chapitre 5, 6, 7 et 8).

Le chapitre 2 constitue une introduction à la problématique traitée dans cette thèse. Dans lapremière partie de ce chapitre, nous définissons les procédés métier et nous présentons les dif-férentes approches pour la coopération des procédés métier. La deuxième partie de ce chapitreest consacrée à l’approche CoopFlow. Celle-ci constitue le point de départ de cette thèse. Latroisième partie de ce chapitre présente nos objectifs dans le cadre de cette thèse. Enfin, dansla quatrième partie nous présentons l’exemple support que nous utilisons tout au long de cettethèse. Dans la première partie du chapitre 3 nous présentons les langages de description syn-taxique des workflows. La deuxième partie de ce chapitre présente les langages de descriptionsémantique des services Web. La première partie du chapitre 4 fait un rappel sur les réseaux dePétri. Dans la deuxième partie du chapitre nous abordons les techniques d’agglomération. Cestechniques peuvent être utilisées pour abstraire les workflows. Dans la dernière partie de ce cha-pitre nous présentons et comparons les différentes approches proposées dans la littérature pourl’appariement de workflows.

Le chapitre 5 est consacré à la présentation de la première partie de notre contribution. Il s’agitde la description sémantique des workflows. Nous décrivons notamment comment les workflowspeuvent être décrit sémantiquement de deux manières et nous montrons les cas où l’une oul’autre description est plus appropriée. La première description consiste à annoter sémantique-ment les workflows. La deuxième description consiste à écrire une ontologie pour les workflows.Le chapitre 6 présente notre approche pour l’abstraction des workflows. Nous y proposons deuxméthodes d’abstraction de workflows : une comportementale et une structurelle. Le chapitre 7présente notre mécanisme d’appariement pour les workflows. Nous décrivons dans ce chapitredeux types d’appariement. Le premier est pour comparer la sémantique métier des workflows etle second est pour comparer leur sémantique comportementale. Le chapitre 8 présente la miseen œuvre de différentes contributions proposées dans cette thèse.

Le chapitre 9 conclut ce mémoire et présente quelques perspectives de notre travail.

Chapitre 2

Contexte et problématique

Sommaire2.1 Contexte général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Approche ascendante vs approche descendante . . . . . . . . . . . . . . 92.1.3 Principes à préserver par l'approche de la coopération choisie . . . . . . 11

2.2 Coopération dans le cadre de l'approche CoopFlow . . . . . . . . . . . 122.2.1 Point de départ : L'approche CoopFlow . . . . . . . . . . . . . . . . . . 122.2.2 Limites de CoopFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Objectif de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Exemple support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Dans ce chapitre nous présentons le contexte et la problématique de notre thèse. Une intro-duction générale de la problématique liée à la coopération interentreprises est donnée dans laSection 2.1. La Section 2.2 est consacrée à la présentation de l’approche CoopFlow. Cette der-nière constitue le point de départ de notre thèse. Dans la Section 2.3 nous présentons l’objectifde notre thèse. La Section 2.4 présente l’exemple support utilisé tout au long de cette thèse etnous concluons dans la Section 2.5

2.1 Contexte général

L’évolution et l’automatisation des procédés d’entreprises combinées à la baisse de leurcoût permettent aux entreprises de coopérer électroniquement pour former des entreprises vir-tuelles. La démocratisation des moyens de communication tels qu’Internet ouvre également lavoie aux entreprises pour réaliser, via la coopération, certaines tâches complexes qui n’étaientpas à leur portée, soit du fait de leur taille (il s’agit souvent des petites ou moyennes entreprises),soit du fait des compétences requises la réalisation des tâches en question. Aussi, nous pensonsque les coopérations interentreprises à large échelle vont devenir de plus en plus fréquentes etnotre objectif est de proposer une approche pour les supporter.

Dans notre cas la coopération interentreprise est effectuée via les workflows de celles-ci encréant un workflow interorganisationnel. Cependant la création de ce dernier workflow soulève uncertain nombre de questions. En effet, la coopération peut être classée en deux catégories suivant

5

6 Contexte et problématique

l’attitude de celle-ci vis-à-vis des propriétés suivantes : le respect du savoir-faire de chaque parte-naire, la tolérance à l’égard de la flexibilité, la préservation de l’autonomie de chaque participantet des workflows pré-établis. Nous distinguons ainsi deux types d’approches pour la coopérationà savoir : l’approche ascendante et l’approche descendante. La première approche est plus adé-quate à une coopération de courte durée et la seconde est plus appropriée pour une coopérationà longue durée.

Le reste de cette section est organisé comme suit. La Section 2.1.1 introduit des notions debase sur les workflows. Une comparaison entre les approches ascendantes et descendantes estdonnée dans la section 2.1.2. Enfin, dans la Section 2.1.3 nous présentons les principes quiguident le choix de l’approche appropriée à notre cas.

2.1.1 Préliminaire

Cette section est consacrée à la présentation des notions de base sur les workflows. Un work-flow (procédé métier) est un ensemble d’actions (étapes) s’enchainant dans un ordre prédéfini.Ces actions peuvent s’enchaîner en fonction de conditions, d’interactions avec d’autres workflowsou en fonction d’interactions humaines 1. Les actions sont appelées également des activités. Uneactivité est un composant réutilisable représentant une étape d’un workflow 2. Les entreprises co-opèrent via leurs workflows créant ainsi un workflow interentreprises. La coopération au sein dece dernier est défini par l’échange des flots de données entre les différents workflows participants.Deux types d’activités sont considérés : activité productrice et activité consommatrice. Une acti-vité appartenant à un workflow (A) est dite productrice lorsqu’elle est utilisée par (A) afin d’initierune activité dans un autre workflow (B) et/ou lui fournir une entrée. Une activité appartenant à unworkflow (A) est dite consommatrice lorsqu’elle reçoit d’un workflow (B) le résultat d’une activité(ou d’un ensemble d’activités) ou lorsqu’elle est initiée par ce workflow (sans communication dedonnées). Nous signalons ici qu’une activité peut être à la fois productrice et consommatrice.

Les activités coopératives représentent les points de production et/ou de consommation deflots de données au sein d’un workflow, permettant de ce fait la synchronisation et l’échange dedonnées avec d’autres workflows ainsi que la notification de changement d’états des activitéset leur exécution. Les activités coopératives peuvent être des activités productrices et/ou desactivités consommatrices.

2.1.1.1 Définitions

Définition 1 (Procédé) Dans [6, 10, 28, 89, 44], les auteurs définissent un procédé comme unensemble d’activités ordonnées selon un ensemble de règles procédurales pour réaliser un ob-jectif précis au sein d’un groupe de personnes (par exemple, dans une entreprise). Un procédédécrit la structure du groupe de personnes (par exemple membres, hiérarchie, etc.), les activitésde ces personnes, la distribution des activités à travers ce groupe (par exemple, rôle, “qui faitquoi”) et les critères de contrôle du bon déroulement de ces activités (par exemple, règles decohérences, délais, délivrables, etc.).

Un procédé peut être, totalement automatisé, comme il peut former une combinaison hybridede procédures automatiques, semi-automatiques et manuelles. Il existe un large panel d’outils de

1. http ://www.workflow-foundation.com2. http ://www.workflow-foundation.com

2.1 Contexte général 7

définition et d’exécution de procédés (par exemple, les agendas partagés, les listes des activitésà faire -to do lists-, les outils de gestion de projets, etc.).

[5] et [44] ont classé les procédés selon quatre catégories complémentaires : le procédé d’ad-ministration, le procédé de production, le procédé de collaboration et le procédé ad-hoc. Nous lesprésentons dans ce qui suit.

Définition 2 (Activité coopérative productrice) Une activité coopérative productrice est uneactivité produisant un flot de données pour une activité externe appartenant à un autre workflow.

Définition 3 (Activité coopérative consommatrice) Une activité coopérative consommatriceest une activité consommant un flot de données depuis une activité externe appartenant à unautre workflow.

Définition 4 (Activité coopérative) Une activité coopérative est une activité productrice ouconsommatrice.

Définition 5 (Activité interne) Une activité interne est une activité non coopérative.

Comme pour les activités, deux types de workflows existent : les workflows coopératifs et lesworkflows internes.

Dans un workflow interne, chaque partenaire commence par définir le workflow reflétant sonsavoir-faire et spécifiant tous les flots de données, les activités coopératives et non coopérativesainsi que les flots de contrôle correspondant. Le workflow spécifie toutes les étapes requises pourl’accomplissement des services d’un partenaire donné indépendamment des autres partenaires.Nous appelons ce workflow un workflow interne.

Le workflow externe, quant à lui, est l’abstraction d’un workflow coopératif selon une procé-dure d’abstraction que nous présentons dans 2.2.1. Celui-ci représente le comportement visiblepar un partenaire du workflow interne [18]. Dans un workflow interne, les activités et les flots decontrôle ne jouant aucun rôle direct dans la coopération sont cachés et on expose à l’extérieuruniquement les activités coopératives et le minimum d’activités internes.

Après avoir donné les différents types d’activités et de workflows, nous donnons ci-dessous ladéfinition formelle d’un workflow et sa modélisation sous forme de réseau de Pétri.

Définition 6 (Workflow) Un Workflow W(P,T,A) est un réseau de Pétri déterminé par :– un ensemble fini P={p1, p2,. . . ,pn} de places– un ensemble fini T={t1, t2,. . . , tm} de transitions (P ∩ T = ∅)– T = Tcoop ∪ Tint où Tcoop représente l’ensemble des activités coopératives et Tint représente

l’ensemble des activités internes (Tcoop ∩ Tint = ∅).– un ensemble d’arcs A ⊆ ( P × T) ∪ (T × P)

L’ensemble de places d’entrée (respectivement sorties) d’une transition t est noté par •t (respec-tivement t• ). L’ensemble de transitions partageant une place p en sortie (respectivement entrée)est noté •p (respectivement p• ).

Définition 7 (Workflow Net) Un workflow W(P, T, A) est un WF-net [86] (Workflow net) si etseulement si :

1. W possède une seule place source i ∈ P (i.e. •i=∅) et une seule place finale o ∈ P (i.e.o• =∅), et

2. Chaque noeud x ∈ P ∪ T se trouve dans un chemin de i à o.


2.1.1.2 Les workflows vus par la WfMC

Si un procédé permet de décrire d’une manière informelle les méthodes de travail d’un groupede personnes et les règles qui les régissent, un workflow permet de formaliser, de structurer,d’automatiser (dans la mesure de possible) et d’exécuter ces méthodes de travail.

Un workflow est une représentation d’un procédé métier dans un format interprétable parla machine. Il est constitué d’un réseau d’activités et de dépendances entre elles, des critèrespour spécifier le démarrage et la terminaison d’un procédé et des informations sur les activitésindividuelles (participants, applications, données informatiques associées, etc.) [94]. Les activitéset les procédés ont des données en entrée et en sortie. Ces données sont représentées commedes ensembles d’éléments de données, appelés conteneurs. Dans ce qui suit, nous décrivonsplus en détail les différents composants du workflow selon le méta modèle proposé par WfMC5 [94].

Activité : une activité est une étape dans un procédé. Chaque activité a un nom, un type, des pré,des post conditions et des contraintes d’ordonnancement. Elles peuvent être des activitésprogramme ou des activités procédé. A chaque activité programme, un programme associésera exécuté lors de l’exécution de l’activité. Une activité est attribuée à des utilisateurs quisont capables de l’exécuter. Chaque utilisateur a une liste d’activités qui nécessitent d’êtreexécutées. A chaque activité est attribué un procédé. Ainsi tout procédé est exécuté quandl’activité est exécutée. Les activités procédés sont utilisées pour une conception modulaire.

Enfin, chaque activité a un conteneur des données en entrée et un conteneur de donnéesrésultats.

Flot de contrôle : un flot de contrôle définit l’ordre dans lequel les activités sont exécutées enspécifiant des connecteurs de contrôle entre les activités tels que les connecteurs de sé-quences (pour les activités s’exécutant séquentiellement) et les connecteurs de synchroni-sation (pour l’exécution parallèle des activités).

Données de procédé : A chaque modèle correspond un ensemble de données qui décriventtoutes les informations nécessaires pour son exécution. Ces données incluent (i) des in-formations requises en entrée des activités, (ii) des informations requises pour l’évaluationdes conditions et (iii) des données qui doivent être échangées entre les activités. Ainsi, nousdistinguons :– le conteneur d’entrée : ensemble de variables et structures typées qui sont utilisées

comme entrée.– le conteneur de sortie : ensemble de variables et structures typées dans lesquelles les

résultats de l’activité sont stockés.

Flot de données : un flot de données est spécifié via des connecteurs de données entre lesactivités mettant en œuvre une série de correspondance entre des conteneurs de donnéesen sortie et des conteneurs des données en entrée permettant l’échange d’information entreles activités.

Conditions : les conditions spécifient quand certains événements se produisent. Il y a trois typesde conditions. Les conditions de transitions sont associées aux connecteurs de contrôleet spécifient quand un connecteur est évalué à vrai ou à faux. Les conditions de démar-rage spécifient quand une activité va être démarrée : par exemple, quand tous ses connec-teurs de contrôle entrants seront évalués à vrai, ou quand un d’eux sera évalué à vrai. Les


conditions de sortie spécifient quand une activité est considérée terminée. Après l’exécu-tion d’une activité, sa condition de sortie est vérifiée. Si elle est vraie alors l’activité s’estproprement terminée, sinon l’activité est re-ordonnancée pour être exécutée.

2.1.1.3 Les workflows vus par l’OMG

L’OMG (Object Management Group) [60, 61, 62] est une organisation internationale supportéepar des centaines de membres

représentant des vendeurs de systèmes, des éditeurs de logiciels et des utilisateurs. Fondéeen 1989, l’OMG promouvoit la théorie et la pratique de la technologie orientée objet dans ledéveloppement de logiciel.

L’OMG a spécifié CORBA [63, 58, 59] (Common Object Request Broker Architecture), unearchitecture objet pour le développement et l’intégration d’applications distribuées garantissantla réutilisabilité, l’interopérabilité et la portabilité. CORBA est la réponse de l’OMG aux besoinsd’interopérabilité entre les composants logiciels et matériels qui ne cessent de se multiplier. Enparticulier, l’OMG présente un workflow comme un objet CORBA et considère l’interconnexiondes workflows comme une intégration d’objets CORBA.

Les spécifications CORBA du workflow sont basées sur les standards définis par la WfMC [94]et fournissent une base stable d’intégration de la technologie workflow à CORBA. CORBA fournit,entre autres, une terminologie commune dans le domaine des objets répartis, un modèle deréférence standard, des interfaces et des protocoles communs. En effet, l’architecture CORBAprésente les objets répartis selon quatre types :

1. les objets applicatifs sont des objets CORBA propres à l’application et non concernés parla standardisation de l’OMG ;

2. les services communs sont des objets indépendants de l’application : nommage, vendeur,transactions, événement, etc. ;

3. les interfaces de domaines sont des interfaces spécifiques à un domaine d’application (parexemple, la médecine, la finance, les télécommunications) ;

4. les utilitaires communs sont des services de plus haut niveau fournissant des fonctionnalitésutiles dans de nombreuses applications (par exemple, les interfaces utilisateurs, la gestionde données, l’administration des systèmes, etc.).

L’OMG traite la spécification du workflow comme un utilitaire CORBA de gestion des acti-vités [74, 73, 61, 62]. La spécification OMG de l’utilitaire de workflow définit les outils CORBAnécessaires au fonctionnement des gestionnaires de workflows en se basant directement sur lesinterfaces OMG-IDL [80] spécifiées par la WfMC pour son WAPI 3 de l’interface 2 [95] et soninterface 4 d’interopérabilité [96].

La section suivante présente les deux types d’approche de coopération des workflows.

2.1.2 Approche ascendante vs approche descendante

Le problème de la coopération dans le cadre des entreprises virtuelles peut être abordé àtravers une approche ascendante ou une approche descendante.

3. Workflow Application Programming Interface


L’approche descendante consiste à partir de la structure globale du workflow pour arriveraux détails. Il s’agit, en effet, de définir un workflow commun réunissant les différents participantset établir les règles régissant la coopération. Le workflow commun est divisé ensuite en plusieurssous workflows. Chaque participant se porte responsable de l’exécution d’un ou de plusieurssous workflows tout en respectant les règles formulées lors de la création du workflow commun.Les différents partenaires sont donc prédéfinis et connus à priori. En somme, dans une approchedescendante, l’étude du projet, la sélection des entreprises candidates, la spécification de leursinteractions et rôles mutuels sont déterminés dès la phase de conception. A l’exécution, chaqueentreprise dispose de toutes les informations nécessaires à sa coopération et ne fait que suivreles instructions déterminées lors de la phase de conception.

Ce type d’approche impose un ensemble de contraintes techniques pour sa mise en œuvre [9,103, 92]. Premièrement, le workflow commun qui réunit les différents partenaires est fixé dès ledébut de la coopération. Deuxièmement, ce type d’approche est caractérisé par le couplage fortdes workflows des différents partenaires ainsi que la prédéfinition des interactions entre eux.Par conséquent, l’approche descendante n’est pas flexible ni évolutive car tout changement estcoûteux. Enfin, étant fortement couplés, les partenaires sont amenés à adapter leurs workflowset leurs ressources en fonction de la coopération à laquelle ils participent et par conséquent ilsperdent leur autonomie et deviennent dépendants les uns des autres.

Ce type d’approche s’avère donc plus adapté aux cas des coopérations de longue durée.

L’approche ascendante consiste, quant à elle, à construire de façon incrémentale le workflowglobal à partir des workflows locaux déjà établis au sein des entreprises. Dans ce cas, aucunecontrainte n’est imposée aux entreprises participantes et chacune d’elles a la possibilité de joindreou quitter une coopération quand elle veut. La coopération dans une approche ascendante se faiten trois étapes. Premièrement, lorsqu’un participant souhaite coopérer, il cherche les partenairespotentiels pouvant satisfaire sa demande. Une fois, qu’il récupère la liste des partenaires candi-dats, il sélectionne le partenaire adéquat et un contrat précisant les responsabilités des différentsintervenants est établi. Enfin, la coopération entre les participants peut commencer.

En fonction des besoins des participants, l’approche ascendante permet d’interconnecter, àla demande, un ensemble de partenaires. Les relations entre les différents participants ne sontpas définies à priori et peuvent changer continuellement d’une coopération à l’autre suivant lesobjectifs du projet et de l’alliance à mettre en place. De plus, le nombre des partenaires ainsi quela structure de l’entreprise virtuelle n’est pas figée et peut par conséquent changer d’une coopé-ration à une autre suivant les intérêts et les besoins des partenaires. Ainsi, un même partenaire,peut jouer plusieurs rôles selon le partenariat auquel il participe. De ce fait, les approches as-cendantes sont plus flexibles puisque leurs structures sont évolutives et dépendent des besoinsdes partenaires et les relations entre les différents partenaires sont définies au moment de l’inter-connexion des entreprises. Il est également à noter que dans ce type d’approche, les partenairessont faiblement couplés et par conséquent sont plus autonomes puisque chacun est indépen-dant des autres et peut, entre deux exécutions d’une coopération, changer et/ou apporter desmodifications à sa structure interne sans changer son rôle dans la coopération. Étant faiblementcouplés, il est possible que des partenaires disparaissent juste après une coopération donnée àcause par exemple d’un éventuel dysfonctionnement ou bien de la faillite de l’entreprise. Ainsi, lesentreprises sont amenées à trouver des alternatives permettant de satisfaire leurs demandes.

D’après les caractéristiques de l’approche ascendante, nous estimons que celle-ci est plusadaptée pour une coopération de courte durée.


Après avoir expliqué les différents types d’approches pour la coopération, nous présentonsdans ce qui suit les principes qui guident le choix de l’approche appropriée à notre situation.

2.1.3 Principes à préserver par l’approche de la coopération choisie

Dans un contexte de globalisation, une pression liée à la concurrence caractérise la situationgénérale au sein des alliances interentreprises. Plusieurs entreprises disposent déjà de leurspropres infrastructures, workflows, systèmes de gestion de workflow préétablis ainsi que deslangages de spécification de workflows spécifiques. Ainsi, toute restructuration ou modificationde l’existant risque de violer l’objectif global du partenariat qui consiste à augmenter l’efficacitédes alliances et à réduire les coûts de la coopération. Un autre souci qui se présente est laprotection du savoir-faire des participants. Les entreprises souhaitent, en effet, coopérer sansdévoiler leurs savoir-faire. Afin de permettre aux entreprises de bénéficier des compétences desautres entreprises et par conséquent augmenter leur rendement avec des coûts moindres, nousavons identifié un ensemble de besoins de coopérations à satisfaire à savoir :

– Respect du savoir-faire : Par définition, la coopération signifie qu’un ensemble de par-tenaires ont la volonté de réunir leurs compétences et travailler ensemble pour atteindreun objectif commun. Or les partenaires d’une alliance se méfient toujours de leurs parte-naires dans le même secteur et veillent à protéger leurs procédés contre toute intrusion ouespionnage. En effet, si un partenaire arrive à déduire ou à acquérir le procédé d’un autrepartenaire, il lui est possible de déduire les points forts et les points faibles de son partenaireet peut donc effectuer des améliorations sur son propre procédé pour offrir de meilleurs ser-vices et gagner des marchés. Par conséquent, les entreprises n’acceptent pas de divulguerleur savoir-faire par mesure de sécurité et de protection de leur expérience et technique detravail. En somme, les entreprises doivent être capables de coopérer et travailler ensemblesans que chacune connaisse les détail des procédés métier des autres entreprises.

– Préservation des workflows préétablis : Les partenaires souhaitant coopérer ensembledisposent généralement de leurs propres workflows préétablis. Or, pour des raisons de co-ordination de leurs activités, ces partenaires peuvent être amenés à modifier une partieou la totalité de leurs workflows. Ce qui touche directement non seulement, à leur autono-mie, puisque le partenaire est obligé de changer la logique de son workflow en fonction del’alliance qu’il mène avec les autres entreprises, mais également au coût d’investissementde la coopération. Or, lors de la planification d’un projet, il est important de noter que toutchangement aussi petit qu’il soit, dans les workflows déjà établis est coûteux. Les chan-gements s’avèrent par conséquent non rentables surtout dans des alliances spontanées etdynamiques.

– Intégration des systèmes de gestion de workflows existants : Dans une entreprise vir-tuelle, chaque partenaire dispose de son propre système de gestion de workflow, outils detravail, matériels et infrastructures logicielles et de sa propre organisation interne. Ainsi, ilest nécessaire de fournir des mécanismes permettant de supporter l’hétérogénéité des sys-tèmes de gestion de workflows existants des différents partenaires constituant l’entreprisevirtuelle afin d’assurer la construction collective des compétences des entreprises à partirdes infrastructures déjà existantes.

Comme nous le montrons dans les chapitres suivants, ces différents besoins de coopérationne sont pas pris en compte par aucune des approches existantes. C’est donc guidés par ces exi-


gences que nous avons travaillé au développement d’une nouvelle approche qui puisse supporterde tels besoins de coopération.

2.2 Coopération dans le cadre de l’approche CoopFlow

Dans cette section nous nous intéressons tout d’abord à la coopération dans le cadre de l’ap-proche CoopFlow présentée dans la thèse de Issam CHEBBI [15]. Les travaux effectués dansnotre thèse sont une extension de CoopFlow. Cette dernière est une approche ascendante pourla coopération de workflows et elle comprend trois étapes : abstraction et publication des work-flows, appariement et interconnexion des workflows, et coopération et surveillance des workflows.CoopFlow a pour objectif de satisfaire les principes requis pour la coopération à savoir : le res-pect du savoir-faire de chaque partenaire, la tolérance à l’égard de la flexibilité, la préservation del’autonomie de chaque participant et des workflows préétablis, et l’intégration des systèmes degestion de workflow hétérogènes. Ensuite nous présentons les résultats obtenus dans ce cadre[15]. Enfin nous présentons dans la Section 2.2.2 les limites de l’approche CoopFlow.

2.2.1 Point de départ : L’approche CoopFlow

CoopFlow [15][16][17][18] est inspirée de l’architecture orientée services qui est basée surtrois opérations : la publication, la recherche et la connexion. Les fournisseurs de services publientles différents services qu’ils offrent. Les demandeurs de services cherchent les différents servicesrépondant à leurs besoins. Une fois que les services sont trouvés, les demandeurs s’y connectentafin d’exécuter un ensemble d’opérations offertes par les services. De même, notre approche estcomposée de trois étapes : (1) publication et abstraction de parties de workflows d’entreprisespouvant être exploitées par d’autres entreprises, (2) appariement et interconnexion de workflowset (3) coopération et surveillance de workflows conformément à un ensemble de politiques decoopérations (contraintes d’interactions).

2.2.1.1 Abstraction et publication de workflow

Dans la première étape de CoopFlow, les entreprises publient leurs workflows au sein d’unannuaire commun. Cette opération consiste à enregistrer l’ensemble des activités de workflowainsi que ses flots de contrôle et de données dans un annuaire. La question qui se pose ici est lasuivante. Faut-il enregistrer toute la structure interne du workflow de l’entreprise qui dans ce cassera visible par tous les participants ? Ou bien faut-il cacher toute la structure et adopter la notionde boîte noire dans laquelle la communication entre les partenaires est de type requête/réponse ?Les deux solutions sont inadéquates vis-à-vis de la coopération. En effet, la première solution neprotège pas le savoir-faire des entreprises qui cherchent toujours à préserver leurs compétenceset leurs structures internes. La seconde solution est fermée et n’est pas adaptée au contexte decoopération interentreprises où on a besoin d’un certain degré de visibilité pour coopérer avec lesautres partenaires. Ainsi, il faut trouver un compromis qui permette à ces entreprises de coopérersans pour autant dévoiler les structures internes de leurs workflows.

Afin de remplir ces objectifs, CoopFlow propose la notion d’abstraction de workflows. Le prin-cipe de cette solution est de n’exposer à l’extérieur que la partie du workflow nécessaire à lacoopération et de cacher toutes les structures et les informations internes qui ne jouent aucun

2.2 Coopération dans le cadre de l’approche CoopFlow 13

rôle direct dans la coopération. En d’autres termes, CoopFlow cherche à réduire la visibilité desworkflows au strict nécessaire.

La méthode proposée consiste à abstraire structurellement les workflows et ainsi elle permetà une entreprise d’exposer plusieurs vues du même workflow suivant les besoins sollicités. Cetteabstraction se fait selon une procédure qui consiste à appliquer un certain nombre de règlessur le workflow interne. A l’issue de cette procédure, le workflow coopératif est généré [15]. Plu-sieurs règles d’abstraction ont été définies dans CoopFlow. Nous en citons le principe ici et nousillustrons leurs utilisation à travers un exemple.

Le but étant d’éliminer les activités internes d’un workflow, nous pouvons classifier les règlesen trois catégories suivant l’emplacement des activités internes dans le workflow. La premièrecatégorie traite les cas où le workflow interne contient une activité interne A1 suivie (resp. précé-dée) par une autre activité interne ou coopérative. Dans ce cas, CoopFlow élimine l’activité A1 duworkflow ainsi que la place la reliant à l’activité qui la suit (resp. précède). Pour illustrer cette caté-gorie de règles, prenons comme exemple le workflow interne de l’assuré présenté dans la figure2.1-(a). Ce workflow contient l’activité interne Etablir Dev précédée par l’activité coopérative Acc.L’application de la règle d’abstraction, résulte en l’élimination de l’activité Etablir Dev ainsi que laplace P3 (voir figure 2.1-(b))

La deuxième catégorie de règles concerne le cas où le workflow contient des activités alter-natives dont certaines sont internes. Dans ce cas, toutes les activités internes alternatives sontéliminées sauf une seule qui sera laissée pour maintenir la sémantique comportementale duworkflow.

La troisième et dernière catégorie de règles d’abstraction définies par CoopFlow s’intéresseau workflow contenant des itérations. Lorsque le workflow contient une itération formée d’uneseule activité interne, celle-ci est supprimée.

Les abstractions de workflows sont faites pour qu’elles soient publiées dans un annuaire com-mun. Ainsi, elles sont accessibles par les partenaires souhaitant former des alliances straté-giques. CoopFlow propose un mécanisme d’appariement grâce auquel, les workflows peuventêtre découverts.

2.2.1.2 Appariement et interconnexion de workflows

Lorsqu’une entreprise souhaite coopérer avec d’autres entreprises, elle commence par iden-tifier les partenaires avec des compétences complémentaires. Cette identification se fait en com-parant la complémentarité (i.e. matching) de l’abstraction de workflow de l’entreprise en questionavec les abstractions des workflows des partenaires. Le résultat de cette étape est un ensemblede politiques de coopération décrivant les responsabilités et les rôles joués par chacun des par-tenaires dans la coopération ainsi que la coordination de leurs workflows.

La construction de l’entreprise virtuelle se réalise grâce à une procédure de correspondancedes interfaces coopératives qui tient compte des flots de contrôle et de données.

Afin de permettre l’identification des partenaires, CoopFlow propose un algorithme d’appa-riement basé sur les graphes de marquage et permettant de vérifier si deux workflows corres-pondent. Tout d’abord, étant donné deux workflows coopératifs le principe est le suivant. Coop-Flow commence par construire le graphe de marquage pour chaque workflow coopératif. Ensuite,


FIGURE 2.1 – Abstraction d’activités internes séquentielles

l’algorithme d’appariement est appliqué aux deux graphes de marquages générés. Enfin, si lesdeux graphes coïncident, ils sont alors interconnectés.

En effet, l’appariement effectué compare les comportements des workflows. Ceux-ci sont mo-délisés dans CoopFlow par la notion de langage. Ce dernier est obtenu à partir du graphe demarquage et il représente toutes les séquences acceptées d’un workflow. Une séquence est unesuccession d’un ensemble d’activités coopératives et elle est dite acceptée si la place i (resp.o) est incluse dans l’ensemble de places d’entrées (resp. sortie). A titre d’exemple, le langagedu workflow de l’assuré présenté dans la figure 2.1-(a) est : {Decl.Acc.Dev.Av.Eval.Fact.Payer,Decl.Acc.Dev.Av.Fact.Payer}

Étant donné un workflow W1 et un annuaire contenant des workflows, CoopFlow établitun ensemble de critères permettant de choisir un workflow W2 de l’annuaire qui sera le par-tenaire de W1. Chaque activité coopérative t d’un workflow W est représentée par un tuplet = 〈name, type,msg〉 telle que (1) l’attribut name de t représente l’étiquette associée à t, (2)l’attribut type est une variable booléenne indiquant si t reçoit (t.type = 1) ou envoi des messages(t.type = 0), et (3) l’attribut msg représente le type de données du message consommé/produitpar la transition.

Afin de vérifier la correspondance entre deux activités t1 et t2, il suffit de comparer les deuxattributs type et msg. S’ils ont le même message (t1.msg ≡ t2.msg) et si leurs types sont différents

2.2 Coopération dans le cadre de l’approche CoopFlow 15

(t1.type = ¬(t2.type)), on dit alors que t1 correspond à t2. Si deux activités correspondent, ellessont renommées avec le même nom.

D’une part, CoopFlow compare les activités de deux workflows deux à deux. D’autre part, ellecompare les comportements des deux workflows. Pour ce faire, CoopFlow compare les langagesdes deux workflows et si l’intersection de ceux-ci n’est pas vide, alors les deux workflows peuventêtre interconnectés.

Dès lors que l’appariement est fait, les workflows sont interconnectés et le résultat de cettephase est un ensemble de politiques de coopération précisant les responsabilités de chacun desworkflows participants. Une fois les workflows sont interconnectés, la coopération commence etelle doit être contrôlée.

2.2.1.3 Coopération et surveillance de workflows

La troisième et dernière étape de l’approche CoopFlow pour la coopération consiste à déployeret à exécuter le workflow interentreprises. Afin de réaliser cet objectif, CoopFlow [17] proposeune plate-forme pour la coopération des workflows s’exécutant sur des systèmes de gestion deworkflows capables d’invoquer des applications externes (programmes, services Web, etc.) etpouvant être invoqués de l’extérieur. Cette condition est nécessaire pour permettre l’échange dedonnées d’une part et l’invocation d’applications dont l’exécution est déléguée à un partenaireexterne d’autre part.

En outre, CoopFlow propose deux architectures : une architecture centralisée pour intercon-necter et faire coopérer des partenaires qui n’ont pas suffisamment de confiance l’un en l’autre etune architecture distribuée pour la coopération de partenaires ayant un certain degré de confianceréciproque.

Dans la carde de l’approche CoopFlow, un prototype permettant la coopération de workflowss’exécutant sur des systèmes de gestion de workflow hétérogènes a été développé. Ce prototypea été testé et validé sur trois systèmes de gestion de workflow : Xflow[102], Osworkflow[64] etShark[77].

Dans ce qui suit nous discutons les limites de l’approche CoopFlow et les améliorations quipeuvent être apportées.

2.2.2 Limites de CoopFlow

Dans cette section, nous nous intéressons aux limites de l’approche CoopFlow. Tout d’abord,la procédure d’abstraction de CoopFlow que nous avons décrit dans la section 2.2.1 est entière-ment informelle. En effet, lorsqu’on applique les règles données sur un workflow interne, rien nenous garantit que le workflow coopératif obtenu a le même langage que le workflow interne. Cettepropriété (la préservation du langage) est importante pour l’interconnexion des workflows.

D’autre part, pour établir la correspondance entre deux workflows, CoopFlow compare le type(réceptrice ou émettrice) des activités et du message que l’activité reçoit ou envoie. La com-paraison des types des messages est une comparaison syntaxique. De ce fait, deux activitésmanipulant deux messages du même type mais avec des noms différents seront considéréespar CoopFlow comme non correspondantes (l’une ne correspond pas (ne match pas) à l’autre).De plus, deux activités manipulant les même messages seront systématiquement considérées


comme correspondantes tandis qu’elles peuvent ne pas l’être. Ce problème vient du fait que lasémantique n’a pas été introduite dans CoopFlow.

Étant donné que l’un des objectifs de CoopFolw consiste à pouvoir publier des workflowsdans un annuaire pour qu’ils puissent être découverts ultérieurement, il est nécessaire que celle-ci développe les aspects relatifs aux stockage des workflows.

Toutes ces limites constituent le point de départ de ce travail et dans ce qui suit nous présen-tons nos objectifs dans le cadre de notre thèse.

2.3 Objectif de la thèse

Partant des travaux réalisés dans CoopFlow en ce qui concerne les trois étapes (l’abstractionet la publication, l’appariement et l’interconnexion, et la coopération et la surveillance), l’objectif decette thèse est triple. Le premier objectif est de fournir une méthode d’abstraction formelle pourles workflows. Celle-ci doit garantir la préservation du langage du workflow. Le second objectifconsiste à décrire les workflows sémantiquement. Une telle description permet, entre autres, lepartage des données et facilite l’appariement. Le troisième et dernier objectif concerne l’amé-lioration de la qualité de l’appariement et la proposition d’une structure pour le stockage desworkflows.

Dans ce qui suit nous présentons tous les objectifs réalisés dans notre thèse.– Formalisation de l’abstraction des workflows : L’abstraction, en général, est une trans-

formation permettant la simplification d’un système. Dans la cadre des workflows, il s’agitde la suppression d’un ensemble d’activités dont la présence dans le workflow n’est pas im-portante pour la coopération avec les partenaires. Néanmoins, il est nécessaire de prouverd’une manière formelle que la suppression de ces activités préserve le langage du workflow.Étant donné que les workflows sont modélisés sous forme de réseaux de Pétri, l’un de nosobjectifs dans cette thèse est d’explorer les techniques formelles de réduction des réseauxde Pétri pour les appliquer aux workflows.

– Description sémantique des workflows : Face à la concurrence et dans le but d’améliorerleur productivité, les entreprises expriment un grand besoin d’ouverture et de coopération àl’échelle mondiale. Afin de faciliter cette coopération, il est nécessaire de trouver un moyenpuissant pour décrire les workflows. Une telle description doit être d’une part, non ambi-guë et interprétable par des programmes afin de permettre le partage des données entreles partenaires. En effet, une donnée décrite avec cette description doit avoir la même si-gnification pour tous les partenaires. D’autre part, la description doit faciliter la rechercheet le contrôle automatique des workflows. L’un de nos objectifs consiste à proposer deuxsolutions répondant à ces exigences et montrer les cas ou l’une ou l’autre solution est plusappropriée.

– Appariement et stockage des workflows : Le dernier objectif de notre thèse concernel’appariement et le stockage des workflows.Après avoir abstrait et décrit les workflows, il convient de les stocker. Notre objectif dans cecadre consiste à trouver des structures de données qui sont efficaces en termes d’espacesans que cette efficacité soit au détriment de la recherche.Une fois que les workflows sont stockés, nous souhaitons développer des algorithmes d’ap-pariement en vue de faciliter la découverte des workflows. Deux types d’appariement sont

2.4 Exemple support 17

nécessaires pour garantir une bonne qualité de l’appariement à savoir : l’appariement de lasémantique métier et de la sémantique comportementale des workflows.

Dans ce qui suit, nous présentons l’exemple support que nous utilisons tout au long de cettethèse.

2.4 Exemple support

Pour illustrer notre approche nous considérons un exemple impliquant deux partenaires : unesociété d’assurance et un client de celle-ci (un assuré). L’exemple est basé sur le formalismedes réseaux de Pétri [85, 8, 25, 27, 91, 54]. La représentation graphique des réseaux de Pétriet leur sémantique bien définie permettent d’exprimer les concepts de workflows d’une manièrecompacte et non ambigüe. L’exemple est inspiré de celui fourni dans [4].

La figure 2.2-(a) présente la définition du workflow de l’assuré. Celui-ci, commence par en-voyer une déclaration d’accident (activité DECL). Ensuite, il reçoit un courrier accusant réceptionde sa déclaration (activité ACC). Puis l’assuré consulte un garagiste afin d’établir un devis (acti-vité ETABLIR DEV) et envoie ce dernier à la société d’assurance (activité DEV). L’assuré attendensuite l’avis de la compagnie d’assurance pour qu’il puisse commencer la réparation (activitéAV). Dès que l’avis est parvenu à l’assuré et s’il est favorable, celui-ci répare sa voiture chez legaragiste (activité REP). Une fois que les réparations sont faites, l’assuré fait parvenir la facturedu garagiste à la compagnie (activité FACT). Enfin, l’assuré reçoit le remboursement de la part dela compagnie (activité PAYER). Dans le cas où la compagnie a donné un avis négatif sur le devis,l’assuré est tenu d’attendre une évaluation des dégâts de la part de la compagnie. Une fois qu’ilreçoit cette évaluation (activité EVAL), il peut engager les réparations (activité REP) si le montantde celles-ci ne dépasse pas celui indiqué dans l’évaluation. L’assuré envoie par la suite la facturedu garagiste (activité FACT) et recevra le paiement (activité PAYER).

Dans la figure 2.2-(b) nous donnons le workflow d’une compagnie d’assurance. Cette dernièreattend une déclaration d’accident provenant d’un assuré (activité DECLARATION). Dès réceptiond’une déclaration, la compagnie crée un dossier pour l’assuré et numérise la déclaration d’acci-dent (activité DOSSIER) et en parallèle, elle envoie automatiquement un courrier accusant récep-tion de la déclaration (activité ACCUSE). Après avoir créé un dossier pour l’accident, la compa-gnie vérifie l’état des cotisations de l’assuré (activité COTISATION). Suivant le type d’assurancesouscrite (activité TYPE ASSURANCE), deux cas se présentent : le client a droit à une voiturede remplacement ou pas. Dans le premier cas, la compagnie loue une voiture de remplacement(activité LOUER VOITURE) et envoie celle-ci à l’assuré (activité VOITURE REMPLACEMENT).Ensuite et quelque soit le type d’assurance souscrit, la compagnie attend la réception d’un devisde la part de l’assuré (activité DEVIS). Suite à la réception d’un devis, la compagnie notifie l’as-suré de son accord ou désaccord pour éventuellement entamer les réparations (activité AVIS). Sil’avis est positif, la compagnie attend ensuite la facture (activité FACTURE) elle effectue le rem-boursement dès réception de celle-ci (activité PAIEMENT). Si par contre l’avis de la compagnieest négatif, celle-ci fait appel à un expert afin d’évaluer les dégâts du véhicule (activité EXPERT).Cette évaluation est envoyée par la suite à l’assuré (activité EVALUATION) et elle a pour but delui préciser le montant maximum que la compagnie est prête à rembourser pour cette réparation.Dès réparation, l’assuré fait parvenir la facture du garagiste à la compagnie (activité FACTURE).Ensuite, la compagnie effectue le remboursement en émettant un chèque à l’assuré (activitéPAIEMENT). Enfin, la compagnie met à jour sa base de données (ARCHIVAGE) en archivant lesinformations concernant l’assuré et l’accident.


i

DECL

ACC

ETABLIR DEV

DEV

ACCUSECOTISATION

i

DECLARATION

o

LOUER VOITURE

TYPE ASSURANCE

VOITUREREMPLACEMENT

DEVIS

AVIS

ARCHIVAGE

Assurré Compagnie d’assurance

AV

PAYER

FACT

REP

PAIER

FACT

REP

EVAL

DOSSIER

EXPERT

EVALUATION

PAIEMENT

FACTURE

FACTURE

PAIEMENT

(a) (b)

FIGURE 2.2 – Les workflows d’un assuré et d’une société d’assurance

Nous signalons que les transitions remplies dans la figure 2.2 représentent les activités co-opératives (qui envoient ou reçoivent des données des partenaires). Les autres activités sontinternes à l’entreprise et concernent son savoir-faire, elles ne sont pas censées être visibles desautres partenaires.

2.5 Synthèse 19

2.5 Synthèse

Nous avons donc choisi d’aborder le problème de la coopération des workflows dans lecontexte des entreprises virtuelles du point de vue d’une approche ascendante. La coopéra-tion via une approche ascendante a l’avantage de permettre la construction du workflow globald’une manière incrémentale, c’est-à-dire à partir des workflows locaux déjà établis au sein desentreprises impliquées dans la coopération. Cependant, ce type d’approche nécessite de décrireles workflows, de les publier, de les découvrir et enfin de supporter leur intégration. Pour publierles workflows, il convient de trouver des structures de données efficaces pour leur stockage. Afinde les découvrir, il faut développer des algorithmes d’appariement.

En outre, l’approche ascendante satisfait les principes requis pour la coopération tels que lerespect du savoir-faire de chaque partenaire, la tolérance à l’égard de la flexibilité, la préservationde l’autonomie de chaque participant et des workflows préétablis, et l’intégration des systèmesde gestion de workflow hétérogènes.

Toutefois, les approches de coopération des workflows existantes sont toutes descendantes.Il nous faut donc développer une approche ascendante. De ce point de vue, les travaux présen-tés dans cette thèse sont basés sur l’approche CoopFlow définie dans dans la thèse de IssamCHEBBI [15]. CoopFlow est composée de trois étapes à savoir : l’abstraction et la publication desworkflows, l’appariement et l’interconnexion des workflows, et la coopération et la surveillancedes workflows.

En ce qui concerne la description, le stockage et l’appariement il ne s’agit toutefois que d’unepremière étape. En effet, CoopFlow s’est focalisée sur l’aspect interconnexion afin de permettrel’intégration des systèmes de gestion des workflows hétérogènes et a abordé également l’abs-traction.

La réalisation des objectifs de cette thèse (section 2.3) a permis la définition et la mise en placed’un annuaire de workflows muni d’un service de courtage. Cet annuaire permet de prendre encompte les aspects liés à :

– la préservation du savoir-faire de chaque partenaire : Cet objectif a été réalisé grâce àla proposition de deux méthodes d’abstraction des workflows. Celles-ci sont formelles etgarantissent la préservation du lange du workflow.

– la découverte automatique des workflows : Afin de rendre la découverte automatique desworkflows possible, nous avons développé deux algorithmes d’appariement de workflows.Le premier est dédié à la comparaison de la sémantique métier des workflows et il se basesur une description sémantique que nous avons proposée. Le second algorithme comparela sémantique comportementale des workflows.

– le stockage des workflows : le dernier aspect pris en compte par notre annuaire concerne lestockage des workflows. Dans ce cadre, nous utilisons des structures de données efficacesen termes d’espace.

Notre annuaire permet donc de stocker efficacement les workflows. Il est muni d’un service decourtage offrant un algorithme polynomial (O(n2)) pour la comparaison de la sémantique compor-tementale des workflows. Notre algorithme se base en effet sur la trace des workflows. Commenous le verrons dans les chapitres suivants, d’autres algorithmes basés sur la bissimulation ou surl’équivalence par simulation offrent une qualité d’appariement meilleur que celle fournie par notrealgorithme. Cependant, tous ces algorithmes sont exponentiels. Ils peuvent être utilisés quandil s’agit de comparer deux workflows. Par contre, lorsqu’on envisage de comparer un workflowavec un nombre important de workflows, ces algorithmes deviennent inadaptés. Notre annuaire


a donc le mérite de pouvoir stocker et rechercher efficacement les workflows. Il a, en revanche,l’inconvénient suivant. Étant donné un workflow W1 pour lequel nous cherchons un partenaire,le service de courtage nous retourne le workflow W2 comme étant compatible à W2. Il n’est pasgaranti que tous les comportements de W2 sont compatibles avec tous les comportements deW1. Toutefois, le service de courtage garantit qu’il y a au moins un comportement de W1 compa-tible avec un comportement de W2. En vu d’améliorer la qualité d’appariement de notre servicede courtage, nous envisageons d’y inclure une comparaison basée sur la bissimulation. Nous uti-lisons tout d’abord notre algorithme polynomial pour sélectionner une liste réduite de workflowspouvant coopérer avec W1. Ensuite, nous appliquons l’algorithme basé sur la bissimulation surcette liste réduite.

Enfin, la fusion de notre annuaire et de CoopFlow offrira aux entreprises une plateforme com-plète pour la description sémantique et la découverte des workflows ainsi que l’intégration dessystèmes de gestion de workflows hétérogènes.

Chapitre 3

Langages de description deworkflows et de services Web

Sommaire3.1 Description syntaxique de work�ows . . . . . . . . . . . . . . . . . . . 21

3.1.1 BPEL4WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.2 YAWL (Yet Another Work�ow Language) . . . . . . . . . . . . . . . . . 223.1.3 XPDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Description sémantique de services Web . . . . . . . . . . . . . . . . 253.2.1 OWL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 SAWSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.3 WSMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Ce chapitre est consacré aux langages de description des workflows et des services Web.Ceux-ci sont divisés en deux catégories : langages de description sémantique et langages dedescription syntaxique. La section 3.1 présente les langages de description syntaxique des work-flows. Les langages de description sémantique des services Web sont présentés dans la section3.2.

3.1 Description syntaxique de workflows

3.1.1 BPEL4WS

BPEL4WS (Business Process Execution Language for Web Services) [81] est un langage demodélisation de workflows basé sur XML. Il permet de définir les interactions intra et interentre-prises et de composer un ensemble de services Web, synchrones ou non, au sein d’un flot deworkflow. Il est le résultat de la fusion et l’extension des fonctionnalités de WSFL [46] d’IBM etXLANG [82] de Microsoft et reprend les riches structures de contrôle de WSFL telles que les sé-quences, les flots parallèles, les boucles et l’instantiation-corrélation et compensation de XLANG.

BPEL4WS permet de gérer deux types de procédés. Le procédé abstrait est une sorte d’abs-traction du comportement des différentes parties. En effet, ce procédé permet de spécifier lesmessages échangés entre les différents intervenants sans dévoiler leurs comportements internes.

21

22 Langages de description de workflows et de services Web

Le second type de procédé est le procédé exécutable qui décrit le workflow proprement dit. Eneffet, il spécifie les différents activités, leur ordre d’exécution, les différents partenaires mis en jeuainsi que la gestion des exceptions et des compensations lorsque des erreurs surviennent.

Un procédé BPEL4WS est formé d’un ensemble de partenaires, d’activités, de transitions etde gestion d’exception de compensation.

Les partenaires de BPEL4WS peuvent être statiques et dans ce cas ils sont connus à priori etle comportement est fixé dès le début, ou bien dynamique et dans ce cas ils ne sont connus qu’àl’exécution.

On distingue deux types d’activités : les activités primitives qui sont des activités simples tellesque receive qui permet de bloquer le système dans l’attente d’un message, reply qui permet àun workflow d’envoyer un message comme réponse à un message reçu par receive et l’activitéassign qui permet la mise à jour de valeurs des variables avec des nouvelles données. Les activi-tés structurées sont des activités complexes mettant en jeu une combinaison d’activités simples.Nous donnons l’exemple de sequence qui permet de définir une collection d’activité à exécuterséquentiellement et switch qui permet de sélectionner exactement une branche d’activité parmiun ensemble de choix.

Il offre également la possibilité d’étendre le langage avec des structures additionnelles à partird’un espace de nom basé sur XML et ce en permettant l’apparition d’attributs qualifiés au seinde n’importe quel élement de BPEL4WS à condition que ces extensions ne changent pas lasémantique des éléments ou attributs provenant des espaces de noms BPEL4WS.

Dans la figure 3.1, nous donnons un exemple de spécification de workflow de services avecBPEL4WS. Nous distinguons quatre parties. La première partie (lignes 1 à 4) permet de spécifierles espaces de noms utilisés par le procédé lors de l’exécution. La seconde partie (lignes 6 à 9)permet de déclarer les structures de données qui vont enregistrer les messages associés à uneinstance de workflow donné. La troisième partie (lignes 11 à 13) permet de définir les rôles jouéspar les partenaires actuels. Enfin, la quatrième partie (lignes 15 à 21S) spécifie la logique duworkflow. Dans notre exemple, il s’agit d’un workflow formé de deux activités. La première permetd’appeler un service pour lui passer un devis de réparation via l’activité invoke et la seconde reçoitun avis concernant le devis. Cette réception est effectuée via l’activité receive.

3.1.2 YAWL (Yet Another Workflow Language)

YAWL (Yet Another Workflow Language) 1 [90] est un langage de workflow basé sur les pa-trons de workflows 2 [88] et supporté par un système se composant d’un moteur d’exécution etd’un éditeur graphique. Initialement, ce langage est développé par des chercheurs des universitéde technologie Eindhoven et de Queensland. Ensuite, plusieurs organisations telles que Inter-Continental Hotels Group, first telecom 3 et ATOS Worldline 4 se sont joints à cette initiative. Lesystème YAWL est maintenant disponible comme un logiciel libre sous la licence LGPL.

Les principes directeurs initiaux de YAWL consistent à définir un langage de workflow suppor-tant la totalité (ou la plupart) des patrons de workflow et possédant une sémantique formelle. Lesconcepteurs de YAWL ont choisi de considérer les réseaux de Pétri comme un point de départ

1. http ://yawlfoundation.org/2. http ://is.tm.tue.nl/research/patterns/3. http ://www.firsttelecom.com4. http ://www.atosworldline.com

3.1 Description syntaxique de workflows 23

1 <process name="assure"2 targetNamespace="urn:bpel:assureService"3 xmlns:tns="urn:bpel:assureService"4 xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">56 <variables>7 <variable name="devisOut" messageType="tns:devisSoapResponse"/>8 <variable name="avisIn" messageType="tns:avisSoapRequest"/>9 </variables>1011 <partnerLinks>12 <partnerLink name="assurePT" partnerRole="service" partnerLinkType="tns:assureLT"/>13 </partnerLinks>1415 <sequence>16 <invoke partnerLink="assurePT" portType="tns:assureBPELPT"17 operation="devis" outputVariable="devisOut">18 </invoke>19 <receive partnerLink="assurePT" portType="tns:assureBPELPT"20 operation="avis" variable="avisIn">21 </receive>22 </sequence>23 </process>

FIGURE 3.1 – Exemple de spécification de workflows de services en BPEL

et ont étendu ce formalisme avec trois structures principales : or-join, annulation et les activi-tés multi-instances. Ces trois concepts permettent de supporter cinq des patrons de workflowsqui ne sont pas directement supportés par les réseaux de Pétri ordinaires, à savoir, la fusionsynchronisée, le discriminateur, la fusion N-parmi-M, les instances multiples sans connaissanced’exécution à priori et l’annulation de cas.

YAWL augmente les réseaux de Pétri avec quelques éléments syntaxiques afin de capturerd’autres patrons de workflows tels que le choix simple (xor-split), la fusion simple (xor-join) et leschoix multiples (or-split). Durant la conception du langage, il s’est avéré que quelques unes desextensions ajoutées aux réseaux de Pétri sont difficiles voire impossibles à re-coder en réseauxde Pétri. Par conséquent, la sémantique formelle originale de YAWL est définie sous forme desystème de transitions étiqueté et non pas en terme de réseaux de Pétri.

YAWL est parfois vu comme une alternative à BPEL. Un avantage majeur de BPEL est le faitqu’il soit dirigé par un comité de standardisation supporté par plusieurs partenaires académiqueset industriels. Par conséquent, BPEL est supporté par un nombre important d’outils (propriétaireset libres) alors qu’actuellement YAWL dispose d’une seule implémentation.

3.1.3 XPDL

XPDL [99] est un langage de définition de procédés proposé par le WfMC et basé sur le lan-gage XML comme support afin d’échanger des définitions de procédé entre différents produits deworkflows. Le but de XPDL consiste à fournir un langage permettant l’importation et l’exportationde définitions de procédés entre une variété d’outils tels que les systèmes de gestion de workflowet les outils de modélisation et simulation.

La définition de workflow fournit un ensemble d’informations associées à son administrationtelles que la date, le nom de l’auteur, la version, . . . et pouvant être utilisées lors de l’exécution deprocédé telles que l’initiation des paramètres, la priorité, la vérification des limites de temps et lesinformations de simulation.


Une définition de workflow consiste en une ou plusieurs activités contenant chacune une unitéde travail au sein du workflow. Ces activités représentent les constructions basiques d’une défi-nition de workflow et sont connectées par des éléments de type Transition avec éventuellementdes conditions associées à ces transitions.

XPDL offre aussi la notion de Participant permettant de spécifier les entités chargées d’exé-cuter le travail. Celui-ci, peut avoir l’une des formes suivantes : une ressource ou un ensemble deressources, un rôle, un humain, un système ou enfin une organisation.

XPDL spécifie l’ensemble des applications et des outils invoqués par les workflows afin desupporter ou automatiser l’exécution associée à chaque activité au sein de workflows. Cesappli-cations peuvent être des outils génériques ou spécifiques à un département ou des procédureslocales implémentées dans le cadre du système de gestion de workflow.

XPDL offre également la notion de paquetage permettant de regrouper les entités communesde plusieurs définitions de workflows différents afin d’éviter la redéfinition de workflows.

Enfin, bien que XPDL contienne plusieurs structures pour la définition de workflows, des ven-deurs et utilisateurs peuvent avoir besoin d’inclure des informations additionnelles. Pour ce faire,XPDL offre la possibilité d’extension grâce à la notion d’attributs étendus qui seront définis parl’utilisateur ou le vendeur afin d’exprimer des caractéristiques supplémentaires des entités.

XPDL représente un standard supportant tous les éléments pour la définition de workflowstels que les flots de contrôle, les flots de données, la gestion de ressources et des applications.Cependant, il souffre d’un ensemble d’insuffisances vis-à-vis de la coopération interentreprises.

En effet, le langage ne propose pas les notions d’espace de stockage de données pu-blique/privé ni de partenaires.

De plus, XPDL ne permet pas la décomposition d’un flux de données en plusieurs parties oude faire la correspondance de deux flux provenant de deux contextes différents.

En ce qui concerne la notion des participants, elle est limitée. Un participant peut en effetêtre soit une ressource ou un ensemble de ressources, une organisation, un rôle, un humain ousystème. La notion de partenaires et de services est absente.

La figure 3.2 montre la description en XPDL de l’activité devis. Nous commençons tout d’abordpar définir le type DevisInfo décrivant la structure d’un devis (3.2, lignes 1 à 4). Ensuite, nous dé-finissons le paramètre formel devisOut de type DevisInfo (3.2, lignes 9 à 15). Ce paramètre estutilisé par l’activité. Ensuite, nous définissons l’application envoyerDevis utilisée pour implémen-ter l’activité (3.2, lignes 17 à 25). Enfin, la description de l’activité Devis est donnée. Devis estimplémentée par l’application envoyerDevis (3.2, ligne 29) et le paramètre effectif passé à cetteapplication est devisOut (3.2, lignes 30 à 32). Enfin, les lignes 35 à 41 spécifient que l’activité sui-vant l’activité Devis dans le workflow de l’assuré est l’activité Avis et que la transition reliant cesdeux activités est la transition dont l’identifiant est 4->5.

D’autres langages pour la description de workflows existe tel que WS-CDL. WS-CDL (WebService Choreography Description Language) [38] 5 est un langage de description de chorégra-phie définit par le W3C 6 (World Wide Web Consortium). Il définit une chorégraphie comme uncontrat multi-partenaires qui décrit, d’un point de vue global, le comportement commun obser-vable des services participants à une collaboration.

5. http ://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/6. http ://www.w3.org/

3.2 Description sémantique de services Web 25

1 <TypeDeclarations>2 <TypeDeclaration Id="DevisInfo" Name="DevisInfo">3 <ExternalReference location="http://www-inf/samples/xpdl/assure.xsd"/>4 </TypeDeclaration>56 <WorkflowProcesses>7 <WorkflowProcess AccessLevel="PUBLIC" Id="1" Name="AssuréProcess">8 <ProcessHeader/>9 <FormalParameters>10 <FormalParameter Id="devisOut" Index="1" Mode="OUT">11 <DataType>12 <DeclaredType Type="DevisInfo"/>13 </DataType>14 </FormalParameter>15 </FormalParameters>1617 <Application Id="envoyerDevis">18 <FormalParameters>19 <FormalParameter Id="devisMsg" Index="1" Mode="OUT">20 <DataType>21 <DeclaredType Id="DevisInfo"/>22 </DataType>23 </FormalParameter>24 </FormalParameters>25 </Application>2627 <Activity Id="4" Name="Devis">28 <Implementation>29 <Tool Id="envoyerDevis" Type="APPLICATION">30 <ActualParameters>31 <ActualParameter>devisOut</ActualParameter>32 </ActualParameters>33 </Tool>34 </Implementation>35 <TransitionRestrictions>36 <TransitionRestriction>37 <TransitionRefs>38 <TransitionRef Id="4->5"/>39 </TransitionRefs>40 </TransitionRestriction>41 </TransitionRestrictions>42 </Activity>43 <Activity Id="5" Name="Avis">44 </Activity>45 </WorkflowProcess>46 </WorkflowProcesses>

FIGURE 3.2 – description XPDL du l’activité devis

Comme c’est le cas pour BPEL4WS, YAWL et XPDL, WS-CDL ne supporte pas la descriptionsémantique de flots de données et de flots de contrôle.

Dans la section suivante, nous présentons des langages supportant la sémantique. Il s’agitdes langages de description sémantique des services Web.

3.2 Description sémantique de services Web

Le Web est en train de subir deux grandes évolutions à savoir les services Web et le Websémantique. D’une part, l’évolution récente des technologies de l’Internet, guidée par le langageXML et ses technologies sous-jacentes, étend le rôle du Web d’un simple support d’informa-tion vers un intergiciel d’applications B2B. Cette nouvelle vague de l’Internet est guidée par leconcept de services Web. Les services Web sont des applications auto-descriptives, modulaireset faiblement couplées qui fournissent un modèle simple de programmation et de déploiementd’applications, basé sur des normes, et s’exécutant au travers de l’infrastructure Web [37]. Les


services Web fournissent ainsi des langages et protocoles standards permettant l’interopérabilitéentre différentes applications logicielles, fonctionnant sur une variété de plateformes et indépen-dant des systèmes d’exploitations. Ces standards facilitent le transport, l’invocation, la descrip-tion et la recherche. Le protocole SOAP transporte les messages XML entre les services Webet permet également d’invoquer des services Web. Le langage WSDL [20] offre la possibilité dedécrire l’interface d’un service Web. Cette description est basée sur XML et elle est purementsyntaxique. Le standard UDDI [83] décrit l’annuaire dans lequel les services Web sont réperto-riés d’une manière homogène. La recherche et la découverte automatique des services devraientêtre supportées par ce protocole. Néanmoins, le manque de sémantique dans WSDL empêchela découverte automatique et par conséquent l’invocation et la composition automatiques.

Le Web sémantique, quant à lui, est une extension du Web actuel, dans lequel les informa-tions ont un sens bien défini afin de permettre aux ordinateurs et aux utilisateurs de travailler encoopération [11]. Le Web sémantique donne du sens au contenu des pages Web, contrairementau Web classique qui se contente de les structurer. Ainsi il permet à un agent logiciel de com-prendre ce contenu. Grâce à cette compréhension, l’agent est capable de parcourir des pages etréaliser des tâches telles que la recherche et l’extraction des informations en se basant sur lesontologies.

L’application du Web sémantique aux services Web a donnée naissance aux services Websémantiques (SWS) [51]. D’une manière automatisée, les agents logiciels devraient pouvoir dé-couvrir, appeler, composer, et surveiller l’exécution des services Web. Pour atteindre ce but, leSWS doit (1) offrir aux fournisseurs la possibilité de publier leurs services, (2) faciliter la tâchede l’annuaire afin qu’il puisse fournir et composer, de façon automatique, les services recherchéset (3) permettre au client d’invoquer et surveiller, de façon automatique, un service sélectionnépar l’annuaire. Plusieurs approches ont été développées pour les SWS. Dans cette section, nouspassons en revue les plus connues parmi elles à savoir OWL-S, SAWSDL et WSMO. Chacune deces approches est motivée par un certain nombre d’objectifs. Néanmoins, elles ont en communles deux objectifs suivant :

– Découverte automatique de services Web : La découverte automatique de services Webest un processus permettant de localiser, d’une manière automatique, des services Webqui fournissent des services répondants à un besoin spécifié par un client.

– Invocation automatique des services Web : En donnant seulement une description décla-rative d’un service Web, un agent logiciel doit être capable d’invoquer automatiquement unservice Web après l’avoir découvert.

Le reste de cette section est organisé de la façon suivante. Dans la Section 3.2.1 nous présen-tons l’approche OWL-S. La Section 3.2.2 est consacrée à l’approche SAWSDL et dans la Section3.2.3 nous étudions l’approche WSMO. La Section 3.2.4 propose une synthèse autour de cesapproches. Enfin, nous présentons quelques conclusions dans la Section 3.2.4.

3.2.1 OWL-S

Semantic Markup for Web Services OWL-S [70, 21, 45] est un langage permettant de décrireles services Web de façon non ambiguë et interprétable par des programmes. Ce langage estbasé sur le langage d’ontologie du Web (OWL) [2]. OWL-S est aussi une ontologie OWL particu-lière. Nous présentons dans la suite les motivations de OWL-S et son ontologie supérieure pourles services Web.


3.2.1.1 Motivations de OWL-S

En plus des motivations indiquées dans l’introduction, que les trois approches visent à réaliser,OWL-S s’applique à accomplir la composition automatique des services Web. L’accomplissementd’une tâche complexe implique la sélection, la composition automatique des services Web. Parexemple, l’utilisateur peut vouloir faire tout le nécessaire pour son voyage à une conférence. Ilveut acheter un billet mais aussi il veut réserver un hôtel proche du lieu de la conférence. Il peutégalement ajouter des contraintes de coût minimal. Afin qu’un agent puisse exécuter ce typede tâche, OWL-S fournit une spécification des pré-requis et des conséquences de l’exécutionde chaque service individuel ainsi qu’un langage pour décrire les services composés et le flux dedonnées. Pour atteindre ces objectifs, OWL-S définit une ontologie supérieure pour la description,l’invocation et la composition des services Web. Celle-ci est présentée dans ce qui suit.

3.2.1.2 Ontologie supérieure de OWL-S

La structuration de l’ontologie supérieure de OWL-S (voir figure 3.3) est motivée par la néces-sité de fournir trois types d’information essentiels pour un service, à savoir :

– Que fait le service : cette information est donnée dans le Service Profile. Ce dernier permetla description, la publication et la découverte des services, en spécifiant une descriptiontextuelle à destination des utilisateurs "humains", des propriétés fonctionnelles et des pro-priétés non fonctionnelles. Dans l’approche OWL-S, la section Profile est utilisée à la foispar les fournisseurs pour publier leurs services et par les clients pour spécifier leurs be-soins. Par conséquent, elle constitue l’information utile pour la découverte et la compositionde services [70]. Les recherches de services peuvent se baser sur n’importe quel élémentde Profile comme critère [14] ;

– Comment utilise-t-on le service : cette information est fournie dans le Service Model qui estutilisé pour, entre autres, composer les services. OWL-S modélise les services en tant queprocessus et celui-ci est défini par ses entrées/sorties. Trois types de processus existent :les processus atomiques (AtomicProcess), simples (SimpleProcess) et composites (Com-positeProcess). Un AtomicProcess représente le niveau le plus fin pour un processus et cor-respond à une action que le service peut effectuer en une seule interaction avec le client.Les CompositeProcess sont décomposables en d’autres processus (composés ou non) ;leur décomposition peut être spécifiée en utilisant un ensemble de structures de contrôlestels que : Sequence, Split, If-Then-Else etc. Un SimpleProcess est utilisé pour fournir unevue d’un processus atomique ou une représentation simplifiée d’un processus composite ;

– Comment accède-t-on au service : cette information est donnée dans le Service Grounding.Celui-ci indique comment accéder concrètement au service et fournit les détails concernantles protocoles, les formats de messages et les adresses physiques.

Service

ServiceProfile

ServiceModel

ServiceGrounding

Que fait leService

comment accède-t-on au service

comment utilise-t-on le service

FIGURE 3.3 – L’ontologie supérieure de OWL-S

La figure 3.4 présente la description OWL-S de l’assuré. Il est composé du profile de l’assuré(assureProfile), de son process (assureProcess) et de son grounding (assureGrounig).


1 <service:Service rdf:ID="assureService">2 <service:presents rdf:resource="&my_profile;#assureProfile"/>3 <service:describedBy rdf:resource="&my_process;#assureProcess"/>4 <service:supports rdf:resource="&my_grounding;#assureGrounding"/>5 </service:Service>

FIGURE 3.4 – Service OWL-S de l’assuré

Dans la figure 3.5 nous présentons le profil de l’assuré. Tout d’abord, un nom est affecté à ceprofile (ligne 2). Ensuite, le processus ainsi que le service auquel appartient ce profil sont donnés(lignes 4 5). Les lignes 7 à 12 définissent le nom du service de l’assuré, une description textuellede ce service ainsi que les noms et les addresses des personnes à contacter pour avoir desinformations sur ce service.

1 <profileHierarchy:Assurance2 rdf:ID="assureProfile">34 <service:presentedBy rdf:resource="&my_service;#assureService"/>5 <profile:has_process rdf:resource="&my_process;#assureProcess"/>67 <profile:serviceName>assureService</profile:serviceName>8 <profile:textDescription>9 C’est la description OWL du workflow modélisant le travail de l’assuré.10 </profile:textDescription>11 <profile:contactInformation>12 </profile:contactInformation>13 </profileHierarchy:Assurance>

FIGURE 3.5 – Le profil de l’assuré

La figure 3.6 montre le processus de l’assuré (assureProcess). Il est composé (dans ce cassimplifié) des deux processus atomiques devis et avis (lignes 14 à 21). assureProcess fourniten sortie un devis (devisDeclaration, lignes 3 à 5) et prend en entrée l’avis de la compagnied’assurance (avisDeLAssureur, lignes 9 à 11). Les deux types DevisOutputType et AvisInputTypesont des classes OWL définissant respectivement le type d’un devis et celui d’un avis de laassureur.

3.2.2 SAWSDL

Semantic annotation for WSDL (SAWSDL) [72] est un langage sémantique de descriptionde service Web. Il est évolutif et compatible avec les standards des services Web existants, etplus spécifiquement avec WSDL[20]. SAWSDL augmente l’expressivité du langage WSDL avecla sémantique en utilisant des concepts analogues à ceux utilisés dans OWL-S[70]. D’une partSAWSDL, fournit un mécanisme permettant d’annoter sémantiquement les types de données,les opérations, les entrées et les sorties de WSDL et d’autre part, il ajoute des éléments pourspécifier les pré-conditions, les effets et les catégories des services Web. Les aspects relatifs àla qualité et l’orchestration des services ne sont pas traités dans SAWSDL.

Nous présentons dans ce qui suit les motivations qui étaient à l’origine de SAWSDL.


1 <process:CompositeProcess rdf:ID="assureProcess">23 <process:hasOutput>4 <process:Output rdf:ID="devisDeclaration">5 <process:parameterType rdf:datatype="&xsd;#anyURI">6 &THIS;DevisOutputType</process:parameterType>7 </process:Output>8 </process:hasOutput>910 <process:hasInput>11 <process:Input rdf:ID="avisDeLAssureur">12 <process:parameterType rdf:datatype="&xsd;#anyURI">13 &THIS;AvisInputType</process:parameterType>14 </process:Input>15 </process:hasInput>1617 <process:composedOf>18 <process:Sequence>19 <process:components>20 <process:Perform rdf:ID="devis"/>21 <process:Perform rdf:ID="avis"/>22 </process:components>23 </process:Sequence>2425 </process:composedOf>26 </process:CompositeProcess>

FIGURE 3.6 – Le processus de l’assuré

3.2.2.1 Motivations de SAWSDL

En plus de la découverte et l’invocation automatiques des services Web, déjà citées dansl’introduction, SAWSDL vise la réalisation des objectifs suivants :

– Un langage au dessus des standards des services Web existants : Les standards de ser-vices Web sont devenus rapidement une technologie préférée pour l’intégration des appli-cations. Les entreprises investissent dans des projets d’intégration basés sur des servicesWeb. Par conséquent, les concepteurs de SAWSDL considèrent que n’importe quelle ap-proche pour la description sémantique des services Web doit être compatible avec l’existant.A cet effet SAWSDL, une extension sémantique de WSDL a été conçu,

– Concevoir un langage incrémental : il est relativement facile de modifier les outils existantsautour de WSDL afin qu’ils s’adaptent à SAWSDL. Ce qui fait de SAWSDL une approcheincrémentale,

– Le mécanisme d’annotation doit être indépendant du langage de représentation de la sé-mantique : Il y a un certain nombre de langages potentiels pour représenter la sémantiquecomme Web Service Modeling Language (WSML) [24], OWL et Unified Modeling Language(UML) [57]. Chaque langage offre différents degrés d’expressivité. La position des concep-teurs de SAWSDL est qu’il n’est pas nécessaire d’attacher les standards des services Webà un langage sémantique particulier. Cette approche est la vision décrite dans [78] et donneplus de flexibilité aux développeurs.

La figure 3.7 montre la description WSDL de l’opération devis de l’assuré. Cette opérationa comme sortie le devis (ligne 2). Nous montrons dans la section suivante comment annotersémantiquement cette opération.

Dans ce qui suit nous présentons comment l’annotation est faite dans SAWSDL.


1 <wsdl:operation name="devis" >2 <wsdl:output element="devisDeclaration" />3 </wsdl:operation>

FIGURE 3.7 – Opération devis de l’assuré

3.2.2.2 Annotation sémantique

L’annotation sémantique des documents WSDL est possible grâce à l’extensibilité de WSDL2.0. En effet, conceptuellement WSDL 2.0 est doté des constructions suivantes : interface, opé-ration, message, binding, service et endpoint. Les trois premiers à savoir interface, operation etmessage concernent la définition abstraite du service tandis que les trois autres sont relatifs àl’implémentation du service. SAWSDL fournie des mécanismes pour référencer des concepts demodèles définis à l’extérieur du document WSDL. Cela se fait grâce à l’attribut "sawsdl". Il existetrois extensions de cet attribut. La première est modelReference et permet d’associer un com-posant WSDL ou XML Schema à un concept d’une ontologie. Les deux autres sont liftingSche-maMapping et loweringSchemaMapping et permettent de spécifier le mapping entre les donnéessémantiques et les éléments XML. Les SchemaMapping sont utilisés pour établir la correspon-dance entre les structures des entrées et des sorties, et est utile lorsque les structures XMLdemandées par le client et celles fournies par le service sont différentes. L’annotation des inter-faces, opérations, entrées/sorties et les types XML simple s’effectue en leur associant un conceptdans une ontologie par le biais de l’attribut modelRefernce. Cependant, l’annotation des types dedonnées XML complexes peut nécessiter en plus un Schema Mapping. En effet, deux servicesWeb peuvent manipuler le même type complexe mais avec deux structures différentes.

Pour illustrer l’annotation sémantique, nous reprenons la description de l’opération devis don-née dans la section précédente. Dans la figure 3.8 nous présentons l’annotation du messageproduit en sortie par l’opération devis en l’associant au concept DevisDeclaration dans l’ontologieAssuranceOnto (lignes 3 à 4 ). Nous présentons également l’annotation de l’opération devis enl’associant au concept Devis dans l’ontologie AssuranceOnto (lignes 1 à 2 ).

1 <wsdl:operation name="devis"2 psawsdl: preference="http://w3/ontology/AssuranceOnto/Operation#Devis"/>3 <wsdl:output element="devisDeclaration"4 psawsdl: preference="http://w3/ontology/AssuranceOnto#DevisDeclaration"/>5 </wsdl:operation>

FIGURE 3.8 – Description de l’opération devis de l’assuré en SAWSDL

Nous présentons dans la section suivante le langage WSMO.

3.2.3 WSMO

WSMO est une ontologie qui décrit les différents aspects relatifs à la composition dynamiquedes services Web, y compris la découverte dynamique, la sélection, la médiation et l’invocation.Elle est basée sur WSMF[29, 45] (Web Service Modelling Framework) qui spécifie les élémentsprincipaux pour décrire les services Web sémantiques. De tels éléments incluent ontologies, ob-jectifs, services Web et médiateurs. Les ontologies définissent la terminologie, utilisée par lesautres éléments, en termes de concepts, relations, fonctions, instances et axiomes. Les buts


indiquent ce que l’utilisateur attend du service. La description du service Web définit les fonc-tionnalités offertes par le service. Les médiateurs lient les différents éléments afin de permettrel’interopérabilité entre les composants hétérogènes. Le langage WSML[24] est utilisé pour décrireformellement tous les éléments de WSMO et l’environnement d’exécution WSMX [101] permet ladécouverte, la sélection, la médiation, l’invocation et l’interopérabilité des services Web séman-tiques. Nous présentons dans la suite les motivations de WSMO.

3.2.3.1 Motivations de WSMO

WSMO [100] partage avec OWL-S les mêmes motivations à savoir la découverte, l’invocationet la composition automatiques des services Web. Cependant WSMO ajoute à celles-ci l’objectifsuivant : Un découplage fort entre les composants et un rôle central pour la médiation. L’un desprincipes fondamentaux de WSMO consiste en la séparation totale entre les différents élémentsimpliqués dans la composition des services Web. A cet effet, WSMO veut distinguer entre com-ment le client formule sa demande et comment le fournisseur expose son service. Sachant que lademande et l’offre sont décrites de façons différentes, un travail important doit être effectué afind’établir la correspondance entre la demande et l’offre. Ce travail est le rôle des médiateurs.

3.2.3.2 Les facettes de WSMO

Les facettes de WSMO sont les ontologies, les médiateurs, les services Web et les buts. Lesontologies fournissent la sémantique compréhensible par une machine pour les informations uti-lisées par tous les acteurs d’un service Web. WSMO permet d’importer une ontologie dans uneautre ontologie soit directement, quand il n’y pas de conflits, soit indirectement, par le biais d’unmédiateur qui va résoudre les conflits possibles. Les blocs de base d’une ontologie sont concepts,relations, functions, instances et axioms. Un ensemble de propriétés non fonctionnelles est don-née généralement au début de chaque définition d’une ontologie. Les médiateurs permettent delier différentes ressources hétérogènes et résoudre les incompatibilités à plusieurs niveaux. Ilpeut y avoir une incompatibilité entre les données ou entre les processus. Dans le premier cas, lamédiation sert à établir la correspondance entre les différentes terminologies. Le deuxième typed’incompatibilité apparaît au moment de la communication entre différents services Web hétéro-gènes et dans ce cas, le médiateur fournit la fonctionnalité pour une analyse d’exécution de deuxservices Web donnés, et compense les éventuelles disparités. Les services Web WSMO sontcomposés d’un ensemble optionnel de propriétés non fonctionnelles, un mécanisme permettantd’importer des ontologies soit directement en utilisant importsOntology, soit indirectement via unmédiateur, une capacité décrivant la fonctionnalité du service en termes de pré et postconditions,hypothèses de bases et effets et une interface décrivant le comportement du service vis-à-vis deses partenaires.

Pour montrer comment le service devis peut être décrit en WSMO, nous commençons pardéfinir les concepts que ce service manipule. La figure 3.9 présente la définition du conceptdevisDeclaration. Tout d’abord, le nom du concept est défini (ligne 1). Ensuite, on définit les typesde données présentés dans un devis. La première donnée est de type personne et représente lepropriétaire qui envoie le devis (ligne 2). La deuxième donnée est le montant du devis (ligne 3).Enfin, la troisième donnée est la date de l’envoie du devis (ligne 4).

Après avoir défini le devis, nous créons une instance de ce devis. La figure 3.10 présente ladéfinition de l’instance devisDecl.


1 concept devisDeclaration2 propriétaire impliesType personne3 montant ofType _float4 date ofType _date

FIGURE 3.9 – Description d’un concept en WSMO

1 instance devisDecl memeberOf DevisDeclaration2 propriétaire assure3 montant 5004 date 05/05/2008

FIGURE 3.10 – Description d’une instance en WSMO

Ensuite, nous donnons dans la figure 3.11 la définition du service permettant d’envoyer undevis à un assureur. Le service est accessible à l’adresse http ://exempleAssurance.org/devis(ligne 1) et a la capacité devisCapacité (ligne 2).

1 webServices _"http://exempleAssurance.org/devis"2 capability devisCapacité

FIGURE 3.11 – Description en WSMO du service devis de l’assuré

Enfin, nous présentons la définition de la capacité du service dans la figure 3.12. Étant donnéque la définition des pré-condition, post-condition, hypothèses de base et effets se fait de lamême manière, nous nous contentons de donner celle des pré-conditions. La pré-condition duservice est que la date de l’accident ne soit pas postérieure à la date courante et que le numérode l’assuré soit reconnu par l’assureur. Tout d’abord la variable utilisée dans le service est définie(ligne 2). Ensuite, on donne la définition de la pré-condition du service. Cette définition commencepar les propriétés non fonctionnelles du service (ligne 4 à 8). Ici, il s’agit d’une description textuelle.Enfin, nous définissons les deux conditions (ligne 9 à 12).

1 capability devisCapacité2 sharedVariable ?devisDecl3 precondition4 nonFonctionalProperties5 #description hasValus "la date de l’accident ne6 doit pas être postérieure à la date courante7 et le numéro de l’assuré soit valide.8 endNonFonctionalProperties9 definedBy10 #valideNumero(?devisDecl.assure.numero)11 and12 neg (wsml#dateLessThan(?devisDecl.date, wsml#currentDate)

FIGURE 3.12 – Description en WSMO du service devis de l’assuré

La section suivante compare les trois langages de description sémantique des services Webà savoir OWL-S, SAWSDL et WSMO.


3.2.4 Synthèse

Avant de procéder à la comparaison des trois approches décrites ci-dessus, il convient de rap-peler qu’aucune parmi celles-ci n’a atteint les objectifs initialement escomptés. En les évaluantpar rapport aux objectifs communs, découverte et invocation automatiques, nous observons queces deux objectifs sont partiellement pris en compte par OWL-S. D’une part, la découverte baséesur la sémantique est faite grâce à des outils, implémentant des algorithmes de Matching, tel queMatcher [50] et d’autre part l’invocation automatique est réalisée en utilisant WSDL. WSMO etSAWSDL permettent uniquement l’invocation automatique. OWL-S étant le premier langage, leslangages qui l’ont suivi tel que WSMO et SAWSDL se sont inspirés de lui, tout en évitant ses dé-fauts. L’une des principales critiques faites à OWL-S est qu’il n’impose aucune contrainte afin quele Service Profile et le Service Model soient cohérents. Étant donné que OWL-S et WSMO sontproches l’un de l’autre, nous allons les comparer et ensuite nous comparons ces deux langagesavec SAWSDL. Quoique WSMO introduise une nouvelle composante, les médiateurs, dans l’ar-chitecture des services, il reste proche de OWL-S. En effet, (1) le Service Profile de OWL-Sressemble aux deux composantes, capacité et propriétés non fonctionnelles de WSMO, (2) leService Model est similaire à une interface dans WSMO et (3) un Objectif WSMO étant composéd’une interface, une capacité et des propriétés non fonctionnelles, il ressemble donc à une partiedu Service Profile et une partie Service Model. Néanmoins, en comparant le Service Profile etl’Objectif nous constatons que ce dernier est plus avantageux. En effet, l’Objectif est défini in-dépendamment du service et ainsi le même Objectif peut être utilisé par plusieurs services afind’effectuer une recherche, tandis que le Service Profile est rattaché à un service donné. La der-nière ressemblance est celle de Service Grounding de OWL-S et le grounding dans WSMO. Lemédiateur de WSMO n’a pas de correspondant dans OWL-S.

S’agissant de SAWSDL, celui-ci s’intéresse à la découverte et l’invocation automatique desservices mais il ne s’occupe pas de la composition. Étant proche de WSDL, SAWSDL ne né-cessite pas beaucoup d’efforts pour les développeurs habitués à WSDL contrairement à OWL-Set WSMO. SAWSDL permet d’utiliser tous types d’ontologies (OWL, WSML et UML ) tandis queOWL-S accepte des ontologies OWL et WSMO des ontologies WSML. Enfin, SAWSDL ne per-met pas de définir des propriétés non fonctionnelles. En termes d’outillage, OWL-S tire partie deson ancienneté et ainsi il dispose de plusieurs outils allant du simple éditeur au composeur semi-automatique en passant par les outils de Matching et de validation. Cependant WSMO ne disposeque des outils pour l’édition, WSML Editor et un seul outil propre à SAWSDL existe, SAWSDL ToolAnnotation (un outil pour l’annotation sémantique). Les outils pour WSMO s’avèrent plus difficilesà développer car celui-ci se base sur WSML, un langage qui n’a pas été utilisé auparavant, tandisque OWL-S et SAWSDL s’appuient sur RDF [1] et XML. Le tableau présentée dans la figure 3.13fournit un récapitulatif de cette comparaison.

OWL-S SAWSDL WSMOType ontologie accepté OWL Tous WSML

Composition des services +/- - +/-Outillage Matcher, éditeurs outil d’annotation éditeur

validateurs . . .Mediation et objectif - - +

FIGURE 3.13 – Comparaison de OWL-S, SAWSDL et WSMO

Chapitre 4

Appariement comportemental deworkflows

Sommaire4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Préliminaire sur les réseaux de Pétri . . . . . . . . . . . . . . . . . . . 36

4.2.1 Dé�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.2 Séquence de franchissement et con�it . . . . . . . . . . . . . . . . . . . . 374.2.3 Propriétés des réseaux de Pétri . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 Agglomération structurelle . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.1 Post-agglomération structurelle . . . . . . . . . . . . . . . . . . . . . . . 404.3.2 Pré-agglomeration structurelle . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 Appariement de work�ows . . . . . . . . . . . . . . . . . . . . . . . . . 464.4.1 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.4.2 Approches d'appariement comportemental des work�ows . . . . . . . . . 494.4.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1 Introduction

La modélisation des workflows consiste à identifier les caractéristiques communes d’un en-semble de workflows et à les représenter dans une syntaxe précise dans le but de les formaliser,les visualiser, les exécuter, les superviser, les contrôler, les auditer, les documenter et les échan-ger.

Elle est aujourd’hui motivée par deux raisons principales :

– le besoin d’évolution rapide du fait du contexte de plus en plus concurrentiel et d’une régle-mentation de plus en plus évolutive,

– le besoin de partage du fait des nouveaux modèles économiques poussant à la coopérationinterentreprises.

Pour faciliter la coopération interentreprises, il convient de développer des techniques permet-tant la préservation du savoir-faire de chaque partenaire et de fournir des outils pour la découverte

35

36 Appariement comportemental de workflows

des workflows. Dans ce chapitre nous nous intéressons à l’état de l’art des techniques facilitantl’abstraction des workflows ainsi qu’aux approches existant pour la comparaison des workflows.

Le formalisme des réseaux de Pétri permet de modéliser les workflows d’une manière for-melle. L’intérêt principal de l’utilisation des réseaux de Pétri pour modéliser les workflows provientdu fait qu’ils permettent de représenter d’une manière simple et claire les notions de séquence,de parallélisme, de synchronisation, de partage de ressources, de communication et de causa-lité, mais surtout parce qu’il permettent d’exprimer aussi bien les propriétés structurelles que lespropriétés comportementales des workflows.

Grâce à l’utilisation des réseaux de Pétri, les techniques d’agglomération de ceux-ci peuventêtre appliquées pour abstraire les workflows. Une fois les workflows abstraits, ils sont ensuitepubliés dans un annuaire et ainsi ils peuvent être découverts. La découverte d’un workflow publiéest réalisée en le comparant avec des workflows requête. Les workflows étant modélisés pardes réseaux de Pétri, leur comparaison revient donc à comparer des réseaux de Pétri. Cettecomparaison permet de statuer si deux workflows donnés sont équivalents ou pas. Cependant,il existe différentes définitions pour la notion d’équivalence. Suivant le type d’équivalence utilisé,plusieurs approches de comparaison des workflows ont été définies.

Le reste de ce chapitre est organisé comme suit. La section 4.2 présente un préliminairesur les réseaux de Pétri. Dans la section 4.3 nous présentons des transformations qui peuventmodifier profondément la structure des réseaux de Pétri auxquels elles sont appliquées. Nousnous intéressons ensuite dans la section 4.4 à l’étude des différentes approches d’appariementdes workflows. Enfin, nous présentons quelques conclusions dans la section 4.5.

4.2 Préliminaire sur les réseaux de Pétri

Le modèle des réseaux de Pétri a été introduit par Carl Adam Pétri en 1962 dans une partie desa thèse de doctorat pour modéliser les processus communicants. Les réseaux de Pétri peuventêtre considérés comme une théorie, un formalisme ou un langage de modélisation. Dans cettethèse, nous utilisons les réseaux de Pétri comme étant un langage pour modéliser les workflows.De ce fait, tous les aspects des réseaux de Pétri ne sont pas développés ici. Seuls ceux relatifsau contexte des workflows sont abordés. Dans cette section nous commençons par définir lanotion de réseau de Pétri (section 4.2.1). Ensuite nous présentons dans la section 4.2.2 la notionde séquence de franchissement. Enfin, nous abordons quelques propriétés des réseaux de Pétridans la section 4.2.3.

4.2.1 Définitions

Les définitions données dans cette section sont en partie inspirées de celles fourniesdans [39].

Définition 8 Un réseau de Pétri (RdP) est un graphe biparti composé de nœuds (places et tran-sitions) et d’arcs orientés reliant les œuds. Nous le représentons par le triplet R = <P, T, A> où

– P est un ensemble fini de places P = {p1, p2, . . . , pm},– T est un ensemble fini de transitions T = {t1, t2, . . . , tn},– A est un ensemble d’arcs reliant les transitions aux places et les places aux transitions. Les

arcs sont de deux types et ils peuvent être représentés par les deux fonctions suivantes :

4.2 Préliminaire sur les réseaux de Pétri 37

t1

p1

p2 p3

p4 p5

t2 t3

t4

FIGURE 4.1 – Exemple de réseau de Pétri

– Pré : la fonction P × T −→ N (ensemble des entiers naturels) correspondant aux arcsdirects reliant les places aux transitions,

– Post : la fonction P × T −→ N correspondant aux arcs directs reliant les transitions auxplaces.

Nous désignons par •t (respectivement t• ) l’ensemble de places d’entrée (resp. de sortie) dela transition t. De même •p (resp. p• ) désigne l’ensemble de transitions d’entrée (resp. de sortie)de la place p.

La figure 4.1 montre un exemple de réseau de Pétri. Les places sont p1, p2, p3, p4 etp5 et les transitions sont t1, t2, t3 et t4. Les places d’entrée de la transition t4 sont p4 et p5(•t4 = {p4, p5}).

Définition 9 (réseau de Pétri marqué) :

Un réseau de Pétri marqué est un couple (RdP, M) tel que :

RdP : un réseau de Pétri

M : une fonction qui associe à chaque place p du RdP un nombre de marques

M : P −→ N.

p −→ M(p)

Le réseau de Pétri donné dans la figure est marqué. En effet, M(p1) = 1 etM(p2) = M(p3) = M(p4) = M(p5) = 0.

Définition 10 (Transition neutre) : Un transition t est dite neutre si l’ensemble de ses placesd’entrée est égal à l’ensemble de ses places de sortie :

•t = t•

Dans la section nous donnons la définition d’une séquence de franchissement.

4.2.2 Séquence de franchissement et conflit

Pour un marquage M , une transition t est dite franchissable si :


∀p ∈ •t M(p) ≥ Pre(p, t)

Le franchissement d’une transition t a pour conséquence :– De retirer de Pre(p,t) les marques de chaque place d’entrée p de la transition t

– D’ajouter à Post(p,t) les marques dans chaque place de sortie p de la transition t.Une autre notion liée au franchissement des transitions et qui a une importance dans notre

travail est la notion de conflit. Un conflit structurel correspond à un ensemble d’au moins deuxtransitions ayant une place d’entrée en commun. Un conflit effectif est l’existence d’un conflitstructurel et d’un marquage M , tel que le nombre de marques dans la place du conflit est infé-rieur à la somme des poids des arcs qui relient cette place aux transitions qu’elle rend franchis-sable [23].

Une séquence de franchissement s est une suite de transitions 〈t1.t2 . . . tn〉 qui permet, à partird’un marquage M , de passer au marquage M ′ par le franchissement successif des transitionsdéfinissant la séquence. Dans la figure 4.1 nous avons donné un exemple de réseau de Pétri.Soit s1 = t1.t2. La séquence s1 est une séquence de franchissement. On note par M0[s1〉M2

le fait que l’exécution de la séquence s1 à partir de l’état M0 (M(p1) = 1) mène à l’état M2

((M(p4) = 1)). Par contre, la séquence t1.t4 n’est pas une séquence de franchissement à partirde M0. On désigne par M∗

0 l’ensemble de marquages accessibles à partir de M0 en franchissantune séquence de transition.

Dans la section suivante nous présentons quelques propriétés des réseaux de Pétri.

4.2.3 Propriétés des réseaux de Pétri

Nous présentons dans cette section les propriétés des réseaux de Pétri que nous utilisonsdans le cadre de ce mémoire. Ces propriétés peuvent être classées en deux catégories [13][19]à savoir les propriétés dynamiques et les propriétés structurelles.

4.2.3.1 Propriétés dynamiques

Les propriétés dynamiques sont celles qui dépendent du marquage initial et sont liées à l’évo-lution du réseau. Ils en existent plusieurs mais nous présentons ici seulement le caractère bornéet la vivacité d’un réseau ainsi que la notion de blocage.

Une place pi est dite bornée pour un marquage initial M0 s’il existe un entier naturel k tel que,pour tout marquage accessible à partir de M0, le nombre de marques dans pi est inférieur ouégal à k. pi est alors k−borné.

Un RdP marqué est borné pour un marquage initial M0 si toutes les places sont bornées pourM∗

0 .

Un RdP marqué (R, M0) est vivant si et seulement si, pour tout marquage accessible M ∈M∗

0 , et pour toute transition t, il existe une séquence de franchissement qui contient t.

La vivacité d’un réseau garantit le franchissement de toute transition quel que soit le marquageatteint. Cette propriété est forte et est souvent difficile à vérifier [54].

La dernière propriété dynamique qui nous intéresse est le blocage des réseaux de Pétri. Unblocage est en effet un marquage tel qu’aucune transition n’est franchissable.

Dans ce qui suit nous présentons le deuxième groupe de propriétés des réseaux de Pétri.

4.3 Agglomération structurelle 39

4.2.3.2 Propriétés structurelles

Les propriétés structurelles dépendent de la typologie du réseau et elles sont indépendantesdu marquage initial du réseau.

L’analyse des propriétés structurelles repose sur l’algèbre linéaire. En effet, la structure d’unréseau peut être définie par une matrice à éléments entiers, appelé matrice d’incidence [23].

Pour un réseau de Pétri avec n transitions et m places, la matrice d’incidence W = [wij ] estune matrice (m x n), définie par :

W (i, j) = [wij ] = Post(pi, tj)− Pre(pi, tj)

Deux autres matrices d’incidence sont définies. Il s’agit de la matrice d’incidence avant W+ etarrière W− :

W+(i, j) = Post(pi, tj) et W−(i, j) = Pre(pi, tj)

D’où l’égalité matricielle suivante W = W+ −W−

La matrice d’incidence permet de définir la notion d’invariant. Il y a deux types d’invariants :les invariants de places (p-invariant) et les invariants de transitions (t-invariant).

Un p-invariant est un vecteur entier positif X de dimension m qui vérifie l’équation suivante :

XT .W = 0

Un t-invariant est un vecteur entier positif Y de dimension n qui vérifie :

W.Y = 0

Après avoir défini les notions de base de réseaux de Pétri, nous nous intéressons dans lasection suivante à deux transformations formelles permettant la modification de la structure d’unréseau. Il s’agit de la technique d’agglomération structurelle.

4.3 Agglomération structurelle

Nous présentons dans cette section un ensemble de transformations définies dans la littéra-ture qui peuvent modifier profondément la structure des réseaux auxquels elles sont appliquées.Dans l’optique de réduction, ces transformations sont constituées d’agglomération de transitions,plusieurs transitions étant réunies pour n’en former qu’une seule. Ces transformations ont étéintroduites dans [12] puis ensuite étendues dans [32]. L’objectif de ces transformations est depouvoir réaliser en un seul déclenchement et de façon indivisible un changement de marquagequi auparavant était obtenu par une séquence de déclenchements.

Ces transformations sont basées sur le fait qu’il n’est pas obligatoire de déclencher une tran-sition sitôt qu’elle est franchissable. Il est en effet possible de retarder le déclenchement d’unetransition jusqu’au déclenchement d’une autre transition et ainsi de confondre les deux transitions.On parle d’agglomération de transitions.

L’objectif de l’agglomération est de réduire le nombre de transition d’un réseau de Pétri. Pouratteindre cet objectif, l’ensemble de transitions T est divisé en sous groupes de transitions tellesque T = T0

⊎i∈I Hi

⊎i∈I Fi avec I ensemble non vide d’indices. Notons que les deux groupes Hi

et Fi sont liés par les ensembles de places Pi. L’idée derrière cette décomposition est de pouvoir


fusionner les transitions de Hi et celles de Fi. Cela impose une dépendance entre les transitionsqui peuvent être agglomérées à savoir celles de chaque couple (Hi, Fi). Afin de formaliser cettedépendance et de préserver certaines propriétés fondamentales des réseaux, des restrictionssont imposées à ces transitions. Ces restrictions conduisent à deux types de transformations àsavoir : la pre et la post-agglomération. Pour chacun de ces deux types de transformations il estpossible de faire une agglomération structurelle [32] ou une agglomération comportementale [12].

Dans le cas d’une agglomération comportementale, la vérification de certaines propriétés né-cessite la construction du graphe d’accessibilité avant la réduction, ce qui est exponentiel. Cepen-dant, la vérification des propriétés structurelles se fait souvent avec des algorithmes polynomiaux.Par conséquent, dans ce chapitre nous nous intéressons uniquement à l’agglomération structu-relle introduite dans [32].

Dans ce qui suit nous présentons les méthodes de post et pre-agglomératoin.

4.3.1 Post-agglomération structurelle

Dans cette section, nous abordons le premier type de réduction, la post-agglomération. Soitune place pi qui a pour entrée un ensemble Hi de transitions et pour sortie un ensemble de tran-sition Fi. la post-agglomération exprime le fait que le franchissement des transitions du groupeFi est conditionné principalement par le franchissement des transitions du groupe Hi et elle re-pose sur le principe suivant : dans n’importe quelle séquence de transitions où un franchissementd’une transition de Hi est plus tard suivi par un franchissement d’une transition de Fi, on auraitpu franchir immédiatement la transition de Fi après la transition de Hi. La post-agglomérationsupprime la place pi et les transitions de Fi et modifie les transitions de Hi en leur incorporant lefranchissement des transitions de Fi.

Étant donné que dans la post-agglomération l’ensemble I est réduit à un singleton, il n’y aalors qu’un seul groupe F et un seul groupe H. Par conséquent dans le reste de cette section,nous utiliserons H et F à la place de Hi et Fi. Dans le cas général, il y a plusieurs groupes Hi etFi.

La figure 4.2-(a) présente un réseau de Pétri modélisant un processus. Le déclenchement del’une des transitions h1, h2 ou h3 met un jeton dans la place p. Ce jeton transitera forcément versla place p′. Par conséquent le marquage du réseau tel que la place p est marquée sera toujours unmarquage intermédiaire entre deux marquaged où elle ne le sera pas. Puisque le déclenchementde la transition f implique le déclenchement de la transition t il est plus simple de considérerqu’il existe une transition t′ dont les fonctions d’entrée sont celles de f et les fonctions de sortiesont celle t. Le réseau est ainsi aggloméré autour de p. Le réseau modifié est donné par la figure4.2-(b).

Afin qu’une telle réduction soit valide, des conditions spécifiques doivent être vérifiées à sa-voir : HF-interchangeable, F-independence et F-continuation.

Le but de la post-agglomération (et l’agglomération en général) étant de fusionner un groupede transitions H avec un autre F , il est raisonnable d’imposer que dans toutes les séquences duréseau originel, une transition de F doit être précédée par une transition de H. Cette conditionest introduite à l’aide de la fonction de dénombrement Γ. La définition formelle de cette fonctionest donnée dans la Définition 11.


p

h1

p’

f

t

p’

t’

(a) (b)

h2h3

h1h2

h3

FIGURE 4.2 – Principe de la post-agglomération

Grâce à la fonction de dénombrement Γ, on peut caractériser les réseaux de Pétri potentiel-lement agglomérables. Il s’agit des réseaux pour lesquels, dans chaque séquence de déclenche-ment à partir du marquage initial, chaque transition de F est précédée par une transition de H.La définition formelle des réseaux potentiellement agglomérables est donnée dans la Définition12.

La Définition 13 introduit la notion de blocage dont on en aura besoin lors de la présentationdes propriétés de la post-agglomération.

Nous appelons le réseau de Pétri originel, le réseau de Pétri avant la réduction et le réseaude Pétri réduit, le réseau de obtenu après la réduction.

Définition 11 (Fonctions de dénombrement) La fonction Γ désigne la différence entre le nombredes transitions de H et le nombre de transitions de F dans une séquence de franchissement duréseau de Pétri originel.

La définition suivante établit que le nombre de transitions de H dans une séquence est supé-rieur ou égal au nombre de transitions de F dans la même séquence.

Soit s ∈ T ∗ une séquence finie. On note par Γ(s) le nombre des transitions de H dans s moinsle nombre des transitions de F dans s.

Γ(s) =| s |H − | s |F

Définition 12 (Réseau potentiellement agglomérable) Cette définition caractérise les réseauxpotentiellement agglomérables et ceux potentiellement structurellement agglomérables. Un ré-seau est potentiellement agglomérable si le nombre d’occurrences de Hi dans une séquence dedéclenchement à partir du marquage initial est supérieur ou égal au nombre d’occurrence de Fi

dans la même séquence.

Rappelons que les deux groupes de transitions H et F sont liés par la place p. Un réseau estpotentiellement structurellement agglomérable si p n’est pas initialement marqué et si les uniquesentrées et sorties de p sont H et F respectivement. De plus, pour toute transition f de F etpour toute transition h de H, le nombre de jetons ajoutés à la place p par le tir de la transition


h (W+(p, h)) ainsi que le nombre de jetons enlevé de la place p par le franchissement de latransition f (W−(p, f)) est égal à 1.

Un réseau marqué (Rp,m0) est

1. potentiellement agglomérable (p-agglomérable) si et seulement si ∀s ∈ L(Rp, m0), ∀i ∈I,Γi(s) ≥ 0

2. structurellement p-agglomérable (sp-agglomérable) si et seulement si ∀i ∈ I,∃pi tel que– m0(pi) = 0, •pi = Hi, pi

•=Fi ; et– ∀h ∈ Hi, ∀f ∈ Fi,W+(pi, h) = W−(pi, f) = 1

Définition 13 (Blocage des transitions)

L’idée de cette propriété est la suivante. Étant donné un réseau de Pétri Rp, un ensemblede transitions T de Rp et une place p de Rp. Le marquage de la place p rend l’ensemble detransitions T infranchissable. On dit alors que la place p bloque les transitions de T et on le notep bloque T . Ci-dessous on donne la définition formelle de cette propriété.

Soit (P, T, A) un réseau de Pétri, p ∈ P et t ∈ T . Supposons le problème linéaire où :– les variables sont {xq}q∈P avec xq désigne le nombre de jetons dans la place q,– les contraintes sont données par la positivité des variables, les invariants du réseau et les

inéquations xp ≥ 1 et ∀q ∈ •t, xq ≥ W−(q, t).n’admet pas de solution. On dit alors que p bloque t. Par extension, p bloque un ensemble detransitions T ′ si ∀t ∈ T ′, p bloque t.

Dans cette section nous avons présenté post-agglomération. la La section suivante seraconsacrée aux conditions requises pour pouvoir appliquer la post-agglomération.

4.3.1.1 Les propriétés de la réduction post-agglomération

Afin que la post-agglomération puisse être appliquée sur un réseau de Pétri, des conditionsspécifiques doivent être vérifiées par le réseau en question à savoir : HF-interchangeable, F--independence et F-continuation. L’idée principale sur laquelle ces règles sont basées est la sui-vante : dans chaque séquence franchissable avec une occurrence de transition h de H suivieultérieurement par une occurrence de transition f de F , il est possible de franchir f immédiate-ment après h. Les règles suivantes permettent d’établir la dépendance entre les deux groupes detransitions H et F qui seront agglomérés par la suite. Dans ce qui suit nous présentons une parune ces propriétés ainsi que leur signification.

4.3.1.1.1 La propriété HF-interchangeabilité La réduction post-agglomération simplifie pro-fondément les réseaux de Pétri. Cependant, la simplification doit préserver certaines propriétésdu réseau telles que la vivacité. A cet effet la propriété HF-interchangeabilité est introduite afind’assurer que le réseau réduit obtenu après l’application de la post-agglomération reste vivant sile réseau originel l’était. Ci-dessous la définition formelle ainsi que l’explication de cette propriété.

Le réseau de Pétri (Rp,m0) est HF-interchangeable si l’une des conditions suivantes est sa-tisfaite :

1. | H |= 1

2. | F |= 1

3. ∀f, f ′ ∈ F, W−(p, f) = W−(p, f ′)


4. ∀h, h′ ∈ H

– W−(p, h) = W−(p, h′) et– ∀f ∈ F, W+(p, h) = W+(p, h′)

L’hypothèse HF-interchangeable garantit que toute transition de H peut être remplacée parune autre transition de H (H-interchangeabilité) et de la même manière toute transition de F peutêtre remplacée par une autre transition de F (F-interchangeabilité). Les conditions 2 et 3 sontrelatives à l’interchangeabilité des transitions de F tandis que les conditions 1 et 4 sont relativesà l’interchangeabilité des transitions de H. L’aspect technique du point 4 est dû au fait que si H

et F ne sont pas réduit à un singleton, alors la possibilité de remplacer une transition h par unetransition h′ implique une équivalence en terme de pré-conditions mais aussi une équivalence enterme de jetons produits par ces transitions est nécessaire pour le franchissement d’une transitionde F

4.3.1.1.2 La propriété F-indépendance L’objectif de la propriété F-indépendance est de per-mettre la commutativité entre les transitions de F et celles de H. Grosso modo, cette propriétésignifie que le franchissement de toute transition f de F peut être anticipé juste après le franchis-sement de h ∈ H le permettant. Ci-dessous, la définition formelle de cette propriété.

Un réseau sp-agglomérable est F-indépendant si ∀f ∈ F, ∀q ∈ (•f\p), ∀t ∈ (•q\F )

1. soit p bloque t

2. soient t et f vérifient les deux conditions suivantes :– W−(q, t) ≥ min(W+(q, t),W−(q, f))– W+(q, f) ≥ min(W−(q, f),W+(q, t))

L’hypothèse F-independance suppose que toute transition f de F peut être commutée avecdes séquences de (T0 ∪H)∗ (ou avec des séquences s de T ∗ telle que ∀s′ ∈ Pref(s),Γ(s′) ≥ 0pour la version forte). La première façon pour obtenir un tel comportement est de supposer qu’au-cune transition produisant des jetons utiles pour le franchissement de F ne peut être franchielorsque p est marquée (y compris H pour la version forte). Une seconde façon est d’imposer quela structure du réseau autour des transitions concernées soit telle que f commute avec les autrestransitions.

4.3.1.1.3 La propriété F-continuation La condition F-continuation assure qu’il existe toujoursune transition de F franchissable sitôt que p est marquée.

Un réseau sp-agglomérable (Rp,m0) est F-continu si l’une des trois conditions suivantes estsatisfaite :

1. ∃f ∈ F tel que •f = {p}2. ou ∃Fs ⊂ F tel que

– toutes les transitions f de Fs ont une seule place en entrée pf différente de p,– le problème de programmation linéaire où les variables sont {xq}q∈P , les contraintes sont

données par la positivité des variables, les invariants du réseau et par les inéquations∀pf ∈ •Fs\{p}, xpf

≤ W−(pf , f)− 1 et xp ≥ 1 n’admet pas de soulution.

3. ou ∃Fs ⊂ F tel que– ∀q ∈ •Fs, q est une place structurellement sûre (i. e. est couverte par un flot binaire positif)– ∀f ∈ Fs, ∀q ∈ •f, W−(q, f) = 1


– le problème de programmation linéaire où les variables sont {xq}q∈P , les contraintessont données par la positivité des variables, les invariants du réseau et les inéquations∀f ∈ Fs

∑q∈•f\{p} xq ≤| •f | −2 et xp ≥ 1 n’admet pas de solution.

L’objectif de cette propriété est de garantir que lorsque p est marquée, il existe une transitionf ∈ F franchissable. Les trois conditions données ci-dessus assurent un tel comportement. Lapremière condition suppose qu’il existe f ∈ F ayant pour seule entrée la place p.

La deuxième manière pour garantir ce comportement consiste à supposer (1) qu’il existe destransitions de Fs ∈ F ayant une seule place d’entrée différente de p et que (2) le marquage de p

n’est jamais bloquant pour les transitions Fs.

La section suivante présente la deuxième méthode de réduction, la pre-agglomération struc-turelle, qui peut être appliquée sur les réseaux de Pétri.

4.3.2 Pré-agglomeration structurelle

La pré-agglomération signifie que le retardement du franchissement d’une transition h ∈ Hi

jusqu’au franchissement d’une certaine transition f ∈ Fi ne modifie pas le comportement du ré-seau. Elle vise à agglomérer les transitions qui se suivent et comportent certaines similitudes.Cette transformation se distingue par rapport à la post-agglomération par le fait que les transi-tions du second groupe (le groupe F ) peuvent avoir d’autres entrées que la place p. Grâce àla pre-agglomération la structure d’un réseau de Pétri pourrait être profondément modifiée touten préservant les propriétés telles que la vivacité. La figure 4.3-(b) présente la réduction du ré-seau fourni dans la figure 4.3-(a) en utilisant cette transformation. De ce fait, la transition h estagglomérée avec les transitions f1 et f2 et elle disparaît ainsi que la place p du réseau réduit.

Cependant, afin de pouvoir pre-agglomérer un réseau, des conditions doivent être vérifiéesentre les transitions. A cet effet, cinq conditions sont nécessaires pour établir la dépendanceentre les groupes de transitions F et H et permettre ensuite la pre-agglomeration. Ces conditionset leur signification sont présentées dans la section suivante.

p

h

p2

f1f2

(a) (b)

p1

p3

p1 p2

f1f2

p3

FIGURE 4.3 – Exemple illustrant le principe de la pre-agglomération


4.3.2.1 Les propriétés de la réduction pre-agglomération

Nous présentons dans cette section les cinq propriétés requise pour la pre-agglomérationà savoir : HF-interchangeabilité, H-indépendance, la non divergence structurelle, la quasi-persistence structurelle et la H-similarité. La HF-interchangeabilité a été présentée dans la Sec-tion 4.3.1.1.1. Dans la suite nous présentons les quatre autres propriétés.

4.3.2.1.1 La propriété H-indépendance Cette propriété offre la possibilité de retarder unetransition h ∈ H franchissable. Ce retardement pourrait être prolongé jusqu’à ce que le fran-chissement des Fi dependant de h sera souhaité Ci-dessous la définition de la propriété H-independance.

Un réseau (N, m0) sp-agglomerable est H-independant si :∀i ∈ I, on note HPi = (Hi

•\{pi}),1. pi bloque HPi

•\Fi

2. si HPi•∩Fi 6= ∅ alors pi bloque Hi

La propriété H-indépendance requiert que les jetons produits par une transition h ∈ Hi (autreque ceux produits dans pi par h) ne peuvent pas être consommés par une transition n’appartenantpas à Fi lorsque pi est marquée. En outre, si des tels jetons sont consommés par une transitiont de Fi alors Hi est bloquée par pi.

4.3.2.1.2 La propriété de non divergence structurelle La propriété de non divergence struc-turelle (divergence freeness) est importante car elle permet d’écarter l’existence d’une boucle in-finie composée uniquement de transitions de H. En effet, si une telle boucle existe dans le réseauoriginel elle pourrait disparaître dans le réseau réduit étant donné que les transitions de H sontagglomérées. Ci-dessous nous donnons la définition formelle de cette propriété.

Un réseau (Rp, m0) sp-agglomérable est structurellement non divergent si ∀i ∈ I,

1. soit pi est couverte par un flot positif

2. soit ∀h ∈ Hi, ∃q ∈ •h tel que •q ⊂ T0

⋃F

L’hypothèse de la non divergence vise à écarter la possibilité d’entrer dans une boucle infiniecomposée uniquement des transitions de H. Afin d’interdire structurellement un tel comporte-ment, il faut que les places pi soient structurellement bornées (point 1) ou bien que le franchisse-ment des transitions de H requiert des jetons qui ne sont pas produits par ces mêmes transitions(point 2).

4.3.2.1.3 La propriété de quasi-persistance structurelle La propriété de la quasi-persistance garantit qu’un franchissement d’une transition de H dans le réseau originel ne conduitpas à un interblocage qui pourrait être évité en retardant ce franchissement.

Un réseau de Pétri est quasi-persistent si l’une des conditions structurelles suivantes est véri-fiée : ∀h ∈ H, ∀t ∈ (•h)•\H, alors

1. soit t ∈ T0 est une transition neutre

2. soit le problème de programmation linéaire suivant n’admet pas de solution– les variables sont {xq}q∈P ,


– les contraintes sont définies par la positivité des variables, les invariants du réseau et lesinéquations ∀q ∈ •h, xq ≥ W−(q, h) et ∀q ∈ •t, xq ≥ W−(q, t)

Si toutes les transitions de (•h)•\H vérifient le point 2 alors le réseau est fortement quasi-persistent.L’idée sur laquelle est basée la quasi-persistence est que toute transition pouvant être en conflitavec une transition h de H est soit n’a pas d’impact sur le marquage (une transition neutre), soitle conflit n’est pas effectif.

4.3.2.1.4 La propriété de H-similarité La propriété H-similarité interdit le cas où le franchis-sement des transitions de F est évité à cause d’un "mauvais" choix d’un sous-ensemble Hi.

Un réseau sp-agglomérable H-independant et quasi-persistent est H-similaire si :∀i, j ∈ I, ∀hj ∈ Hj , fj ∈ Fj , ∀hi ∈ Hi,∃fi ∈ Fi tel que ∀p ∈ •fi\{pi},W−(p, hj · fj) ≥ W−(p, hi · fi)

Les preuves de toutes ces propriétés sont données dans [32].

Après avoir donné les définitions et les significations des différentes propriétés, nous donnonsdans ce qui suit la définition formelle d’un réseau de Pétri aggloméré.

Définition 14 (Réseau de Pétri aggloméré) Soit (Rp, m0) un réseau de Pétri marqué. Suppo-sons que T = T0

⊎i∈I Hi

⊎i∈I Fi. Le réseau de Pétri réduit (Rpr,m0r ) est défini par :

– Pr = P et T = T0 ∪i∈I (Hi × Fi). hf désigne un couple (h, f) de Hi × fi ;– ∀ tr ∈ T0, ∀p ∈ Pr, W−

r (p, t) = W−(p, t) et W+r (p, t) = W+(p, t)

– ∀ i ∈ I, ∀ hf ∈ Hi×Fi, ∀ p ∈ Pr, W−r (p, hf) = W−(p, h.f) et W+

r (p, hf) = W+(p, h.f).Tel que, les matrices d’incidence W, W− et W+ sont étendues recursivement à P × T ∗ dela manière suivante :– W (p, λ) = W−(p, λ) = W+(p, λ) = 0,– Soit s = s1.t

– W (p, s) = W (p, s1) + W (p, t)– W−(p, s) = Max(W−(p, s1), W−(p, t)−W−(p, s1))– W+(p, s) = W (p, s) + W−(p, s)

– m = m0

Après avoir montré comment les réseaux de Pétri peuvent être agglomérés, nous présentonsdans ce qui suit l’état de l’art des approches d’appariement de workflows.

4.4 Appariement de workflows

Dans cette section nous nous intéressons aux différentes approches d’appariement des work-flows.

Les workflows étant modélisés par des réseaux de Pétri, leur comparaison revient donc àcomparer des réseaux de Pétri. Cette comparaison permet de statuer si deux workflows donnéssont équivalents ou pas. Cependant, il existe différentes définitions pour la notion d’équivalence.Suivant le type d’équivalence utilisé, plusieurs approches de comparaison des workflows ont étédéfinies.

4.4 Appariement de workflows 47

Le reste de cette section est organisé comme suit. Nous commençons par donner un exempleque nous utilisons pour illustrer les approches d’appariement. Ensuite, nous présentons les dif-férentes approches d’appariement des workflows. Enfin, nous les comparons afin de mettre enexergue les points forts et les points faibles de chacune d’entre elles.

4.4.1 Exemple

Dans cette section, nous présentons une version simplifiée d’un exemple de service de paie-ment de contravention par Internet. L’exemple implique un usager et le service de paiement lui-même. Les workflows modélisant la méthode de travail de l’usager et du service sont les suivants.Suite à une infraction déjà enregistrée, le service de contravention initie la communication en en-voyant une amende à l’usager. Le service accepte deux modes de paiement, chèque et cartebancaire. L’usager, quant à lui, peut recevoir une contravention et suite à la réception de celle-ci,il envoie son mode de paiement.

Les workflows de l’usager et du service de contravention peuvent être décrits de plusieursmanières. Suivant, la manière dont on les décrit, leur coopération peut conduire ou pas à un inter-blocage. Nous avons choisi de décrire chacun des deux workflows de trois manières différentesafin d’illustrer les différents cas qui peuvent se présenter.

La première description est fournie dans la figure 4.4. Dans ce cas, le service fait le choix dumode de paiement avant d’envoyer l’amende. Par contre, l’usager attend la réception de l’amendepour choisir son mode de paiement préféré.

q0 .Amende

q1

q2

Cheque

p0

p2

p3

Cheque

.

p1

Carte_bancaire

Workflowe de l’usager

Amende Amende

Carte_bancaire

Workflowe du service

S1U1

FIGURE 4.4 – Description 1 : Workflows du service et celui de l’usager

Dans la deuxième description fournie dans la figure 4.5, le workflow de l’usager et celui duservice ont la même structure . Le service de contravention, envoie l’amende et suivant le modede paiement choisi par l’usager, il exécute l’activité correspondante. Le workflow de l’usager com-mence par recevoir l’amende et choisit ensuite un mode de paiement.

La troisième description est une modification légère de la première et elle est montrée dansla figure 4.6. Dans cette description, le service de contravention, envoie l’amende et suivant lemode de paiement choisi par l’usager, il exécute l’activité adéquate. Le client, quant à lui, reçoitl’amaede et ensuite il choisit le mode de paiement qui lui convient.

Afin de pouvoir juger si le workflow de l’usager et celui du service dans chacune des descrip-tions (figures 4.4, 4.5 et 4.6) sont équivalents et donc peuvent coopérer ensemble, nous allonsexaminer les différentes notions d’équivalence des workflows. Étant donné que la compréhension


q0.Amende

q1

q2

Cheque Carte_bancaire

Workflowe de l’usager Workflowe du service

p0.Amende

p1

p2


U2 S2


p0 .Amende

p1

p2

Cheque

q0

q2

q3

Cheque

.

q1

Carte_bancaire

Workflowe du service

Amende Amende

Carte_bancaire

Workflowe de l’usager

U3 S3


de ces notions d’équivalence nécessite la construction des graphes de marquage, nous com-mençons par présenter les graphes de marquage du workflow de l’usager et celui du service decontravention fournis dans la figure 4.4. Ces deux graphes sont donnés dans la figure 4.7-(a) et lafigure 4.7-(b) respectivement. Les nœuds dans ces graphes sont appelés états et correspondentaux états possibles du workflow. Les arcs les reliant sont labélisés par les noms des activités duworkflow et on les appelle transitions. Pour passer d’un état à un autre, on franchit une transition.

.Amende

Cheque

.

Carte_bancaire

(a) (b)

S0

S1

S2

Amende


S’0

S’1S’2

Amende

S’3

FIGURE 4.7 – Graphe de marquages des workflows de l’usager (a) et du service (b)

Après avoir présenté l’exemple support utilisé dans de cette section, nous présentons dans lasection suivante les approches de comparaison des workflows.


4.4.2 Approches d’appariement comportemental des workflows

Dans la littérature nous avons identifié deux approches d’appariement comportemental desworkflows. Il s’agit de l’approche d’utilisabilité des workflows [49] et de l’approche de découvertede services en utilisant la spécification du comportement [22]. Avant d’aborder ces deux ap-proches, nous présentons dans ce qui suit les différents types d’équivalence des workflows.

4.4.2.1 Types d’équivalence des workflows

Dans ce qui suit nous présentons les trois principaux types d’équivalence existant dans lalittérature. Il s’agit de l’équivalence des traces, l’équivalence par bissimulation et l’équivalence parsimulation.

4.4.2.1.1 Equivalence des traces Deux workflows peuvent être comparés suivant leur com-portement l’un vis-à-vis de l’autre en termes de messages échangés [98]. Il s’agit, en effet, defaire une comparaison basée uniquement sur la partie du workflow visible de l’extérieur et neprenant pas en compte sa structure interne. Ce type de comparaison est appelé comparaison detraces. Dans le cas où les traces de deux workflows sont les mêmes, on dit alors que les deuxworkflows sont équivalents et qu’ils correspondent.

Prenons comme exemple le workflow de l’usager et celui du service de contraven-tion présentés dans les figures 4.4, 4.5 et 4.6. La trace du workflow de l’usager est{Amende.Cheque,Amende.Carte_bancaire} dans les trois cas. La trace du workflow du servicede contravention est {Amende.Cheque, Amende.Carte_bancaire} dans les trois cas. Il en résulteque les traces soient équivalentes et cela indépendamment de la description choisie. Notons queces traces sont obtenues à partir des graphes de marquage.

Dans le cas où l’intersection des traces de deux workflows n’est pas vide, les deux workflowsont alors au moins un comportement en commun. Il s’agit d’une forme d’équivalence de tracesplus faible que celui que nous venons de présenter. Dans notre thèse nous nous basons sur cetype d’équivalence.

Nous avons donné ici une définition informelle de la notion d’équivalence des traces. Unedéfinition formelle de celle-ci est donnée dans [33].

4.4.2.1.2 Equivalence par bissimulation L’opposé de l’approche de comparaison basée surla trace est celle qui se base sur la structure des workflows et elle porte le nom d’équivalence parbissimulation [87][40]. Dans ce type d’approche, deux workflows sont considérés équivalents s’ilsont le même comportement et la même structure interne.

En effet, un état x1 du graphe de marquage d’un workflow W1 est dit bissimulable à un état x2

d’un autre graphe de marquage d’un workflow W2 si chaque transition t franchissable à partir dex1 est aussi franchissable à partir de x2. De plus, l’état atteint x′1 après le franchissement de t àpartir de x1 doit être bissimulable à l’état x′2 atteint après le franchissement de t à partir de x2.

Deux workflows sont bissimulables si les états initiaux de leurs graphes de marquages sontbissimulables.

Pour vérifier si les workflows de l’usager et du service de contravention dans chacune destrois descriptions sont bissimulables, il convient de construire leurs graphes de marquage. A titre


d’exemple, dans la figure 4.7 nous présentons le graphe de marquage pour la première descrip-tion fournie dans la figure 4.4. L’état initial du graphe de marquage du workflow de l’usager S0n’est pas bissimulable à l’état initial du graphe de marquage du workflow du service de contraven-tion S′0. En effet, en franchissant la transition Amende à partir de S0 on atteint S1 tandis qu’en lafranchissant à partir de S′0 on atteint les états S′1 et S′2. En conclusion, les deux workflows pré-sentés dans la figure 4.4 ne sont pas bissimulables. De la même manière nous pouvons prouverque ceux donnés dans la figure 4.6 ne sont pas bissimulable non plus. Par contre les workflowsexposés dans la figure 4.5 sont bissimulables. Les différents types de bissimularité ainsi que leurpertinence pour les workflows sont fournies dans [40].

L’équivalence par bissimularité est très restrictive. En effet, nous montrons dans la sectionsuivante que deux workflows peuvent coopérer sans qu’ils soient bissimulables.

4.4.2.1.3 Equivalence par simulation Ce troisième type d’équivalence a été introduit dans[48]. L’auteur estime que la comparaison par trace est faible et que celle de la bissimulation esttrès restrictive. L’idée vient des deux constats suivants. Premièrement, il est possible que deuxworkflows aient la même trace et que leur coopération mène à un inter-blocage (par exemple lesworkflows de la figure 4.4). En effet, le service envoie la contravention après avoir choisi le modede paiement (Carte_Bancaire ou Cheque). Le service peut choisir le cheque comme mode depaiement et envoyer l’Amende à l’usager. Ce dernier voit qu’il a la possibilité de choisir le modede paiement qui lui convient et choisit par la suite de payer par Carte_bancaire. Dans ce cas lacoopération ne peut être menée jusqu’au bout.

Deuxièmement, deux workflows qui ne sont pas bissimulables peuvent coopérer sans que leurcoopération mène à un inter-blocage (par exemple les workflows de la figure 4.6). Dans ce cas,il n’y pas d’inter-blocage car le service envoie l’Amende et attend que l’usager choisit le mode depaiement pour continuer l’exécution.

L’idée de l’équivalence par simulation est guidée par ces deux constats et son objectif estd’établir des critères permettant de décider si la coopération avec un workflow donné est possibleou pas. Ces critères sont obtenus grâce la structure du graphe de communication (c-graphe)présentée dans la Section 4.4.2.2

Informellement, l’idée consiste à dire que lorsqu’un workflow contient un choix entre deuxbranches et l’exécution de l’une ou l’autre branche dépend des messages envoyés par le parte-naire, alors le choix de l’une ou de l’autre branche ne doit pas être effectué avant la réceptiondes messages provenant du partenaire. Si le choix est fait avant la réception des message, lacoopération avec le workflow en question peut mener à un inter-blocage.

Dans cette section nous avons exposé les trois types d’équivalence les plus connus et dans cequi suit nous présentons la première approche d’appariement des workflows à savoir l’utilisabilitédes workflows.

4.4.2.2 Utilisabilité des workflows

Le travail réalisé dans le cadre de cette approche est motivé par l’importance qu’ont acquisles workflows en général et les processus composés de services Web (BPEL) en particulier.

L’objectif visé est double. D’une part, fournir une méthode permettant de vérifier si un proces-sus BPEL exécutable correspond à son processus abstrait et fournir d’autre part une méthode


permettant de décider si deux workflows sont équivalents ou pas. Cette approche se base surl’équivalence par simulation. L’idée de ce type d’équivalence consiste à construire pour un work-flow W1 donné un graphe contenant tous ses comportements possibles. Ce graphe est appelégraphe de communication (c-graphe). Chaque chemin de ce graphe commençant par l’état initialest appelé une séquence de communication. Si une séquence contient un choix qui n’est pasexplicite pour les partenaires de W1, alors la coopération avec W1 peut induire un inter-blocage.

Formellement, un graphe de communication ((V , H, E), m) est un graphe orienté, fortementconnecté, étiqueté et biparti tel que

– Le graphe a deux types de nœuds : des nœuds visibles V et nœuds cachés H. Chaque arce ∈ E connecte deux nœuds de types différents.

– Le graphe a un nœud racine v0 ∈ V , chaque feuille est un nœud visible aussi.Tout arc ayant pour origine un nœud visible est étiqueté avec un ensemble de messages

envoyés aux workflows sous-jacents au graphe. Ces messages sont appelés entrées. Chaquearc ayant pour origine un nœud caché est étiqueté avec un ensemble de messages envoyé parle workflow - appelé sortie. L’algorithme de construction du c-graph est fourni dans [48, 49].

Le graphe de communication permet de décider si la coopération avec le workflow sous-jacentpeut mener à un inter-blocage. S’il peut y avoir une coopération sans inter-blocage, le workflowest appelé alors utilisable. Afin de démontrer cette utilisabilité, il suffit de trouver un sous-graphefini du graphe de communication, tel que celui-ci contient l’état initial et l’état final du c-graphe [49].Un tel sous-graphe est appelé graphe d’utilisabilité (u-graph) et un graphe de communication peuten contenir plusieurs.

Un graphe d’utilisabilité d’un workflow peut être obtenu à partir d’un graphe de communicationpar application de la stratégie de recherche en largeur d’abord. Il est possible de démontrer qu’ilpeut être obtenu même si le graphe de communication est infini [47].

Les figures 4.8 et 4.9 présentent les graphes de communications du service de contraventionprésentés dans 4.4 et 4.5 respectivement. En analysant les deux graphes, nous constatons quele graphe de communication présenté dans la figure 4.8 ne contient aucun graphe d’utilisabilité.Par conséquent, le workflow du service montré dans la figure 4.4 n’est pas utilisable. En effet, unefois que l’Amende est envoyée à l’usager et quelque soit le mode de paiement choisi par l’usager,le workflow du service peut se trouver dans un état bloquant.

Cependant, le graphe entier de la figure 4.9 est un graphe d’utilisabilité. De plus, le sous-graphe sans le nœud h2 (resp. h3) est aussi un graphe d’utilisabilité. En effet, après l’envoi del’amende le service reste dans l’état [P1] jusqu’à que l’usager choisisse le mode de paiement quilui convient.

Dans ce qui suit nous présentons une deuxième approche de comparaison de workflowsbasée sur l’équivalence des traces.

4.4.2.3 Découverte de services en utilisant la spécification du comportement

Dans [30], les auteurs proposent l’ approche Découverte de Services en utilisant la Spécifica-tion du Comportement (DSSC) pour la comparaison des services en se basant sur leurs compor-tements. Ces comportements peuvent être décrits en utilisant BPEL ou encore WSCL. L’approchecommence tout d’abord par la transformation du langage dans lequel le service est décrit en un


[Amende]

[Cheque] [Carte_bancaire]

h1

[p0] v0

[]

[p1]

[p2]

[p3]

[p3]

[p3, cq] [][]

[] []

[Cheque][Carte_bancaire]

h3

h2

h5h4

[p2, ct]

[p2, ct]

ct ~ Carte_bancaire

cq ~ Cheque

[p1, cq]

FIGURE 4.8 – Graphe de communication de la description 1 du service

[Amende]

[Cheque] [Carte_bancaire]

v1

[p0] v0

[]

[p1]

[p2]

[][]

h1

h2h3

FIGURE 4.9 – Graphe de communication de la description 2 du service


WSCLParser

Document WSCL en entrée

Document WSCL enregistré

DécompositionComparaison des graphes

Comparaison linguistique

Règles deComparaison

grapheen entrée

grapheenregistré

FIGURE 4.10 – Architecture

graphe. Ensuite, elle décompose les graphes en activité atomique. La dernière étape de l’ap-proche est la comparaison des graphes composés. Dans ce qui suit nous abordons chacune deses étapes.

L’architecture du système de comparaison est donnée dans la figure 4.10. Elle est composéed’un parseur et un module de comparaison de graphes. Le parseur transforme la conversationWSCL en un graphe dont les nœuds représentent les interactions et les arcs représentent lestransitions.

Premièrement, les protocoles des conversations à comparer sont transformés en graphes.Deuxièmement, les graphes sont développés afin d’avoir la même granularité dans les deuxgraphes et l’algorithme de comparaison présenté dans [52] est appliqué.

4.4.2.3.1 Transformation de WSCL en graphe Dans cette section, nous présentons com-ment l’approche DSSC transforme les documents WSCL en graphes. L’approche proposée peutêtre appliquée sur d’autres types de langage tant que ceux-ci peuvent être transformés engraphes d’une façon unique. Pour faciliter la compréhension de cette transformation, nous rap-pelons la structure d’un document WSCL. Une conversation WSCL contient, en effet, deux élé-ments : les interactions et les transitions.

– Interaction : les interactions représentent les actions de la conversation. WSCL comportecinq types de conversations : Send (le service envoie un document) ; Receive (le service re-çoit un document) ; SendReceive (le service envoie et reçoit des documents) ; ReceiveSend(le service reçoit et envoie des documents) ; Empty (ne contient aucun document mais il estutilisé pour marquer le début ou la fin d’une conversation)

– Transition : les transitions spécifient l’ordre entre les interactions.La transformation d’un document WSCL en un graphe se fait de la manière suivante :– Chaque interaction est représentée par un nœud dans le graphe.– Les transitions sont représentées pas les arcs du graphe.


Étant donné un document WSCL contenant deux interactions I1 et I2 et une transition T1

les reliant, sa transformation en graphe consiste à créer un graphe qui a deux nœuds (un pourreprésenter I1 et un pour représenter I2) et un arc reliant les deux nœuds pour représenter T1.

4.4.2.3.2 La décomposition des interactions L’étape qui suit la transformation de WSCL estla décomposition des graphes obtenus. La décomposition permet en effet d’avoir le même niveaude granularité pour les workflows et facilite ainsi la comparaison des workflows. Cependant, la dé-composition dépend fortement du méta-modèle des workflows à comparer. Par exemple, pour leméta-modèle de WSCL, il se peut qu’un workflow représente une activité qui envoie et reçoit parl’interaction SendReceive, tandis qu’un deuxième workflow la représente par l’interaction Sendsuivie par l’interaction Receive. La décomposition transforme toute interaction composée en in-teractions atomiques. Ainsi, l’interaction SendReceive est transformée en interaction Send suiviepar une interaction Receive tel que :

– Tous les arcs ayant pour destination l’interaction SendReceive auront pour destination l’in-teraction Send ;

– Tous les arcs ayant pour origine l’interaction SendReceive auront pour origine l’interactionReceive ;

– Un arc est ajouté entre les deux interactions Send et receive.

Si par exemple, l’interaction SendReceive avait une sortie a et une entrée b, l’interaction Sendaura la sortie a et Receive aura l’entrée b.

La décomposition de l’interaction ReceiveSend se fait de la même manière que pour l’interac-tion SendReceive.

Après avoir décomposé les graphes, l’approche propose un certain nombre de règles pour lacomparaison des graphes que nous introduisons dans la section suivante.

4.4.2.3.3 Règles de comparaison Dans cette section nous présentons les règles régissantla comparaison des graphes proposées dans [30]. Les graphes utilisés dans cette approche sontétiquetés et orientés. Un graphe étiqueté et orienté est défini par le quadruple G = (V,E, α, β) telque V est l’ensemble des nœuds, E ⊂ V ×V est l’ensemble des arcs, α : V → LV est la fonctiond’étiquetage des nœuds et β : E → LE est la fonction d’étiquetage de des arcs.

Afin de comparer les graphes modèles (les graphes enregistrés dans un annuaire) avec legraphe d’entrée (graphe requête), il est nécessaire d’avoir des opérations permettant de calculerla distance entre deux graphes. Pour ce faire, les opérations d’édition des graphes sont intro-duites. Ce genre d’opération est déjà utilisé dans la comparaison des chaînes de caractère etl’idée est de modifier les graphes modèles jusqu’à l’obtention d’un sous-graphe isomorphe augraphe d’entrée. Plusieurs types de modifications peuvent être effectués sur un graphe. Il s’agitde la suppression d’un nœud ou d’un arc, la substitution du label d’un nœud ou d’un arc parun autre label ou l’insertion d’un nouvel arc entre deux nœuds existant. Par conséquent, uneopération d’édition de graphe δ sur le graphe G peut :

– substituer le label α(v) du nœud v par l

– substituer le label β(e) de l’arc e par l′– supprimer le nœud v de G

– supprimer l’arc e de G

– insèrer un arc entre deux nœud existants


Une autre opération d’édition de graphe permet d’apparier deux nœuds. Il s’agit de l’opérationVertexMatch présentée dans l’algorithme 1. Étant donné que les nœuds représentent les interac-tions WSCL, cette opération compare donc deux interactions WSCL. Les interactions WSCL sontcomparées selon trois attributs. Il s’agit de l’identifiant de l’interaction Id, son type Type et sesdocuments D. L’algorithme donne la priorité à la comparaison des types, et si deux interactionsont le même type, il compare alors les documents (TotalSD). Dans le cas où il n’ y aucune simi-larité entre eux (TotalSD > 0), il calcule la similarité des noms des interactions (SimId) grâce àla fonction LS. Cette dernière effectue une comparaison linguistique incluant la comparaison dessynonymes et des abréviations.

La fonction SD(Di, Dj) compare les deux ensembles Di et Dj tels que Di et Dj sont lesensembles des documents de Nodei et Nodej respectivement. Les poids wd et wi indiquent lacontribution de TotalSD (similarité des documents) et SimId (similarité des noms) respective-ment dans la DistanceNode (distance entre deux interactions).

Algorithme 1 Opération de comparaison des nœuds (VertexMatch)1: INPUTS : (Nodei, Nodej) ;2: DistanceNode

3: if (Typei 6= Typej) then4: return DistanceNode = 1 ;5: else6: if (TotalSD > 0) then7: SimID = LS(Idi, Idj) ;8: DistanceNode = 1− wd ∗ TotalDS + wi ∗ SimId

wd + wi;

9: return DistanceNode ;10: else11: return DistanceNode = 1 ;12: end if13: end if

A partir du moment où l’appariement des nœuds un-à-un est effectué, l’approche DSSC pro-pose d’appliquer l’algorithme donné dans [52] pour l’appariement des comportements de deuxgraphes. Cet algorithme a une complexité exponentielle. En effet, sa complexité est de O(m2 ∗n2)dans le meilleur des cas et de O(mn ∗n) dans le pire des cas tel que m est le nombre des nœudsdu graphe d’entrée et n le nombre des nœuds du graphe enregistré dans l’annuaire.

Les auteurs parlent de la possibilité de construire un graphe correspondant au graphe d’en-trée à partir des sous-graphes disjoints des graphes modèles. En revanche, ils n’évoquent pascomment cette construction peut être faite.

4.4.3 Synthèse

Dans cette section nous avons présenté deux approches traitant de la comparaison des work-flows à savoir l’approche Utilisabilité des wokrlflows et l’approche Découverte de services enutilisant la spécification du comportement (DSSC)

D’une part, l’approche Utilisabilité des workflows fournit une méthode formelle permettant dedéterminer si la coopération de deux workflows peut être effectuée sans inter-blocage. Ceci estfait grâce aux deux structures graphe de communication et graphe d’utilisabilité. Cependant l’algo-rithme proposé par cette approche pour construire le graphe de communication a une complexité


exponentielle en termes de nombre des nœuds [48, 49]. Une fois que le graphe de communicationest généré, l’approche se focalise sur la recherche d’un sous graphe d’utilisabilité dans le graphede communication. Or, il est connu que le problème de la détection d’un sous graphe dans ungraphe est un problème NP-complet [71]. Par conséquent, la construction des graphes de com-munication et la recherche de graphe d’utilisabilité implique l’utilisation de deux algorithmes dontles complexités ne sont pas polynomiales.

D’autre part, l’approche de découverte de services en utilisant la spécification du comporte-ment [30] consiste à transformer les documents WSCL en graphes. Ensuite, à décomposer lesnœuds du graphe en des nœuds atomiques et enfin de comparer les graphes avec l’algorithmedonné dans [52]. Dans [22] les auteurs présentent une application de cette approche au langageBPEL en implémentant la stratégie présentée dans [35] pour transformer les BPELs en graphes.Cette approche met en place un framework qui prend en entrée deux conversations WSCLs etdonne en sortie une valeur numérique (entre 0 et 1) indiquant la similarité des deux WSCLs. L’al-gorithme utilisé pour comparer les graphes a une complexité de O(m2 ∗ n2) dans le meilleur descas et de O(mn ∗ n) dans le pire des cas où m est le nombre des nœuds du graphe d’entrée et n

le nombre des nœuds du graphe enregistré dans l’annuaire.

Étant donné qu’un objectif principal de cette thèse est la création d’un service de courtagedans lequel les workflows sont stockés et peuvent être recherchés, ces deux approche s’avèrentinadaptées pour plusieurs raisons. Premièrement, les algorithmes d’appariement ont des com-plexités exponentielles. Par conséquent, lorsque un partenaire souhaite rechercher un workflowéquivalent au sien dans un service de courtage contenant un nombre important de workflows, lesalgorithmes de recherche se révéleront très pénalisant. Deuxièmement, les deux approches neproposent pas des comparaisons basées sur la sémantique des activités des workflows. Enfin,ces deux approches n’offrent pas des structures efficaces permettant le stockage des workflows.Le tableau suivant récapitule les fonctionnalités des ces deux approches.

DSSC Utilisabilité Notre approcheType d’équivalence Trace Simulation Trace

Complexité de l’appariement comportemental Exponentiel Exponentiel PolynomialComplexité en espace Non Non Oui

Appariement de la sémantique métier Non Non Oui

4.5 Conclusion

Ce chapitre a commencé par présenter le formalisme des réseaux de Pétri. Ceux-ci per-mettent en effet de modéliser d’une manière claire et simple les workflows.

Nous avons ensuite présenté la technique de l’agglomération. Il s’agit d’un ensemble de trans-formations permettant de modifier la structure d’un réseau de Pétri. Dans l’optique de réduction,ces transformations sont constituées d’agglomération de transitions, plusieurs transitions étantréunies pour n’en plus former qu’une seule.

L’intérêt de l’agglomération pour les workflows provient du fait qu’elle facilite la préservationdu savoir-faire. Comme nous allons le voir dans les chapitres suivants, un workflow peut contenirun ensemble d’activités dont la présence n’est pas importante pour la coopération du workflowen question avec ses partenaires. Cependant, la suppression de ces activités doit être régiepar un certain nombre de conditions afin de préserver un ensemble de propriétés du workflow

4.5 Conclusion 57

requises pour la coopération. Grâce à la technique d’agglomération les propriétés du workflowsont préservées.

Enfin, nous avons présenté les différentes approches pour la comparaison des workflows.A nos connaissances, les approches existantes sont l’approche Utilisabilités des workflows etl’approche Découverte de services en utilisant la spécification du comportement (DSSC). Nousavons montré que les algorithmes utilisés dans ces approches sont exponentiel et par conséquentils ne sont pas adaptés pour qu’ils soient utilisés par un service de courtage comparant un nombreimportant de workflows.

L’objectif de notre thèse est de créer un annuaire et un service de courtage de workflows.Trois points doivent être prises en compte par cet annuaire à savoir la description sémantiquedes workflows, la préservation du savoir-faire des partenaires et l’appariement de workflows. Cechapitre a introduit l’état de l’art relative à la préservation du savoir-faire et à l’appariement deworkflows. Le chapitre précédent à présenté les langages existant pour la description des work-flows. La partie suivante de la thèse aborde nos contributions par rapport à ces trois aspects àsavoir la description, l’abstraction et l’appariement de workflows.

Deuxième partie

Contributions

Chapitre 5

Description sémantique deworkflows

Sommaire5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2 Exemple d'ontologie modélisant le domaine de l'assurance . . . . . 63

5.2.1 Comptabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2.2 Interaction Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.3 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2.4 Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Annotation sémantique de XPDL (SAXPDL) . . . . . . . . . . . . . . 675.3.1 Principe de l'annotation sémantique . . . . . . . . . . . . . . . . . . . . 685.3.2 Les mécanismes d'annotation . . . . . . . . . . . . . . . . . . . . . . . . 685.3.3 Annotation des documents XPDL . . . . . . . . . . . . . . . . . . . . . 705.3.4 Capacités des activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4 OWL-Ontologie pour les work�ows inter-organisationnel . . . . . . 755.4.1 Limites du méta-modèle des work�ows de WfMC . . . . . . . . . . . . . 765.4.2 Ontologie de work�ows . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.4.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.4.4 Inference sur l'ontologie des work�ows . . . . . . . . . . . . . . . . . . . 80

5.5 Synthèse et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.1 Introduction

Face à la concurrence et dans le but d’améliorer leur productivité, les entreprises expriment ungrand besoin d’ouverture et de coopération à l’échelle mondiale. Elles ont besoin de s’allier avecd’autres entreprises de compétences complémentaires afin de coopérer avec elles et réaliserdes projets qui ne sont pas à la portée d’une seule entreprise (par exemple, fusion de groupes,extensions à l’international des structures des entreprises, externalisations intensives de services,etc.). L’intégration de différents workflows partenaires dans un seul workflow global exige desefforts de coordination. En effet, les workflows de différentes entreprises doivent s’adapter à unnouveau contexte, à un nouvel environnement d’organisation et ils doivent se compléter.

61

62 Description sémantique de workflows

Afin de permettre l’automatisation de cette coopération, un mécanisme d’appariement desworkflows s’impose. Étant donné qu’un workflow est composé de deux parties : son flot decontrôle (sa sémantique comportemental) et son flot de données (sa sémantique métier), l’ap-pariement doit tenir compte de ces deux composantes. L’objectif de ce chapitre est de fournirune approche permettant la description de la sémantique métier des workflows. Cette descrip-tion est nécessaire pour réaliser l’appariement basé sur la sémantique métier. Le chapitre suivant(Chapitre 6) s’intéresse à l’abstraction structurelle et comportementale nécessaire pour réaliserl’appariement basé sur la sémantique comportementale.

En effet, pour faciliter l’appariement, il convient de trouver un moyen puissant pour modéliserles workflows. En utilisant des réseaux de Pétri pour décrire les workflows, seuls les problèmespurement syntaxiques de la composition peuvent être résolus. Les réseaux de Pétri définissent,en effet, une sémantique opérationnelle qui facilite la composition, la simulation, et la validationdes workflows. Cependant, l’absence de la sémantique métier, peut entraver la découverte desworkflows. Habituellement, plusieurs partenaires, même s’ils partagent le même domaine, ontdes vocabulaires spécifiques. De même, des entreprises travaillant dans des domaines différentspeuvent utilisés le même vocabulaire pour désigner des choses différentes. En vue d’éviter cegenre de conflits, une nouvelle approche pour la modélisation des workflows s’impose. Cettedernière doit fournir une description des workflows interprétable par des machines. Ainsi, nonseulement la syntaxe mais également la sémantique des métadonnées décrivant les workflowsest considérée lors de la découverte. Grâce aux langages de description sémantiques tels queRDF (Resource Description Framework) et OWL (Web Ontology Language) [79], une descriptioninterprétable par les machines est possible. En effet, la description sémantique permet l’automa-tisation d’un certain nombre de tâches qui sont effectuées manuellement telles que la sélection etla composition des services. Elle permet également l’inférence sur les données et par conséquentleurs modifications sans avoir besoin de les recompiler.

A l’instar des approches de description sémantique existantes pour les services Web présen-tées dans le chapitre 3.2, nous proposons dans ce chapitre une approche de description séman-tique des workflows. Cette approche est conçue pour deux types d’utilisateurs : (1) les workflowssouhaitant établir un partenariat avec d’autres workflows et (2) les concepteurs de workflows.D’une part, le workflow souhaitant coopérer avec d’autres workflows a besoin que ceux-ci par-tagent avec lui la même sémantique. Ainsi chaque workflow propose à ses partenaires une des-cription interprétable par des machines de ses fonctionnalités, des entrées qu’il requiert et dessorties qu’il produit. D’autre part, le concepteur a besoin d’exprimer des contraintes sémantiquessur les activités utilisées dans un workflow et les relations entre elles.

Pour satisfaire ces deux besoins, nous proposons ici deux types de description sémantique deworkflows. Le premier permet la découverte et la composition automatique des workflows mais nerépond pas aux besoins d’un concepteur de workflows. Ce type de description a l’avantage qu’ilne nécessite pas beaucoup d’effort pour les développeurs des workflows étant donné qu’il se basesur les langages existants. Le second type de description, quant à lui, répond aux besoins d’unconcepteur et permet également la composition automatique des workflows. Son inconvénientest qu’il requiert un effort d’apprentissage supplémentaire pour les développeurs de workflows.

Le reste de ce chapitre est organisé comme suit. Dans la section 5.2 nous commençons parprésenter un exemple d’ontologie modélisant le domaine de l’assurance. Ensuite, nous utilisonscet exemple dans la section 5.3 pour illustrer l’annotation sémantique des workflows décrits avecle langage XPDL. Dans la section 5.4 nous proposons une ontologie pour la description séman-tique des workflows. Les conclusions sont données dans la Section 5.5

5.2 Exemple d’ontologie modélisant le domaine de l’assurance 63

5.2 Exemple d’ontologie modélisant le domaine de l’assu-rance

Dans cette section nous présentons une ontologie que nous utilisons pour illustrer l’annota-tion sémantique des flots de données des workflows. L’ontologie en question décrit une partie desconnaissances propres au domaine de l’assurance -les connaissances qui peuvent être manipu-lées par un assuré et une compagnie d’assurance. Nous donnons ici seulement une partie desconcepts et les relations qui peuvent exister entre eux.

L’ontologie supérieure (voir figure 5.1) est composée de quatre services à savoir : servicede comptabilité, service d’interaction avec les assurés, service de location et service d’études.Chacun de ces services couvre un sous domaine du domaine global décrit par l’ontologie. Dansce qui suit, nous donnons le rôle de chaque service ainsi que la signification des concepts (ouclasses) les composant.

FIGURE 5.1 – Ontologie supérieure d’une compagnie d’assurance

5.2.1 Comptabilité

Cette partie de l’ontologie (voir la figure 5.2) contient tout ce qui a trait à la comptabilitéd’une compagnie d’assurance. En vue de simplifier l’ontologie, nous présentons uniquement lesconcepts susceptibles d’être utilisés par l’exemple de la section 2.4.

La classe mère dans cette partie de l’ontologie est la classe Comptabilité. Les trois classes :GestionFacture, Cotisation et Remboursement héritent de cette classe supérieur. GestionFactureest dédiée à la gestion des factures de la compagnie. Celles-ci peuvent être envoyées par unclient après la réparation de son véhicule accidenté (la classe FactureRéparationAccident) ou bienpeuvent être d’autres types de factures venant des autres services de la compagnie (la classeAutreFacture). Deux types de clients (assurés) peuvent envoyer des factures : professionnels etparticuliers. Étant donné que les factures provenant des assurés particuliers et celles provenantdes clients professionnels sont gérées différemment, nous définissons deux classes de facturesFactureParticulier et FactureProfessionnel.

La deuxième classe héritant de la classe Comptabilité est Cotisation. Cette dernière décrit lescotisations des assurés. Elle a deux sous classes VérifierCot et EncaisserCot. La première sert àvérifier l’état des cotisations d’un assuré et la seconde classe permet d’encaisser les cotisationsd’un assuré.

La troisième classe héritant de la classe Comptabilité est Remboursement. Elle décrit la ma-nière dont les remboursements sont effectués.


FIGURE 5.2 – Ontologie simplifiée de la comptabilité d’une compagnie d’assurance

5.2.2 Interaction Client

Cette partie de l’ontologie décrit les interactions qui peuvent avoir lieu entre un client (unassuré) et la compagnie d’assurance (voir la figure 5.3). En d’autres termes, elle décrit les diffé-rents messages échangés entre l’assuré et la compagnie d’assurance ainsi que les différentesactivités que l’un ou l’autre peut accomplir. La classe supérieure dans cette arborescence estInterfaceClient. Elle a deux sous classes, Operation et Message. Les deux classes, Requête-Client et RéponseCompagnie héritent de la classe Message. La première décrit les messagesenvoyés par l’assuré à la compagnie d’assurance et la seconde représente les messages quela compagnie envoie à l’assuré. Les deux classes DevisÉtabli et DéclarerAccident héritent de laclasse RequêteClient. Cette dernière classe décrit le fait qu’un assuré impliqué dans un accidentdéclare celui-ci auprès de la compagnie et la classe DevisÉtabli représente le devis qu’un as-suré peut envoyer à sa compagnie d’assurance. La deuxième classe héritant de messages estRéponseCompagnie. Celle-ci a aussi deux sous classes décrivant les réponses produites par lacompagnie d’assurance suite à la réception des messages de la part de l’assuré. La premièresous classe de RéponseCompagnie est Notification qui décrit le message accusant réceptiond’une déclaration d’accident. Ce message est envoyé par la compagnie à l’assuré. La secondesous classe de RéponseCopmagnie est AvisPourRéparation. Cette classe représente l’avis de lacompagnie d’assurance relatif à un devis préalablement envoyé par l’assuré.

La deuxième classe héritant de InterfaceClient est la classe Operation. Cette dernière a huitsous classes décrivant les activités qui peuvent être accomplies par l’assuré et/ou par la sociétéd’assurances. Ces sous classes sont : Reparer, Evaluer, Declarer, Notifier, Aviser, Estimer, Rem-bourser et Facturer. La classe Reparer décrit l’action de réparation d’une voiture. La classe Eva-luer spécifie l’opération dédiée à la gestion des dégâts d’un accident. La classe Declarer permetde décrire la création ou la réception d’une déclaration d’accident. La classe Notifier décrit l’ac-tion d’envoi des messages accusant réception d’une déclaration. La classe Aviser représente lesopérations responsables de la gestion des avis coté assuré et coté compagnie d’assurance. Pourla compagnie d’assurance, il s’agit d’envoyer un avis signalant à l’assuré qu’il peut commencer laréparation. Pour l’assuré, il s’agit de recevoir cet avis. La classe Estimer décrit l’opération d’envoiet de réception des devis. Les classes Rembourser et Facturer spécifient les actions de rembour-sement et facturation respectivement. Enfin, la propriété aParam reliant les classes Operation etMessage signifie qu’une opération peut avoir comme paramètre un message.

5.2 Exemple d’ontologie modélisant le domaine de l’assurance 65

FIGURE 5.3 – Ontologie simplifiée de l’interaction client/compagnie d’assurance

5.2.3 Location

La troisième partie de l’ontologie (voir la figure 5.4) dont la classe mère est Location, présenteun service de location auquel la compagnie d’assurance a souvent recours. Trois classes héritentde Location à savoir : Agence, Matériel et Voiture.

La classe Voiture représente les types voitures que la compagnie d’assurance est susceptiblede louer. En effet, la compagnie peut louer des voitures pour son personnel (la classe VoitPour-Personnel). Elle peut également louer des voitures pour des clients qui est subi des accidents etayant droit à une voiture de remplacement pendant la période de réparation de leur voiture (laclasse VoitPourClient). Le dernier type de voiture louée par la compagnie est les taxis (la classeTaxi). Ceux-ci sont loués pour déplacer des assurés lorsqu’il y a eu un accident.

Dans la classe Agence, sont décrites les agences chez lesquelles la compagnie louent desvoitures ou du matériel.

La relation de location entre le concept Agence d’une part et les deux concepts Voiture etMateriel d’autre part est définie dans l’ontologie respectivement par les deux propriétés loueVoitet loueMat.

5.2.4 Expert

La dernière partie décrite dans l’ontologie (voir la figure 5.5) est la description du serviceque la compagnie sollicite pour établir des rapports, évaluer les dégâts d’un accident etc. . . Laclasse supérieure dans cette branche est la classe Expert. Les domaines d’expertise auxquelsla compagnie s’intéresse sont l’immobilier, la stratégie et l’automobile. A cette fin, trois sous-classes de Expert sont créées. La première ExpAouto décrivant les experts en automobile. Un


FIGURE 5.4 – Ontologie simplifiée de ce que loue la compagnie d’assurance

expert en automobile peut être tout simplement un technicien que la compagnie désigne pourévaluer les dégâts d’un accident. La deuxième sous classe est ExpImmobilier. Elle spécifie lesexperts immobiliers qui peuvent intervenir pour le compte de la compagnie d’assurance. Un expertimmobilier est nommé par la compagnie afin de déterminer la valeur d’un bien immobilier. Il peutêtre un juriste, un technicien, un fiscaliste ou un chercheur dans tout ce qui intervient, ou danstout ce qui détermine la valeur d’un bien immobilier. Le troisième type d’experts auxquels lacompagnie d’assurance affecte des mission sont les experts en stratégie ExpStratégie. Ceux-ciélaborent des études de marché pour mieux orienter la compagnie.

Les experts préparent des rapports (classe Rapport) pour la compagnie d’assurance. Cetterelation entre les experts et les rapports est décrite à travers la propriété Etablit. Cette dernière atrois sous propriétés à savoir : effectue, evalueD et evalueI.

En effet, un rapport est soit une étude (classe Etude), soit une évaluation (classe Evaluation).Un expert en stratégie (ExpStratégie) établit des études (classe Etude). Cette relation est exprimépar la propriété effectue. Deux types d’évaluations peuvent être réalisées pour l’entreprise. Lepremier type concerne les dégâts d’un accident d’automobiles (classe DégâtAuto). Il est accomplipar un expert en automobile (classe ExpAuto). La propriété evalueD modélise cette relation. Ledeuxième type d’evaluations consiste à évaluer un bien immobilier (classe EvalImmobilier). Ilest effectué par un expert en immobilier (classe ExpImmobilier) et décrit dans l’ontologie par lapropriété evalueI.

FIGURE 5.5 – Ontologie simplifiée des domaines d’expertise de la compagnie d’assurance

L’ontologie est décrite en OWL et sa description compléte est présentée dans l’annexe A.1.

Nous utilisons cette ontologie pour annoter sémantiquement les workflows décrits en XPDL etBPEL. Dans la section suivante nous montrons l’utilisation de cette ontologie pour XPDL.

5.3 Annotation sémantique de XPDL (SAXPDL) 67

5.3 Annotation sémantique de XPDL (SAXPDL)

Lorsque le web sémantique a été introduit [11], son objectif consistait à faciliter la recherche etl’interprétation automatique des données. Cet objectif sera atteint quand il y aura des programmescapables de collecter les contenus du Web à partir de sources diverses, de traiter l’informationet d’échanger les résultats avec d’autres programmes. L’efficacité de ces programmes nécessite,en effet, la publication du contenu du Web avec des termes compréhensibles par les machines.Ceci peut être réalisé grâce aux ontologies. Une ontologie est utilisée pour la représentation desdonnées d’un modèle. Un aperçu complet sur les différentes définitions de l’ontologie peut êtretrouvé dans [55]. Une ontologie décrit les concepts d’un domaine ainsi que les relations entre cesconcepts. En d’autres termes une ontologie définit le vocabulaire commun pour des utilisateurssouhaitant partager les informations d’un domaine. Lorsqu’une ontologie est décrite, ses conceptspeuvent être rattachés à tout type de documents. Nous parlons alors d’une annotation.

Étant donné que l’un des objectifs de la sémantique est de faciliter la découverte automatiquedes workflows, l’approche que nous proposons consiste à annoter sémantiquement les compo-sants du workflow, que nous jugeons potentiellement susceptibles d’être utilisés comme critère derecherche. Il s’agit des composants décrivant les entrées/sorties des workflows, ceux indiquantle type de tâches que le workflow peut accomplir et éventuellement les participants impliquésdans le workflow. Laissons la description des flots de contrôle au langage XPDL [99] (ou aussiPNML [93]), l’approche se concentre plus sur les flux des données et les fonctionnalité des acti-vités des workflows et fournit une description sémantique pour celles-ci. Elle ajoute également lanotion de capacité aux activités

XPDL (XML Process Definition Language) est un langage de description de workflow standar-disé par le WfMC (Workflow Management Coalition) 1 et est utilisé au sein d’un grand nombre desystème de gestion de workflows. Compte tenu de sa popularité, nous proposons SAXPDL (Se-mantic Annotation for XPDL), une approche pour l’annotation sémantique de XPDL. Ce faisant,nous aspirons à ce que notre approche ait un succès semblable à celui qu’a eu SAWSDL pourles services Web. En effet, SAWSDL a été privilégié par le consortium du W3C 2 au détrimentde OWL-S et WSMO pour essentiellement deux raisons. D’une part, SAWSDL est simple à créeret permet d’utiliser tout type d’ontologie et d’autre part, il est relativement facile d’adapter lesoutils existants pour WSDL à SAWSDL et l’apprentissage de ce dernier ne nécessite pas beau-coup d’efforts pour les développeurs habitués à WSDL. De même, SAXPDL se base sur XPDLet a pour objectif de fournir une description sémantique des workflows qui sera simple à réaliser.SAXPDL permet également l’annotation sémantique des documents XPDL en utilisant tous lestypes des ontologies. Il est totalement indépendant du langage de représentation de l’ontologie.

Conscient du nombre important d’outils utilisant XPDL et pour lesquels la migration vers unautre langage sera difficile et en vue de fournir une approche qui n’implique pas la modification del’existant, nous proposons une approche incrémentale pour la description sémantique des work-flows. Dans ce qui suit, nous présentons le principe de l’annotation des workfows (section 5.3.1).Ensuite nous exposons les extensions apportées à XPDL afin qu’il supporte l’annotation séman-tique (section 5.3.2). Enfin, nous montrons comment l’annotation dans SAXPDL est réalisée surdes exemples de workflows (section 5.3.3).

1. www.wfmc.org/2. www.w3.org


5.3.1 Principe de l’annotation sémantique

Les workflows sont généralement décrits syntaxiquement avec XML. Afin de rendre séman-tique cette description , une approche consiste à rattacher les éléments XML à des conceptsdécrits dans une ontologie. Pour ce faire, une ontologie modélisant le domaine dans lequel leworkflow opère est décrite tout d’abord. Ensuite les différents éléments XML du workflow réfé-rencent les concepts correspondant dans l’ontologie. Nous présentons ici l’annotation pour XMLmais elle peut être effectuée pour d’autres langages.

La figure 5.6 montre le principe de ce type de description sémantique. Dans cet exemple nousavons une description d’un workflow contenant l’élément notif (voir figure 5.6-(a)). Ce dernier estune chaîne de caractères. Pour donner un sens précis à cet élément, on le rattache au conceptNotification dans l’ontologie (voir figure 5.6-(b)).

FIGURE 5.6 – Annotation sémantique d’un type de message dans un workflow

Ce type de description sémantique permet la découverte automatique des workflows. Grâceà une telle description sémantique, les problèmes relatifs au partage de données sont résolus.En effet, si deux workflows travaillent dans le même domaine et utilisent des noms de messagesdifférents, il suffit de rattacher les messages ayant la même sémantique aux concepts correspon-dant dans l’ontologie.

La section suivante présente le mécanisme d’annotation utilisé dans SAXPDL.

5.3.2 Les mécanismes d’annotation

Un document XPDL contient des descriptions de workflows. Chaque workflow est décrit à tra-vers des activités, des participants, des applications, des transitions et des données. Les activitésdécrivent les tâches accomplies par le workflow et reliées entre elles par les transitions. Les parti-cipants sont les ressources susceptibles d’exécuter les activités. Les applications sont les agentsou les programmes qui peuvent être associés à une activité.

Étant donné que les activités ainsi que leurs données (entrées/sorties) peuvent intervenir dansla coopération avec des workflows partenaires, nous proposons d’annoter sémantiquement cesdeux composantes de XPDL. Cette annotation facilitera la découverte et la composition automa-tique des workflows. L’annotation est faite par l’ajout de deux attributs dans SAXPDL à savoir :


– L’attribut modelReference spécifie l’association entre XPDL ou un schéma XML et unconcept dans une ontologie. Il est utilisé pour annoter une activité, une donnée ou un typed’un schéma XML.

– L’attribut schemaMapping qui permet d’établir la correspondance entre un concept dansune ontologie et un schéma XML.

Un des avantages de SAXPDL est qu’il permet de multiples annotations. Cela signifie quele même élément XPDL ou XML peut être associé à plusieurs concepts. Ainsi modelReferenceoffre la possibilité de référencer plusieurs concepts.

5.3.2.1 L’attribut modelReference de SAXPDL

Dans cette partie nous présentons la définition de l’attribut modelReference (voir la figure 5.7)ainsi que sa signification.

1 <xs:attribute name="modelReference" type="listOfAnyURI" />2 <xs:simpleType name="listOfAnyURI">3 <xs:list itemType="xs:anyURI"/>4 </xs:simpleType>

FIGURE 5.7 – Définition du schéma XML de de l’attribut modelReference

La valeur de l’attribut modelReference est un ensemble de plusieurs URIs 3 (une URI est unecourte chaîne de caractères identifiant une ressource sur un réseau (par exemple une ressourceWeb) physique ou abstraite), séparées par des espaces, qui identifient des concepts dans un mo-dèle sémantique. Chaque URI est une référence à un concept dans un modèle sémantique et estprévue pour fournir des informations sémantiques sur un l’élément XPDL ou XML l’annotant. LesURIs peuvent faire référence à des concepts décrits dans des modèles sémantiques différents.

Des exemples de l’annotation sémantique utilisant modelReference sont fournis dans la sec-tion 5.3.3.

5.3.2.2 L’attribut schemaMapping de SAXPDL

L’attribut modelReference est utilisé pour déterminer si un workflow correspond à une requêtedonnée. Une fois que la correspondance est établie, l’attribut schemaMapping est ajouté afin derésoudre des différences structurelles entre des schémas XML et les concepts sémantiques quileurs correspondent. Par exemple, supposons que le nom et le prénom de l’assuré sont décritsdans XPDL par deux éléments XML et que dans l’ontologie il y a un seul concept qui les repré-sente. Dans ce cas, le schemaMapping permet d’établir la correspondance. Pour ce faire l’attributschemaMapping référence un mécanisme effectuant la transformation nécessaire. Dans notreprototype, nous avons utilisé XSLT 4 pour effectuer cette transformation.

La définition de l’attribut schemaMapping est donnée dans le figure 5.8.

La section suivante fournit des exemples de l’utilisation des attributs modelReference etschemaMapping pour annoter XPDL.

3. http ://en.wikipedia.org/wiki/Uniform_Resource_Identifier4. http ://www.w3.org/TR/xslt


1 <xs:attribute name="schemaMapping" type="listOfAnyURI" />2 <xs:simpleType name="listOfAnyURI">3 <xs:list itemType="xs:anyURI"/>4 </xs:simpleType>

FIGURE 5.8 – Définition du schéma XML de l’attribut schemaMapping

5.3.3 Annotation des documents XPDL

FIGURE 5.9 – Workflow d’un assuré

Dans cette section nous montrons à travers des exemples comment nous avons étendu XPDLavec le nouveau attribut modelReference. Ce dernier permet d’associer une activité XPDL ou unélément XML à un concept dans une ontologie. Nous rappelons que l’ajout de cet attribut reste op-tionnel. S’il n’est pas présent, la sémantique de l’élément ne sera pas définie. Le modelReferencedétermine donc la sémantique d’une activité et/ou les entrées/sorties de celle-ci. Pour illustrercette annotation, nous avons décrit en XPDL l’exemple du workflow de l’assuré présenté dans


la Section 2.4 (voir figure 5.9). Nous donnons dans la figure 5.10 une partie de cette descriptionincluant les noms des activités. La description complète est donnée dans l’annexe A.

1 <Activity Id="1" Name="Decl">2 <Implementation>3 </Implementation>4 </Activity>5 <Activity Id="2" Name="Acc">6 <Implementation>7 </Implementation>8 </Activity>9 <Activity Id="4" Name="Dev">10 <Implementation>11 </Implementation>12 </Activity>13 <Activity Id="5" Name="Av">14 <Implementation>15 </Implementation>16 </Activity>17 <Activity Id="6" Name="Eval">18 <Implementation>19 </Implementation>20 </Activity>21 <Activity Id="8" Name="Fact">22 <Implementation>23 </Implementation>24 </Activity>25 <Activity Id="9" Name="Payer">26 <Implementation>27 </Implementation>28 </Activity>

FIGURE 5.10 – Noms XPDL des activités du workflow de l’assuré

5.3.3.1 Annotation des activités

L’annotation d’une activité sert à définir la sémantique de celle-ci et à spécifier son compor-tement. Dans l’exemple de la figure 5.11, nous donnons la définition XPDL de l’activité Decl duworkflow de l’assuré. D’après cette définition, Decl est implémentée par l’application compose-Declaration qui a deux paramètres accidInfo et declaraOut. Decl a également une transition dontl’identifiant est 1->2. Une telle définition n’indique pas le métier de l’activité.

1 <Activity Id="1" Name="Decl">2 <Implementation>3 <Tool Id="composeDeclaration" Type="APPLICATION">4 <ActualParameters>5 <ActualParameter>accidInfo</ActualParameter>6 <ActualParameter>declaratOut</ActualParameter>7 </ActualParameters>8 </Tool>9 </Implementation>10 <TransitionRestrictions>11 <TransitionRestriction>12 <TransitionRefs>13 <TransitionRef Id="1->2"/>14 </TransitionRefs>15 </TransitionRestriction>16 </TransitionRestrictions>17 </Activity>

FIGURE 5.11 – Définition XPDL de l’activité Decl

Cette définition est purement syntaxique et ne permet pas d’identifier la tâche métier accom-plie par l’activité.


Grâce à l’annotation sémantique, nous arrivons à déterminer la sémantique de l’activité. D’unepart, le concepteur du workflow sait que l’activité Decl permet de créer une déclaration d’accidentmais cette information n’est pas compréhensible par un programme. D’autre part, nous avons uneontologie (OntoAssurance montrée dans les figures 5.1, 5.2, 5.3, 5.4 et 5.5) qui quant à elle peutêtre comprise et exploitée par un programme logiciel. Cette ontologie contient la classe Declarerqui décrit une opération permettant de créer ou de recevoir une déclaration d’accident.

Par conséquent, afin qu’un programme puisse comprendre la tâche accomplie par l’activitéDecl, il suffit d’associer celle-ci avec la classe Declarer de l’ontologie OntoAssurance. Cette as-sociation est effectuée par l’ajout de l’attribut modelReference (voir figure 5.12, ligne 2).

1 <Activity Id="1" Name="Decl"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#Declarer">3 <Implementation>4 <Tool Id="composeDeclaration" Type="APPLICATION">5 <ActualParameters>6 <ActualParameter>accidInfo</ActualParameter>7 <ActualParameter>declaratOut</ActualParameter>8 </ActualParameters>9 </Tool>10 </Implementation>11 <TransitionRestrictions>12 <TransitionRestriction>13 <TransitionRefs>14 <TransitionRef Id="1->2"/>15 </TransitionRefs>16 </TransitionRestriction>17 </TransitionRestrictions>18 </Activity>

FIGURE 5.12 – Annotation sémantique de l’activité Decl

Ensuite nous annotons la deuxième activité du workflow Acc en l’associant avec la classeNotifier de l’ontologie (voir figure 5.13, ligne 2). Cette annotation permet de définir une sémantiquede haut niveau pour l’activité Acc. Grâce à cette annotation un programme logiciel comprendraque l’activité Acc envoie ou reçoit des accusés de réception.

1 <Activity Id="2" Name="Acc"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#Notifier">3 <Implementation>4 <Tool Id="recevoireAccuse" Type="APPLICATION">5 <ActualParameters>6 <ActualParameter>MsgRetourne</ActualParameter>7 </ActualParameters>8 </Tool>9 </Implementation>10 <TransitionRestrictions>11 <TransitionRestriction>12 <TransitionRefs>13 <TransitionRef Id="2->3"/>14 </TransitionRefs>15 </TransitionRestriction>16 </TransitionRestrictions>17 </Activity>

FIGURE 5.13 – Annotation sémantique de l’activité Acc

De la même manière on peut annoter le reste des activités en les associant aux classesqui leurs correspondent dans l’ontologie. Les activités Dev, Av, Eval, Rep, Fact et Payer (voirfigure 5.9) sont ainsi associées aux classes Estimer, Aviser, Evaluer, Facturer et Rembourserrespectivement.


5.3.3.2 Annotation des types de données

Comme nous l’avons souligné auparavant nous annotons deux parties du workflow, les acti-vités et les flots de données. Dans cette section nous montrons comment annoter les données.Cette annotation sera effectuée à l’aide de l’attribut modelReference. Cependant, il s’avère quedans certains cas, il est nécessaire d’utiliser une transformation afin d’établir la correspondanceentre des éléments qui ont la même sémantique mais ont des structures différentes. Pour ce fairenous avons étendu XPDL en lui ajoutant l’attribut schemaMapping.

Pour éclaircir cette notion, prenons comme exemple le type DeclarationInfo manipulé par l’ac-tivité Decl (voir figure 5.14).

1 <TypeDeclaration Id="DeclarationInfo" Name="DeclarationInfo">2 <xsd:complexType>3 <xsd:sequence>4 <xsd:element name="NomAssuré" type="xsd:string"/>5 <xsd:element name="PrénomAssuré" type="xsd:string"/>6 <xsd:element name="IdAssuré" type="xsd:integer"/>7 <xsd:element name="DateAcc" type="xsd:date"/>8 <xsd:element name="Lieu" type="xsd:string"/>9 </xsd:sequence>10 </xsd:complexType>11 </TypeDeclaration>

FIGURE 5.14 – Définition du type de donné DeclarationInfo

Le type complexe DeclarationInfo contient cinq élément à savoir : le nom de l’assuré (NomAs-suré), son prénom (PrénomAssuré), son numéro d’identification (IdAssuré), la date de l’accident(DateAcc) et le lieu de l’accident (Lieu).

Pour annoter le type DeclarationInfo nous associons celui-ci à la classe DeclarerAccident dansl’ontologie (voir figure 5.3). Ceci est effectué dans la figure 5.15.

1 <TypeDeclaration Id="DeclarationInfo" Name="DeclarationInfo" {\bf2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#DeclarerAccident"}>3 <xsd:complexType>4 <xsd:sequence>5 <xsd:element name="NomAssuré" type="xsd:string"/>6 <xsd:element name="PrénomAssuré" type="xsd:string"/>7 <xsd:element name="IdAssuré" type="xsd:integer"/>8 <xsd:element name="DateAcc" type="xsd:date"/>9 <xsd:element name="Lieu" type="xsd:string"/>10 </xsd:sequence>11 </xsd:complexType>12 </TypeDeclaration>

FIGURE 5.15 – Annotation sémantique du type de données DeclarationInfo

Avec cette annotation le type DeclarationInfo est maintenant rattaché à la classe DeclarerAcci-dent. En revanche une déclaration d’accident doit être effectuée par un assuré. Et dans l’ontolgiechaque assuré a un nom (classe Nom), un identifiant (classe identifiant), une date de naissance(classe DateNaiss) et un lieu de naissance (classe LieuNaiss). Donc dans l’ontolgie la classeNom décrit le nom et le prénom de l’assuré tandis que dans le type DeclarationInfo, le nom et leprénom sont décrit par deux éléments distincts. D’où la nécessité d’ajouter un attribut permettantde signaler que les deux éléments nom et prénom de DéclarationInfo correspondent à la classeNom de l’ontologie. Ceci est fait grâce à l’attribut schemaMapping (voir figure 5.16). schemaMap-


ping référence la feuille mapping.xslt. Cette dernière établit la correspondance entre le nom et leprénom dans la description XPDL et le concept Nom de l’ontologie.

1 <TypeDeclaration Id="DeclarationInfo" Name="DeclarationInfo"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#DeclarerAccident"3 {\bf4 saxpdl:schemaMapping="http://www.int-evry.fr/OntoAssurance/mapping.xslt>}5 <xsd:complexType>6 <xsd:sequence>7 <xsd:element name="NomAssuré" type="xsd:string"/>8 <xsd:element name="PrénomAssuré" type="xsd:string"/>9 <xsd:element name="IdAssuré" type="xsd:integer"/>10 <xsd:element name="DateAcc" type="xsd:date"/>11 <xsd:element name="Lieu" type="xsd:string"/>12 </xsd:sequence>13 </xsd:complexType>14 </TypeDeclaration>

FIGURE 5.16 – Correspondance entre la structure du DeclarationInfo et le concept grâce à sche-maMapping

Dans cette section nous avons vu comment la sémantique a été ajoutée à XPDL pour facilitersa découverte. La section suivante présente une autre extension que nous avons apporté à XPDLafin qu’il supporte la notion de capacité.

5.3.4 Capacités des activités

L’annotation sémantique des activités permet de décrire la sémantique métier de celles-ci. End’autres termes, la description sémantique définit de manière explicite la fonctionnalité accom-plie par l’activité en question. En plus de cette sémantique fonctionnelle, une activité peut avoirdifférentes capacités pour la même fonctionnalité. Dans [69] nous avons proposé d’enrichir ladescription des services Web avec la notion de capacité afin de faciliter leur découverte. Pourillustrer cette extension, prenons comme exemple l’activité Acc du workflow permettant d’envoyerun accusé de réception à l’assuré après la réception d’une déclaration. En plus de sa fonctionna-lité (l’envoi d’un accusé), cette activité peut envoyer l’accusé par SMS sur le portable de l’assuré.Elle peut également l’envoyer par email ou par courrier postal. La figure 5.17 montre un exempled’ontologie modélisant la capacité des activités.

FIGURE 5.17 – Exemple d’ontologie de capacités

La capacité est donc un moyen pour donner plus de précision sur la sémantique des activitésdes workflows. Ainsi, elle permet d’améliorer la qualité de l’appariement des workflows. L’apportde la capacité à la qualité de l’appariement est présenté dans le chapitre 7

5.4 OWL-Ontologie pour les workflows inter-organisationnel 75

Afin de rendre l’ajout de la capacité possible, nous avons étendu la description de XPDL avecl’attribut capacity. L’utilisation de cet attribut est identique à l’utilisation de l’attribut modelRefe-rence. La définition de l’attribut capacity est donnée dans la figure 5.18.

1 <xs:attribute name="capacity" type="listOfAnyURI" /> <xs:simpleType2 name="listOfAnyURI">3 <xs:list itemType="xs:anyURI"/>4 </xs:simpleType>

FIGURE 5.18 – Définition du schéma XML de de l’attribut capacity

1 <Activity Id="2" Name="Acc"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#Notifier"3 saxpdl:capacite="http://www.int-evry.fr/OntoCapacite#Email">4 <Implementation>5 <Tool Id="recevoireAccuse" Type="APPLICATION">6 <ActualParameters>7 <ActualParameter>MsgRetourne</ActualParameter>8 </ActualParameters>9 </Tool>10 </Implementation>11 <TransitionRestrictions>12 <TransitionRestriction>13 <TransitionRefs>14 <TransitionRef Id="2->3"/>15 </TransitionRefs>16 </TransitionRestriction>17 </TransitionRestrictions>18 </Activity>

FIGURE 5.19 – Annotation sémantique de l’activité Acc

Dans le cas du workflow de notre exemple, l’activité a la capacité d’envoyer l’accusé de recep-tion uniquement par email. Par conséquent, elle référence le concept Email dans l’ontologie decapacité (voir figure 5.19). Les activités ayant toutes les capacités de transmissions (SMS, emailet courrier) doivent référencer le concept père dans l’ontologie (le concept Moyens de Transmis-sion).

Cette section a présenté la première possibilité de décrire les workflows sémantiquement.Dans ce qui suit, nous présentons le deuxième mode de description sémantique.

5.4 OWL-Ontologie pour les workflows inter-organisationnel

Dans [66] nous avons proposé une ontologie pour la description sémantique des workflows.Celle-ci est motivée par le fait qu’un workflow ne doit pas être décrit uniquement pour faciliterla découverte de ses fonctionnalités. En plus de la description doit avoir comme vocation desimplifier la tâche des concepteurs en terme de maintenance des workflows, de leur évolution etde leur contrôle etc. En effet, certaines études industrielles [3] montrent que ses problématiquess’avèrent parfois plus importantes pour les entreprises que la découverte elle même.

Étant donné que de telle problèmes ne peuvent pas être résolues par l’annotation présen-tée dans la section précédente (section 5.3), nous proposons dans cette section une deuxièmedescription sémantique des workflows.


Ce deuxième type de description sémantique des workflows consiste à définir une ontologiedédiée aux workflows. Celle-ci peut être utilisée avec ou sans la description syntaxique du work-flow en question. L’avantage de ce type de description est que les workflows peuvent tirer parti dela puissance d’expression des langages de description sémantique. En effet, la description pré-sentée dans la section précédente ne permet pas de faire d’inférences sur les workflows, étantdonné que ceux-ci ne sont pas décrits sémantiquement mais font seulement référence à une des-cription sémantique. En outre, elle ne permet pas non plus de définir des relations sémantiquesentre les différentes composantes d’un workflow.

Grâce à cette deuxième description, le concepteur du workflow a la possibilité d’exprimer faci-lement des relations entre les différentes composantes du workflow. Il a également la possibilitéde faire évoluer la description de ses workflows à l’aide des règles d’inférence. Les règles per-mettent aussi de typer les workflows. Ainsi, le concepteur peut définir des règles régissant lesstructures des workflows. Le moteur d’inférence refuse la création de tout workflow non-conformeà ces règles. Par exemple, le concepteur des workflows d’une compagnie d’assurance peut sou-haiter imposer la condition suivante à certains workflows de la compagnie. Tout workflow dédié àla coopération avec les assurés doit contenir une activité qui envoie un accusé de reception pourtoute déclaration reçue. Si une telle condition n’est pas vérifiée le workflow ne doit pas être créé.

Avant de présenter l’ontologie des workflows que nous proposons (Section 5.4.2), nous ex-posons dans la section 5.4.1 les raisons justifiant le fait que le méta-modèle de cette ontologieest différent du méta-modèle des workflows proposé par le WfMC. Dans la section 5.4.3 nousdonnons un exemple de workflow sémantique et dans la section 5.4.4 nous abordons l’inférencesur les workflows.

5.4.1 Limites du méta-modèle des workflows de WfMC

La figure 5.20 présente le méta-modèle des workflows XPDL proposé par le WfMC [99]. Nousdonnons ici une brève présentation de ce méta-modèle.

Un workflow (process) possède plusieurs attributs (date, auteur. . .), et contient plusieurs acti-vités, transitions, participants qui vont permettre de spécifier toutes les étapes du workflow et tousles participants, qu’il s’agisse d’acteurs humains ou d’applications. Une activité effectue une tâcheparticulière dans le workflow et elle est réalisée par un acteur humain ou une application. Elle estreliée à d’autres activités via les transitions. Enfin, les activités peuvent accéder aux données duworkflow.

Ce méta-modèle ne répond pas à nos besoins pour la découverte des workflows pour deuxraisons. D’une part, il contient des informations que nous jugeons inutiles pour les partenairestelle que les ressources utilisées et les applications réalisant les activités. Par conséquent, ces in-formations ne doivent pas être publiées dans un annuaire. En effet, rappelons que l’ontologie desworkflows est faite, entre autres, pour décrire les workflows qui seront publiés dans un annuaireafin qu’ils soient découverts par les partenaires. D’autre part, certaines informations nécessairespour la coopération ne sont pas décrites dans ce méta-modèle. En effet, chaque activité a unefonctionnalité particulière (elle accomplit une tâche donnée). Cependant seules les activités co-opératives sont impliquées directement dans la coopération. Ainsi, il est nécessaire de distinguerdans l’ontologie entre les activités coopératives et les activités internes. Cette distinction n’estpas faite dans le méta-modèle de WfMC (voir figure 5.20). Il est également nécessaire de fairela différence entre les entrées qu’une activité reçoit et les sorties qu’elle produit. Cela permet,


FIGURE 5.20 – Méta-modèle des workflows XPDL

par exemple, d’établir la correspondance entre deux activités dont l’une consomme une entréeproduite par l’autre.

La section suivante présente l’ontologie que nous proposons pour la description sémantiquedes workflows.

5.4.2 Ontologie de workflows

L’ontologie que nous proposons ici (voir la figure 5.21) fournit les informations nécessairespour la découverte des workflows ainsi que celles requises par le concepteur telles que la capacitéd’exprimer des relations entre les activités et l’inférence sur les workflows.

Un worklow (classe Workflow) est composé (propriété estComposeDe) d’un ensemble de sé-quences et/ou d’un ensemble d’activités. Une séquence (classe Sequence) est composée d’unensemble d’activités. Cette propriété est transitive (c’est à dire que les activités composant uneséquence d’un workflow, sont des activités du workflow).

Nous avons également ajouté une classe Disponibilité. Celle-ci est utile pour le concepteur duworkflow car elle lui permet de spécifier si un workflow, une séquence ou une activité donnée estdisponible et dans ce cas il peut être découvert par les partenaires. La propriété aDisponibiliterelie un workflow, une séquence ou une activité avec une disponibilité. La classe Disponibilité estcaractérisée par une date de fin de disponibilité (aDateFin) et une variable booléenne indiquantl’état de la disponibilité (aEtatDispo). Un workflow, une séquence ou une activité est indisponible


FIGURE 5.21 – Ontologie des workflows

quand la valeur de aEtatDispo est faux et il est disponible sinon. Lorsque la date de fin de dis-ponibilité est atteinte la valeur de cette variable est mise automatiquement à faux. Cependant, ilse peut que la valeur de aEtatDispo soit à faux tandis que la date de fin de disponibilité n’est pasatteinte.

Nous avons deux types d’activité : coopérative et interne (classes Cooperative et Interne).Une activité a une transition de départ (propriété transDe) et une transition d’arrivée (propriététransVers). Une activité peut être reliée à une autre activité (propriété estReliee). La sémantiquede cette dernière relation diffère d’un domaine à un autre mais dans le cas général sa significationest la suivante. Si l’activité A est reliée (estReliee) à l’activité B et A reçoit un message, alorsB répond au message reçu par A. Une autre relation pouvant exister entre deux activités estnonDansMemeWorkflow. Elle signifie que les deux activités ne doivent pas appartenir au mêmeworkflow. L’appartenance d’une activité à un workflow est définie par la propriété estDans. Lapropriété nonCoopDansMemeWorkflow est utilisée lorsque nous souhaitons indiquer que deuxactivités coopératives ne peuvent pas être coopératives dans le même workflow.

Une activité a également un paramètre (propriété aParametre) qui peut être en entrée (classeEntree) ou en sortie (classe Sortie).

Pour faciliter la lisibilité de l’ontologie, les relations d’héritage entre les propriétés ne sont pasmontrées sur la figure 5.21. Celles-ci sont données dans la figure 5.22. La propriété aParametrea deux sous propriétés aEntree et aSortie (voir la figure 5.22-(a)). La propriété nonDansMeme-Workflow indiquant que deux activités données ne peuvent coexister dans le même workflow, aune sous propriété (voir la figure 5.22-(b)) nonCoopDansMemeWorkflow précisant, quant à elle,que deux activités données ne peuvent pas être coopératives dans le même workflow.

Cette ontologie définit un workflow et ses caractéristiques de base. Grâce au moteur d’infé-rence (reasoning), d’autres caractéristiques spécifiques à un domaine donné peuvent être ajou-tées. Dans la section suivante nous donnons un exemple de workflow instanciant cette ontologie.


FIGURE 5.22 – Hiérarchie des propriétés de l’ontologie des workflows

5.4.3 Exemple

FIGURE 5.23 – Instance de l’ontologie : Workflow de l’assuré

Les figures 5.23, 5.25 et 5.24 montrent une instance de l’ontologie des workflows. Cette ins-tance est la description sémantique du workflow de l’assuré (Section 2.4). Le workflow AssWork-flow est composé de deux séquences SeqAvecEval et SeqSansEval (voir la figure 5.23). La sé-quence SeqAvecEval contient toutes les activités et la séquence SeqSansEval contient toutesles activités sauf l’activité Eval. Les activités Decl, Acc, Dev, Av, Eval, Fact et Payer sont desinstances de la classe Cooperative (voir la figure 5.24). Les activités Etablir_Dev et Rep sont desinstances de la classe Interne (voir la figure 5.24). La sortie de Decl est DeclarInfo (une instancede la classe Sortie). Les activités Dev et Fact ont respectivement les sorties DevisInfo et Factu-reDetail (voir la figure 5.25). Les activités Acc, Avis, Eval et Payer ont respectivement les entrées(des instances de la classe Entree) accuseRecep, AvisRep, evaluationDegat et recuTransfert (voirla figure 5.24). L’activité Acc envoie un accusé signalant la prise en compte de la déclaration parl’activité Decl. Les deux activités Decl et Acc sont donc reliées (propriété estReliee).

Après avoir présenté un exemple d’instance de l’ontologie, nous présentons dans la sectionsuivante l’inférence sur l’ontologie.


FIGURE 5.24 – Instance de l’ontologie : les activités et leurs entrées

FIGURE 5.25 – Instance de l’ontologie : les activités et leurs sorties

5.4.4 Inference sur l’ontologie des workflows

L’inférence fournit un moyen puissant aux concepteurs des workflows en leur permettant d’en-richir ou modifier dynamiquement l’ontologie des workflows sans avoir besoin d’écrire explicite-ment les modifications dans l’ontologie. Le processus d’inférence est déclenché à chaque chan-gement dans les données de l’ontologie.

En effet, certaines informations relatives aux workflows changent durant le cycle de vie deceux-ci ou ne sont pas connues au départ. D’une part, les informations telles que la disponibilitéd’un workflow dépendent des éléments le composant. La disponibilité d’un workflow est détermi-née, entre autres, à partir de la disponibilité des séquences et activités composant le workflow.Aussi, la disponibilité des séquences dépend également de celle des activités les composant.Par conséquent, le changement dans l’état de disponibilité des activités doit se répercuter sur ladisponibilité des séquences et des workflows les contenant. Ce type de modification peut êtreeffectué dynamiquement sur l’ontologie grâce à l’inférence.

D’autre part, certaines informations ne pouvant pas être décrites dans l’ontologie étant donnéqu’elles sont propres à un domaine ou un type de workflows donné, nécessitent d’être ajoutées.L’inférence permet de rajouter ce type d’information à une ontologie décrite auparavant. La pre-mière utilisation de l’inférence est donc de faire évoluer les workflows.


Une autre utilisation de l’inférence est celle consistant à l’utiliser pour contrôler la conformitéd’un workflow à un certain nombre de règles bien définies. L’inférence est alors utilisée pour lacompilation (la vérification de leur structure par rapport un certain nombre de règles) de workflow.

Dans ce qui suit nous présentons un ensemble de règles que nous avons identifié pour lesworkflows. Le premier type de règles est général et ne dépend pas d’un domaine d’applicationparticulier. Le deuxième type de règles contient des règles métier. Celles-ci concernent un do-maine d’application bien spécifié.

5.4.4.1 Règles générales

Dans cette section nous proposons un ensemble de règles permettant de faire évoluer lesworkflows. Ces règles sont applicable à tout type de workflow.

La règle donnée dans la figure 5.26 exprime la transitivité de la propriété estComposeDe pourles workflows. Si un workflow W est composé, entre autre, d’une séquence S et S elle-même estcomposée, entre autre, de l’activité A, alors W est composé (propriété estComposeDe), entreautre, de l’activité A. Grâce à cette règle le concepteur du workflow n’a pas besoin de décrireexplicitement dans l’ontologie que W est composé de A.

1 @prefix pre: <http://www-inf.int-evry.fr/OntWorkflow.owl#>.23 # Règle transitive4 [TransitiveEstComposeDe: (?W rdf:type pre:Workflow)5 (?W pre:estComposeDe ?S) (?S rdf:type pre:Sequence)6 (?S pre:estComposedDe ?A) -> (?W pre:estComposeDe ?A) ]

FIGURE 5.26 – Règle exprimant la transitivité de la propriété estComposeDe

Les règles présentées dans la figure 5.27 définissent la symétrie entre les deux propriétésestComposeDe et estDans. Elles signifient que si un workflow est composé (propriété estCompo-seDe) d’un ensemble d’activités, alors ces activités appartiennent (propriété estDans) au workflowet vice-versa.

1 @prefix pre: <http://www-inf.int-evry.fr/OntWorkflow.owl#>.23 # Règle symetrique4 [SymetricIsComposedOf: (?W rdf:type pre:Workflow) (?A rdf:type pre:Activite)5 (?W pre:estComposeDe ?A) -> (?A pre:estDans ?W) ]67 # Règle symétrique8 [SymetricEstDans: (?W rdf:type pre:Workflow) (?A rdf:type pre:Activite)9 (?A pre:estDans ?W) -> (?W pre:estComposeDe ?A) ]

FIGURE 5.27 – Règle définissant la symétrie entre la propriété estComposeDeet la propriété estDans

Dans la figure 5.28 nous définissons deux règles reliant la propriété correspondA et estReliee.La première règle (correspondA) signifie que si une activité A a une entrée x et qu’elle est reliée(propriété estReliee) à une activité B ayant la sortie y, alors y correspond (propriété correspondA)à x. Par exemple, dans le workflow de l’assuré (5.9) l’activité Acc a été déclarée comme étantreliée à l’activité Decl étant donné qu’elle reçoit un accusé correspondant à la déclaration envoyéepar l’activité Decl. Cette règle permet de déduire que AccuseRecep (entrée de Acc) correspondau DeclarInfo (sortie de Decl).


La deuxième règle (EstReliee) est l’inverse de la première. Elle signifie que si la sortie d’uneactivité B correspond à l’entrée d’une activité A, alors A est reliée à B.

1 @prefix pre: <http://www-inf.int-evry.fr/OntWorkflow.owl#>.23 # Règle de définition4 [CorrespondA: (?X rdfs:subClassOf pre:Activite) (?A rdf:type ?X)5 (?A pre:estReliee ?B) (?A pre:aEntree ?x)6 (?B pre:aSortie ?y) -> (?y pre:correspondA ?x) ]78 # Règle de définition9 [EstReliee: (?y rdf:type pre:Parametre)10 (?y pre:correspondA ?x) (?A pre:aEntree ?x)11 (?B pre:aSortie ?y) -> (?A pre:estReliee ?B) ]

FIGURE 5.28 – Règles pour les propriétés estReliee et correspondA

Les règles données dans la figure 5.29 définissent la disponibilité d’une activité, d’une sé-quence et d’un workflow dans notre cadre. Grâce à la première règle, une activité est rendueautomatiquement indisponible lorsque sa date de fin de disponibilité est atteinte. La méthodeV erifierV alidite(?Date) vérifie si une date est supérieure à la date actuelle (courante) et re-tourne vrai si c’est le cas. Sinon elle retourne faux. La méthode RendreIndisponible(?X) remetla valeur de aEtatDispo correspondant à l’activité à faux et met à jour les séquences auxquellesl’activité appartient.

La deuxième règle (estDisponibleS1) associe une disponibilité à toute séquence qui n’en apas grâce à la méthode DefinirDispo(?S). Si l’état de disponibilité (aEtatDispo) de toutes lesactivités est vrai, la séquence est alors disponible. De plus, la date de fin de disponibilité de laséquence est celle de l’activité ayant la date de fin la plus proche.

Nous imposons, à travers la troisième règle (estDisponibleS2), la disponibilité de toutes lesactivités composant une séquence pour que celle-ci soit disponible. Lorsque l’une des activitésn’est pas disponible, cette règle a comme effet de rendre la séquence indisponible.

La dernière règle (estDisponibleW) indique qu’un workflow devient disponible lorsqu’il contientau minimum une séquence disponible. La date de fin de disponibilité du workflow est celle dela séquence ayant la date de fin la plus proche. La méthode DefinirDispo(?W ) définit cettedisponibilité pour le workflow.

5.4.4.2 Règles métier

Comme nous l’avons expliqué auparavant, le but de la description sémantique est non seule-ment de permettre la découverte automatique des workflows mais également de contrôler leurcréation et de faciliter leur maintenance. En effet, l’une des étapes précédant le développementdes workflows est celle qui consiste à créer les activités. L’utilisation de ses activités doit êtrecontrôlée (par exemple, deux activités données ne doivent pas être dans le même workflow).En vue de faciliter ce contrôle, nous proposons dans cette section des règles permettant à unconcepteur de workflow d’imposer une forme bien définie à ses workflows. La liste de règlesque nous donnons n’est pas exhaustive mais l’avantage de l’inférence est que d’autres règlespeuvent être ajoutées facilement selon le besoin. Notons que cette catégorie de règles dépenddu domaine d’application du workflow.

La première règle impose que lorsque une instance du workflow contient une activité quireçoit un message, il faut obligatoirement que cette instance contienne au moins une activité


1 @prefix pre: <http://www-inf.int-evry.fr/OntWorkflow.owl#>.23 # Règle de définition4 [estDisponibleA: (?X rdfs:subClassOf pre:Activite) (?A rdf:type ?X)5 (?A pre:aDisponibilite ?Dis) (?Dis pre:aDateFin ?Date)6 VerifierValidite(?Date) -> RendreIndisponible(?A) ]78 # Règle de définition9 [estDisponibleS1: (?S rdf:type pre:Sequence)10 noValue(?S pre:aDisponibilite)-> DefinirDispo(?S) ]1112 # Règle de définition13 [estDisponibleS2: (?S rdf:type pre:Sequence)14 (?S pre:estComposeDe ?A) (?A pre:aDisponibilite ?Dis)15 (?Dis pre:aEtat ?Etat) equals(?Etat, false) -> RendreIndisponible(?S) ]161718 # Règle de définition19 [estDisponibleW: (?W rdf:type pre:Workflow)20 (?W pre:estComposeDe ?S) (?S rdf:type pre:Sequence)21 (?S pre:aDisponibilite ?Dis) (?Dis pre:aEtat ?Etat)22 equals(?Etat, true) -> DefinirDispo(?W) ]2324

FIGURE 5.29 – Règles pour définir la disponibilité d’un workflow

répondant à ce message. Sinon le workflow n’est pas valide et ne sera pas créé. Par exemple,le concepteur des workflows d’une compagnie d’assurance peut souhaiter imposer la conditionsuivante à certains workflows de la compagnie. Tout workflow dédié à la coopération avec lesassurés doit contenir une activité qui envoie un accusé (activité Acc) de reception pour toutedéclaration reçu par l’actvité Decl. Si une telle condition n’est pas vérifiée le workflow ne doit pasêtre créé.

1 @prefix pre: <http://www-inf.int-evry.fr/OntWorkflow.owl#>.23 # Règle de définition4 [ValiditeWorkflow1: (?W rdf:type pre:Workflow)5 (pre:Acc pre:estDans ?W) (pre:Decl pre:estDans ?W)6 noValue(pre:Decl pre:estReliee pre:Acc) -> WorkflowNonValid(?W) ]

FIGURE 5.30 – Règles conditionnant la validité d’un workflow

La deuxième règle (figure 5.32) impose qu’un workflow contenant deux activités ne pouvantpas être coopératives en même temps, ne doit pas être créé. Cette règle peut être généraliséepour le cas où les deux activités ne peuvent pas coexister dans le même workflow. Ce genre derègle est utilisé par exemple pour les activités représentant des services proposant des offresnon cumulables. Afin de l’illustrer, prenons l’exemple de la figure 5.31 dans lequel nous avonsune activité d’offre de bienvenue (OffreBienvenue). Cette activité est proposée par une compa-gnie d’assurance aux assurés ayant assuré plus de deux voitures et n’ayant pas commis desaccidents. Les deux types d’offres de bienvenue existants sont le remboursement de la cotisa-tion du premier mois (activité RembourserPremierMois) et l’envoi d’un chèque cadeau (activitéChequeCadeau). Le même assuré ne peut pas cumuler les deux offres. Donc, les deux activi-tés RembourserPremierMois et ChequeCadeau ne doivent pas être coopératives dans le mêmeworkflow. La règle (figure 5.32) vérifie cette contrainte.

Pour implémenter ces règles nous avons utilisé des fonctions procédurales prédéfinies dansJena [36] comme lessThan ( ?x, ?y) (retourne vrai si la valeur de x est inférieure à la valeur de


FIGURE 5.31 – Exemple d’activités ne pouvant pas être coopératives dans le même workflow

1 @prefix pre: <http://www-inf.int-evry.fr/OntWorkflow.owl#>.23 # Règle de définition4 [nonCoopDansMemeWorkRule:5 (?W rdf:type pre:Workflow) (pre:RembourserPremierMois pre:estDans ?W)6 (pre:EnvoyerChequeCadeau pre:estDans ?W) -> WorkflowNonValid(?W) ]

FIGURE 5.32 – Règles conditionnant la validité d’un workflow

y) ou notEqual( ?x, ?y) (retourne vrai si les deux variables sont différentes). Étant donné que l’ex-pressivité de Jena est limitée (des fonctions comme not ou l’opérateur existentiel n’existent pas),nous avons implémenté des fonctions spécifiques telle que VerifierValidite( ?Date), RendreIndis-ponible( ?X), DefinirDispo( ?X). Nous avons également développé la méthode WorkflowNonVa-lid( ?W) qui affiche un message d’erreur au développeur du workflow et détruit les workflows nonvalides. Les détails de ces implémentations sont fournis dans le chapitre 8.

5.5 Synthèse et conclusion

Ce chapitre a présenté deux approches de description sémantique des workflows. La premièreapproche (SAXPDL) consiste à prendre une description existante d’un workflow et l’annoter àl’aide d’une ontologie décrivant un domaine donné. Nous avons illustré cette approche sur lelangage de description de workflow XPDL. La deuxième approche (Ontologie de workflows) dedescription des workflows proposé dans ce chapitre consiste à créer une ontologie dédiée auxworkflows.

Chacune de ces approches a des avantages et des inconvénients. En effet, l’approcheSAXPDL est incrémentale. Elle a l’avantage d’être simple à réaliser et aussi elle ne nécessitepas beaucoup d’effort pour les développeurs habitués au langage XPDL. De plus, les systèmesde gestion de workflows basé sur XPDL (Il y en a plus de 70) peuvent être facilement adaptés afinde prendre en compte SAXPDL. SAXPDL n’est pas limité à un langage de description d’ontologieparticulier. Il peut référencer toute ontologie indépendamment de son langage de description.

Cependant SAXPDL présente quelques inconvénients. D’une part, SAXPDL ne permet pas dedéfinir des relations entre les différentes composantes d’un workflow étant donné celui-ci n’est pasdécrit sémantiquement mais fait seulement référence à une description sémantique. D’autre part,SAXPDL n’offre pas la possibilité d’apporter des modifications dynamiques sur les workflows. Eneffet, certaines données relatives aux différentes composantes d’un workflow changent durant le

5.5 Synthèse et conclusion 85

cycle de vie de celui-ci. Ces changements ont un impact sur le workflow et doivent être pris encompte. Un exemple de ces données est la disponibilité d’une activité. Lorsque cette disponibilitéchange, cela peut avoir un impact sur la disponibilité du workflow.

Les deux inconvénients de SAXPDL que nous venons d’évoquer sont des avantages de ladeuxième approche OWL-ontologie pour les workflows. Cette dernière approche consiste à écrireune ontologie dédiée aux workflows. Elle permet d’exprimer des relations entre les différentescomposantes d’un workflow. Grâce à l’inférence, des modifications peuvent être apportées à l’on-tologie dynamiquement. L’inférence permet également d’imposer des contraintes sur la structurede certains workflows. Ainsi, il fournit un moyen de contrôler les workflows.

L’inconvénient majeur de l’approche OWL-ontologie pour les workflows est qu’elle nécessiteplus d’effort pour les développeurs habitués à XPDL étant donné qu’il s’agit d’une descriptioncomplètement différente. Le deuxième inconvénient de cette approche est que les ontologiesutilisées doivent être des ontologies OWL ou RDFS.

Chacune des approches a un contexte où elle est la plus adéquate. Par exemple, si le besoinest seulement de partager des données pour éviter des conflits pouvant exister dans une descrip-tion syntaxique, l’approche SAXPDL est suffisante. Si par contre, il y a une nécessité de contrôlerles workflows et de les faire évoluer, l’approche OWL-ontologie est plus appropriée. Le tableausuivant récapitule les avantages et inconvénients de chacune des approches.

SAXPDL OWL-Ontologie pour les workflowsType d’ontologie accepté Tous OWL/RDFSDécouverte automatique oui oui

Incrémental oui nonContrôle des workflows non ouiExprimer des relations non oui

entre les éléments d’un workflowEvolution dynamique des workflows non oui

Chapitre 6

Abstraction structurelle etcomportementale de workflows

Sommaire6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.2 Graphe de marquage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.3 Abstraction structurelle . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3.1 Préservation de la trace du work�ow projetée sur ses activités coopératives 916.3.2 Formalisation des règles d'abstraction dé�nies dans [15] . . . . . . . . . 916.3.3 Deuxième catégorie de règles d'abstraction . . . . . . . . . . . . . . . . 96

6.4 Abstraction comportementale . . . . . . . . . . . . . . . . . . . . . . . 1026.4.1 Construction des graphes d'observation symboliques . . . . . . . . . . . 1036.4.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.4.3 Préservation du langage . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.1 Introduction

Le développement des technologies de l’information et de la communication a permis aux en-treprises d’automatiser leurs procédés et d’adopter des systèmes de workflow pour les réaliser.Dans ce contexte, les entreprises focalisent sur leurs compétences et accèdent aux autres com-pétences via la coopération, créant une nouvelle forme de réseau appelée les organisations vir-tuelles. Afin de supporter la coopération, on doit s’occuper des problèmes tels que la préservationde workflow préétablis et le respect de savoir-faire. En effet, la coopération a besoin d’un certaindegré d’inter-visibilité afin d’accomplir les interactions et l’échange des données. Néanmoins, lacoopération peut être utilisée comme couverture pour internaliser le savoir-faire des partenaires.Pour préserver le savoir-faire et l’autonomie, on doit réduire l’inter-visibilité de workflow au strictminimum que la coopération exige.

Un workflow inter-organisationnel peut être considéré comme la coopération de plusieursworkflows locaux. Chacun a deux types d’activités (transitions) : activités coopératives qui in-teragissent avec les autres workflows et activités locales qui effectuent des actions locales. Afind’établir une coopération, les workflows doivent être abstraits afin de préserver le savoir-faire, et

87

88 Abstraction structurelle et comportementale de workflows

doivent être publiés dans un annuaire pour qu’ils puissent être découverts et interconnectés avecles workflows partenaires. Dans ce chapitre nous nous intéressons à l’abstraction des workflows.

L’abstraction, en général, est une transformation permettant la simplification d’un système.Dans la cadre des workflows, il s’agit de la suppression d’un ensemble d’activités dont la présencedans le workflow n’est pas importante pour la coopération du workflow en question avec sespartenaires. La suppression de ces activités implique la suppression des flots de contrôle qui leursont directement liés.

L’application de l’abstraction sur un workflow est régie par un certain nombre de conditions etelle doit préserver un ensemble de propriétés du workflow. Les workflows étant modélisés sousforme de réseau de Pétri [85, 8, 25, 27, 91, 54], les conditions de l’abstraction peuvent porter surla structure (modèle) du workflow ou sur le graphe des marquages sous-jacent. La propriété àpréserver par l’abstraction est la trace du workflow projetée sur ses activités coopératives.

Suivant le cas où l’abstraction est appliquée sur la structure (modèle) du workflow ou sur legraphe de marquage sous-jacent, nous distinguons deux types d’abstraction : abstraction struc-turelle et abstraction comportementale. L’abstraction structurelle est appliquée sur la structure duworkflow. Ses conditions d’application portent sur la structure tel que les invariants du workflow.

L’abstraction comportementale, quant à elle, est effectuée sur le graphe des marquages duworkflow. Ses conditions d’application portent des propriétés comportementales telles que le ca-ractère borné.

Le reste de ce chapitre est organisé comme suit. La Section 6.2 présente un rappel sur lanotion de graphe de marquage. Dans la Section 6.3 nous présentons une méthode d’abstrac-tion structurelle. La Section 6.4 est consacrée à la deuxième méthode d’abstraction à savoir :l’abstraction comportementale. Enfin, nous donnons quelques conclusions dans la section 6.5.

6.2 Graphe de marquage

Étant donné un marquage initial d’un réseau de Pétri, l’ensemble des marquages accessiblesde ce réseau, n’est autre que l’ensemble des situations possibles du réseau de Pétri durant sonévolution en partant du marquage initial.

Le graphe de marquage permet de représenter l’évolution du réseau de Pétri. Il s’agit d’ungraphe orienté dont les sommets sont étiquetés par des marquages et dont les arcs sont étiquetéspar des transitions.

Nous avons adapté la technique des graphes de marquage au contexte des workflows enreprésentant le workflow par un Wf-net fini associé à un marquage initial m0. La description dumarquage est représentée par un vecteur fixe de variables booléennes.

L’algorithme 2 représente l’un des nombreux algorithmes de construction de graphe de mar-quage d’un réseau de Pétri proposés dans la littérature [53]. Nous signalons ici, que nous sommesindépendant de l’algorithme de construction de graphes de marquage.

Les structures de données utilisées par l’algorithme 2 sont un tableau Accessibles pour en-registrer l’ensemble des marquages accessibles d’un réseau de Pétri et un tableau A_Explorerpour sauvegarder les marquages qui ne sont pas complètement traités.

6.2 Graphe de marquage 89

Deux fonctions sont utilisées, Pre() et Post(). Pre() prend en entrée une transition t et retourneun vecteur, dont les lignes correspondent aux différentes places du workflow, indiquant les condi-tions d’entrée de franchissement de la transition t. Chaque ligne pi du vecteur correspond au coûtde l’arc menant de la place pi à la transition t. S’il existe un arc entre pi et t, son coût par défautvaut 1. Dans le cas contraire, (il n’existe pas d’arc reliant pi à t), le coût vaut 0.

Post() prend en entrée une transition t et retourne un vecteur, dont les lignes correspondentaux différentes places du workflow, indiquant les conditions de sortie de franchissement de latransition t. Chaque ligne pi du vecteur correspond au coût associé à l’arc menant de la transitiont à la place pi. Comme dans le cas de Pre, s’il existe un arc menant de t à pi, son coût par défautvaut 1. S’il n’existe pas d’arc relant t et pi alors ce coût vaut 0.

Le principe de l’algorithme consiste, à partir d’un marquage initial du réseau de Pétri corres-pondant au workflow d’un partenaire, à déterminer l’ensemble des marquages accessibles. Ainsi,pour un marquage donné M , on cherche s’il existe des transitions ti franchissables (lignes 9 à17). Dans le cas positif, on calcule un nouveau marquage M ′ résultat du tir de ti (ligne 11). Si M ′

n’a pas déjà été traité (ligne 12), on l’ajoute à l’ensemble de marquages accessibles (ligne 13)et à celui des marquages à explorer (ligne 14), respectivement. On réitère la procédure jusqu’autraitement de tous les marquages (A_explorer = ∅).

Algorithme 2 Construction du graphe de marquage1: ConstruireGM (marquage m0) ;2: set Accessibles = {marquage_intial} ;3: set A_Explorer = {marquage_initial} ;4: marquage M ;5: marquage M’ ;6: while (A_explorer) 6= ∅ do7: M = un marquage élement de “A_explorer” ;8: A_explorer = A_explorer - {M} ;9: for toutes les transitions t du réseau do

10: if M > Pre(t) then11: M’ = M + Post(t) - Pre(t) ;12: if M’ /∈ Accessibles then13: Accessibles = Accessibles ∪ {M’} ;14: A_explorer = A_explorer ∪ {M’} ;15: end if16: end if17: end for18: end while

En appliquant l’algorithme de construction de graphe de marquage sur le workflow de l’assuréet de la société d’assurance donnés dans la section 2.4, nous obtenons les graphes de la figure6.1-(a) et de la 6.1-(b) successivement.

La construction détaillé du graphe de marquage est donnée dans l’annexe A.

Après avoir présenté les graphes de marquage, l’étape suivante consiste à introduire le pre-mier type d’abstraction à savoir : l’abstraction structurelle.


FIGURE 6.1 – Les graphes de marquages de l’assuré (a) et d’une société d’assurance (b)

6.3 Abstraction structurelle

Partant de l’abstraction informelle définie dans [15], nous proposons dans cette section uneformalisation de cette abstraction. A la différence de l’approche introduite dans la section précé-dente, la formalisation proposée ici est structurelle étant donné qu’elle se base sur le modèle duworkflow et non pas sur les graphes des marquages.

En effet, l’abstraction donnée dans [15] a été définie en termes de huit règles. Il n’a pas étéprouvé que l’application des ses règles sur un workflow préserve la trace de celui-ci projeté surses activités coopératives. Nous proposons dans cette section l’utilisation de la technique del’agglomération présentée dans le chapitre 4 afin d’effectuer l’abstraction. Comme nous l’avonsmontré, l’agglomération préserve les formules linéaires temporelles (LTL) et la trace du workflowprojetée sur ses activités coopératives est une formule LTL.

Compte tenu du fait que trois des huit règles peuvent être généralisée afin de couvrir un éven-tail plus large de workflows, nous proposons trois autres règles à leurs places. Nous définissonségalement une catégorie particulière des workflows et nous prouvons que l’abstraction de cettecatégorie préserve la trace du workflow en question projeté sur ses activités coopératives. Cettepreuve est réalisée grâce à deux propositions et leurs démonstrations.

L’organisation du reste de cette section est la suivante. Dans la Section 6.3.1, nous présentonsla propriété de trace du workflow projetée sur ses activités coopératives ainsi que sa définitionen tant que formule de la logique linéaire temporelle. Dans la Section 6.3.2 nous formalisons lesrègles d’abstraction tirée de la thèse de Issam Chebbi [15]. Enfin, nous présentons les règlesd’abstraction que nous avons définies dans la Section 6.3.3.

6.3 Abstraction structurelle 91

6.3.1 Préservation de la trace du workflow projetée sur ses activités co-opératives

La préservation par l’abstraction de la trace du workflow projeté sur ses activités coopérativesest une propriété fondamentale pour notre travail. Celle-ci signifie que toute séquence d’activitédans le workflow originel, sa projection (la définition de la projection est donnée ci-dessous) surles activités coopératives existe dans le workflow abstrait.

Soit σ ∈ T ∗ une séquence d’activités. La projection de σ sur un ensemble d’activités X ⊆ T

(notée σbX ) est la séquence obtenue en supprimant de σ toute les activités n’appartenant pasà X. La projection est étendue à un ensemble de séquences de la manière suivante : LbX ={σbX , σ ∈ L}.

Soient le workflow W et Wab le workflow obtenu après l’abstraction de W . Formellement, lapréservation de la trace du workflow W projeté sur ses activités coopératives signifie que :

∀σ ∈ LbTcoop(W ) ⇒ σ ∈ L(Wab)

La trace du workflow projetée sur ses activités coopératives est une formule de la logiquetemporelle linéaire (LTL). Pour le démontrer, nous prenons un cas particulier et ensuite nousgénéralisons.

Le workflow donné dans la figure 6.2 est celui de l’assuré de notre exemple support. Latrace de ce workflow projeté sur ses activités coopératives est {Decl.Acc.Dev.Av.Eval.Fact.Payer,Decl.Acc.Dev.Av.Fact.Payer}. Cette trace contient deux séquences d’activités. Les activitésde chaque séquence seront exécutées séquentiellement. Cela signifie qu’en premier lieul’activité Declaration est exécutée, ensuite l’activité Accuse est exécutée et ainsi de suite.Ce séquencement peut être exprimé par l’opérateur X (next) de la logique temporelle li-néaire. Par exemple la séquence {Decl.Acc.Dev.Av.Eval.Fact.Payer} est exprimée en LTL par{Decl ∧ X Acc ∧ X Dev ∧ X Av ∧ X Eval ∧ X Fact ∧ X Payer}

Étant donné que la trace d’un workflow est composé d’un ensemble de séquences d’activités,pour démontrer que chaque séquence peut être exprimée sous forme d’une formule LTL, nouspouvons adopter la même démarche que celle adoptée pour l’exemple de l’assuré.

Il en résulte donc que toute séquence d’activités peut être exprimée sous forme d’une formuleLTL et par conséquent la trace est l’union d’un ensemble de formules LTL.

Après avoir définie la propriété que nous souhaitons préserver lors de l’abstraction, nousprésentons dans la section suivante les règles d’abstraction définies dans la thèse de IssamChebbi [15] ainsi que leur formalisation.

6.3.2 Formalisation des règles d’abstraction définies dans [15]

L’abstraction structurelle que nous proposons est effectuée grâce à deux types de règles. Lepremier type de règles a été défini dans [15]. Dans cette section nous présentons ces règles etnous proposons une méthode pour les formaliser.

Étant donné un workflow Wi(Pi, Ti, Fi), les activités de Wi sont réduites en se basant sur lesrègles suivantes :


FIGURE 6.2 – Le workflow de l’assuré

Règle 1 (Abstraction d’activités internes séquentielles) ∃ ti, tj ∈ T, pij ∈ P oùP = {p1, . . . , pij , . . . , pn}P’ = P-{pij}T = {t1, . . . , ti, tj , . . . , tm}T’ = T - {ti}F = {f1, . . . , (ti, pij), (pij , tj), . . . , fk}F’ = F - ({(ti, pij), (pij , tj)} ∪ {(pk, ti)/pk ∈ •ti}) ∪ {(pk, tj)/pk ∈ •ti}C = seq(ti, tj , pij), ti ∈ Tint et tj ∈ Tint

Regle1 :(P, T, F ), C(P ′, T ′, F ′)

ti

tj

Pij ti

FIGURE 6.3 – Abstraction d’activités internes séquentielles


Informellement, la définition de la règle 1 est la suivante. Si une activité interne ti est liée àune autre activité interne tj via une place pij , alors on élimine l’activité tj et la place pij d’unepart, et les flots entre ti et tj et ceux sortant de tj , d’autre part. Ensuite, on crée un nouveau flotqui liera les places appartenant à tj• à ti (voir figure 6.3).

Afin de garantir que cette règle peut être appliquée tout en préservant la trace du workflowprojetée sur ses activités coopératives, nous allons utiliser la technique pré et post-agglomération.En réduisant le workflow avec cette technique, nous obtenons le même workflow que celui obtenuà l’issue de l’application de la règle1.

En prenant H = ti et F = (tj), nous remarquons que le workflow est p-agglomerable autourde pij étant donné que chaque séquence de franchissement contenant tj , contiendra forcémentti. Le workflow est également sp-agglomerable (la définition des propriétés p-agglomerable etsp-agglomerable est donnée dans la section 12). En effet :

1. m0(pij) = 0, •pij = ti, pij•=tj

2. W+(pij , ti) = W−(pij , tj) = 1

Étant donné que le workflow est sp-agglomerable, nous allons voir s’il vérifie les conditionsde post-agglomeration. Si c’est le cas, nous pouvons éliminer la transition tj tout en étant sûrque le workflow obtenu après cette réduction a la même projection de la trace sur les activitéscoopératives que le workflow originel.

1. HF-interchangeable : | H |= 1. Donc cette propriété est vérifiée ;

2. F-independence : •tj = pij . Donc q = •tj \ pij = ∅. Et par conséquent t ∈ •q = ∅. Donc pij

bloque t et on en déduit que la propriété F-independence est vérifiée ;

3. F-continuation : Etant donné que •tj = pij , F est donc continuable.

Compte tenu du fait que les transitions ti et tj vérifient les conditions de la post-agglomeration,nous pouvons par conséquent les agglomérer. De ce fait, la transition tj disparaîtra et nous obte-nons ainsi le même workflow que celui obtenu après l’application de la règle 1.

Règle 2 (Abstraction d’activités internes et coopératives séquentielles) ∃ ti, tj ∈ T, pij ∈ PoùP = {p1, . . . , pij , . . . , pn}P’ = P-{pij}T = {t1, . . . , ti, tj , . . . , tm}T’ = T - {ti}F = {f1, . . . , (ti, pij), (pij , tj), . . . , fk}F’ = F - ({(ti, pij), (pij , tj)} ∪ {(pk, ti)/pk ∈ •ti}) ∪ {(pk, tj)/pk ∈ •ti}C = seq(ti, tj , pij), ti ∈ Tint et tj ∈ Tcoop

Regle2 :(P, T, F ), C(P ′, T ′, F ′)

Lorsqu’on dispose d’une activité interne ti liée à une activité coopérative tj via une place pij ,alors on élimine l’activité ti et la place pij d’une part, et tous les flots existant entre ti et tj ( (ti,pij) et (pij , tj)) et ceux entre •ti et ti, d’autre part. Ensuite, on ajoute de nouveaux flots reliant lesplaces appartenant à •ti à l’activité tj (voir figure 6.4).


FIGURE 6.4 – Abstraction d’activités internes et coopératives séquentielles

D’une part, le workflow donné dans la figure 6.4 est post-agglomérable. Ceci peut être dé-montré de la même manière que pour le workflow présenté dans la figure 6.3. D’autre part, laformalisation de la règle 2 est identique à celle de la règle 1. Donc la trace du workflow projetésur les activités coopératives est préservée par cette règle.

Règle 3 (Abstraction d’activités alternatives suivies d’une seule activité interne) ∃ bi ∈Tint, bj ,. . . bk ∈ Tcoop, pi, pj et pk ∈ P oùP = {p1, p2, . . . , pk, . . . , pn}P’= P-{pj}T = {. . . , bi, . . . , bm}T’ = T - {bi}A = {f1, . . . , (bl, pj), (pj , bi), (bi, pk), . . . , fk, l ∈ {j, . . . , k}}A’ = F - {(pj , bi), (bi, pk), (bl, pj), l ∈ {j, . . . , k}} ∪ {(bs, pk), s ∈ {j, . . . , k}}C = alt(bj , . . . , bk, pi, pj)

Regle3 :(P, T, A), C(P, T ′, A′)

Pj

bj b(j+1)

Pk

bi

bk

Pi

Pk

bj b(j+1) bk

Pi

FIGURE 6.5 – Abstraction d’activités alternatives suivies d’une même activité interne

La règle 3 illustre le cas d’un ensemble d’activités alternatives suivies d’une seule activitéinterne. Dans ce cas de figure, nous enlevons l’activité interne, la place qui la relie aux activitésalternatives ainsi que tous les arcs se trouvant entre les activités alternatives et la place de sortie


de l’activité interne. Ensuite, nous ajoutons des arcs qui lient les activités alternatives à la placede sortie de l’activité interne. La figure 6.5 montre le workflow originel (à gauche) et celui obtenuaprès l’application de règle 3 (à droite).

Étant donné que cette règle n’est pas formelle, notre objectif est de la formaliser grâce à latechnique de post et pré-agglomeration. En partant du workflow originel nous assurons qu’il vérifieles propriétés de l’agglomération et ensuite nous y appliquons la post ou la pré-agglomerationsuivant les propriétés qu’il vérifie.

Soient H = bj bj+1 . . . bk et F = bi. Il est facile de démontrer que ce workflow est p--agglomérable. Nous remarquons que le workflow est également sp-agglomerable autour de pj .En effet :

1. m0(pj) = 0, •pj = bjbj+1 . . . bk, pj•=bi

2. W+(pi, bl) = W−(pi, bi) = 1, ∀l ∈ {j, j + 1, . . . k}Étant donné que la sp-agglomerabilité est vérifiée, nous examinons les propriétés de la post-

agglomeration. Si ces dernières sont satisfaites, nous éliminerons alors l’activité bi.

1. HF-interchangeable : | F |= 1. Par conséquent la HF-interchangeabilité est vérifiée ;

2. F-independence : •bi = pj . Donc q = •bi \ pj = ∅. Et par conséquent t ∈ •q = ∅. Donc pj

bloque t et on en déduit que la propriété F-independence est vérifiée ;

3. F-continuation : Étant donné que •bi = pj , F est donc continuable.

Vu que le workflow originel satisfait à toutes les conditions de la post-agglomeration, nous pou-vons par conséquent supprimer l’activité bi. Ainsi, nous obtenons en résultat le workflow montrédans la figure 6.8-(b).

Règle 4 (Abstraction d’une activité interne suivie d’activités alternatives) ∃ bi ∈ Tint, bj ,. . .bk ∈ Tcoop, pi, pj et pk ∈ P oùP = {p1, p2, . . . , pj , . . . , pn}P’= P-{pj}T = {b1, . . . , bi, . . . , bm}T’ = T - {bi}A = {f1, . . . , (pi, bi), (bi, pj), . . . , fk}A’ = F - {(pi, bi), (bi, pj)} ∪ {(pi, bl), l ∈ {j,. . .,k}}C = alt(bj , . . . , bk, pj , pk)

Regle4 :(P, T, A), C(P, T ′, A′)

A travers la règle 4 on définit que lorsqu’on dispose d’une activité interne suivie d’activitésalternatives, nous enlevons l’activité interne ainsi que tous les flots qui lui sont directement liés,la place qui la relie aux activités alternatives et les arcs qui sont liés à cette dernière. Ensuite,nous ajoutons des arcs qui lient la place d’entrée de l’activité interne aux activités alternatives(voir figure 6.6).

Cette règle peut être démontrée de la même manière que la règle 3.

Dans cette section, nous avons présenté le premier type de règles sur lesquelles nous nousbasons pour abstraire les workflows. La section suivante se focalise sur le deuxième type derègles.


Pj

Pi

bi

bj b(j+1) bk

Pi

bj b(j+1) bk

FIGURE 6.6 – Abstraction d’une activité interne suivie d’activités alternatives

6.3.3 Deuxième catégorie de règles d’abstraction

Nous présentons dans cette section les règles que nous avons définies pour l’abstractiondes workflows. L’objectif de ce deuxième type de règles est de permettre d’abstraire un plusgrand nombre de workflows étant donné que les règles précédemment définies se limitent à desworkflows très particuliers.

Certaines des règles que nous avons définies ne peuvent pas être formalisées par la tech-nique l’agglomération. Afin de les formaliser nous avons besoin de définir et démontrer une nou-velle propriété des workflows. Cette propriété est présentée dans la section 6.3.3.1. Dans lasection 6.3.3.2 nous présentons les règles d’abstraction.

6.3.3.1 Propriété particulière des workflows

Dans cette section, nous nous intéressons à une catégorie particulière de workflows. Il s’agitdes workflows dont la structure est donnée dans la figure 6.7. Ensuite nous présentons quelquespropriété de cette catégorie de workflows sous forme de propositions et nous donnons la dé-monstration de chaque proposition.

La définition formelle de cette catégorie de workflows est la suivante. Soit le workflow W ∈CategorieW . La structure de W = (P, T, A) est donnée dans la figure 6.7. W est composé detrois sous workflows W1 = (P1, T1, A1), W2 = (P2, T2, A2) et W3 = (P3, T3, A3). W vérifie :

– i ∈ P1 (la place racine i du workflow appartient à P1)– ∀t1 ∈ T1, ∀t2 ∈ T2, p′ ∈ t1

• et p′ ∈ •t2 ⇒ p′ = pl1 ( W1 et W2 sont lié via une seule placepl1)

– ∀t1 ∈ T1, t1•∈P1 et •t1 ∈ P1

– ∀t2 ∈ T2,∀t3 ∈ T3, p′ ∈ t2• et p′ ∈ •t3 ⇒ p′ = pl2 ( W2 et W3 sont lié via une seule place pl2)

– ∀t2 ∈ T2, t2•∈P2 et •t2 ∈ P2

– o ∈ P3 (la place finale du W appartient à l’ensemble P3 de W3)– ∀t3 ∈ T3, t3

•∈P3 et •t3 ∈ P3

– ∀(p, t) ∈ Pi × Tj , i ∈ {1, 3}, j ∈ {1, 3}, i 6= j ⇒ W−(p, t) = 0 et W+(p, t) = 0 (W1 n’est paslié à W3)


W1

W2

pl

W3

1

pl2

FIGURE 6.7 – Union des traces des workflow

Avant de présenter les propositions, nous introduisons quelques fonctions.

La première fonction que nous définissons est la fonction de concaténation Concat. Cettedernière permet de concaténer des transitions, des séquences de franchissement ainsi qu’unetransition et des séquences de franchissement. Soient σ, σ1, σ2 . . . σn des séquences de franchis-sement et t1, . . . , tn des transitions.

Concat(σ1, σ2, σ3) = Concat(Concat(σ1, σ2), σ3) = σ1.σ2.σ3

Nous notons par Trace(W ) la fonction qui retourne la trace du workflow W . A partir de cesdéfinitions nous faisons la proposition suivante :

Proposition 1 Soit W = (P, T,A),∈ CategoriW . La trace du workflowW est égale à la concatenation des traces des workflow les composantsTrace(W ) = Concat(Trace(W1), T race(W2), T race(W3))

Démonstration 1 La proposition 1 signifie que :∀σ ∈ Trace(W ) alors σ = σ1.σ2.σ3 tel que σ1 ∈ Trace(W1), σ2 ∈ Trace(W2) et σ3 ∈ Trace(W3)

Soit σ = a1 . . . an ∈ Trace(W )Étant donné que la place i ∈ P1 et la place o ∈ P3, alors a1 ∈ T1 et an ∈ T3.Soit ai la première transition de σ appartenant à T1 et se trouvant après a1 tel que ai ∈ T1 et(ai

•)• /∈T1 (il est possible que ai = a1)Soit aj la première transition de σ appartenant à T3 et se trouvant avant an tel que aj ∈ T3 et•(•aj) /∈ T3 (il est possible que aj = an)


σ = a1 . . . ai.ai+1 . . . aj−1.aj . . . an. Prenons σ1 = a1 . . . ai, σ2 = ai+1 . . . aj−1 et σ3 = aj . . . an.Par définition σ1 ∈ Trace(W1) et σ3 ∈ Trace(W3). Montrons que σ2 ∈ Trace(W2). Pour ce faire, ilnous suffit de démontrer que ai+1 est la première transition de W2, aj−1 est la dernière transitionde W2 et que toute toute transition entre ai+1 et aj−1 appartienne à T2.

Tout d’abord montrons que ai+1 ∈ T2 et aj−1 ∈ T2. Soit ai•=p′. p′ ∈ P1 et p′ /∈ T1 ⇒ p′ = pl1.

Donc p′•∈T2 et par conséquent, ai+1 ∈ T2.

Montrons que aj−1 ∈ T2. Soit •aj = p′. p′ ∈ P3 et •p′ /∈ T3 ⇒ p′ = pl2. Donc aj−1 ∈ T2

Prouvons maintenant que ∀ak tel que ai+1 . . . ak . . . aj−1 alors ak ∈ T2.

Supposons que ak /∈ T2. Alors ak ∈ T1 ∪ T3. Il y a donc deux cas de figure :

1. Cas 1 : ak ∈ T1. Soit ar la première transition de σ appartenant à T1 et se trouvant avantak telle que ar ∈ T1 et •(•ar) /∈ T1. Soit p′ = •ar et ar−1

•=p′ (ar−1 6= ∅ puisque ak estprécédée au moins par une transition n’appartenant pas à T1 qui est ai+1). ar ∈ T1 ⇒p′ ∈ P1 ⇒ ar−1 ∈ T1, ce qui est une contradiction. Donc ak /∈ T1 (ak ne peut pas appartenirà T1).

2. Cas 2 : ak ∈ T3. De la même manière nous pouvons prouver que ak /∈ T3

Il en résulte que ak appartient forcément au T2 (ak ∈ T2).

Nous pouvons déduire donc que σ2 = ai+1 . . . aj−1 ∈ Trace(W2). Et par conséquent :

σ = σ1.σ2.σ3 = Concat(σ1, σ2, σ3)

Proposition 2 Soit W = (P, T,A) ∈ CategorieW . La projection de la trace du W est égale à laconcaténation des projections des traces des workflows W1, W2 et W3.Soit σ = σ1.σ2.σ3 avec σ1 ∈ Trace(W1), σ2 ∈ Trace(W2) et σ3 ∈ Trace(W3). Prouvons que pourX ⊆ T , σbX = σ1bX .σ2bX .σ3bX

Démonstration 2 σ ∈ Trace(W ) et σ = σ1.σ2.σ3.Soit σ = a1 . . . an, σbX = ak . . . am et σ1bX .σ2bX .σ3bX = al . . . ar. Prouvons que ak . . . am =al . . . ar. Pour ce faire, nous allons prouver que ak . . . am ⊂ al . . . ar et que al . . . ar ⊂ ak . . . am

1. ak . . . am ⊂ al . . . ar.Par définition ak ∈ σ ∩ X ⇒ ∃i ∈ {1, 2, 3} tel que ak ∈ σi ∩ X. Donc la séquence al . . . ar

contient ak. Par conséquent σ1bX .σ2bX .σ3bX = al . . . ak . . . ar.D’autre part am ∈ σ ∩ X ⇒ ∃i ∈ {1, 2, 3} tel que am ∈ σi ∩ X. Donc la séquence al . . . ar

contient am. Par conséquent σ1bX .σ2bX .σ3bX = al . . . ak . . . am . . . ar.

2. al . . . ar ⊂ ak . . . am. La preuve de cette inclusion est identique à la précédente preuve.

Après avoir défini cette catégorie de workflow, nous présentons dans la section suivante lesrègles régissant l’abstraction.

6.3.3.2 Règles d’abstraction

Étant donné un workflow Wi(Pi, Ti, Fi), les activités de Wi sont réduites en se basant sur lesrègles suivantes :

Règle 5 (Abstraction d’activités internes alternatives )


Pi

Po

f1 f3f2Po

(a) (b)

h1 h2h1 h2’’h2 h1’ h2’ h1’’

P3

P3

FIGURE 6.8 – Abstraction d’activités internes alternatives

A travers la règle 5 nous définissons que lorsque nous disposons d’un workflow W conte-nant plusieurs activités alternatives,H (H = {h1, . . . , hn}), reliées à plusieurs activités internesalternatives F = {f1 . . . fn} via une place pi, nous agglomérons les deux ensembles H et F . Lerésultat de cette agglomération est, d’une part la suppression des transitions de F , de la placepi ainsi que tous les flots de contrôle qui leur sont directement liés et d’autre part, la création de| H | ∗ | F | transitions. Ce dernier groupe de transitions est appelé H ′. Dans notre cas, nousdupliquons les transitions de H, | F | fois pour obtenir les transitions de H ′.

Pour illustrer cette règle, nous prenons un exemple de workflow où H contient deux transitions,h1 et h2, et F contient trois transitions f1, f2 et f3 (voir figure 6.8-(a)). Les groupes H et F sontliés via la place Pi. Le résultat de l’application de la règle 5 sur ce workflow est le workflow donnédans la figure 6.8-(b). Les transitions h′1 et h′′1 ont la même sémantique que h1. Les transitions h′2et h′′2 ont la même sémantique que h2.

Nous allons démontrer, grâce à la post-agglomération qu’en transformant le workflow de tellemanière, la trace de celui-ci projetée sur ses activités coopératives reste préservée. Pour cefaire, il nous suffit de prouver que le workflow est post-agglomerable autour de pi. D’abord, nouscommençons par démontrer qu’il est p-agglomerable et ensuite sp-agglomerable. Enfin, nousexaminons les propriétés de la post-agglomerabilité.

Le workflow 6.8-(a) est p-agglomerable.

Soit σ = σ1σ2tiσn.

1. σ2 ∈ •(•ti)

2. •ti = pi Et •pi = {h1 . . . hn}3. 1. et 2. ⇒ σ2 ∈ {h1 . . . hn}Et par conséquent, chaque séquence σ contenant une transition ti, contient forcément une

transition hi. Donc le workflow est p-agglomerable.

Soient Hi = •pi et Fi = b1 b2 b3 . . . bn. Nous remarquons que le workflow est sp-agglomerableautour de pi. En effet :

1. m0(pi) = 0, •pi = Hi, pi•= b1 b2 b3 . . . bn

2. W+(pi, h) = W−(pi, bk) = 1, ∀h ∈ Hi et k ∈ {1, 2, 3, . . . n}Étant donné que la sp-agglomerabilité est vérifiée pour le workflow originel, nous examinons

les propriétés de la post-agglomeration. Si ces dernières sont satisfaites nous éliminerons lesactivités b2 b3 . . . bn.


1. HF-interchangeable : ∀bi, b′i ∈ FiW

−(pi, bi) = W−(pi, b′i). En effet cette propriété est satis-

faite puisqu’elle vérifie la condition (3) des conditions de la HF-interchangeabilité ;

2. F-independence : •bk = pi, k ∈ {1, 2, 3, . . . n}. Donc q = •bk \ pi = ∅. Et par conséquentt ∈ •q = ∅. Donc pi bloque t et on en déduit que la propriété F-independence est vérifiée ;

3. F-continuation : Étant donné que •b2 = pi, F est donc continuable.

Vu que le workflow originel satisfait toutes les conditions de la post-agglomeration, nous pou-vons par conséquent supprimer les activités f1 f2 . . . fn. Ainsi, nous obtenons en résultat leworkflow montré dans la figure 6.8-(b).

Règle 6 (Abstraction d’activités internes et sous workflow alternatives)

Po

Wi

fnf1

(a) (b)

Pi

Po

Wi

f1

WPi

FIGURE 6.9 – Abstraction d’activités internes et sous workflow alternatives

A travers cette règle, nous définissons que lorsqu’un workflow W est composé d’un ensembled’activités internes (f1. . . fn) et un sous workflow Wi alternatives (Wi peut contenir des activitéscoopératives ou internes), nous supprimons toutes les activités internes fi telles que i ∈ {2 . . . n}.La figure 6.9 montre un exemple d’application de cette règle.

Nous allons maintenant démontrer que la règle 6 préserve la trace du workflow W projetéesur ses activités coopératives.

Trace(W ) = {Trace(Wi), f1, f2, . . . , fn}La trace de W projetée sur ses activités coopératives est :Trace(W )bTCoop

= {Trace(Wi), f1, f2, . . . , fn}bTCoop

Étant donné que f1, f2 . . . fn sont internes, Trace(W )bTCoop= {Trace(Wi)}bTCoop

∪ {∅}.Compte tenu du fait que f1 est interne Trace(W )bTCoop

= {Trace(Wi), f1}bTCoop.

D’autre part, la trace du workflow (voir figure 6.9-(b)) obtenue après l’application de la règle 6est {Trace(Wi), f1}.

Par conséquent, la trace du workflow W (voir figure 6.9-(a)) projetée sur ses activités coopé-ratives est identique à celle du workflow obtenu après l’application de la règle (voir figure 6.9-(b)).Donc la règle 6 préserve la trace du workflow projeté sur ses activités coopératives.


Règle 7 (Abstraction d’activités internes et coopératives alternatives) ∃ b1, b2, . . . bj ∈ Tint,bj+1, bj+2, . . . bn ∈ Tcoop, pi, po ∈ P oùT = {b1, . . . , bj , bj+1, . . . , bn}T’ = T - {b1, b2, . . . , bj}A = {f1, . . . , (pi, b1), (b1, po), . . . , (pi, bj), (bj , po), . . . , fk}A’ = A - {(pi, b1), (b1, po), . . . , (pi, bj), (bj , po)}C = alt(b1, b2, . . . , bn, pi, po) et b1, . . . , bj ∈ Tint

Regle7 :(P, T, A), C(P, T ′, A′)

Pi

Po

bj bnb(j+1)b1

Pi

Po

bnb(j+1)b1

(a) (b)

W1

W2

W3

W1

W3

h2h1h1 h2

FIGURE 6.10 – Abstraction d’activités internes et coopératives alternatives

Dans la règle 7, nous définissons que lorsque nous disposons d’un ensemble bi, i ∈ {1, . . . , j}d’activités internes qui sont alternatives à un ensemble d’activités coopératives bk, k ∈ {j+1, . . . ,n}, alors nous éliminons toutes les activités internes bi, i ∈ {2, . . . , n} ainsi que tous les flots decontrôle qui leur sont directement liés (voir la figure 6.10).

Afin de démontrer que cette règle pourrait être appliquée tout en préservant la trace du work-flow projetée sur ses activités coopératives, nous procédons comme suit.

Le workflow W présenté dans la figure 6.10-(a) est composé de de trois sous workflows W1,W2 et W3. D’après la proposition 1Trace(W ) = Concat(Trace(W1), T race(W2), T race(W3))= Concat(Concat(Trace(W1), T race(W2)), T race(W3))=Concat(Concat(Trace(W1), h1.b1, . . . , h1.bj , h1.bj+1, . . . , h1.bn, h2.b1, . . . , h2.bj , h2.bj+1, . . . , h2.bn), T race(W3))

La projection de la trace du workflow W sur ses activités coopératives est :Trace(W )bTcoop

= Concat(Trace(W1), T race(W2), T race(W3))bTcoopbTcoop. D’après la proposition


2 la projection et la trace sont commutatives. DoncConcat(Trace(W1), T race(W2), T race(W3))bTcoop

= Concat(Trace(W1)bTcoop, T race(W2)bTcoop

, T race(W3)bTcoop).

Étant donné que b1 . . . bj sont internes, alors

Concat(Trace(W1), T race(W2), T race(W3))bTcoop

=Concat(Concat(Trace(W1)bTcoop

, h1, . . . , h1, h1.bj+1, . . . , h1.bn, h2, . . . , h2, h2.bj+1, . . . , h2.bn), T race(W3)bTcoop)

=Concat(Concat(Trace(W1)bTcoop

, h1, h1.bj+1, . . . , h1.bn, h2, h2.bj+1, . . . , h2.bn), T race(W3)bTcoop)

D’autre part la trace du workflow de la figure 6.10-(b) est :Concat(Concat(Trace(W1)bTcoop

, h1, h1.bj+1, . . . , h1.bn, h2, h2.bj+1, . . . , h2.bn), T race(W3)bTcoop)

Par conséquent la trace du workflow W (figure 6.10-(a)) projeté sur ses activités coopérativesest identique à la trace du workflow de la figure 6.10-(b) et ainsi la règle 7 préserve cette propriété.

La section suivante présente l’abstraction comportementale des workflows.

6.4 Abstraction comportementale

La section précédente a présenté une méthode structurelle pour l’abstraction des workflows.Dans cette section nous présentons une deuxième méthode comportementale, basée sur la tech-nique de graphe d’observation symbolique, permettant également l’abstraction des workflows..

Étant donné un workflow W = (P, T, A), l’abstraction comportementale du W consiste àconstruire tout d’abord le graphe de marquage sous-jacent. Ensuite, à supprimer toutes les ac-tivités internes apparaissant dans une séquence de franchissement. Cela permettra, en effet, àune entreprise de cacher le savoir-faire représenté par les activités internes.

Cependant, l’application de l’abstraction comportementale sur un workflow doit préserver unepropriété importante pour la coopération des workflows. Il s’agit de la préservation de la trace duworkflow projeté sur ses activités coopératives (voir Section 6.3.1).

Parmi les méthodes d’abstraction comportementale des réseaux de Pétri figure la techniquede graphe d’observation symbolique [41, 31]. Il s’agit d’une technique pour la vérification despropriétés µ-calcul [43]. Son utilisation dans le cadre de la coopération des workflows permetde réduire l’inter-visibilité des workflows partenaires au sein d’un workflow inter-organisationnel.Le graphe d’observation symbolique (SOG) est une structure compacte représentant la partiesignificative du comportement d’un système par rapport à la propriété que l’on souhaite vérifier.Le résultat de la vérification d’une propriété de µ-calcul linéaire sur le graphe d’observation estéquivalent à sa vérification sur le graphe d’accessibilité du système original.

La construction des graphes d’observation est guidée par l’ensemble des transitions survenantdans la formule à vérifier. Des telles transitions sont appelées observées (observed) tandis queles autres transitions du système sont appelées non observées (unobserved). Cette constructioncommence par l’étiquetage des transitions du réseau et se termine par le regroupement des mar-quages reliés par des transitions non observées. La structure obtenue à l’issue de cette construc-tion est le graphe d’observation symbolique. Chaque nœud de ce graphe, appelé méta-état, estune agrégation d’un sous-graphe des marquages non observés, et un arc reliant deux méta-états

6.4 Abstraction comportementale 103

Algorithme 3 La cloture1: Saturate(set S, transitions Local) ;2: set From, Reach, To ;3: From = S; Reach = S ;4: repeat5: To = Img(From, Local) ;6: From = To \Reach ;7: Reach = Reach ∪ To ;8: until From == ∅ ;9: return Reach ;

sera étiqueté par une transition observée. Le graphe d’observation est donc une structure degraphe qui abstrait toutes les séquences de transitions non observées pouvant exister dans lesous graphe sous-jacent à un nœud.

Nous pensons que la technique des graphes d’observations convient parfaitement à l’abstrac-tion des workflows pour plusieurs raisons. D’abord, en considérant que les transitions observablessont les activités coopératives et les transitions non observées sont les activités non coopératives,le graphe d’observation permet de représenter le langage du workflow projeté sur les transitionscoopératives c.-à-d. que les activités internes du workflow sont cachées et ainsi le savoir-faire duworkflow est préservé. La deuxième raison est qu’une telle abstraction revient à vérifier si deuxworkflows représentés par leur graphe d’observation peuvent être interconnectés (voir le chapitre7). De plus, étant donné un workflow, son graphe d’observation est construit une seule fois et ilpeut rester inchanger aussi longtemps que les modifications apportées au modèle ne mènent pasà l’ajout d’une occurrence des transitions coopératives. Enfin, la taille réduite du SOG (en géné-ral) pourrait être un avantage quand on souhaite stocker et gérer un grand nombre d’abstractionsde workflows dans le même annuaire.

Le reste de cette section est organisé comme suit. Dans la Section 6.4.1, nous montronscomment les graphes d’observations peuvent être construits. La Section 6.4.2 illustre à travers unexemple détaillé les graphes d’observations. Dans la section 6.4.3, nous montrons une propriétédes graphes d’observation à savoir la préservation du langage.

6.4.1 Construction des graphes d’observation symboliques

La section 6.4 a présenté l’idée générale des graphes d’observations et dans cette sectionnous détaillons comment ceux-ci peuvent être construits.

Soit Tobs un sous-ensemble de transitions observées d’un réseau de Pétri. L’objectif derière laconstruction du graphe d’observation est d’avoir une structure de graphe dans laquelle n’appa-raissent que des arcs étiquetés par des transitions observées. Les transitions non observées nesont pas visibles dans cette structure. Par conséquent, les transitions non observées ne sont fran-chies que dans le but d’aboutir à un franchissement d’une ou plusieurs transitions observées. Lesmarquages liés entre eux par le franchissement de séquences de transitions non observées sontagrégés (regroupés) sous forme d’un nœud unique du graphe d’observation appelé méta-état. Dece fait, le graphe d’observation est un graphe dont les nœuds sont des ensembles de marquagesappelés méta-états et les arcs sont étiquetés par les transitions observées. Les transitions nonobservées relient les marquages au sein d’un même méta-état.


Algorithme 4 Construction du graphe d’observation1: BuildOG (state m0, Transitions Coop) ;2: set S ; vertex v, v′ ;3: Vertices V ;4: Edges E ;5: Transitions Local = T \ Coop ;6: stack st ;7: S = Saturate({m0}, Local) ;8: v.set = Reduce(S, Local, 1) ;9: V = {v} ; E = ∅ ;

10: st.Push(〈v, S′〉) ;11: repeat12: st.Pop(〈v, S〉) ;13: for t ∈ Coop do14: S′ = Img(S, t) ;15: if (S′ 6= ∅) then16: S′ = Saturate(S′, Local) ;17: v′.set = Reduce(S′, Local, 1) ;18: if (∃w ∈ V s.t.w == v′) then19: E = E ∪ {v t→ w} ;20: else21: V = V ∪ {v′} ;22: E = E ∪ {v t→ v′} ;23: st.Push(〈v′, S′〉) ;24: end if25: end if26: end for27: until st == ∅ ;

Nous avons adapté dans [42] l’algorithme 4 au contexte des workflows. Cet algorithme aété défini dans [41]. L’algorithme utilise un certain nombre d’opérations. L’opération Img calculel’ensemble de tous les successeurs immédiats d’un nœud S (nœud du graphe des marquagesaccessibles) par le franchissement d’une transition t. L’opération Img peut être généralisée à unensemble de transitions T de la manière suivante : Img(S,T)=∪t∈T Img(S, t).

L’algorithme crée à la volée les méta-états et à cet effet il dispose de l’operation Saturate.En effet un méta-état du graphe d’observation est caractérisé par un ensemble de marquagesaccessible qui lui sont associés. Saturate permet de générer cet ensemble de marquages acces-sibles. Saturate opère sur un ensemble de marquages et calcule tous les marquages accessiblespar franchissement de séquences ne contenant que des transitions non observées. Elle permetainsi d’obtenir un ensemble d’états clos par franchissement de transitions non observées. Elle estdéfinie par :

Saturate = {s′, ∃s ∈ S et ∃σ ∈ (T \ Tobs) ∗ |s[σ〉s′}Nous designons par Local l’ensemble de transitions non observées. Formellement Local =

T \ Tobs.

L’algorithme 3 calcule pour un réseau de Pétri donné, l’ensemble des marquages successeurpar franchissement de transitions non observées. cet ensemble est stocké progressivement dansla variable Reach. A chaque itération, on obtient en un pas tous les marquages accessibles parfranchissement de transitions non observées à partir de l’ensemble From. Pour l’itération sui-


vante, seuls les nouveau marquage sont préservées. L’algorithme boucle jusqu’à ce qu’il n’aitplus de nouveau marquage généré. Le nombre d’itération exécutées par l’algorithme correspondau nombre de franchissements possibles à partir de l’ensemble de marquages de départ S et lapremière occurrence d’un marquage accessible à partir de cet ensemble.

L’algorithme 4 construit le graphe d’observation pour un Wf-net (un workflow modélisé sousforme d’un réseau de Pétri). Le marquage initial de ce workflow est m0. L’ensemble Coop repré-sente les activités coopératives du workflow (les transition observées du réseau de Pétri) et lesactivités non coopératives sont représentées par l’ensemble Local (les transitions non observéesdu réseau de Pétri). Les données manipulées par cet algorithme sont les suivantes :

– Une structure de graphe standard (V, E) permettant de stocker les méta-états visités et lesarcs les reliant. A chaque nœud est associée un ensemble d’états v.set abstrait par v.

– Une pile (St ) pour stocker le chemin courant de l’exploration en profondeur. Un elementde la pile représente une paire dont le premier composant v est un méta-état et le secondS désigne l’ensemble des transitions observées franchissables. (l’interprétation de ce sousensemble est donnée dans le paragraphe qui suit)

Les lignes (7-9) de l’algorithme 4 constituent l’étape d’initialisation. Au cours de cette étapeles nœuds du graphe d’observation sont initialisées (lines 7-8) ainsi que la structure du graphe(line 9). L’itération principale consiste à enlever un élément 〈v, S〉 de la pile jusqu’à ce que celle-cisoit vide. Le but de cette itération est de générer tous les successeurs du nœud courant dans legraphe d’observation. Partant du nœud initial du graphe d’observation, l’ensemble d’états S cor-respond aux états atteints en franchissant n’importe quelle séquence de transitions coopérativesmenant à v.

Pour chaque nœud pris au sommet de la pile, le nœud successeur est obtenue par le fran-chissement de la première transition non encore traitée (après avoir retiré cette transition del’ensemble des transitions à considérer). Ensuite, nous calculons l’image S′ de S en franchissantune transition observée. Dans le cas où S′ n’est pas vide, un nouveau arc étiqueté par la transi-tion observée est généré et ajouté au graphe d’observation. Maintenant nous vérifions si le nœudatteint en frachissant cet arc est un nouveau nœud ou pas. Pour ce faire la fremeture transitive deS′ obtenu par franchissement des transition locales est calculée. Ensuite, nous calculons à partirde S un sous-ensemble d’états caractérisant le comportment observable en commençant par S′.

Enfin, si le nœud atteint n’appartient pas déjà au graphe d’observation, il est ajouté au graphed’observation et empilé avec l’ensemble S′.

6.4.2 Exemple

Dans cette section, nous appliquons l’algorithme de construction de graphes d’observationssur l’exemple de l’assuré et de la société d’assurance fourni dans la section 2.4. Étant donnéque l’algorithme s’applique sur les graphes des marquages, nous construisons tout d’abord cesgraphes des marquages (voir figure 6.1) et ensuite nous appliquons l’algorithme.

A titre d’illustration nous montrons dans la suite de cette section comment construire le graphed’observation du workflow de la société d’assurance. La construction du graphe d’observation del’assuré est identique à celle effectuée pour la société d’assurance.

Dans la figure 6.11, nous commençons par initialiser les structures de données manipuléespar l’algorithme. Ainsi nous empilons dans st le marquage initial S1 et nous l’ajoutons en tant quepremier nœud du graphe d’observation symbolique.


FIGURE 6.11 – Construction du graphe d’observation de la société d’assurance, étape 1

Dans la figure 6.12, nous traitons la seule transition franchissable depuis le marquage initialà savoir Declaration. Cette dernière mène à S2. Conformément à l’algorithme nous calculons lafermeture transitive de S2 grâce à l’opération Saturate. Compte tenu du fait qu’il existe une tran-sition interne (locale) franchissable depuis S2, nous allons alors créer un méta-état représentantles transitions internes. La figure 6.13 montre le calcul de la fermeture transitive en franchissantles transitions Dossier et Cotisation respectivement. Le franchissement de ces deux transitions



mènent au marquage S3 et ensuite S5. Vu qu’il n’y plus de transition non coopérative franchissabledepuis S5, nous créons alors un méta-état S′2 que nous ajoutons en tant que nœud du graphed’observation. Nous ajoutons également un arc étiqueté par la transition coopérative Declarationau graphe d’observation.

Ensuite, nous traitons les seuls marquages franchissables par la transition Accuse à savoirles marquages S5 et S3. D’une part, nous ajoutons au graphe d’observation le nœud S6 et l’arc



la reliant avec S′2, S5 étant abstrait par S′2. D’autre part, le franchissement de la transition Accuseà partir du marquage S3 mène à S4. Cette dernière est suivie par une transition non observée(locale). Ainsi, nous calculons la fermeture transitive de S4.

Dans la figure 6.14, le seul marquage accessible à partir de S7 par une transition coopérative.Il s’agit de la transition Devis. Nous ajoutons ainsi au graphe d’observation le nœud S10 ainsi quel’arc le reliant à S′4.



Dans la figure 6.15, nous traitons le seul marquage accessible à partir de S8 par le fran-chissement de la transition coopérative Voiture Remplacement. Nous ajoutons donc au graphed’observation le nœud S9 ainsi qu’un arc reliant S′4 à S9.

Dans la figure 6.16, nous traitons le seul marquage accessible à partir de S8 par le franchisse-ment de la transition coopérative Devis. Étant donné que le nœud S10 existe déjà dans le graphed’observation, nous ajoutons un arc reliant S9 à S10.



Le franchissement de la transition Avis à partir du marquage S10 mène au marquage S11.La seule transition accessible depuis S11 est la transition non observée Expert. Par conséquent,dans la figure 6.17 nous calculons la fermeture transitive de S11.

En procédant de la même manière pour les marquages non encore traités (S13, S14, S15 etS16), nous obtenons le graphe d’observation présenté dans la figure 6.18-(b).



De même nous construisons le graphe d’observation correspondant au workflow de l’assuréque nous illustrons dans la figure 6.18-(a)

Dans ce qui suit nous montrons comment les graphes d’observations préservent le langaged’un réseau de Pétri. Par cette propriété, ils préservent donc la trace du workflow projetée sur sesactivités coopératives.



6.4.3 Préservation du langage

La section 6.4 a introduit la technique des graphes d’observation symboliques et les raisonsjustifiant leur utilisation dans le cadre des workflows inter-organisationnels. Le graphe d’observa-tion est en effet, une structure de graphe qui abstrait toutes les séquences de transitions internespouvant exister dans un méta-etat. De ce fait, il représente une partie du comportement d’unworkflow. Dans cette section, nous présentons une propriété préservée par les graphes d’obser-vations. Il s’agit de la préservation du langage du workflow projeté sur ses transitions coopéra-tives. Afin de garantir qu’une telle propriété reste vérifiée, trois types de séquences doivent êtrepréservées dans le graphe d’observation à savoir : les séquences observées infinies, les sé-quences maximales finies (séquences bloquantes) et les séquences finies divergentes. La figure6.19 montre les trois types de séquences. Supposons que N0 et N1 sont deux nœuds du graphed’observation tels que N0 est le méta-état initial. Pour chacun des nœuds, nous donnons le graphesous-jacent. La séquence (m0 → m1 → m3 → m4 → m5 → m0)∞ donnée dans la figure 6.19-(a)contient une séquence de transitions coopératives infinie du graphe de marquages accessibles.Cette séquence fait apparaître infiniment souvent des transitions coopératives (celles reliant m3

à m4 et m5 à m0). Même en ignorant les sous-graphes sous-jacent aux méta-états N0 et N1, une


FIGURE 6.18 – Graphe d’observation de l’assuré (a) et celui de la société d’assurance (b)

telle séquence est préservée dans le graphe d’observation. En effet, le chemin (N0 → N1 → N0)est un chemin reconnu par le graphe d’observation. La séquence des transitions coopératives cor-respondant à ce chemin est la projection d’une séquence, faisant apparaître infiniment souventdes transitions coopératives, acceptée dans le graphe de marquages correspondant.

Le deuxième type de séquence qui doit être préservée est la séquence maximale finie (l’exis-tence de nœuds sans successeur dans la séquence). L’existence d’une telle séquence dans legraphe des marquages accessibles est automatiquement détectée au niveau du graphe d’ob-servation. La séquence (m0 → m1 → m3 → m4 → m6) donnée dans la figure 6.19-(b) est unexemple de séquence maximale finie (séquence bloquante) acceptée par le graphe des mar-quages accessibles initial.

Le troisième et dernier type de séquence à préserver sont les séquences infinies divergentes.La séquence (m0 → m1 → m3 → m4 → m5 → m0)∞ de la figure 6.19-(c) en est un exemple. Laprésence d’une telle séquence dans le graphe des marquages accessibles est automatiquementdétectée au niveau du graphe d’observation.


m0

m3

m2m1

m7

m6m5

m4

m0

m3

m2m1

m7

m6m5

m4

N

m0

m3

m2m1

m7

m6m5

m4

N 0N 0N 0

1N1 N1

(a) (b) (c)

FIGURE 6.19 – (a) Séquence observé infinie (b) Séquence maximale finie (c) Séquence diver-gente

La préservation de ces trois types de séquence par la technique des graphes d’observationssymboliques est prouvée dans [41].

Cette propriété (la préservation du langage) est fondamentale pour la coopération des work-flows, étant donné que notre comparaison est basé sur la trace.

6.5 Conclusion

Dans ce chapitre, nous nous sommes intéressé à l’étape d’abstraction de workflows. L’abs-traction, en général, est une transformation permettant la simplification d’un système. Dans lecadre des workflows, il s’agit de la suppression d’un ensemble d’activités dont la présence dansle workflow n’est pas importante pour la coopération du workflow en question avec ses parte-naires. La suppression de ces activités implique la suppression des flots de contrôle qui leur sontdirectement liés.

Nous avons proposé deux types d’abstraction : l’abstraction comportementale et l’abstractionstructurelle. L’abstraction structurelle est appliquée sur la structure (modèle) du workflow, tandisque l’abstraction comportementale est appliquée au graphe de marquages du workflow. Ces deuxabstractions sont formelles et préservent la trace du workflow projetée sur ses activités coopéra-tives.

Le principe de la procédure d’abstraction est d’enlever toutes les activités internes ainsi queles flots de contrôle qui leur sont directement liés et de ne laisser que les activités coopérativeset les activités internes permettant de conserver la sémantique comportementale du workflow.

Grâce à l’abstraction, l’inter-visibilité des workflows est réduite au strict nécessaire de la co-opération. Ceci permet, non seulement de préserver le savoir-faire des entreprises participantesmais également leur autonomie. En effet, les partenaires ne voient pas les workflows internes desautres partenaires mais plutôt leurs abstractions et par conséquent ils ne voient que l’ensembledes activités avec lesquelles ils vont coopérer.

6.5 Conclusion 115

De plus, l’abstraction préserve l’autonomie des partenaires. En effet, les participants peuvententre deux exécutions changer et/ou faire évoluer la structure interne de leurs workflows sanspour autant changer leur rôle dans la coopération avec la seule condition de ne pas violer lasémantique de l’abstraction. Nous verrons dans le chapitre suivant, dans quelles conditions unemodification d’un workflow interne ne change pas son rôle dans la coopération.

Une fois abstraits, les workflows sont publiés au sein d’un annuaire. Lors de l’établissementd’un partenariat, les partenaires cherchent d’autres partenaires avec des compétences complé-mentaires afin de s’y interconnecter et coopérer avec. Dans le chapitre suivant, nous nous inté-ressons à la phase de l’appariement des workflows interentreprises.

Chapitre 7

Appariement métier etcomportemental de workflows

Sommaire7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177.2 Appariement de la sémantique métier . . . . . . . . . . . . . . . . . . 118

7.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187.2.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197.2.3 Requête par l'exemple (QBE ) . . . . . . . . . . . . . . . . . . . . . . . . 1207.2.4 Préférences utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227.2.5 Di�érencier entre les entrées et les sorties lors de l'appariement . . . . . 1237.2.6 Algorithme d'appariement sémantique . . . . . . . . . . . . . . . . . . . 124

7.3 Appariement comportemental . . . . . . . . . . . . . . . . . . . . . . . 1287.3.1 Propriété Candidat à la coopération . . . . . . . . . . . . . . . . . . . . 1297.3.2 Algorithme d'appariement comportemental . . . . . . . . . . . . . . . . 1327.3.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

7.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

7.1 Introduction

L’objectif de cette thèse est de développer un annuaire de workflows muni d’un service decourtage pour faciliter la coopération interentreprises. Pour réaliser cet annuaire nous procédonsen trois étapes. Premièrement, la description des workflows publiés doit être interprétable pardes programmes. Deuxièmement, le savoir-faire de chaque partenaire doit être préservé. Enfin,un mécanisme d’appariement de workflows doit être développé. Les deux chapitres précédentsont traité les deux premiers objectifs et dans ce chapitre nous nous intéressons à l’appariementde workflows

Dans le cadre des entreprises virtuelles, les partenaires ne se connaissent pas à priori et ilsdoivent avoir la possibilité de se découvrir les un les autres dynamiquement tout en préservantleur savoir-faire. Pour préserver le savoir-faire, nous avons proposé une méthode formelle d’abs-traction des workflows. Afin de faciliter la découverte dynamique nous avons proposé de unedescription sémantique des workflows. Lorsque ces deux étapes sont réalisées (l’abstraction etla description), les workflows peuvent être publiés dans un annuaire.

117

118 Appariement métier et comportemental de workflows

Une fois que les workflows sont publiés dans l’annuaire, il convient de trouver un moyen per-mettant leur découverte. Pour ce faire, nous proposons dans ce chapitre un mécanisme d’appa-riement des workflows. Etant donné qu’un workflow est composé d’une sémantique métier (flot dedonnées) et d’une sémantique comportementale (flot de contrôle), la réalisation du mécanismed’appariement nécessite la prise en compte de ces deux types de sémantique.

Nous nous intéressons tout au long de ce chapitre à ces deux types d’appariement. Lapremière partie du chapitre aborde l’appariement de la sémantique métier. Cet appariementconcerne la comparaison des fonctionnalités des activités des workflows à apparier ainsi quela comparaison des entrées et des sorties des activités. Nous proposons dans ce chapitre unalgorithme pour l’appariement de la sémantique métier des workflows. Lorsque deux activitéssont sémantiquement identiques nous leur affectons le même nom grâce à notre algorithme derenommage.

Le deuxième appariement est celui des comportements des workflows. L’appariement com-portemental se base sur les comportements observables des deux workflows à comparer. Lecomportement observable d’un workflow est obtenu grâce aux graphes d’observation symboliqueprésenté dans le chapitre précédent. Après avoir construit les graphes d’observation symboliquede deux workflows, nous appliquons notre algorithme d’appariement comportemental. Si le résul-tat de cet appariement est positif les deux workflows peuvent alors coopérer.

Le reste de chapitre est organisé comme suit. Nous commençons par présenter l’appariementde la sémantique métier dans la Section 7.2. Ensuite nous présentons l’appariement comporte-mental dans la Section 7.3. Enfin, nous concluons dans la Section 7.4.

7.2 Appariement de la sémantique métier

7.2.1 Introduction

Étant donné deux workflows W1 et W2, l’objectif de l’appariement sémantique est de décidersi ces deux workflows ont la même sémantique métier, c’est à dire qu’ils se complètent mutuel-lement du point de vue de leurs fonctionnalités. Pour ce faire, nous comparons les activités desdeux workflows deux à deux. En effet, dans le chapitre 5, nous avons présenté comment lesworkflows sont décrits sémantiquement. Nous nous basons sur cette description pour effectuerl’appariement de la sémantique métier. Nous étendons cette description en y incluant les préfé-rences des utilisateurs et les propriétés rhétoriques. D’une part, l’ajout des propriétés rhétoriquesoffre à un utilisateur la possibilité d’exprimer sa requête en spécifiant les propriétés des élémentsrecherchés. D’autre part, lorsqu’il y a plusieurs réponses possibles à une requête, les préférencesutilisateur permettent de définir des priorités sur les réponses. Nous avons réalisé deux déclinai-sons de cette approche : une pour SAXPDL et une autre pour SAWSDL.

Le reste de cette section est organisé comme suit. Nous commençons dans la section 7.2.2par présenter l’exemple que nous utilisons pour illustrer l’appariement sémantique. Dans la sec-tion 7.2.3 nous présentons notre mode d’interrogation par l’exemple. On y montre également com-ment les propriétés rhétoriques peuvent être définies dans la requête. La section 7.2.4 présenteles préférences utilisateur. Dans la section 7.2.5 nous montrons la différence entre les entrées etles sorties lors de l’appariement. Enfin, nous présentons l’algorithme d’appariement sémantiquedans la section 7.2.6.

7.2 Appariement de la sémantique métier 119

7.2.2 Exemple

FIGURE 7.1 – Exemple montrant l’utilité des préférences lors de l’appariement

Afin de montrer la pertinence des préférences utilisateurs et des propriétés rhétoriques, re-prenons l’exemple de l’activité proposant une offre de bienvenue. Cette activité est rattachée soitau concept OffreBienvenue soit à l’une de ses sous classes ChequeCadeau, DépôtImmédiat ouRembourserPremierMois. Nous avons ajouté le concept DépôtImmédiat modélisant un troisièmetype d’offre de bienvenue. Cette offre de bienvenue consiste à faire un virement immédiat d’unesomme sur le compte de l’assuré. Nous avons également ajouté la classe ModeDePaiementmodélisant le paiement de l’offre de bienvenue. De cette classe héritent trois classes Virement,Espece et Cheque (voir la figure 7.1) pour indiquer les différents modes de paiement possibles.Le remboursement de la cotisation du premier mois ainsi que le virement immédiat d’une sommesont effectués par virement tandis le deuxième type d’offre est l’envoi d’un chèque. Ces conceptssont utilisés pour annoter les activités des workflows utilisés comme exemples dans les sectionssuivantes.

Soient quatre workflows de quatre compagnies d’assurance contenant les activités Offre1,Offre2, Offre3 et Offre4. Le rôle de ces quatre activités est de proposer une offre de bienvenue auxnouveaux assurés. Les descriptions des activités Offre1, Offre2, Offre3 et Offre4 sont donnéesrespectivement dans les figures 7.2, 7.3, 7.4 et 7.5.

L’activité Offre1 (voir figure 7.2) est rattachée au concept OffreBienvenue. Par conséquent,elle peut offrir les trois types d’offre de bienvenue (le chèque cadeau, le remboursement de lapremière cotisation et le virement immédiat d’une somme sur le compte de l’assuré).

1 <Activity Id="13" Name="Offre1"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#OffreBienvenue">3 </Activity>

FIGURE 7.2 – Description sémantique de l’activité Offre1


L’activité Offre2 (voir figure 7.3), quant à elle, est rattachée au concept RembourserPremier-Mois et donc elle propose l’offre de bienvenue uniquement sous forme de remboursement de lacotisation du premier mois.

1 <Activity Id="14" Name="Offre2"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#RembourserPremierMois">3 </Activity>


La troisième activité Offre3 (voir figure 7.4) est rattachée au concept ChequeCadeau et parconséquent propose l’offre de bienvenue sous forme de chèque cadeau.

1 <Activity Id="15" Name="Offre3"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#ChequeCadeau">3 </Activity>


Enfin, la quatrième activité Offre4 (voir figure 7.5) est rattachée au concept DepotImmediatet donc elle propose l’offre de bienvenue sous forme de virement immédiat sur le compte del’assuré.

1 <Activity Id="16" Name="Offre4"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#DepotImmediat">3 </Activity>


Les workflows contenant ces quatre activités sont publiés dans un annuaire de workflows.

La section suivante présente comment les requêtes peuvent être décrites afin de découvrirles workflows publiés.

7.2.3 Requête par l’exemple (QBE )

A partir du moment où les workflows sont publiés dans l’annuaire, les utilisateurs peuventles découvrir en soumettant des requêtes au service de courtage. Deux modes d’interrogationsont proposés par le service de courtage. Le premier consiste à utiliser le langage de requêteRDQL [76]. Le second mode d’interrogation que nous allons détailler dans cette section estl’interrogation par l’exemple (Query By Example ou QBE). L’avantage de QBE est qu’il ne s’agitpas, pour l’utilisateur, d’apprendre le langage de requête RDQL, mais tout simplement de défi-nir une image de la réponse que l’on veut obtenir, pour voir figurer les workflows répondant àl’interrogation demandée.

Le mode d’interrogation QBE pour les workflows est réalisé de la manière suivante. Étantdonné que l’un des objectifs de notre approche est la coopération inter-workflows, les workflowsdésirant établir des coopérations incorporent les requêtes dans leurs descriptions (descriptionsdes workflows). De ce fait, la description d’un workflow est utilisée à la fois pour la coopérationet le requêtage. Une telle description est faite en se basant sur le langage SAXPDL. Ainsi, pour


qu’un utilisateur décrive les activités qu’il recherche, il faut rattacher chacune d’elles à un conceptdans une ontologie. Ce concept est la représentation sémantique de la fonctionnalité de l’activitéen question.

Néanmoins, cela ne suffit pas pour décrire la sémantique des requêtes des utilisateurs. Eneffet, dans le cas où l’utilisateur ne connaît pas le concept mais qu’il connaît les propriétés de ceconcept, SAXPDL ne lui offre pas la possibilité de décrire son activité en indiquant les propriétésqu’elle vérifie. Pour clarifier cette notion, prenons l’exemple d’un assuré (ass1) souhaitant décou-vrir un workflow proposant, entre autre, une activité d’offre de bienvenue. L’assuré ass1 souhaiteque cette offre soit transmise par virement. La seule chose qui importe pour ass1 est que le modede paiement soit par virement. Les activités répondant à la requête de ass1 sont celles rattachéesaux concepts RembourserPremierMois et DépôtImmédiat. Si ass1 référence dans sa requête leconcept OffreBienvenue, toutes les activités proposant une offre lui seront fournies comme ré-ponse à sa requête, y compris les activités proposant un chèque cadeau. Si par contre, ass1référence l’un des concepts RembourserPremierMois et DépôtImmédiat dans sa requête, il dé-couvre uniquement les activités offrant le remboursement de la première cotisation ou le virementimmédiat d’une somme tandis qu’il aurait souhaité découvrir les deux types d’activités. De plus, sil’ontologie est enrichie ultérieurement par un nouveau concept proposant une offre de bienvenuedont le mode paiement est le virement, l’assuré ne le découvre pas non plus.

Pour pallier ce manque, nous proposons d’étendre SAXPDL en y ajoutant l’attribut modelRe-ferenceProp. Cet attribut associe une activité à un concept décrivant une propriété de l’activitérecherchée. La définition de l’attribut modelReferenceProp est donnée dans la figure 7.6.

1 <xs:attribute name="modelReferenceProp" type="listOfAnyURI" />2 <xs:simpleType name="listOfAnyURI">3 <xs:list itemType="xs:anyURI"/>4 </xs:simpleType>

FIGURE 7.6 – Définition du schéma XML de de l’attribut modelReferenceProp

Grâce à l’attribut modelReferenceProp l’assuré ass1 peut maintenant exprimer dans sa re-quête que le mode de paiement de l’activité qu’il recherche est le virement. Ainsi, en référençantle concept OffreBienvenue par modelreference et le concept Virement par modelRefrenceProp,ass1 découvre toutes les activités d’offre de bienvenue mais en les restreignant à celles dont lemode de paiement est le virement. La figure 7.7 montre la définition de cette activité.

1 <Activity Id="25" Name="OffreRequeteAss1"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#OffreBienvenue"3 saxpdl:modelReferenceProp="http://www.int-evry.fr/OntoPref#Virement">4 </Activity>

FIGURE 7.7 – Découverte des offres de bienvenue transmises par virement

Dans cette section nous avons montré comment les requêtes peuvent être formulées et dansla section suivante nous présentons comment inclure les préférences utilisateurs dans les re-quêtes.


7.2.4 Préférences utilisateurs

L’un des objectifs de notre approche d’appariement sémantique consiste à permettre aux uti-lisateurs d’interroger un annuaire en spécifiant des préférences sur certains éléments de leursrequêtes. En effet, dans la section précédente nous avons montré comment un utilisateur peutspécifier la fonctionnalité du service qu’il recherche. Lorsqu’il y a plusieurs services offrant cettefonctionnalité, il y a souvent un de ces services qui est préférable (ou prioritaire) aux yeux del’utilisateur vis à vis des autres services. Pour offrir à l’utilisateur la possibilité de définir cette pro-priété, nous avons ajouté la notion de préférence à SAXPDL. Dans [67], nous avons égalementétendu le langage SAWSDL en lui ajoutant la notion de préférence. Cette extension est réaliséepar le biais de l’attribut preference (voir figure 7.8). Ce dernier rattache une activité, une entrée ouune sortie à un concept dans une ontologie de préférence. Nous supposons qu’une telle ontologiedoit contenir au moins les deux concepts Obligatoire et Null. Obligatoire est le concept désignantla préférence la plus importante et Null est le niveau de préférence le moins important.

Pour simplifier, l’ontologie que nous utilisons actuellement dans notre prototype contient uneclasse énumérée appelé niveau. Celle-ci est composée de cinq classes : Obligatoire, Elevé,Moyen, Faible et Null. Les valeurs numériques associées à ces classes sont respectivement 1,0.75, 0.5, 0.25 et 0.

1 <xs:attribute name="preference" type="listOfAnyURI" />2 <xs:simpleType name="listOfAnyURI">3 <xs:list itemType="xs:anyURI"/>4 </xs:simpleType>

FIGURE 7.8 – Définition du schéma XML de l’attribut preference

1 <Activity Id="25" Name="OffreRequeteAss1"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#OffreBienvenue"3 saxpdl:modelReferenceProp="http://www.int-evry.fr/OntoAssurance#Virement4 saxpdl:modelReferenceProp="http://www.int-evry.fr/OntoPref#Obligatoire">5 </Activity>

FIGURE 7.9 – Découverte des offres de bienvenue transmises par virement

L’utilisation de ces préférences permet, par exemple, à un assuré de spécifier ses prioritésconcernant les services qu’il recherche. Afin d’illustrer l’utilisation des préférences dans desexemples, reprenons la requête OffreRequeteAss1 de l’assuré ass1. Ass1 cherche une com-pagnie d’assurance proposant une offre de bienvenue et exige que l’offre lui soit transmise parvirement. Il introduit ainsi dans sa requête une préférence indiquant que les compagnies aveclesquelles il peut coopérer sont uniquement celles qui peuvent lui faire un virement de l’offre debienvenue. La description de la requête de l’assuré ass1 est donnée dans la figure 7.9.

Soient les deux assurés ass2 et ass3. ass2 cherche une compagnie d’assurance pouvant luipayer son cadeau de bienvenue en espèce. Cependant cette dernière condition (le paiement enespèce du cadeau) n’est pas importante pour lui. La description de cette requête est donnée dansla figure 7.10.

Enfin, l’assuré ass3 cherche une compagnie d’assurance et exige que cette dernière lui donneen espèce son cadeau de bienvenue. La description de cette requête est donnée dans la figure7.11.


1 <Activity Id="26" Name="OffreRequeteAss2"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#OffreBienvenue"3 saxpdl:modelReferenceProp="http://www.int-evry.fr/OntoAssurance#Espece4 saxpdl:modelReferenceProp="http://www.int-evry.fr/OntoPref#Faible">5 </Activity>

FIGURE 7.10 – Découverte des offre de bienvenue payable en espèce ou autre

1 <Activity Id="27" Name="OffreRequeteAss3"2 saxpdl:modelReference="http://www.int-evry.fr/OntoAssurance#OffreBienvenue"3 saxpdl:modelReferenceProp="http://www.int-evry.fr/OntoAssurance#Espece4 saxpdl:modelReferenceProp="http://www.int-evry.fr/OntoPref#Obligatoire">5 </Activity>

FIGURE 7.11 – Découverte des offres de bienvenue payable en espèce

Cette section a mis en exergue l’utilisation des préférences dans notre mécanisme d’apparie-ment sémantique. La section suivante sera consacrée à un autre critère permettant d’améliorerla qualité de l’appariement. Il s’agit de la différenciation entre les entrées et les sorties.

7.2.5 Différencier entre les entrées et les sorties lors de l’appariement

Une dernière particularité de notre algorithme d’appariement sémantique est la prise encompte de la différence entre les entrées et les sorties lors de l’appariement. L’utilité de cettedifférenciation a déjà été soulevée dans [34]. Lorsque nous comparons deux activités, la sortied’une activité de la requête ne doit pas être considérée comme étant similaire à une sortie, d’uneactivité publiée, plus générique qu’elle. A l’inverse, l’entrée d’une activité dans la requête peutêtre considérée comme étant similaire à une entrée plus générique qu’elle d’une activité publiée.Pour illustrer cette notion, prenons l’exemple de la figure 7.12.

La figure 7.12-(a) présente deux activités, une publiée et une dans une requête. D’une part,l’activité publiée prend en entrée un numéro d’identification de tout type de voitures et retourne ensortie un devis d’assurance pour la voiture donnée en entrée. D’autre part, l’activité se trouvantdans la requête prend en entrée un numéro d’identification d’une voiture quatre roues motrices(4X4) et elle retourne en sortie un devis d’assurance pour cette voiture. Nous remarquons quel’entrée requise par l’activité recherchée est une spécialisation de celle requise par l’activité pu-bliée et dans ce cas (l’entrée de la requête est une sous classe de l’entrée l’activité publiée) nousconsidérons que les deux entrées sont similaires (match).

La figure 7.12-(b) présente, elle aussi, deux activités une publiée et une dans une requête.L’activité publiée prend en entrée un numéro d’identification de tout type de voitures et retourneen sortie un devis d’assurance. L’activité se trouvant dans la requête prend en entrée un numérod’identification d’une voiture 4X4 et elle retourne en sortie un devis d’assurance pour cette voiture4X4. Nous remarquons que la sortie offerte par l’activité recherchée est une spécialisation de lasortie de l’activité publiée et dans ce cas (la sortie de la requête est une sous classe de la sortiede l’activité publiée) nous considérons que les deux sorties ne sont pas exactement similaires.

Dans la section suivante nous présentons notre algorithme d’appariement


FIGURE 7.12 – Difference entre les entrées et les sorties lors de l’appariement

7.2.6 Algorithme d’appariement sémantique

Après avoir examiné les différents facteurs intervenant dans le calcul de l’appariement, nousprésentons ici l’algorithme d’appariement. Celui-ci est composé de trois parties. La première par-tie concerne l’appariement des concepts (classe et concept désigne la même chose). La secondepartie présente l’impact des préférences utilisateur sur l’appariement et la troisième et dernièrepartie est le calcul résultat final de l’appariement à partir des résultats partiels.

Avant de présenter ces trois parties de l’algorithme, nous donnons quelques définitions utilespour la suite.

– Nous désignons par la fonction PropNumber(Cpt) le nombre de propriétés du concept Cpt

donné en paramètre de cette fonction ;– La fonction path(X, Y ) désigne l’ensemble des classes se trouvant sur le chemin dans

l’ontologie entre les deux classes X et X (y compris X et Y ) ;– RhetoProp(X,Y ) indique le nombre de propriétés partagées par les deux classes X et Y .

Dans ce qui suit nous présentons la procédure d’appariement de concepts de notre algo-rithme.

7.2.6.1 Appariement de concepts

L’appariement de concepts est réalisé grâce à la fonction MatchCpt(X,Y ). Celle-ci prend enparamètre deux concepts X et Y . Le premier concept (X) provient de la requête et le secondconcept (Y ) provient de l’annuaire. Ces concepts sont l’annotation sémantique d’un élément d’unworkflow (une activité, une entrée ou sortie). Ils sont référencés soit par l’attribut modelReferenceet dans ce cas ils (les concepts) représentent le sens sémantique de l’élément, soit ils sont réfé-rencés par l’attribut modelReferenceProp et dans ce cas ils indiquent la valeur d’une propriété del’élément. Nous donnons maintenant la définition de la fonction MatchCpt(X, Y ) :

1. MatchCpt(X, Y ) = MatchCpt(Y, X) = 1 ; Si X = Y ou X et Y sont déclarés comme étant classeséquivalentes.

2. X est une sous classe de Y . Par conséquent X hérite de toutes les propriétés de Y .


Comme nous l’avons souligné auparavant, dans ce cas il est important de distinguer le casoù X et Y sont des sorties ou non. Soit Z la première super-classe commune à X et Y .Dans ce cas Y == Z.

– MatchCpt(Y, X) = 1 ; si X et Y sont des sorties. L’appariement du concept de la requête (Y ,premier paramètre) et celui publié (X, deuxième paramètre) est exact.

MatchCpt(X, Y ) =

∑

n∈path(Y,Z)

PropNumber(n)

∑

n∈path(X,Z)

PropNumber(n). L’appariement du concept de la requête (X, pre-

mier paramètre) et celui publié (Y ) est le ratio entre le nombre de propriétés de Y et lasomme des propriétés de toutes les classes se trouvant sur le chemin entre X et Y (X etY comprises).

– Si X et Y ne sont pas des sorties : MatchCpt(X, Y ) = 1

et

MatchCpt(Y, X) =

∑

n∈path(Y,Z)

PropNumber(n)

∑

n∈path(X,Z)

PropNumber(n)

3. X et Y sont des sous classes de Z. Elles héritent donc de toutes les propriétés de Z. Ledegré de similarité de X et Y dépend du nombre de propriétés communes entre elles.rhProp = RhetoProp(X, Y ) ; le nombre de propriété reliant X à Y et/ou Y à X.etsum1 =

∑

n∈path(X,Z)

PropNumber(n) − rhProp ; le nombre totale des propriétés de X moins celles

entre X et Y .etsum2 =

∑

n∈path(Y,Z)

PropNumber(n)− rhProp

etMatchCpt(X, Y ) = MatchCpt(Y, X)

etMatchCpt(X, Y ) =

P ropNumber(Z)+rhP ropsum1+sum2−P ropNumber(Z)

4. Pour tous les autres cas la similarité entre X et Y est nulle.MatchCpt(X, Y ) = MatchCpt(Y, X) = 0

7.2.6.2 Impact des préférences utilisateur sur l’appariement

La deuxième partie de l’algorithme consiste à prendre en compte les préférences utilisateur.Notre algorithme utilise la fonction prefV alue(X) qui retourne la valeur numérique de la pré-férence associée à un élément X. La fonction MatchPref(X, Y ) (voir algorithme 5) prend enentrée la préférence associée à un élément de la requête et le résultat de l’appariement de cetélément retourné par MatchCpt().

Algorithme 5 MatchPref(Rqtpref , Matchres)1: if (Rqtpref == null) then2: x = 1 ;3: end if4: x = prefV alue(Rqtpref ) ;5: if (Matchres == 0) then return 0 ;6: else if (x == 1) then return Matchres ;7: else return (Matchres − 1)x + 1 ;


D’une part, lorsqu’aucune préférence n’est spécifiée par l’utilisateur, l’algorithme affecte unepréférence par défaut. La valeur affectée à cette préférence par défaut est la valeur la plus élevéeà savoir 1 (lignes 1 à 2 de l’Algorithme 5). D’autre part, nous considérons que lorsque la préfé-rence associée à une requête est Obligatoire (ligne 6 de l’Algorithme 5), l’algorithme garde lerésultat de l’appariement retourné par la fonction MatchCpt(). Par contre, lorsque la préférenceassociée à la requête n’est pas Obligatoire, l’algorithme augmente le degré de similarité (ligne 7).En effet, lorsqu’il y a un élément dans la requête qui n’est pas important pour l’utilisateur, l’al-gorithme peut proposer à la place de cet élément un autre élément qui ne lui correspond pasexactement.

7.2.6.3 L’appariement global : calcul du résultat final

Dans les deux sections précédentes nous avons présenté comment comparer deux conceptstout en prenant compte les préférences utilisateur spécifiées dans la requête. Une fois cet appa-riement effectué entre chaque couple de concepts, nous calculons l’appariement final entre lesactivités des workflows. Ceci est fait en comparant les activités des deux workflows (le workflowrequête et le workflow publié) deux-à-deux. Dans le calcul de ce résultat final intervient non seule-ment les concepts rattachés aux deux activités, les entrées et les sorties des deux activités maiségalement les propriétés et les préférences fournies dans la requête.

L’algorithme 6 calcule le résultat final de l’appariement de deux activités, une provenant de larequête et la deuxième de l’annuaire (les activités des workflows publiés). Les deux activités sontrqtAct et advAct respectivement. La liste listPropAndPrferenceRqt (ligne 8) contient des couples〈propCpt, pref〉 représentant une propriété d’un élément de la requête (propCpt) et la préférence(pref ) associée à cet élément par l’utilisateur. La liste listPropAdv (ligne 9) contient les propriétésdu concept de l’activité publiée. Ces propriétés sont les propriétés directes du concept ainsi quetoutes les propriétés des ses sous-classes. L’algorithme commence par comparer les concepts dedeux activités et pondère le résultat par la prise en compte des préférences (ligne 11−12). Ensuitel’algorithme compare les entrées et les sorties des deux activités et les pondère également enutilisant les préférences (ligne 13 − 18). Lorsqu’aucune propriété n’est spécifiée par l’utilisateur,le résultat final de l’appariement est la moyenne des résultats de l’appariement des entrées, dessorties et des activités elles mêmes (ligne 11−21). Si par contre, certaines propriétés de l’activitésont fournies dans la requête, l’algorithme les compare avec les concepts publiés dans l’annuaire(ligne 22− 27). Dans ce cas l’algorithme teste si le concept associé à l’une des deux activités (larequête ou celle publiée) est une sous classe de l’autre. Si c’est le cas, il considère que les deuxconcepts sont similaires (ligne 28 − 30). Enfin, le résultat final de l’appariement est calculé (ligne31).

Dans ce qui suit nous appliquons cet algorithme (voir la figure 7.13) d’appariement séman-tique aux activités publiées de l’exemple donné dans la section 7.2.2 et les requêtes donnéesdans la section 7.2.3. Les activités publiées sont les quatre activités d’offre de bienvenue Offre1(figure 7.2), Offre2 (figure 7.3), Offre3 (figure 7.4) et Offre4 (figure 7.5). Les requêtes sont Offre-RequeteAss1 (figure 7.9), OffreRequeteAss2 (figure 7.10) et ass3 (figure 7.11). Pour simplifier lecalcul, nous ne prenons pas en compte l’appariement des entrées/sorties dans cet exemple. Eneffet, l’appariement d’entrées/sorties se fait de la même manière que celui d’activités que nousallons montrer dans ce qui suit.

Dans la figure 7.13 nous comparons la requête OffreRequeteAss1 avec les deux activitésOffre1 et Offre3 d’une part, et les deux requêtes OffreRequeteAss2 et OffreRequeteAss3 avec


Algorithme 6 MatchActivity(rqtAct, advAct)1: rqtCpt = getConcept(rqtAct) ;2: advCpt = getConcept(advAct)3: advInCpt = getConceptIn(advAct)4: advOutCpt = getConceptOut(advAct)5: rqtInCpt = getConceptIn(rqtAct)6: rqtOutCpt = getConceptOut(rqtAct)7: prefCpt = getPrefConcept(rqtAct) ;8: listPropAndPrferenceRqt = getCoupleProp_Pref(rqtAct) ;9: listPropAdv = getProp(rqtAdv) ;

10: sumMatchProp = 0 ; numberOfProp = 0 ;11: matchActTmp = MatchCpt(rqtCpt, advCpt) ;12: matchActResult = MatchPref(prefCpt, matchActTmp) ;13: prefRqtin = getPrefConcept(rqtInCpt)14: matchInTmp = MatchCpt(rqtInCpt, advOutCpt) ;15: matchInResult = MatchPref(prefRqtin, matchInTmp) ;16: prefRqtout = getPrefConcept(rqtOutCpt)17: matchOutTmp = MatchCpt(rqtOutCpt, advInCpt) ;18: matchOutResult = MatchPref(prefRqtout,matchOutTmp) ;19: if (listPropAndPrference is ∅) then20: return matchOutResult+matchInResult+matchActResult

3 ;21: else22: for (〈prop1, pref1〉 ∈ listPropAndPrferenceRqt and prop2 ∈ listPropAdv) do23: resMatchProp = MatchCpt(prop1, prop2)24: sumMatchProp = sumMatchProp + MatchPref(pref1, resMatchProp) ;25: numberOfProp + + ;26: end for27: finalMatchProp = sumMatchProp

numberOfProp ;28: if (matchActResult > 0) then29: matchActResult = 130: end if31: return finalMatchProp+matchOutResult+matchInResult+matchActResult

4

32: end if

l’activité Offre2 d’autre part. L’appariement des autres requêtes avec toutes les activités se faitsur le même modèle.

Dans la figure 7.13-(a) nous comparons l’activité Offre1 avec la requête OffreRequeteAss1.OffreRequeteAss1 et Offre1 sont rattachées au même concept OffreBienvenue et par conséquentl’appariement des concepts de ces deux activités est exact (ligne 3 de la figure 7.13-(a)). Lapropriété virement (concept Virement) requise dans la requête est proposée par Offre1 et parconséquent l’appariement des propriétés est exact (ligne 4 de la figure 7.13-(a)). Le résultat finalde l’appariement de OffreRequeteAss1 et Offre1 est donc égal à 1.

Dans la figure 7.13-(b) nous montrons l’appariement de la requête OffreRequeteAss1 etOffre3. Offre3 est rattachée au concept ChequeCadeau et par conséquent l’appariement desconcepts des deux activités est exact (ligne 3 de la figure 7.13-(b)). Cependant, la propriété re-quise par la requête OffreRequeteAss1 est Virement avec une préférence Obligatoire tandis quela propriété proposée par Offre3 est Cheque. Par conséquent, l’appariement des propriétés estégal à 0.5 et comme la préférence est Obligatoire, le résultat de l’appariement des propriétés est


le même. L’appariement final est la moyenne du résultat de l’appariement des propriétés et celuides concepts auxquels les activités sont rattachées.

Dans la figure 7.13-(c) et 7.13-(d) nous comparons les deux requêtes OffreRequeteAss2 etOffreRequeteAss3 avec l’activité Offre2. Les deux requêtes cherchent une activité d’offre de bien-venue capable de donner cette offre en espèce (concept Espece). Ce qui les distingue est quela préférence associée à la propriété de paiement en espèce est faible (concept Faible) pour larequête OffreRequeteAss2, tandis qu’elle est obligatoire (concept Obligatoire) pour la requêteOffreRequeteAss3. Cette différence de préférence fait que le degré d’appariement de OffreRe-queteAss2 et Offre2 est plus élevé que celui de OffreRequeteAss3 et Offre2.

FIGURE 7.13 – Appariement des requêtes des assurés et des activités offertes

Cette section a été consacrée à l’appariement sémantique de la sémantique métier des work-flows. La section suivante présente l’appariement de la sémantique comportementale des work-flows.

7.3 Appariement comportemental

Dans cette section, nous commençons par donner la définition du langage d’un workflow etla propriété candidat à la coopération qui définit les conditions pour que deux workflows puissentcoopérer et puis nous présentons l’algorithme d’appariement (matching) comportemental propre-ment dit. Enfin, nous présentons un exemple illustrant l’appariement comportemental.

7.3 Appariement comportemental 129

7.3.1 Propriété Candidat à la coopération

La définition formelle ainsi que sa modélisation sous forme de réseau de Pétri sont donnéesdans 2.1.1.

Définition 15 (Langage de workflow) Soit σ une séquence de transitions (σ ∈ T ∗). La projectionde σ sur un ensemble de transitions X ⊆ T (notée σbX ) est une séquence obtenue en enlevantde σ toutes les transitions n’appartenant pas à X. Une séquence σ = t1t2 . . . tn sur les transitionsest dite acceptée si i (resp. o) est incluse dans l’ensemble des places d’entrées (resp. sortie)de t1 (resp. tn) et σ peut être exécutée par le workflow. Le langage L(W ) d’un workflow W estl’ensemble de toutes les séquences acceptées et la fonction de projection est étendue à L commesuit : LbX = {σbX , σ ∈ L}.

Etant donné un Wf-net W1 et un annuaire de partenaires éventuels pour W1, nous discutonsdans cette section des critères de sélection permettant de choisir dans l’annuaire un Wf-net W2

comme partenaire à W1. De tels critères sont basés sur le comportement observable de W1, quidoit correspondre au comportement observable de W2. Le comportement observable d’un work-flow est défini formellement par son graphe d’observation symbolique (SOG). Dans le chapitre 6nous avons montré comment le graphe d’observation symbolique d’un workflow peut être obtenu.

Avant de procéder à la comparaison des SOGs de deux workflows, nous comparons leursactivités (transitions) et ensuite nous les renommons. L’algorithme 7.3.1 représente la procédurede renommage de deux transitions coopératives qui correspondent. Afin de vérifier s’il existe unecorrespondance entre deux transitions (activités) coopératives t1 et t2 appartenant à deux Wf-netdifférents, nous avons besoin de comparer sémantiquement ces transitions. Cette comparaison(ligne 2 de l’algorithme 7.3.1) est effectuée par la fonction MatchActivity() donnée dans l’algo-rithme 6. Lorsque le résultat de l’appariement de deux transitions est exact, les deux transitionssont renommées en leur affectant le même nom (ligne 3 de l’algorithme 7.3.1).

Algorithme 7 (Rename(SOG1(s0, S1, T1), SOG2(s′0, S2, T2)))1: for (tj ∈ T2) do2: if (∃ ti ∈ T1 telle que MatchActivity(tj , ti) = 1) then3: tj .name = ti.name

4: end if5: end for

Pour illustrer la procédure de renommage nous prenons l’exemple des graphes d’observationsymbolique de l’assuré et de la compagnie d’assurance (voir Figure 7.14).

Tout d’abord, nous avons d’un coté la transition DECL appartenant à l’assuré(Figure 7.14-(a)) et de l’autre coté la transition DECLARATION appartenant à lacompagnie d’assurance (Figure 7.14-(b)). Ces deux transitions sont rattachées aumême concept dans l’ontologie. Par conséquent, leur appariement sémantique est exact(MatchActivity(DECL, DECLARATION) = 1). L’algorithme 7.3.1 affecte donc le même nom(DECLARATION) aux deux activités. De la même manière toutes les autres activités sont renom-mées. En effet, les deux d’activités de chacun des couples 〈ACC , ACCUSE 〉, 〈DEV , DEVIS 〉,〈AV , AVIS 〉, 〈FACT , FACTURE 〉, 〈EVAL, EVALUATION 〉 et 〈PAYER, PAIEMENT 〉 sont rat-tachées au même concept. Par conséquent, l’appariement des activités de chaque couple estexact. Etant donné que l’appariement est exact, les activités de chaque paire seront renommées.


FIGURE 7.14 – Graphes d’observation symbolique de l’assuré (a) et de la compagnie d’assurance(b)

Par exemple, la paire 〈ACC , ACCUSE 〉 est renommée 〈ACCUSE , ACCUSE 〉. De la même ma-nière toutes les autres paires d’activités sont renommées. Après avoir renommé toutes les activi-tés nous obtenons les deux graphes d’observations symbolique donnés dans la figure 7.15

L’hypothèse suivante est importante pour le reste de cette section. Elle dit qu’au sein d’unmême Wf-net W , si une transition coopérative se produit plus qu’une fois, alors ses occurrencessont exécutées exclusivement. Dans ce cas, nous notons par Occ(W , t) l’ensemble des occur-rences de la transition coopérative t dans un Wf-net W . Soit 〈W1,m1〉 un Wf-net marqué et soit T1

l’ensemble de ses transitions coopératives. Alors ∀t1 ∈ T1, ∀σ = αt1α′t1α′′, où α, α′ et α′′ ∈ T ∗1 ,

alors σ 6∈ L(W1,m1) (H). Cette hypothèse permet d’enlever l’ambiguité lors de l’interconnexionde workflows interentreprises puisque la correspondance des transitions coopératives est ainsidéterministe.

Dans la figure 7.16-(a), nous donnons l’exemple d’un workflow W ne satisfaisant pas l’hypo-thèse (H). Le workflow est formé des activités A, B, C, D et E et comporte trois occurrences dela transition coopérative A (Occ(W,A) = 3). Nous remarquons aisément que l’exécution des oc-currences de A n’est pas exclusive. En effet, la transition coopérative A est exécutée exactementdeux fois quelque soit l’exécution du workflow W : A → B → A, A → B → C → D → A, A → B →C → E → A.

Dans la figure 7.16-(b), nous donnons l’exemple d’un workflow W satisfaisant l’hypothèse (H).Ce workflow est formé des activités A, B, C, D et E et comporte trois occurrences de la transitioncoopérative C (Occ(W,C) = 3) qui s’exécutent exclusivement. En effet, la transition coopérativeC est exécutée exactement une fois quelque soit l’exécution du workflow W : A → B → C, A → B→ D → C → E.


FIGURE 7.15 – Graphes d’observation symbolique renommés

FIGURE 7.16 – Les occurrences d’une même transition coopérative sont exécutées exclusivement

Pour définir formellement le fait qu’un Wf-net W1 peut coopérer avec un Wf-net W2 donné,nous avons besoin de définir la propriété d’un candidat à la coopération.

Définition 16 (Candidat à la coopération) Soit 〈W1,m1〉 et 〈W2,m2〉 deux Wf-nets marqués.〈W2, m2〉 est un candidat à la coopération avec 〈W1,m1〉 si et seulement LbT1coop

(〈W1,m1〉) ∩LbT2coop

(〈LW1(W2), m2〉) 6= ∅.

La section suivante présente l’algorithme d’appariement comportemental.


7.3.2 Algorithme d’appariement comportemental

Dans cette section nous présentons l’algorithme d’appariement comportemental de deuxworkflows. L’algorithme que nous utilisons ici est le même que celui utilisé dans la thèse de Is-sam Chebbi [15]. La différence est que nous l’appliquons sur des graphes d’observation symbo-lique tandis que dans [15] il est appliqué aux graphes de marquages. Le principe de l’algorithmeconsiste à tester si l’intersection des langages de deux Wf-net W1 et W2 n’est pas vide, en sebasant sur leurs graphes d’observation symbolique. Ainsi, le Wf-net W2 est un candidat pour co-opérer avec W1 si l’intersection des langages du graphe d’observation symbolique de W1 et decelui de LW1(W2) n’est pas vide.

L’algorithme 8 d’appariement (matching) comportemental de workflows s’exécute à la volée.La construction du produit synchronisé [7] entre les graphes d’observation symbolique impliquéspeut être stoppée à n’importe quel instant, du moment que la comparaison des ensembles desorties des états n’est pas satisfaite.

Pour deux états de graphes d’observation symbolique de workflows, nous récupérons l’en-semble de leurs sorties. Ensuite, nous testons s’il existe au moins un comportement communentre les deux graphes d’observation des partenaires en question. Ceci se traduit par le test d’in-tersection entre les sorties des états des graphes d’observation. Si à un moment donné, le testéchoue, l’algorithme s’arrête avec échec. Dans le cas contraire, nous mémorisons les états quine sont pas complètement traités et nous leurs appliquons la procédure d’appariement. Lorsquetous les états sont complètement traités, l’algorithme s’arrête avec succès et nous déduisons queles graphes d’observation correspondent (leur appariement est exact) et les workflows peuventainsi être interconnectés.

Les paramètres de cet algorithme sont les graphes d’observation symbolique SOG1 =〈s0, S1, E1〉 et SOG2 = 〈s′0, S′1, E′

1〉 de (W1,m1) et (LW1(W2), m2) respectivement. s0 (resp. s′0)représente l’état initial de SOG1 (resp. SOG2), S1 (resp. S2) représente son ensemble d’états etE1 (resp. E2) l’ensemble de ses arcs.

Les structures de données utilisées par l’algorithme 8 sont un tableau Synch et une pile st.Synch est utilisée dans le but de sauvegarder les états du produit synchronisé qui ne sont pascomplètement traitées.

Un élément de st est un tuple 〈s1, s2, f1〉 composé d’un état accessible de (W1,m1), un étataccessible de (LW1(W2),m2) et du plus petit ensemble de transitions coopératives communesfranchissables par les deux nœuds à synchroniser. La pile st permet de sauvegarder l’ensembledes états ainsi que les transitions étiquetant leurs sorties qui ne sont pas encore complètementtraités.

Quatre fonctions sont utilisées dans l’algorithme : Out(), Img(), Names() et Intersection().

– Out() prend en entrée un nœud du graphe d’observation symbolique et retourne l’ensembledes transitions étiquetant ses arcs sortants. La détermination des transitions sortantes d’unétat donné constitue une phase préliminaire pour tester l’interconnexion de langages deworkflows de partenaires. L’application de la fonction Out() à l’état s4 du graphe d’observa-tion symbolique de l’assuré de la figure 7.15-(a) par exemple, résulte aux deux transitionsFACTURE et EVALUATION ;

– Img() prend en entrée un état s1 et une transition t (franchissable en ce nœud) et retournel’état accessible depuis ce nœud. A une itération i de l’algorithme, cette fonction permet dedéterminer l’état à traiter. L’application de la fonction Img() à l’état s4 du graphe d’observation


Algorithme 8 (L(SOG1 = 〈s0, S1, E1〉) ⊆ L(SOG2 = 〈s′0, S2, E2〉)) ?1: State s1, s2, s′1, s′2 ;2: Set of transition f1, f2, f3 ;3: stack st ;4: s1 = s0 ; s2 = s′0 ;5: f1 = Out(s0), f2 = Out(s′0) ;6: if (f1 6= ∅ and f2 6= ∅) then7: f3 = Intersection(f1, f2) ;8: if (f3 = ∅) then9: return false ;

10: end if11: end if12: Synch = {〈s1, s2〉} ;13: st.Push(〈s1, s2, f3〉) ;14: repeat15: st.Pop(〈s1, s2, f3〉) ;16: for (t ∈ f3) do17: s′1 = Img(s1, t) ; s′2 = Img(s2, t)18: if (〈s′1, s′2〉 6∈ Synch) then19: f1 = Out(s′1) ; f2 = Out(s′2) ;20: if (f1 6= ∅ and f2 6= ∅) then21: f3 = Intersection(f1, f2) ;22: if (f3 = ∅) then23: return false ;24: end if25: end if26: Synch = Synch ∪ {〈s′1, s′2〉};27: st.Push(〈s′1, s′2, f3〉) ;28: end if29: end for30: until (st == ∅) ;31: return true ;

de l’assuré (Figure 7.15-(a)) et à la transition FACTURE donne l’état s6, puisque à partir des4, le franchissement de la transition FACTURE nous amène à l’état s6 ;

– Names() prend en entrée un ensemble de transitions f et retourne l’ensemble des noms deces transitions. Cette fonction est utilisée pour tester ensuite l’intersection de langages deworkflows ;

– Intersection prend en entrée deux tableaux A et B pour vérifier leur intersection et retourneun tableau C contenant l’ensemble de leurs éléments communs.

L’algorithme d’appariement est constitué de deux parties majeures. La première partie est unephase d’initialisation des variables de l’algorithme dans laquelle nous commençons par récupérerles états initiaux des deux graphes d’observation symbolique (Algorithme 8, ligne 4). Puis nousdéterminons l’ensemble des transitions étiquetant leurs sorties (Algorithme 8, ligne 5). L’étapesuivante consiste à tester l’intersection des ensembles des noms étiquetant les transitions sor-tantes du premier état et de l’ensemble de noms des transitions étiquetant les sorties du secondétat (Algorithme 8, lignes 6 à 10). Enfin, nous initialisons le produit synchronisé avec la paire desétats initiaux (Algorithme 8, ligne 12) et la pile avec le triplet formé des deux états initiaux et lestransitions communes étiquetant de leurs sorties respectives (Algorithme 8, ligne 13). Dans le


cas d’un test positif, nous sauvegardons les états visités et ceux qui ne sont pas complètementtraités.

La seconde partie de l’algorithme consiste en un ensemble d’itérations de test d’appariementd’états. Pour chaque itération, nous récupérons un triplet formé de deux états ainsi qu’un petit en-semble commun des noms de transitions étiquetant leurs sorties. Ensuite, pour chaque état si ettransition t du triplet, nous cherchons l’état accessible depuis si en franchissant la transition t (Al-gorithme 8, ligne 17). Si la paire des états obtenus n’est pas encore visitée alors nous cherchonsles transitions étiquetant les sorties des états en question (Algorithme 8, ligne 19) et nous testonsleur intersection. Si le test est négatif, alors l’algorithme s’arrête avec échec (Algorithme 8, ligne23) et nous concluons que les deux graphes d’observation symbolique ne correspondent (match)pas. Dans le cas contraire, nous ajoutons la paire de états en question à l’ensemble de produit desynchronisation (Algorithme 8, ligne 26) et nous sauvegardons ces états ainsi que leurs sortiesdans la pile st (Algorithme 8, ligne 27).

L’algorithme est appliqué de nouveau aux différents éléments de la pile jusqu’à ce que cettedernière soit vide (Algorithme 8, ligne 30) et dans ce cas les deux graphes d’observation symbo-lique correspondent ou bien le test d’intersection des ensembles de sorties de deux états échoueet dans ce cas les graphes d’observation symbolique ne correspondent pas.

La section suivante montre l’application de cet algorithme sur l’exemple des workflows del’assuré et de la compagnie d’assurance.

FIGURE 7.17 – Appariement des workflows de l’assuré et de la compagnie d’assurance-Etape1

7.4 Conclusion 135

7.3.3 Exemple

Dans cette partie, nous appliquons l’algorithme d’appariement sur les graphes d’observationsymbolique de l’assuré et de la compagnie d’assurance (Figure 7.15) après les avoir renommés.Nous montrons ensuite comment vérifier la correspondance entre ces deux graphes d’observa-tion. Notons que les cercles noirs dans les graphes d’observation symbolique de l’assuré et de lacompagnie d’assurance désignent les états déjà traités.

Dans la figure 7.17, nous commençons par initialiser les variables de l’algorithme avec lesétats initiaux à comparer (s0 et s′0). Ensuite, nous cherchons l’ensemble des transitions étiquetantles arcs sortant de s0 et s′0. Dans les graphes d’observation symbolique, nous remarquons quechacun des états s0 et s′0 possède une seule sortie étiquetée par DECLARATION (lignes 3 et4, Figure 7.17). L’étape suivante consiste à tester l’intersection des ensembles de noms de tran-sitions sortantes de s0 et s′0. Puisque les deux ensembles sont égaux, nous gardons trace desétats qui correspondent : la paire (s0,s′0) (ligne 6, Figure 7.17) et nous sauvegardons les états duproduit synchronisé qui ne sont pas complètement traités (ligne 7, Figure 7.17).

Dans la figure 7.18, nous récupérons le triplet (s0,s′0, DECLARATION) qui représente le pointde départ de la seconde itération de l’algorithme d’appariement. Ensuite, nous cherchons lesétats accessibles depuis s0 en franchissant la transition DECLARATION. Ainsi, nous obtenonsl’état s1. De même, nous cherchons l’ensemble des états accessibles depuis s′0 en franchissantla transition DECLARATION pour obtenir l’état s′1. Après avoir vérifié que la paire (s1,s′1) n’estpas encore traitée (s − 1,s′1 6∈ Synch), l’étape suivante consiste à chercher toutes les transitionssortantes de s1 et s2 respectivement. Dans la figure 7.18, nous remarquons que chacun desdeux états s1 et s′1 dispose d’une seule sortie étiquetée de ACCUSE (lignes 3 et 4, Figure 7.18).L’intersection des ensembles des transitions des deux états n’étant pas vide, nous ajoutons lapaire (s1,s′1) à l’ensemble du produit synchronisé (ligne 6, Figure 7.18) et nous sauvegardons letriplet (s1,s′1,ACCUSE) à la tête de la pile pour traitement (ligne 7, Figure 7.18).

Nous déroulons l’algorithme de la même manière jusqu’à que tous les états soient traités.La pile étant vide, ceci marque la fin de l’algorithme d’appariement (matching) comportementalavec succès. Ainsi, les deux graphes d’observation symbolique de l’assuré et de la compagnied’assurance correspondent (Figure 7.19) conformément à deux comportements. Le premier com-portement est composé des paires 〈(s0, s

′0), (s1, s

′1), (s2, s

′2), (s3, s

′4), (s4, s

′5), (s6, s

′7), (s7, s

′8)〉 et le

second comportement est 〈(s0, s′0), (s1, s

′1), (s2, s

′2), (s3, s

′4), (s4, s

′5), (s5, s

′6), (s6, s

′47, (s7, s

′8)〉

7.4 Conclusion

L’objectif de ce chapitre était de fournir un mécanisme d’appariement permettant de vérifiersi deux workflows coïncident et par conséquent s’ils peuvent coopérer ensemble. Pour permettrela création dynamique des entreprises virtuelles, l’appariement doit être effectué d’une manièreautomatique et doit offrir une bonne qualité.

Pour ce faire, nous avons procédé à une solution composée de trois parties. La premièrepartie consiste à apparier les activités des deux workflows à comparer. Ensuite, les activitéssont renommées. La troisième partie consiste à comparer le comportement observable de deuxworkflows.


FIGURE 7.18 – Appariement des workflows de l’assuré et de la compagnie d’assurance-Etape2

FIGURE 7.19 – Appariement des workflows de l’assuré et de la compagnie d’assurance-Dernièreétape

Pour vérifier si deux workflows correspondent (match), nous comparons à la fois leur séman-tique métier et leur sémantique comportementale. L’appariement de la sémantique métier consiste

7.4 Conclusion 137

à comparer sémantiquement les activités des deux workflows deux-à-deux. Lors de cet apparie-ment, nous comparons les concepts d’ontologie auxquels les deux activités sont rattachées. Cesconcepts représentent en effet les fonctionnalités des activités. Nous comparons également lesentrées et sorties des activités. Toute paire d’activités ayant un résultat d’appariement exact estrenommée en leur affectant le même nom.

Nous procédons ensuite à l’appariement comportemental. Celui-ci consiste à comparer lescomportements observables des workflows. Le comportement observable d’un workflow est ob-tenu grâce à la structure appelée graphe d’observation symbolique. Nous avons proposé un al-gorithme pour l’appariement des graphes d’observation symbolique. L’algorithme teste s’il existeun mot commun entre les langages des deux graphes d’observation symbolique. En cas d’échec,l’algorithme vérifie leur intersection. Si le résultat est toujours négatif, nous déduisons que lesdeux workflows ne peuvent pas coopérer ensemble. Dans le cas contraire, nous concluons queles deux workflows peuvent coopérer étant donné qu’ils ont des fonctionnalités complémentaireset qu’ils ont le même comportement observable.

Ce chapitre ainsi que les deux précédents ont montré comment les workflows peuvent êtredécrits, abstraits et comparés. Dans le chapitre suivant, nous présentons la mise en œuvre deces différents concepts.

Chapitre 8

Mise en œuvre

Sommaire8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398.2 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408.2.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8.3 Structures de données pour le stockage des work�ows . . . . . . . . 1428.3.1 Matrice d'adjacence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428.3.2 Liste d'adjacence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438.3.3 Diagramme de décision binaire . . . . . . . . . . . . . . . . . . . . . . . 1458.3.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

8.4 Abstraction et publication de work�ow . . . . . . . . . . . . . . . . . 1518.5 Appariement et interconnexion des work�ows . . . . . . . . . . . . . 153

8.5.1 Interconnexion dynamique des services Web composés (BPEL) . . . . . 1538.5.2 Inférence sur les work�ows . . . . . . . . . . . . . . . . . . . . . . . . . . 156

8.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

8.1 Introduction

Le travail dans le cadre de cette thèse s’intéresse à la description, abstraction et appariementde workflows. Il a comme point de départ l’approche CoopFlow.

CoopFlow est une approche pour la coopération occasionnelle et à courte durée entre en-treprises où peu de contraintes structurelles sur la coopération sont définies à priori et où lespartenaires sont identifiés dynamiquement selon les besoins de la coopération. CoopFlow estcomposée de trois étapes, abstraction et publication de workflows, appariement et interconnexionde workflows, et coopération et surveillance de workflows.

Notre objectif est de proposer des structures de données pour stocker efficacement les work-flows, de fournir une description des workflows interprétable par des programmes et de faciliterla découverte et l’interconnexion dynamique des workflows tout en préservant leurs savoir-faire.Mis à part le stockage, nos contributions concernant tous les autres aspects ont été abordéesdans les chapitres précédents. Le but de ce chapitre est de présenter la mise en œuvre de cesdifférentes contributions.

139

140 Mise en œuvre

Pour stocker les workflows efficacement, il convient de faire une étude comparative de diffé-rentes structures de données pour le stockage de workflows. Raison pour laquelle, nous étudionstrois structures de données à savoir les listes, les matrices et les diagrammes de décision binaire.Nous comparons ces trois structures vis-à-vis de l’espace nécessaire pour le stockage d’un work-flow ainsi qu’au temps requis pour vérifier si un nœud est successeur d’un autre.

Le reste de ce chapitre est organisé comme suit. La première partie de ce chapitre (Sec-tion 8.2) sera consacrée à la présentation de l’architecture et la conception de l’approche ainsiqu’au choix d’implémentation de chaque classe. Dans la Section 8.3 nous présentons une étudecomparative de différentes structures de données permettant le stockage de workflows. Ensuite,nous abordons dans la Section 8.4 notre contribution en terme d’implémentation à l’étape abs-traction et publication de workflow de l’approche CoopFlow. La Section 8.5 présente notre implé-mentaion de l’étape appariement et interconnexion de workflows. Enfin nous donnons quelquesconclusions dans la Section 8.6.

8.2 Approche

Cette section est consacrée à la présentation de l’architecture et de la conception de notreapproche. Nous commençons par présenter l’idée générale de l’approche dans la section 8.2.1.Nous détaillons ensuite la conception de cette approche à travers un diagramme de classe dansla section 8.2.2.

8.2.1 Architecture

FIGURE 8.1 – Architecture

8.2 Approche 141

Dans la figure 8.1 nous présentons l’architecture de notre approche. Cette architecture estcomposée d’un module de création de workflows, d’un vérificateur de workflows, d’un moduled’annotation de workflows, d’un abstracteur, d’un module d’appariement et d’un annuaire pour lestockage de workflows.

D’abord les workflows sont décrits sémantiquement. Cette description peut être effectuée dedeux manières. Le premier type de description consiste à annoter sémantiquement des workflowsdécrits syntaxiquement. Le second type de description consiste à créer une ontologie de work-flows. Pour ce dernier type de description nous pouvons faire des inférences (reasoning) sur lesworkflows. Ces inférences permettent, entre autre, de vérifier la structure d’un workflow par rap-port à des règles bien définies. S’agissant de l’approche d’annotation sémantique des workflows,nous en avons fait deux déclinaisons, une pour les workflows en général et une deuxième pourles compositions de services Web. Nous avons utilisé SAXPDL comme langage de descriptionde workflows et BPEL combiné à SAWSDL comme langage de composition de services Web.

Une fois que les workflows sont décrits, ils sont ensuite abstraits. Cette abstraction permetde préserver le savoir-faire de chaque partenaire. Ensuite, les workflows étant abstraits, ils sontpubliés dans un annuaire afin qu’ils soient découverts par les partenaires. D’une part, l’annuairestocke les workflows et d’autre part, il est muni d’un service de courtage permettant la découvertede ceux-ci. Ensuite, en recevant des requêtes des utilisateurs, le service de courtage sollicite sonmodule d’appariement pour découvrir les workflows correspondant à la requête. Le module d’ap-pariement fait appel à un module d’extraction des donnés (parseur) pour extraire de la requête etdes workflows publiés dans l’annuaire les données à comparer. Il compare ensuite la sémantiquemétier et la sémantique comportementale de la requête avec celles des workflows publiés. Enfin,une réponse est retournée à l’utilisateur.

Après avoir présenté l’architecture de notre approche, nous présentons dans la section sui-vante la conception de celle-ci.

8.2.2 Diagramme de classe

Cette section présente la conception de notre approche via un diagramme de classe. La fi-gure 8.2 montre ce diagramme et dans ce qui suit nous détaillons le rôle de chacune de cesclasses.

La classe Abstracteur génère les workflows internes à partir des workflows coopératifs. Grâceà cette classe une abstraction structurelle et/ou comportementale peut être effectuée pour lesworkflows. Rappelons que l’objectif de l’abstraction est de préserver le savoir-faire des workflowspubliés dans l’annuaire.

La classe Annuaire permet d’enregistrer et découvrir les workflows.

Grâce à la classe Stockage l’annuaire stocke la sémantique métier et comportementale desworkflows d’une manière efficace.

La classe ServiceCourtage se charge de la découverte des workflows en se basant sur leurssémantiques métier et comportemental. Pour ce faire elle fait appel à la classe Apparieur. Deuxtypes d’appariement sont effectués sémantique et comportemental. La classe Comportementalcompare les sémantiques comportementales des workflows et la classe Semantique compare lessémantiques métier des workflows. Notons que l’appariement est indépendant de la façon dontles workflows sont stockés.

142 Mise en œuvre

La classe Parseur est utilisée par la classe Apparieur afin d’extraire les données sémantiquesdes descriptions des workflows.

La classe Superviseur se charge de la surveillance de la coopération. Elle permet égalementà des workflows déployés de découvrir les services qui leurs manquent et de les intégrer dansla composition sans avoir besoin d’être redéployés. Ainsi, cette classe permet de réaliser l’inter-connexion dynamique des workflows. Nous abordons en détail le fonctionnement de cette classedans la section 8.5.

La classe Propriete permet de chercher et manipuler tous les éléments nécessaires à la co-opération. Ces éléments sont formés de l’ensemble des partenaires intervenant dans la coopé-ration, les politiques de coopération contenant les règles d’interaction définissant les différentesresponsabilités des partenaires, les correspondances entre les activités réelles et virtuelles duworkflow et enfin l’ensemble des vues qu’offre un partenaire donné aux autres participants.

Une vue est formée d’une ou plusieurs activités virtuelles, d’une ou plusieurs places et d’unou plusieurs arcs. Chaque activité est reliée à une autre activité via une place et une activitéest reliée à une place via un arc. En d’autre termes, une vue n’est autre qu’un réseau de Pétrireprésentant la partie du workflow exposée à un partenaire donné.

La classe Partenaire (resp Regle et Correspondance) utilise la classe DetailsPartenaire (respDetailsRegle et DetailsCorrespondance) afin de stocker toutes les informations relatives à unpartenaire (resp. à une règle d’interaction et à une correspondance) sous forme de structures dedonnées.

Cette section a présenté l’architecture et la conception de notre approche pour la coopérationdes workflows. Un composant important de notre approche est l’annuaire permettant le stockageet la découverte des workflows. Dans la section suivante nous passons en revue les différentesstructures de données pouvant être utilisées pour le stockage des workflows.

8.3 Structures de données pour le stockage des workflows

L’objectif de cette section est d’étudier les différentes structures de données permettant lestockage des workflows. Étant donné que les workflows sont modélisés par des réseaux de Pétri,ils peuvent par conséquent être stockés en utilisant les structures de données habituellementutilisées pour stocker les graphes. Nous avons identifié trois structures de données permettant lestockage de graphes. Il s’agit des matrices d’adjacence, les listes d’adjacence et les diagrammesde décision binaire.

L’organisation du reste de cette section est la suivante. La section 8.3.1 commence par pré-senter les matrices d’adjacence. Ensuite, nous présentons dans la section 8.3.2 les listes d’adja-cence. La section 8.3.3 est consacré aux diagrammes de décision binaire. Enfin, nous comparonsces trois structures de données dans la section 8.3.4

8.3.1 Matrice d’adjacence

La première approche pour stocker les graphes consiste à utiliser les matrices d’adjacence.Dans ce cas, un graphe de n nœuds est représenté par une matrice M carrée de n2. Les nœudsdu graphe sont numérotés de 1 jusqu’à n et ces numéros sont utilisés comme indice de la matrice.

8.3 Structures de données pour le stockage des workflows 143

VerificateurWorkflow ServiceCourtage

Proprietes

Partenaire Regle Correspondance Vue

ActiviteVirtuelle Lien

1..11..*

1

1..* 1..* 1..*

1..*

PlaceDetailsPartenaire DetailsRegle DetailsCorrespondance

utiliseutilise

utilise

Abstracteur Apparieur

utilise

Parseur

ComportementalSemantique

Superviseur

invoque

utilise

produit

Annuaire

Stockage

FIGURE 8.2 – Diagramme de classe

Chaque case M [i][j] de la matrice contient 0 ou 1 suivant qu’il y un arc reliant les deux nœuds i

et j. Pour tester si un nœud est le successeur d’un autre, un seul test suffit (O(1)).

Pour montrer comment un graphe est représenté avec une matrice, nous prenons le graphedonné dans 8.3.

Le graphe contient quatre nœuds et il nécessite donc une matrice 4 × 4. Les nœuds A, B,C et D sont représentés par les indices 1, 2, 3 et 4 respectivement. Ce graphe ainsi que sareprésentation matricielle sont donnés dans la figure 8.3.

8.3.2 Liste d’adjacence

La deuxième structure permettant la représentation des graphes est la liste d’adjacence. Laliste d’adjacence représente l’ensemble des nœuds et associe à chaque nœud la liste de sessuccesseurs rangés dans un certain ordre. Ainsi un espace de O(n + p) est requis pour stockerun graphe orienté de n nœuds et p arcs.

Dans la figure 8.4 nous reprenons le graphe utilisé comme exemple pour les matrices et nousmontrons comment il est représenté par une liste d’adjacence.

144 Mise en œuvre

FIGURE 8.3 – Représentation d’un graphe avec une matrice d’adjacence

FIGURE 8.4 – Représentation d’un graphe avec une liste d’adjacence


8.3.3 Diagramme de décision binaire

Dans cette section nous présentons la dernière structure de données pour le stockage desgraphes à savoir : les diagrammes de décision binaire.

Le reste de cette section est organisé comme suit. Nous commençons dans la section 8.3.3.1par une présentation des notions de base de la logique propositionnelle qui sont utiles pour ladéfinition des diagrammes de décision binaire. Ensuite, étant donné qu’un diagramme de décisionbinaire est, par définition, écrit sous forme d’expressions booléennes if-then-else (INF), nousdéfinissons cette forme dans la section 8.3.3.2. La section 8.3.3.3 est consacrée à la procédurede construction des diagrammes de décision binaire. Le diagramme lors de cette étape peut êtreréduit grâce aux règles définies dans la section 8.3.3.4. La section 8.3.3.5 montre les diagrammesde décision binaire réduits. Enfin, nous présentons dans la section 8.3.3.6 comment un graphepeut être représenté par un diagramme de décision binaire.

8.3.3.1 Logique propositionnelle

Nous définissons ici le langage de la logique propositionnelle en précisant tout d’abord lasyntaxe puis la sémantique du langage.

8.3.3.1.1 Syntaxe Le langage de la Logique Propositionnelle est construit à partir de l’alphabetconstitué de :

– Un ensemble v de variables propositionnelles ;– Les parenthèses "(" et ")"– Les opérateurs, appelés également connecteurs, non "¬", ou " ∨", et " ∧ ", implique " ⇒ ",

équivaut "⇔"– les deux constantes vrai et faux que l’on peut noter également par "true" et "false" ou ">"

et "⊥" ou encore "0" et "1".

8.3.3.1.2 Expression Booléenne L’ensemble des expressions booléennes du calcul proposi-tionnel est le plus petit ensemble d’expressions tel que : Les variables propositionnelles et lesconstantes 1 et 0 sont des expressions booléennes. Si F est une expression booléenne alors ¬F

et (F ) sont des expressions booléennes. Si F et G sont des expressions booléennes alors F ∨ G,F ∧ G, F ⇒ G, F ⇔ G sont des expressions booléennes.

Dans la section suivante nous présentons quelques définitions

Définition 17 (Interprétation) Une interpretation I est une fonction I : v −→ {vrai, faux}. Uneinterprétation est généralisée d’une manière inductive à tout l’ensemble des expressions boo-léennes de la logique propositionne.

I(vrai) = vrai si I(faux) = faux

I(6= F ) = vrai si et seulement si I(F ) = faux

I(F ∨G) = vrai si et seulement si I(F ) = vrai ou I(G) = vrai

I(F ∧G) = vrai si et seulement si I(F ) = vrai et I(G) = vrai

Une interprétation booléenne est donc définie par l’interprétation de toute les variables qui lacomposent.

146 Mise en œuvre

8.3.3.2 Forme normale If-Then-Else (INF)

Soit l’interprétation t −→ t0, t1. L’opérateur if-then-else est défini par :

t −→ t0, t1 = (t ∧ t0) ∨ (¬t ∧ t1)

Par conséquent l’interprétation t −→ t0, t1 est vrai si t et t0 sont vrai ou si t est faux et t1 estvrai.

Tous les opérateurs peuvent être exprimés par if-then-else et les constantes 0 et 1. Parexemple ¬x est (x −→ 0, 1), x ⇔ y est x −→ (y −→ 1, 0), (y −→ 0, 1).

Une expression booléenne est dite en forme normale If-Then-Else si elle est construite en-tièrement avec des opérateurs if-the-else et les constantes 0 et 1.

t[0/x] désigne l’expression booléenne t dans la quelle on a substitué x par 0. Ainsi, nous avonsl’équivalence suivante :

t = x −→ t[1/x], t[0/x].

Cette équation est appelée l’expansion de Shannon de l’expression t en ce qui concerne lavariable x. L’expansion de Shannon permet la génération de la forme normale INF de n’importequelle expression booléenne.

Afin de générer la forme INF d’une expression t, on regarde si t ne contient pas de variables.Si c’est le cas, t est alors équivalente à 0 ou à 1 qui sont en forme INF. Dans le cas contraire,nous appliquons l’expansion de Shannon sur t en ce qui concerne une des variables x de t.Par conséquent, les deux expressions t0 = t[0/x] et t1 = t[1/x] contiennent chacune moins devariables que t. On peut construire ainsi récursivement la forme INF de t0 et de t1.

La forme INF de t est alors : x → t1, t0

8.3.3.3 Construction d’un diagramme de décision binaire

Dans cette section nous allons détailler comment un BDD peut être construit pour uneexpression booléenne. Pour ce faire, prenons l’exemple de l’expression booléenne suivante :t = (x1 ⇔ y1) ∧ (x2 ⇔ y2).

La première étape vers la construction du BDD consiste à choisir l’ordre des variables danslequel l’expansion de Shannon sera appliquée.

On choisit l’ordre de variables x1 < y1 < x2 < y2 sur lequel on applique l’expansion deShannon et on obtient les expressions suivantes :

t = x1 −→ t1, t0t0 = y1 −→ 0, t00t1 = y1 −→ t11, 0

t00 = x2 −→ t001, t000t11 = x2 −→ t111, t110

t000 = y2 −→ 0, 1t001 = y2 −→ 1, 0t110 = y2 −→ 0, 1t111 = y2 −→ 1, 0


FIGURE 8.5 – Graphe de décision binaire avant réduction

Ces expressions peuvent être représentées sous la forme du graphe donné dans la figure 8.5.Les arcs pointillés dans ce graphe désigne les branches else et les autres les branches then.

Nous constatons que de nombreuses expressions sont identiques. Par exemple, les expres-sions t110 et t000 d’une part et t111 et t001 d’autre part sont identiques. D’où l’idée de réduirece graphe en ne gardant qu’une seule expression des expressions identique. La réduction desgraphes de décision binaire est régie par les règles présentées dans la section suivante.

8.3.3.4 Règles de réduction

Avant de présenter les règles de réduction, nous rappelons que chaque nœud v du graphequi n’est pas une feuille est étiqueté par une une variable xk appelée indice de v, et a exactementdeux successeurs désignés par low(v) et high(v). Un arc pointillé dans le graphe (voir figure 8.5)relie un nœud v avec son successeur low(v) et l’arc continu relie v avec son successeur high(v).

Il y a deux types de réduction, la réduction par suppression et la réduction par fusion.

– La réduction par suppression peut être appliquée lorsqu’il y a un nœud v dans le BDD telque low(v) = high(v) = v′. Dans ce cas, tous les arcs qui pointent sur v sont redirigés surv′ et on supprime le nœud v. Dans la figure 8.6 nous donnons deux exemples de nœudsvérifiant cette propriété. En effet low(x2)=high(x2) dans les deux figures 8.6 -(a) et 8.6 -(c).

– La réduction par fusion peut être appliquée quand il y a deux nœuds v et v′ identiques, c’està dire high(v) = high(v′) et low(v) = low(v′). Dans ce cas, tous les arcs qui pointent sur v

sont redirigés sur v′ et on supprime le nœud v.

8.3.3.5 Diagramme de décision binaire réduit

En appliquant les règles données dans la section précédente nous pouvons réduire le BDDdonné dans la figure 8.5. Par exemple au lieu de t110on peut utiliser t000 et au lieu de t111 on peututiliser t001. En substituant t110 par t000 dans la partie droite de t11 et en substituant égalementt111 par t001, nous constatons que t00 et t11 sont identiques. Nous pouvons ensuite substituer t11

par t00 dans t1.

148 Mise en œuvre

(a)

x2 X3

10

x1

1

x1

x2

(b) (d)

x1

1

(c)

X3

10

x1

FIGURE 8.6 – Suppression des nœuds

FIGURE 8.7 – Graphe de décision binaire réduit

Après identification de toutes les expressions équivalentes, et en les remplaçant dans t nousobtenons les expressions suivantes :

t = x1 −→ t1, t0t0 = y1 −→ 0, t00t1 = y1 −→ t00, 0

t00 = x2 −→ t001, t000t000 = y2 −→ 0, 1t001 = y2 −→ 1, 0

Chacune des sous-expressions ci-dessus peut être vue comme un nœud dans un graphe.Chaque nœud peut être un terminal dans le cas où il est égal à 0 ou à 1, ou un non-terminaldans le cas contraire. Un nœud non-terminal possède un fils-gauche (low-edge) qui correspondà la partie else et un fils-droit (high-edge) qui correspond à la partie then (cf la figure 8.5). Legraphe ainsi obtenu est appelé diagramme de décision binaire réduit ROBDD (voir figure 8.7) .En général le terme BDD désigne un ROBDD.


FIGURE 8.8 – Un graphe G = (V, E) et un codage χ : E → {0, 1}2

Après avoir montré comment construire un diagramme de décision binaire, nous présentonsdans la section suivante comment représenter un graphe sous forme de diagramme de décisionbinaire.

8.3.3.6 Représentation d’un graphe par un BDD

Pour représenter un graphe par un BDD il faut définir sa fonction caractéristique. C’est celle-ci que nous représentons par le BDD. Soit G = (V, E) un graphe où V est un ensemble fini denœuds et où E ⊆ V ×V un ensemble fini de paires de nœuds, appelées arcs. Soit χE : E → {0, 1}la fonction caractéristique de l’ensemble des arcs de G. χE est définie par :

χE(v1, v2) = 1 ⇔ {v1, v2} ∈ E

La fonction caractéristique ne dépend pas que du graphe mais elle dépend également ducodage choisi pour coder les noeuds de celui-ci.

On note par | z |:= ∑n−1i=0 zi2i la valeur binaire réprésentée par la chaîne de n bits zn−1 . . . z0 ∈

{0, 1}n. Réciproquement, on note par [k]n, n ≥ dlog(k + 1)e, la chaîne de n bits représentantl’entier k ≥ 0. Afin de coder les sommets par des variables booléennes, nous employons laconvention suivante V = {[0]n . . . [N − 1]n} avec N ≥ 0 et n = dlog Ne.

Pour mieux illustrer comment coder un graphe par un BDD, voici un exemple utilisant ungraphe de taille réduite (voir figure 8.8). Ce graphe possède quatre noeuds A,B,C et D que nouspouvons coder sur 2 bits. On choisit par exemple 00, 01,10 et 11 pour coder respectivement A, B,C et D. Avec ce codage, nous obtenons la fonction caractéristique du graphe χE : {0, 1}4 → {0, 1}définie par :

χG(γ) ={

1, si γ ∈ {(00, 01), (01, 10), (10, 00), (11, 10), (01, 11)}0, sinon

La fonction caractéristique peut être directement représentée par un BDD. Ainsi, le BDD re-présentant le graphe 8.8 est donné dans la figure 8.9.

150 Mise en œuvre

FIGURE 8.9 – Le BDD représentant le graphe

8.3.4 Synthèse

Dans cette section nous comparons les trois structures des données permettant le stockagedes graphes que nous venons de présenter. Il s’agit des diagrammes de décision binaire (BDD),les matrices d’adjacence et les listes d’adjacence.

Premièrement, pour stocker un graphe de n nœuds il faut une matrice d’adjacence M de n2.Les nœuds du graphe sont numérotés de 1 jusqu’à n et ces numéros sont utilisés comme indicede la matrice. Chaque case M [i][j] de la matrice contient 0 ou 1 suivant qu’il y un arc reliant lesdeux nœuds i et j. Pour tester si un nœud est le successeur d’un autre, un seul test suffit (O(1)).

Deuxièmement, les listes d’adjacence permettent de stocker un graphe orienté de n nœudset p arcs sur un espace de l’ordre de O(n + p). Par contre, pour tester si un nœud est successeurd’un autre, il suffit de faire n tests au maximum.

Troisièmement, les diagrammes de décision binaire permettent de stocker un graphe de n

nœuds et p arcs sur un espace de l’ordre O(p ∗ log(n) ∗ (log(p) + log(log(n)) [56]. Pour tester siun nœud est le successeur d’un autre, il est nécessaire de faire log(n) tests au pire des cas.

Les workflows sont des graphes clairsemés (sparse graph) étant donné que chaque activitéest reliée généralement à un petit nombre (moins de dix) d’activités. De ce fait, il est plus avanta-geux de les représenter par des BDD que par les listes d’adjacence ou des matrices d’adjacence.Pour stocker des graphes clairsemés, l’espace requis par les BDDs est légèrement supérieur àcelui requis par les listes et il est largement inférieur à celui requis par les matrices [56][26]. Ce-pendant, le temps nécessaire pour tester si deux nœuds sont voisins dans un BDD est largementmeilleur que celui nécessaire pour tester le voisinage dans des listes et il est moins meilleur quecelui des matrices.

En outre, il a été montré dans [56][26] que les listes et les matrices ne sont pas adaptées pourstocker des graphes de grandes tailles. D’où l’intérêt d’utiliser les BDDs dans notre cas. En effet,lorsque les BDDs sont manipulés en mémoire, ils sont non seulement stockés dans la même table

8.4 Abstraction et publication de workflow 151

mais ils réutilisent les mêmes variables. Nous reproduirons la même chose sur disque, c’est à direque nous créons un seul BDD dans lequel nous stockons tous les workflows du même domaine.Étant donné que les mêmes activités peuvent être utilisées dans des workflows différents, cettetechnique s’avère donc avantageuse. Cette technique est intéressante dans la mesure où pluson rajoute des workflows, plus il y aura du partage.

Après avoir présenté les différentes structures de données pouvant être utilisées pour le sto-ckage de workflows, nous nous intéressons dans les sections suivantes à nos contributions enterme d’implémentation aux trois étapes de CoopFlow (abstraction et publication, appariement etinterconnexion, et coopération et surveillance de workflow).

8.4 Abstraction et publication de workflow

Les implémentations effectuées au niveau de cette étape sont un module pour l’abstraction deworkflows, un module pour l’appariement de workflows et un troisième module pour le stockagede workflows. Dans cette section nous nous contentons de présenter le module de stockage deworkflows.

Dans la section 8.3 nous avons montré comment coder un graphe non étiqueté sous formedes diagrammes de décision binaires (BDD). Dans cette section, nous adaptons les BDDs pourle stockage de workflows.

Étant donné qu’un workflow est représenté sous forme de graphe, notre objectif dans cettesection est de développer un module permettant de générer un BDD en sortie pour tout work-flow donné en entrée. Toutefois, deux particularités des workflows doivent être prises en comptelors de la représentation de ceux-ci sous forme de BDD. Premièrement, les workflows sont desgraphes étiquetés. En effet, à la différence du codage des graphes que nous avons montré, lorsdu codage d’un workflow nous avons besoin de coder à la fois les nœuds et les transitions. Lestockage des transitions est important car elles sont utilisées au moment de l’appariement.

Deuxièmement, le nombre de bits nécessaires pour coder les transitions dépend du nombredes transitions dans le workflow à stocker. Ainsi, la même transition (activité) peut être codéedifféremment suivant le nombre des transitions du workflow. Pour illustrer ce propos, prenons lesworkflows donnés dans la figure 8.10. Le workflow 8.10-(a) contient deux transitions et le workflow8.10-(b) contient quatre transitions. La première étape de la représentation des workflows sousforme de BDD consiste à coder en binaire les nœuds et les arcs.

Étant donné que nous voulons stocker les transitions dans le BDD (celles-ci sont nécessairespour l’appariement), nous ajoutons à la fin du codage de chaque arc le codage de la transitionreliant les deux extrémités de l’arc. Pour coder les deux transitions du workflow 8.10-(a), il nousfaut un seul bit (dlog(2)e) tandis que pour coder les transitions du workflow 8.10-(b), il nous fautdeux bits (dln(4)e). Le codage des transitions du workflow 8.10-(a) est fournie dans la figure8.10-(c) et le codage des transitions du workflow 8.10-(b) est donné dans la figure 8.10-(d). Pourstocker ces transitions dans le BDD, nous ajoutons leurs codages à la fin des ceux des arcs (voirfigures 8.10-(e) et 8.10-(f))

En ajoutant les codages des transitions à la fin des arcs, nous stockons ainsi les transitionsdans les BDDs. Cependant, un problème subsiste. Les transitions A e B n’ont pas les mêmescodes dans les deux workflows. Par conséquent, lors de l’appariement la transition A du workflow8.10-(a) ne sera pas considérée comme étant similaire à la transition A du workflow 8.10-(b) (A

152 Mise en œuvre

FIGURE 8.10 – Workflows codés sur un nombre de bits différents

est représenté par 0 dans 8.10-(a) et par 00 dans 8.10-(b)). Il en est de même pour la transitionB. Rappelons que chaque bit représente une variable dans le BDD et donc 00 est différentede 0. Pour comparer deux workflows, il faut qu’ils aient le même codage pour les transitions,c’est-à-dire que les transitions des deux workflows doivent être codées avec le même nombre debits. Ceci signifie que le nombre de bits sur lesquels les transitions seront codés doit être fixéindépendamment du nombre des transitions des workflows.

Nous proposons pour résoudre ce problème de fixer le codage des transitions selon le nombrede concepts représentant des activités dans l’ontologie. Ce nombre de concept est fixé indépen-damment des workflows. Supposons que l’ontologie utilisée pour annoter les deux workflows(8.10) est celle donnée dans la figure 8.11. La transition A est rattachée au concept concept3.Les transitions B, C et D sont rattachées aux concepts Concept6, Concept2, et Concept7 respec-tivement. L’ontologie contient sept concepts. Pour les coder en binaire, il nous faut trois bits. Lecodage de ces concepts est donné dans la figure 8.12.

A la place du codage des transitions précédemment utilisé, nous remplaçons le codage dechaque transition par celui du concept auquel elle est rattachée. L’avantage de ce choix est quela même activité aura le même codage dans tous les workflows auxquels elle appartient, ce quisimplifie l’appariement. L’inconvénient de ce codage est que si l’ontologie est modifiée, tous lesworkflows déjà publiés doivent être recodés. Compte tenu du fait que les ontologies changent peudans le temps et sont rarement modifiées, ce choix s’avère réaliste.

8.5 Appariement et interconnexion des workflows 153

FIGURE 8.11 – Ontologie des workflows

FIGURE 8.12 – Codage des concept et nouveau codage des arcs

Cette section a présenté la mise en œuvre d’un module pour le stockage de workflows. La sec-tion suivante aborde l’implémentation de la deuxième étape de CoopFlow à savoir : Appariementet interconnexion des workflows.

8.5 Appariement et interconnexion des workflows

Dans cette section nous abordons deux aspects de l’implémentation de l’étape appariement etinterconnexion de workflows. Il s’agit d’un module pour l’interconnexion dynamique des workflowset un pour l’inférence sur les workflows. La section 8.5.1 est consacrée à la présentation dupremier module. Le second module est présenté dans la section 8.5.2.

8.5.1 Interconnexion dynamique des services Web composés (BPEL)

L’objectif de l’interconnexion dynamique est de permettre à des workflows déployés de dé-couvrir et coopérer avec d’autres workflows sans qu’il y ait besoin de les redéployer à nouveau.Pour la mise en œuvre de cette interconnexion nous avons utilisé des services Web composés.Ces services Web composés sont décrits avec BPEL combiné à SAWSDL. Ainsi BPEL fournit lasémantique comportementale de la composition et SAXPDL présente la sémantique métier decette composition.

154 Mise en œuvre

Dans [65, 68] nous avons proposé une approche et une implémentation d’un module pourl’interconnexion des services Web composés. Grâce à ce module, la connaissance à l’avance detous les services impliqués dans une composition n’est plus nécessaire avant le déploiement. Enoutre, ce module permet également à un BPEL déployé de changer certains de ses services Websans avoir besoin d’être redéployé à nouveau.

Le diagramme de séquence 8.13 montre un scénario d’une interconnexion dynamique deBPELs. Le scénario implique deux BPELs, BPEL_A et BPEL_B. Ces deux BPEL sont déployés.Chacun de ces deux BPEL est composé d’un ensemble de services. Nous supposons que cer-tains services du BPEL_A et du BPEL_B ne sont pas disponibles. Nous supposons que les ser-vices manquant à BPEL_A sont fournis par BPEL_B et vice versa. Pour commencer le scénario,un client instancie le superviseur_A du BPEL_A. Le superviseur_A constate que certains servicesdu BPEL_A ne sont pas disponibles. Ensuite, superviseur_A envoie une requête à l’annuaire pourdécouvrir les services manquant. Ce dernier se sert de l’Abstracteur et de l’Apparieur pour ré-pondre à cette requête. L’annuaire estime que BPEL_B répond à la requête et retourne ainsi ausuperviseur_A l’adresse du superviseur_B. L’annuaire établit également un ensemble de proprié-tés spécifiant la correspondance entre les services et les règles régissant la coopération entre lesdeux compositions de services Web BPEL_A et BPEL_B.

Client

BPEL_A(Orchestra)

Superviseur_A Annuaire Abstracteur Apparieur Proprietes BPEL_B(Orchestra)

Superviseur_B

Demarer BPEL Requête

Réponse

Requête

Réponse Requête

Réponse

Invoque

Reçoit Envoie Invoque

Reçoit Reçoit Invoque

Reçoit Envoie

Invoque

Reçoit Reçoit Invoque

Reçoit

Terminer BPEL

FIGURE 8.13 – Diagramme de séquence montrant l’interaction entre deux BPEL

La figure 8.14 présente l’implémentation des différentes classes impliquées dans la coopéra-tion.

8.5.1.1 L’annuaire

Dans l’Annuaire, des abstractions des workflows sont stockées. L’annuaire dispose d’un ser-vice de courtage pour la découverte des workflows. Lorsqu’il reçoit une requête il fait appel àl’Abstracteur et l’Apparieur. L’accès à ces composants est transparent pour l’utilisateur. L’annuaireest implémenté en tant que EJB session sans état et il est exposé sous forme de service Web.

8.5 Appariement et interconnexion des workflows 155

Intergiciel

Intergiciel

Orchestra Orchestra

SOAP

(EJB statefull)

Superviseur

(EJB statefull)

Superviseur

(EJB Stateless)

Abstracteur

(EJB Stateless)

Apparieur

(EJB Stateless)

Annuaire

(EJB Stateless)

Propriete

Partneur

(EJB Entity) (EJB Entity) (EJB Entity) (EJB Entity)

Regles Corresponadance Vue

Parseur(EJB Stateless)

FIGURE 8.14 – Interaction dynamique entre deux BPELs sous Orchestra

8.5.1.2 Abstracteur

L’Abstracteur est sollicité par l’annuaire lorsqu’un nouveau workflow va y être publié. L’annuairefait également appel à l’Abstracteur quand il reçoit une requête. L’Abstracteur implémente une ac-tivité métier permettant de cacher les différents détails du workflow ne jouant aucun rôle directdans la coopération. L’accès à ce composant doit être facile et sa localisation doit être transpa-rente aux applications qui l’invoquent. C’est pour ces raisons là que nous avons choisi d’exposerl’Abstracteur comme un service Web et nous l’avons implémenté en tant qu’un EJB session sansétat.

8.5.1.3 Apparieur (MatchMaker)

L’Apparieur est utilisé par le service de courtage pour comparer les abstractions des work-flows. Il effectue deux types de comparaison, une comparaison des comportements des work-flows et une comparaison da la sémantique métier des workflows. Afin que l’Apparieur puisseêtre partagé par différents service de courtage nous avons choisi de l’implémenter en tant queEJB session sans état et il est exposé sous forme de service Web. Pour faciliter l’appariementsémantique, l’Apparieur fait appel à un parseur.

8.5.1.4 Parseur

Le parseur extrait les données sémantiques d’une description de workflow. Nous avons déve-loppé deux parseurs un pour le langage SAXPDL (Semantic annotation for XPDL) et le second

156 Mise en œuvre

pour le langage SAWSDL (Semantic annotation for WSDL). Pour faciliter le partage des parseurspar différents service d’appariement, nous les avons implémenté en tant que EJB session sansétat et nous les exposons sous forme de services Web.

8.5.1.5 Superviseur

Le Superviseur implémente une activité métier permettant l’envoi et la réception de donnéesainsi que des notifications. Il peut être utilisé par des applications distantes telles que les parte-naires distants ayant des compétences complémentaires. En outre, l’accès à ce composant estfacile et sa localisation ainsi que la complexité des détails de son implémentation sont cachéset transparents. Afin de conserver les ressources durant tout le cycle de vie de la coopération,nous avons choisi d’implémenter ce composant en tant que EJB session avec état et de l’ex-poser comme un Service Web. Ainsi, toutes les données utilisées et les contrats requis pour lacoopération persistent après l’interrogation du superviseur. Nous avons intégré dans le code dusuperviseur des méthodes JAX-RPC pour les appels distants des services des partenaires. Eneffet, grâce à sa simplicité et aux fonctionnalités qu’il offre JAX - RPC correspond à nos besoinsde développement.

Dans cette section nous avons présenté un module pour l’interconnexion dynamique des ser-vices Web composés. La section suivante aborde l’inférence sur les workflows.

8.5.2 Inférence sur les workflows

Dans le chapitre 5 nous avons présenté une ontologie pour la description des workflows.Les workflows décrits en utilisant cette ontologie peuvent être enrichis et contrôlés grâce à unensemble de règles d’inférence que nous avons définies.

Pour implémenter ces règles nous avons utilisé des fonctions procédurales prédéfinies dansJena [36] comme lessThan ( ?x, ?y) (retourne vrai si la valeur de x est inférieur à la valeur de y)ou notEqual( ?x, ?y) (retourne vrai si les deux variables sont différentes). Étant donné que l’ex-pressivité de Jena est limitée (des fonctions comme not ou l’opérateur existentiel n’existent pas),nous avons implémenté des fonctions (Builtin) spécifiques telle que VerifierValidite( ?Date), Ren-dreIndisponible( ?X), DefinirDispo( ?X) . . . . Nous avons également développé la méthode Work-flowNonValid( ?W) qui affiche un message d’erreur au développeur du workflow et détruit lesworkflows non valides.

A titre d’exemple, pour rendre un workflow indisponible, nous avons besoin de détruire la pro-priété aDisponibilite reliant un workflow et une disponibilité. Pour ce faire, nous avons développéle Builtin SupprimerPropriete (voir figure 8.15). En effet, lorsqu’on a besoin d’une fonctionnalitéqui n’est pas proposée par Jena, on doit définir une classe qui hérite de la classe Builtin et implé-menter les méthodes getName(),getArgLength(),headAction(Node[] args, int length, RuleContextcontext) et (Node[] args,int length,RuleContext context).

La méthode getName() doit retourner le nom de la classe (ici supprimerPropriete). La méthodegetArgLength() doit retourner le nombre de paramètre qui doit être donné au Builtin (ici 3).

Lorsque le Builtin se trouve en partie gauche d’une règle, c’est la méthode bodyCall qui seraexécutée, sinon c’est la méthode headAction qui sera exécutée. Étant donné que notre BuiltinSupprimerPropriete se trouve en partie droite d’une règle, nous utilisons par conséquent laméthode headAction.

8.6 Conclusion 157

1 static class SupprimerPropriete extends BaseBuiltin {2 public String getName(){3 return "supprimerPropriete";4 }5 public int getArgLength(){6 return 3;7 }8 public void headAction(Node[] args, int length, RuleContext context){9 String objet =nameSpaceToName(args[0].toString());10 String valeur =nameSpaceToName(args[1].toString());11 String propriete = args[2].toString();1213 OntoFileHandle ont = new OntoFileHandle();14 Individual ind=ont.findIndividual(objet,model);15 Individual indVal=ont.findIndividual(valeur,model);16171819 OntProperty p = model.getOntProperty(ind.getNameSpace()+propriete);20 // System.out.println("la propriete est "+p.getLocalName());21 NodeIterator ni = ind.listPropertyValues(p);22 while (ni.hasNext()) {23 RDFNode node = ni.nextNode();24 if(node.toString().equals(args[1].toString())){25 ind.supprimerPropriete(p,node);26 break;27 }28 }29 }30 public boolean bodyCall(Node[] args,int length,RuleContext context) {31 return true;32 }33 }

FIGURE 8.15 – Le Builtin définissant la suppression d’une propriété d’un concept

8.6 Conclusion

Ce chapitre a été consacré à la mise en œuvre et la validation de notre approche. Nous avonscommencé par présenter l’architecture globale ainsi que la conception de notre approche. Étantdonné que le stockage de workflow est important pour notre travail, nous avons procédé ensuite àune étude comparative de differentes structures de données permettant le stockage de workflows.

Ensuite, nous nous sommes intéressés à nos contributions en termes d’implémentaion auxtrois étapes de CoopFlow à savoir, abstraction et publication, appariement et interconnexion, etcoopération et surveillance de workflow. Nous avons présenté les différentes classes et justifié lechoix des technologies utilisées pour l’implémentation.

Cependant, compte tenu de l’inutilité de détailler toute l’implémentation, nous avons choiside présenter l’implémentation de trois points à savoir : le stockage de workflows, un prototypepour l’interconnexion dynamique de workflows de services Web (BPEL), et l’inférence sur lesworkflows.

Le choix de la structure de données pour stocker les workflows s’est porté sur les diagrammesdes décisions binaires (BDD). Nous avons montré comment les BDD peuvent être adapté afin derépondre à nos besoin en termes de stockage et appariement des workflows.

Le prototype d’interconnexion dynamique des services Web composés BPELs permet à desBPELs d’être déployé même si les services impliqués dans la composition ne sont pas connu aumoment du déploiement. En outre, il offre la possibilité de découvrir automatiquement les servicesmanquant à BPEL et de les interconnecter avec la composition BPEL.

158 Mise en œuvre

Enfin, l’inférence sur les workflows a permis, quant à elle, d’enrichir et contrôler des workflowsdécrits avec une ontologie. Nous avons définis des règles et utilisé les moteurs d’inférence deJena pour accomplir cette tâche.

Chapitre 9

Conclusions et perspectives

9.1 Conclusions

Les travaux de cette thèse s’inscrivent dans le cadre d’une approche pour la coopérationascendante de workflows. Nous avons pris comme point de départ l’approche CoopFlow. Celle-ciest une approche pour la coopération occasionnelle et à courte durée entre entreprises où peude contraintes structurelles sur la coopération sont définies à priori et où les partenaires sontidentifiés dynamiquement selon les besoins de la coopération. CoopFlow est composée de troisétapes, abstraction et publication de workflows, appariement et interconnexion de workflows, etcoopération et surveillance de workflows.

Dans la première étape de CoopFlow, la publication et l’abstraction de workflows, les entre-prises publient leurs workflows au sein d’un annuaire commun. Afin de préserver le savoir-fairede chaque entreprise participante à la coopération, CoopFlow propose de n’exposer à l’extérieurque la partie du workflow nécessaire à la coopération et de cacher toutes les structures et lesinformations internes qui ne jouent aucun rôle direct dans la coopération.

La deuxième étape de CoopFlow, appariement et interconnexion de workflows, consiste àidentifier et ensuite interconnecter les workflows souhaitant coopérer. Cette identification se faiten comparant les abstractions des workflows publiés dans l’annuaire lors de la première étape. Lerésultat de cette étape est un ensemble de politiques de coopération décrivant les responsabilitéset les rôles joués par chacun des partenaires dans la coopération.

Une fois que chaque entreprise a identifié ses partenaires, la troisième et dernière étapeconsiste à déployer et à exécuter le workflow interentreprises.

Cependant l’approche CoopFlow présente quelques limites. Premièrement, la procédured’abstraction de CoopFlow est entièrement informelle. Pour pallier ce manque nous avons pro-posé dans le cadre de cette thèse deux méthodes formelles pour l’abstraction des workflows. Ils’agit d’une méthode structurelle et une méthode comportementale.

La deuxième limite de CoopFlow est que les workflows publiés sont seulement décrits syntaxi-quement. Pour remédier à ce problème nous avons proposé de décrire les sémantiques métieret comportementale des workflows. Une telle description permet, entre autres, le partage desdonnées et facilite l’appariement. Cette description sémantique nous a permis également d’avoirune qualité d’appariement meilleure que celle de CoopFlow. Cette description sémantique, nous

159

160 Conclusions et perspectives

avons proposé de la décrire de deux manières. La première description sémantique consiste à an-noter les workflows décrits syntaxiquement en utilisant des ontologies de domaines. La deuxièmedescription est faite en créant une ontologie de workflows. Nous avons montré les cas où l’une oul’autre description est plus adaptée.

La troisième limite de CoopFlow à laquelle nous avons remédié est que celle-ci ne permetpas aux workflows déjà déployés de découvrir et coopérer ensuite avec d’autres workflows sansqu’ils soient redéployés à nouveau. Pour valider cet aspect nous avons proposé un prototype pourl’interconnexion dynamique des workflows de services Web décrits avec BPEL.

En plus de ces trois contributions, nous nous sommes intéressés au stockage de workflows.En effet, pour pouvoir publier des workflows dans un annuaire, il est nécessaire de les stocker.Pour ce faire, nous avons étudié différentes structures de données permettant ce stockage. Aprèscette étude, il s’est avéré que les diagrammes de décision binaire sont les plus efficaces. Ainsi,nous les avons utilisés dans notre annuaire de workflows.

La réalisation de ces différentes contributions a permis la définition et la mise en place d’unannuaire de workflows muni d’un service de courtage. Cet annuaire permet de prendre en compteles aspects liés à :

– la préservation du savoir-faire de chaque partenaire : Cet objectif a été réalisé grâce àla proposition de deux méthodes d’abstraction des workflows. Celles-ci sont formelles etgarantissent la préservation du lange du workflow.

– la découverte automatique des workflows : Afin de rendre la découverte automatique desworkflows possible, nous avons développé deux algorithmes d’appariement de workflows.Le premier est dédié à la comparaison de la sémantique métier des workflows et il se basesur une description sémantique que nous avons proposée. Le second algorithme comparela sémantique comportementale des workflows.

– le stockage des workflows : le dernier aspect pris en compte par notre annuaire concernele stockage des workflows. Dans ce cadre, nous avons utilisé des structures de donnéesefficaces en termes d’espace.

Notre annuaire permet donc de stocker efficacement les workflows. Il est muni d’un service decourtage offrant un algorithme polynomial (O(n2)) pour la comparaison de la sémantique compor-tementale des workflows. Notre algorithme se base en effet sur la trace des workflows. Commenous l’avons vu dans l’état de l’art de cette thèse, d’autres algorithmes basés sur la bissimulationou sur l’équivalence par simulation offrent une qualité d’appariement meilleur que celle fourniepar notre algorithme. Cependant, tous ces algorithmes sont exponentiels. Ils peuvent être utili-sés quand il s’agit de comparer deux workflows. Par contre, lorsqu’on envisage de comparer unworkflow avec un nombre important de workflows, ces algorithmes deviennent inadaptés. Notreannuaire a par conséquent le mérite de pouvoir stocker et rechercher efficacement les workflows.Il a, en revanche, l’inconvénient suivant. Étant donné un workflow W1 pour lequel nous cherchonsun partenaire, le service de courtage nous retourne le workflow W2 comme étant compatible àW2. Il n’est pas garanti que tous les comportements de W2 sont compatibles avec tous les com-portements de W1. Toutefois, le service de courtage garantit qu’il y a au moins un comportementde W1 compatible avec un comportement de W2.

Enfin, la fusion de notre annuaire et de CoopFlow offrira aux entreprises une plateforme com-plète pour la description sémantique et la découverte des workflows ainsi que l’intégration dessystèmes de gestion de workflows hétérogènes.

9.2 Perspectives 161

9.2 Perspectives

Le travail que nous avons proposé ne résout pas tous les problèmes liés à la coopération inter-entreprises, plusieurs perspectives de recherches complémentaires nous semblent intéressantesà explorer.

9.2.1 Amélioration de l’appariement

Actuellement notre algorithme pour comparer les sémantiques comportementales se basesur la trace des workflows. Nous avons vu que si notre service de courtage nous retourne unworkflow W2 comme étant partenaire potentiel d’un workflow W1, il n’est pas garanti que tous lescomportements de W2 soient compatibles avec ceux de W1. En vu d’améliorer la qualité d’appa-riement de notre service de courtage, nous envisageons d’y inclure une comparaison basée surla bissimulation. Nous utilisons tout d’abord notre algorithme polynomial pour sélectionner uneliste réduite de workflows pouvant coopérer avec W1. Ensuite, nous appliquons l’algorithme basésur la bissimulation sur cette liste réduite.

9.2.2 Abstraction structurelle ou abstraction comportementale

Pour préserver le savoir-faire des partenaires nous avons proposé de cacher les parties deworkflows ne jouant aucun rôle direct dans la coopération. Ceci est réalisé grâce à l’abstrac-tion. Nous avons proposé deux méthodes d’abstraction une structurelle et une comportementale.L’abstraction structurelle réduit la structure de workflows. L’abstraction comportementale, quant àelle, se base sur la réduction de graphe représentant le comportement de workflows. Afin d’appli-quer à chaque workflow le type d’abstraction qui lui soit adapté, nous envisageons d’étudier troiscas de figures. La première étude consiste à identifier les classes de workflows où l’abstractionstructurelle est plus adaptée. Dans un deuxième temps, nous allons identifier les workflows oùl’abstraction comportementale est plus adaptée. Troisièmement, il est également possible quedans certains cas la combinaison de deux types d’abstraction soient meilleur que l’utilisation del’une ou l’autre abstraction.

9.2.3 Cohérence de propriétés

Dans nos travaux sur l’appariement et la description sémantique des workflows, nous avonsproposé un langage permettant de décrire les requêtes des utilisateurs par l’exemple. Pour expri-mer sa requête, l’utilisateur fournit les propriétés des éléments qu’il recherche. Le langage permetégalement aux utilisateurs de spécifier des préférences sur les éléments de la requête. Cepen-dant, il est possible que les propriétés fournies aussi bien que les préférences spécifiées soientcontradictoires entre elles. Nous envisageons de développer cet aspect afin de pallier ce manque.

9.2.4 Vérification de propriétés non fonctionnelles

L’abstraction structurelle que nous avons proposée est régie par un ensemble de règles. Nousavons montré que l’application de ces règles préserve les formules de la logique linéaire tem-porelle. Notre exploitation de cette caractéristique s’est limitée à la préservation de la trace des

162 Conclusions et perspectives

workflows projetés sur leurs activités coopératives. Nous envisageons étudier d’autres formulesde la logique linéaire temporelle qui peuvent être utiles pour la coopération.

D’autre part, nous envisageons d’étendre notre étude sur les propriétés des workflows à unautre aspect. Il s’agit de partir de l’hypothèse que les workflows satisfont un certain nombrede propriétés telles que la soundeness [84] du workflow qui consiste à vérifier (1) qu’il n’existepas d’activités bloquantes et (2) que le workflow termine et que lors de sa terminaison seule saplace finale est marquée, et ensuite étendre nos algorithmes tel que l’algorithme de matchingpour préserver ces propriétés. Le but est de fournir des mécanismes permettant de préserverde bonnes propriétés de workflows après l’interconnexion. Par exemple, il est judicieux d’assurerque l’interconnexion de workflows non bloquant donne lieu à un workflow interentreprises nonbloquant.

Annexe A

Code source de l’exemple

A.1 Code source de l’ontologie en OWL

<?xml version="1.0"?> <rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:xsd="http://www.w3.org/2001/XMLSchema#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xmlns="http://www.owl-ontologies.com/unnamed.owl#"

xml:base="http://www.owl-ontologies.com/unnamed.owl">

<owl:Ontology rdf:about=""/>

<owl:Class rdf:ID="Materiel">

<rdfs:subClassOf>

<owl:Class rdf:ID="Location"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="VerifierCot">

<rdfs:subClassOf>

<owl:Class rdf:ID="Cotisation"/>

</rdfs:subClassOf>

<owl:disjointWith>

<owl:Class rdf:ID="EncaisserCot"/>

</owl:disjointWith>

</owl:Class>

<owl:Class rdf:ID="Estimer">

<owl:disjointWith>

<owl:Class rdf:ID="Notifier"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:ID="Facturer"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:ID="Evaluer"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:ID="Aviser"/>

</owl:disjointWith>

163

164 Code source de l’exemple

<owl:disjointWith>

<owl:Class rdf:ID="Reparer"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:ID="Declarer"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:ID="Rembourser"/>

</owl:disjointWith>

<rdfs:subClassOf>

<owl:Class rdf:ID="operations"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="Taxi">

<rdfs:subClassOf>

<owl:Class rdf:ID="Voiture"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:about="#Evaluer">

<owl:disjointWith rdf:resource="#Estimer"/>

<owl:disjointWith>

<owl:Class rdf:about="#Notifier"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:about="#Rembourser"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:about="#Aviser"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:about="#Declarer"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:about="#Facturer"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:about="#Reparer"/>

</owl:disjointWith>

<rdfs:subClassOf>

<owl:Class rdf:about="#operations"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="ExpStrategie">

<rdfs:subClassOf>

<owl:Class rdf:ID="Expert"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:about="#Location">

<rdfs:subClassOf>

<owl:Class rdf:ID="services"/>

</rdfs:subClassOf>

</owl:Class>

A.1 Code source de l’ontologie en OWL 165

<owl:Class rdf:about="#Facturer">

<owl:disjointWith>


</owl:disjointWith>

<owl:disjointWith>


</owl:disjointWith>


<owl:disjointWith>

<owl:Class rdf:about="#Declarer"/>

</owl:disjointWith>

<owl:disjointWith rdf:resource="#Evaluer"/>

<owl:disjointWith>


</owl:disjointWith>

<owl:disjointWith>


</owl:disjointWith>

<rdfs:subClassOf>


</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="AutreFacture">

<owl:disjointWith>

<owl:Class rdf:ID="FactureReparationAccident"/>

</owl:disjointWith>

<rdfs:subClassOf>

<owl:Class rdf:ID="GestionFacture"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="Rapport">

<rdfs:subClassOf rdf:resource="#services"/>

</owl:Class>

<owl:Class rdf:ID="Notification">

<rdfs:subClassOf>

<owl:Class rdf:ID="ReponseCompagnie"/>

</rdfs:subClassOf>

<owl:disjointWith>

<owl:Class rdf:ID="AvisPourReparation"/>

</owl:disjointWith>

</owl:Class>

<owl:Class rdf:ID="Etude">

<rdfs:subClassOf rdf:resource="#Rapport"/>

</owl:Class>

<owl:Class rdf:ID="messages">

<rdfs:subClassOf>

<owl:Class rdf:ID="InterfaceClient"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="VoitPourPersonnel">

<rdfs:subClassOf>

<owl:Class rdf:about="#Voiture"/>


</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:about="#Expert">


</owl:Class>

<owl:Class rdf:ID="FactureProfessionnel">

<owl:disjointWith>

<owl:Class rdf:ID="FactureParticuliers"/>

</owl:disjointWith>

<rdfs:subClassOf>

<owl:Class rdf:about="#FactureReparationAccident"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:about="#Voiture">

<rdfs:subClassOf rdf:resource="#Location"/>

</owl:Class>

<owl:Class rdf:ID="Comptabilite">


</owl:Class>

<owl:Class rdf:ID="DevisEtabli">

<owl:disjointWith>

<owl:Class rdf:ID="DeclarerAccident"/>

</owl:disjointWith>

<rdfs:subClassOf>

<owl:Class rdf:ID="RequeteClient"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="DegatAuto">

<rdfs:subClassOf>

<owl:Class rdf:ID="Evaluation"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:about="#GestionFacture">

<owl:disjointWith>

<owl:Class rdf:about="#Cotisation"/>

</owl:disjointWith>

<owl:disjointWith>

<owl:Class rdf:ID="Remboursement"/>

</owl:disjointWith>

<rdfs:subClassOf rdf:resource="#Comptabilite"/>

</owl:Class>

<owl:Class rdf:ID="Agence">

<rdfs:subClassOf rdf:resource="#Location"/>

</owl:Class>

<owl:Class rdf:about="#InterfaceClient">


</owl:Class>

<owl:Class rdf:about="#Declarer">

<owl:disjointWith>


</owl:disjointWith>




<owl:disjointWith>


</owl:disjointWith>

<owl:disjointWith>


</owl:disjointWith>

<owl:disjointWith>


</owl:disjointWith>

<owl:disjointWith rdf:resource="#Facturer"/>

<rdfs:subClassOf>


</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:about="#Cotisation">


<owl:disjointWith>

<owl:Class rdf:about="#Remboursement"/>

</owl:disjointWith>

<owl:disjointWith rdf:resource="#GestionFacture"/>

</owl:Class>

<owl:Class rdf:about="#Remboursement">

<owl:disjointWith rdf:resource="#GestionFacture"/>

<owl:disjointWith rdf:resource="#Cotisation"/>


</owl:Class>

<owl:Class rdf:about="#Reparer">

<rdfs:subClassOf>


</rdfs:subClassOf>



<owl:disjointWith rdf:resource="#Declarer"/>

<owl:disjointWith>


</owl:disjointWith>

<owl:disjointWith>


</owl:disjointWith>

<owl:disjointWith>


</owl:disjointWith>


</owl:Class>

<owl:Class rdf:about="#FactureParticuliers">

<rdfs:subClassOf>

<owl:Class rdf:about="#FactureReparationAccident"/>

</rdfs:subClassOf>

<owl:disjointWith rdf:resource="#FactureProfessionnel"/>

</owl:Class>

<owl:Class rdf:about="#RequeteClient">


<rdfs:subClassOf rdf:resource="#messages"/>

<owl:disjointWith>

<owl:Class rdf:about="#ReponseCompagnie"/>

</owl:disjointWith>

</owl:Class>

<owl:Class rdf:about="#EncaisserCot">

<rdfs:subClassOf rdf:resource="#Cotisation"/>

<owl:disjointWith rdf:resource="#VerifierCot"/>

</owl:Class>

<owl:Class rdf:about="#Rembourser">




<owl:disjointWith>


</owl:disjointWith>

<owl:disjointWith rdf:resource="#Reparer"/>


<owl:disjointWith>


</owl:disjointWith>

<rdfs:subClassOf>


</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:about="#Evaluation">

<rdfs:subClassOf rdf:resource="#Rapport"/>

</owl:Class>

<owl:Class rdf:about="#Notifier">



<owl:disjointWith>


</owl:disjointWith>



<owl:disjointWith rdf:resource="#Rembourser"/>


<rdfs:subClassOf>


</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:about="#DeclarerAccident">

<rdfs:subClassOf rdf:resource="#RequeteClient"/>

<owl:disjointWith rdf:resource="#DevisEtabli"/>

</owl:Class>

<owl:Class rdf:ID="VoitPourClient">

<rdfs:subClassOf rdf:resource="#Voiture"/>

</owl:Class>

<owl:Class rdf:about="#ReponseCompagnie">

<owl:disjointWith rdf:resource="#RequeteClient"/>

<rdfs:subClassOf rdf:resource="#messages"/>


</owl:Class>

<owl:Class rdf:about="#operations">

<rdfs:subClassOf rdf:resource="#InterfaceClient"/>

</owl:Class>

<owl:Class rdf:about="#Aviser">


<owl:disjointWith rdf:resource="#Notifier"/>

<owl:disjointWith rdf:resource="#Rembourser"/>





<rdfs:subClassOf rdf:resource="#operations"/>

</owl:Class>

<owl:Class rdf:about="#AvisPourReparation">

<owl:disjointWith rdf:resource="#Notification"/>

<rdfs:subClassOf rdf:resource="#ReponseCompagnie"/>

</owl:Class>

<owl:Class rdf:ID="ExpImmobilier">

<rdfs:subClassOf rdf:resource="#Expert"/>

</owl:Class>

<owl:Class rdf:ID="ExpAuto">

<rdfs:subClassOf rdf:resource="#Expert"/>

</owl:Class>

<owl:Class rdf:ID="EvalImmoblier">

<rdfs:subClassOf rdf:resource="#Evaluation"/>

</owl:Class>

<owl:Class rdf:about="#FactureReparationAccident">

<owl:disjointWith rdf:resource="#AutreFacture"/>

<rdfs:subClassOf rdf:resource="#GestionFacture"/>

</owl:Class>

<owl:ObjectProperty rdf:ID="hasParameter">

<rdfs:domain rdf:resource="#operations"/>

<rdfs:range rdf:resource="#messages"/>

</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="loueVoit">

<rdfs:range rdf:resource="#Voiture"/>

<rdfs:domain rdf:resource="#Agence"/>


<owl:ObjectProperty rdf:ID="effectue">

<rdfs:domain rdf:resource="#ExpStrategie"/>

<rdfs:range rdf:resource="#Etude"/>

<rdfs:subPropertyOf>

<owl:ObjectProperty rdf:ID="Etablit"/>

</rdfs:subPropertyOf>


<owl:ObjectProperty rdf:about="#Etablit">

<rdfs:domain rdf:resource="#Expert"/>

<rdfs:range rdf:resource="#Rapport"/>


<owl:ObjectProperty rdf:ID="evalueI">

<rdfs:domain rdf:resource="#ExpImmobilier"/>

<rdfs:subPropertyOf rdf:resource="#Etablit"/>

<rdfs:range rdf:resource="#EvalImmoblier"/>


<owl:ObjectProperty rdf:ID="loueMat">

<rdfs:domain rdf:resource="#Agence"/>

<rdfs:range rdf:resource="#Materiel"/>


<owl:ObjectProperty rdf:ID="evalueD">

<rdfs:subPropertyOf rdf:resource="#Etablit"/>

<rdfs:domain rdf:resource="#ExpAuto"/>

<rdfs:range rdf:resource="#DegatAuto"/>


</rdf:RDF>



A.2 Code source du workflow de l’assuré en XPDL

<?xml version="1.0" encoding="UTF-8"?> <Package Id="0" Name="sample

workflow process" xmlns="http://www.wfmc.org/2002/XPDL1.0"

xmlns:xpdl="http://www.wfmc.org/2002/XPDL1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.wfmc.org/2002/XPDL1.0

http://wfmc.org/standards/docs/TC-1025_schema_10_xpdl.xsd">

<PackageHeader>

<XPDLVersion>0.09</XPDLVersion>

<Vendor>XYZ, Inc</Vendor>

<Created>6/18/2002 5:27:17 PM</Created>

</PackageHeader>

<ConformanceClass GraphConformance="NON_BLOCKED"/>

<TypeDeclarations>

<TypeDeclaration Id="AccuseRec" Name="AccuseRec">

<ExternalReference location="http://www-inf/samples/xpdl/assure.xsd"/>

</TypeDeclaration>

<TypeDeclaration Id="DevisInfo" Name="DevisInfo">


</TypeDeclaration>

<TypeDeclaration Id="AvisComp" Name="AvisComp">


</TypeDeclaration>

<TypeDeclaration Id="EvalEnvoyé" Name="EvalEnvoyé">


</TypeDeclaration>

<TypeDeclaration Id="factureEnvoyé" Name="factureEnvoyé">


</TypeDeclaration>

<TypeDeclaration Id="RemboursmComp" Name="RemboursmComp">


</TypeDeclaration>

A.2 Code source du workflow de l’assuré en XPDL 171

<TypeDeclaration Id="DeclarationInfo" Name="DeclarationInfo">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="NomAssuré" type="xsd:string"/>

<xsd:element name="PrénomAssuré" type="xsd:string"/>

<xsd:element name="IdAssuré" type="xsd:integer"/>

<xsd:element name="DateAcc" type="xsd:date"/>

<xsd:element name="Lieu" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</TypeDeclaration>

</TypeDeclarations>

<Participants>

<Participant Id="DBConnection">

<ParticipantType Type="SYSTEM"/>

<Description>Reference to Database Resource</Description>

</Participant>

</Participants>

<WorkflowProcesses>

<WorkflowProcess AccessLevel="PUBLIC" Id="1" Name="AssuréProcess">

<ProcessHeader/>

<FormalParameters>

<FormalParameter Id="declaratOut" Index="1" Mode="OUT">

<DataType>

<DeclaredType Type="DeclarationInfo"/>

</DataType>

</FormalParameter>

<FormalParameter Id="MsgRetourne" Index="2" Mode="IN">

<DataType>

<DeclaredType Type="AccuseRec"/>

</DataType>

</FormalParameter>

<FormalParameter Id="devisOut" Index="3" Mode="OUT">

<DataType>

<DeclaredType Type="DevisInfo"/>

</DataType>

</FormalParameter>

<FormalParameter Id="AvisCompany" Index="4" Mode="IN">

<DataType>

<DeclaredType Type="AvisComp"/>

</DataType>

</FormalParameter>

<FormalParameter Id="evalAssuré" Index="5" Mode="OUT">

<DataType>

<DeclaredType Type="EvalEnvoyé"/>

</DataType>

</FormalParameter>

<FormalParameter Id="factureAccid" Index="6" Mode="OUT">

<DataType>

<DeclaredType Type="FactureEnvoyé"/>

</DataType>

</FormalParameter>


<FormalParameter Id="paiementComp" Index="7" Mode="IN">

<DataType>

<DeclaredType Type="RemboursmComp"/>

</DataType>

</FormalParameter>

</FormalParameters>

<DataFields>

<DataField Id="accidInfo" IsArray="FALSE">

<DataType>

<BasicType Type="INTEGER"/>

</DataType>

</DataField>

</DataFields>

<Applications>

<Application Id="composeDeclaration">

<FormalParameters>

<FormalParameter Id="accidInfo" Index="1" Mode="IN">

<DataType>

<BasicType Type="STRING"/>

</DataType>

</FormalParameter>

<FormalParameter Id="acciDeclaration" Index="2" Mode="OUT">

<DataType>

<DeclaredType Id="DeclarationInfo"/>

</DataType>

</FormalParameter>

</FormalParameters>

</Application>

<Application Id="verifAvis">

<FormalParameters>

<FormalParameter Id="avisInfo" Index="1" Mode="IN">

<DataType>

<DeclaredType Id="AvisComp"/>

</DataType>

</FormalParameter>

</FormalParameters>

</Application>

</Applications>

<Activities>

<Activity Id="1" Name="Decl">

<Implementation>

<Tool Id="composeDeclaration" Type="APPLICATION">

<ActualParameters>

<ActualParameter>accidInfo</ActualParameter>

<ActualParameter>declaratOut</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>

<TransitionRestrictions>

<TransitionRestriction>

<TransitionRefs>

<TransitionRef Id="1->2"/>


</TransitionRefs>

</TransitionRestriction>

</TransitionRestrictions>

</Activity>

<Activity Id="2" Name="Acc">

<Implementation>

<Tool Id="recevoireAccuse" Type="APPLICATION">

<ActualParameters>

<ActualParameter>MsgRetourne</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>



<TransitionRefs>


</TransitionRefs>



</Activity>

<Activity Id="3" Name "Etablire Devis" >

<Route/>






</Activity>

<Activity Id="4" Name="Dev">

<Implementation>

<Tool Id="envoyerDevis" Type="APPLICATION">

<ActualParameters>

<ActualParameter>devisOut</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>



<TransitionRefs>


</TransitionRefs>



</Activity>

<Activity Id="5" Name="Av">

<Implementation>

<Tool Id="verifAvis" Type="APPLICATION">

<ActualParameters>

<ActualParameter>AvisCompany</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>




<Split Type="XOR">

<TransitionRefs>



</TransitionRefs>

</Split>



</Activity>

<Activity Id="6" Name="Eval">

<Implementation>

<Tool Id="evaluer" Type="APPLICATION">

<ActualParameters>

<ActualParameter>evalAssuré</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>



<TransitionRefs>


</TransitionRefs>



</Activity>

<Activity Id="7" Name="Reparer">

<Implementation>

<No/>

</Implementation>

</Activity>

<Activity Id="8" Name="Fact">

<Implementation>

<Tool Id="facturer" Type="APPLICATION">

<ActualParameters>

<ActualParameter>factureAccid</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>



<TransitionRefs>


</TransitionRefs>



</Activity>

<Activity Id="9" Name="Payer">

<Implementation>

<Tool Id="payer" Type="APPLICATION">

<ActualParameters>


<ActualParameter>paiementComp</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>

</Activity>

<Transitions>

<Transition From="1" Id="1->2" To="2"/>









</Transitions>

</WorkflowProcess>

</WorkflowProcesses>

<ExtendedAttributes>

<ExtendedAttribute Name="MadeBy" Value="JaWE"/>

<ExtendedAttribute Name="Version" Value="1.0"/>

</ExtendedAttributes>

</Package>

Annexe A

Construction du graphe demarquage

Dans ce qui suit, nous appliquons l’algorithme de construction de graphe de marquage sur leworkflow de l’assuré donné dans la section 2.4. Pour chaque étape nous donnons l’évolution desdifférentes structures de l’algorithme. Pour illustrer cet exemple, nous disposons de cinq tableaux(voir figure A.1) : un tableau contenant les différents marquages qui ne sont pas complètementtraités (figure A.1-(a)), un tableau contenant l’ensemble des marquages accessibles ainsi que lestransitions qui leur ont donné lieu (figure A.1-(b)), un tableau présentant les pré conditions desdifférentes transitions (figure A.1(c)), un tableau présentant les post conditions des différentestransitions (figure A.1(d)) et enfin un tableau illustrant le marquage courant à traiter (figure A.1(e)).

Dans la figure A.2, nous commençons par initialiser les structures de données A_explorer etAccessibles avec le marquage initial. Nous remarquons que la seule transition dont le vecteur depré conditions est inférieur au marquage initial est la transition Declaration. Ainsi, nous calculonsle marquage accessible depuis Declaration et nous l’ajoutons aux deux ensembles A_explorer etAccessibles.

Dans la figure A.3, nous traitons le seul marquage de A_explorer (M ′1). La seule transition

dont le vecteur de pré conditions est inférieur à M ′1 est la transition Accuse. Ainsi, nous calculons

le marquage accessible depuis Accuse et nous l’ajoutons aux deux ensembles A_explorer etAccessibles.


dont le vecteur de pré conditions est inférieur à M ′1 est la transition Etablir Devis. Ainsi, nous

calculons le marquage accessible depuis Etablir Devis et nous l’ajoutons aux deux ensemblesA_explorer et Accessibles.


dont le vecteur de pré conditions est inférieur à M ′1 est la transition Devis. Ainsi, nous calcu-

lons le marquage accessible depuis Devis et nous l’ajoutons aux deux ensembles A_explorer etAccessibles.


dont le vecteur de pré conditions est inférieur à M ′1 est la transition Avis. Ainsi, nous calculons le

marquage accessible depuis Avis et nous l’ajoutons aux deux ensembles A_explorer et Acces-sibles.

177

178 Construction du graphe de marquage

FIGURE A.1 – Structures de données de l’algorithme de construction de graphe de marquage

Dans la figure A.8, nous traitons le seul marquage de A_explorer (M ′1). Chacune des tran-

sitions Evaluation et Reparer dispose d’un vecteur de préconditions inférieur à M ′1. Ainsi, nous

calculons les deux marquages accessibles depuis Evaluation et Reparer et nous les ajoutons auxdeux ensembles A_explorer et Accessibles.

Dans la figure A.9, nous traitons le premier marquage de A_explorer (M ′1). La seule transi-

tion dont le vecteur de pré conditions est inférieur à M ′1 est la transition Evaluation. Ainsi, nous

calculons le marquage accessible depuis Evaluation.


dont le vecteur de pré conditions est inférieur à M ′1 est la transition Reparer. Ainsi, nous calculons

le marquage accessible depuis Reparer.


dont le vecteur de pré conditions est inférieur à M ′1 est la transition Facture. Ainsi, nous calculons

le marquage accessible depuis Facture.

179

FIGURE A.2 – Marquage accessible depuis la transition Declaration

FIGURE A.3 – Marquage accessible depuis la transition Accuse


dont le vecteur de pré conditions est inférieur à M ′1 est la transition Paiement. Ainsi, nous calcu-

lons le marquage accessible depuis Paiement.


FIGURE A.4 – Marquages accessibles depuis la transition Etablir Devis

FIGURE A.5 – Marquages accessibles depuis la transition Devis

Nous remarquons qu’il n’existe plus aucune transition dont le vecteur de pré condition estinférieur à M ′

1 et par conséquent il n’existe aucun marquage état accessible depuis M ′1.

De la même manière, nous pouvons traiter le deuxième marquage M ′2. Le marquage ac-

cessible depuis la transition Reparer est S10. Or ce marquage existe déjà dans l’ensemble desmarquages Accessibles. En effet, le marquage S10 est le même que S8.

181

FIGURE A.6 – Marquages accessibles depuis la transition Avis

FIGURE A.7 – Marquage accessible depuis la transition Facture


FIGURE A.8 – Marquages accessibles depuis les transitions Evaluation et Reparer

FIGURE A.9 – Marquage accessible depuis la transition Evaluation

183

FIGURE A.10 – Marquage accessible depuis la transition Reparer

FIGURE A.11 – Marquage accessible depuis la transition Paiement

Bibliographie

[1] Frank Manola, Eric Miller. RDF Primer . http ://www.w3.org/TR/rdf-primer/, Février 2004.

[2] M. K. Smith, C. Welty, D. L. McGuinness. OWL Web Ontology Language Guide.http ://www.w3.org/TR/2004/RECowlguide20040210/, Février 2004.

[3] 01 Informatique rédaction. Dossier SOA : Des architectures pas conçues pour les métiers. 01 Informatique, (1927) :40–49, 29 Novembre 2007.

[4] M. Ader. Le workflow ou la productivité des entreprises de demain.http ://www.wngs.com/downloads/wf_prod_entr.pdf.

[5] G. Alonso, D. Agrawal, A. E. Abbadi, and C. Mohan. Functionality and limitations of currentworkflow management systems. IEEE Expert - Special Issue on Cooperative InformationSystemes, 12(5), 1997.

[6] G. Alonso and C. Mohan. Workflow management systems : The next generation of distri-buted procesing tools, 1997.

[7] A. Arnold. Systèmes de transitions finis et sémantique des processus communicants. Mas-son, Paris, France, 1992.

[8] K. Barkaoui and L. Petrucci. Structural analysis of workflow nets with shared resources. InW. Aalst, G. Michelis, and C. A. Ellis, editors, Workflow Management : Net-based Concepts,Models, Techniques and Tools (WFM’98), volume 98/7, pages 82–95, Lisbon, Portugal,June 1998. Eindhoven University of Technology, Eindhoven.

[9] A. Basu and A. kumer. Research commentary : Workflow management issues in e-business. Information Systems Research, 13(1) :1–14, 2002.

[10] M. Beaudouin-Lafon, editor. Computer Supported Co-operative Work, volume 7 of Trendsin Software. John Wiley & Sons, 1999.

[11] T. Berners-Lee, J. Hendler, and O. Lassila. The Semantic Web. Scientific American,284(5) :34–43, 2001.

[12] G. Berthelot. Transformations et analyse de reseaux de Pétri - application aux protocoles.PhD thesis, Université P. et M. Curie, Paris, France, Octobre 1983.

[13] G. BRAMS. Réseaux de Pétri : Théorie et Pratique. Masson, Paris, France, 1983.

[14] J. Charlet, P. Laublet, and C. Reynaud. Web sémantique Rapport final. Rapport de re-cherche, Action spécifique 32 CNRS / STIC, FRANCE, Octobre 2003.

[15] I. Chebbi. CoopFlow : une approche pour la coopération ascendante de workflows dansle cadre des entreprises virtuelles. PhD thesis, Insitut National des Télécommunications,Evry, France, Avril 2007.

185

186 BIBLIOGRAPHIE

[16] I. Chebbi, S. Dustdar, and S. Tata. The view-based approach to dynamic inter-organizational workflow cooperation. Data and Knowledge Engineering Journal,56(2) :139–173, 2006.

[17] I. Chebbi and S. Tata. CoopFlow : a framework for inter-organizational workflow coope-ration. In Proceedings of International Conference on Cooperative Information Systems,pages 112–129, Agia Napa, Cyprus, 31 Octobre - 4 Novembre 2005.

[18] I. Chebbi, S. Tata, and S. Dustdar. Cooperation policies for inter-organizational workflows. InTeamware : supporting scalable virtual teams in multi-organizational settings, Symposiumon Applications and the Internet, Trento, Italy, 31 Janvier - 4 Février 2005.

[19] A. Choquet-Geniet. Les Réseaux de Pétri : Un outil de modélisation. Dunod, Paris, France,2006.

[20] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web services descriptionlanguage (WSDL) Version 1.1. Technical report, W3C Note, Mars 2001.

[21] D. B. Claro, P. Albers, and J.-K. Hao. Approaches of web services composition - comparisonbetween BPEL4WS and OWL-S. In International Conference on Enterprise InformationSystems (ICEIS 4), pages 208–213, 2005.

[22] J. C. Corrales, D. Grigori, and M. Bouzeghoub. BPEL processes matchmaking for servicediscovery. In Proceedings International Conference on Cooperative Information Systems,Montpelier, France, Novembre 2006.

[23] R. David and H. Alla. Pétri Nets and Grafcet : Tools for Modelling Discrete Event Systems.Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1992.

[24] De Bruijn J. et al. The web service modeling language WSML. WSML Final Draft, DERI,Octobre 2005.

[25] J. Desel and J. Esparza. Free choice Pétri nets. Cambridge University Press, New York,NY, USA, 1995.

[26] C. Dong and P. Molitor. What graphs can be efficiently represented by bdds ? In ICCTA’07 : Proceedings of the International Conference on Computing : Theory and Applications,pages 128–134, Washington, DC, USA, 2007. IEEE Computer Society.

[27] C. A. Ellis and G. J. Nutt. Modelling and enactment of workflow systems. In M. A. Marsan,editor, Application and Theory of Pétri Nets, volume 691 of Lecture Notes in ComputerScience, pages 1–16. Springer-Verlag, Berlin, 1993.

[28] F. L. et D. Roller. Production Workflow, Concepts ant techniques. Prentice-Hall, Inc, 2000.

[29] D. Fensel and C. Bussler. The web service modeling framework WSMF. Electronic Com-merce Research and Applications, 1(2) :113–137, 2002.

[30] D. Grigori, J. C. Corrales, and M. Bouzeghoub. Behavioral matchmaking for service re-trieval. In Proceedings IEEE International Conference on Web Services, Chicago, USA,Septembre 2006.

[31] S. Haddad, J.-M. Ilié, and K. Klai. Design and evaluation of a symbolic and abstraction-based model checker. In F. Wang, editor, Automated Technology for Verification and Analy-sis : Second International Conference, Taipei, Taiwan, ROC, volume 3299 of Lecture Notesin Computer Science, pages 196–210. Springer-Verlag, Berlin, 31 Octobre - 3 Novembre2004.

[32] Haddad, S. et al. Efficient reductions for LTL formulae verification. Technical report,LAMSADE-CNRS et CEDRIC-CNRS, 2004.

BIBLIOGRAPHIE 187

[33] J. Hidders, M. Dumas, W. M. P. van der Aalst, A. H. M. ter Hofstede, and J. Verelst. Whenare two workflows the same ? In CATS ’05 : Proceedings of the 2005 Australasian sympo-sium on Theory of computing, volume 41, pages 3–11, Newcastle, NSW, Australia, 2005.Australian Computer Society.

[34] M. C. Jaeger, G. Rojec-Goldmann, G. Mühl, C. Liebetruth, and K. Geihs. Ranked matchingfor service descriptions using OWL-S. In P. Müller, R. Gotzhein, and J. B. Schmitt, edi-tors, Kommunikation in verteilten Systemen (KiVS 2005), Informatik Aktuell, pages 91–102,Kaiserslautern, Germany, Février 2005. Springer.

[35] J. o. Z. Jan Mendling. Transformation of BPEL processes to EPCS. In Proceedings of 4thGI Workshop on Event-Driven Process Chains (EPK2005), 2005.

[36] Jena. project homepage : http ://jena.sourceforge.net/, consulé Mars 2008.

[37] H. Kadima and V. Monfort. Les Web Services. Dunod, Paris, France, 2003.

[38] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, Y. Lafon, and C. Barreto. Web serviceschoreography description language version 1.0. World Wide Web Consortium, CandidateRecommandation CR-ws-cdl-10-20051109, Novembre 2005.

[39] W. Khansa. Réseaux de Pétri P-Temporels contribution à l’étude des systèmes à événe-ments discrets. PhD thesis, Ecole Supérieure d’Ingénieur d’Annecy, Annecy, France, Mars1997.

[40] B. Kiepuszewski, A. H. M. ter Hofstede, and W. M. P. van der Aalst. Fundamentals of controlflow in workflows. Springer, Berlin, Germany, 2003.

[41] K. KLAI. Réseaux de Pétri : Vérification Modulaire et Symbolique. PhD thesis, UniversitéParis 6, Paris, France, Decembre 2003.

[42] K. Klai, N. Ould Ahmed M’Bareck, and S. Tata. Behavioral technique for workflow abstrac-tion and matching. In Business Process Management, Lecture Notes in Computer Science,pages 477–483, Vienna, Austria, 2006. Springer.

[43] D. Kozen. Results on the propositional mu-calculus. Theoretical Computer Science,27(3) :333–354, 1983.

[44] d. L. Fisher. The workflow hndbook 2001. Published in association with the WorkflowManagement Coalition (WfMC), Octobre 2000.

[45] R. Lara, D. Roman, A. Polleres, and D. Fensel. A conceptual comparison of WSMO andOWL-S. In Proceedings of the European Conference on Web Services (ECOWS 2004), 112004.

[46] F. Leymann. Web Services Flow Language (WSFL 1.0). Technical report, IBM Corporation,Mai 2001 2001.

[47] A. Marten. Verteilte Geschäftsprozesse - Modellierung und Verifikation mit Hilfe von WebServices. PhD thesis, Institut für Informatik, Humboldt Universität zu Berlin, 2003.

[48] A. Martens. On Usability of Web Services. In C. Calero, O. Díaz, and M. Piattini, editors,Proceedings of 1st Web Services Quality Workshop (WQW 2003), Rome, Italy, 2003.

[49] A. Martens. Simulation and Equivalence between BPEL Process Models. In Proceedings ofthe Design, Analysis, and Simulation of Distributed Systems Symposium (DASD’05), Partof the 2005 Spring Simulation Multiconference (SpringSim’05), San Diego, California, Avril2005.

[50] O.-S. Matcher. project homepage : http ://owlsm.projects.semwebcentral.org.

188 BIBLIOGRAPHIE

[51] S. A. McIlraith, T. C. Son, and H. Zeng. Semantic web services. IEEE Intelligent Systems,16(2) :46–53, 2001.

[52] B. Messmer. Graph Matching Algorithms and Applications. PhD thesis, University of Bern,1995.

[53] P. Molinaro, D. Delfieu, and O. Roux. Improving the calculus of the marking graph of pétri netwith bdd like structure. In IEEE International Conference on Systems, Man and Cybernetics,pages 43– 48, Octobre 2002.

[54] T. Murata. Pétri nets : properties, analysis, and applications. Proceedings of the IEEE,77(4) :541–580, Avril 1989.

[55] N. Guarino. Formal ontology and information systems. In Proceedings of the 1st Inter-national Conference on Formal Ontologies in Information Systems, FOIS’98, pages 3–15,Trento, Italy, 1998. IOS Press.

[56] R. Nunkesser and P. Woelfel. Representation of graphs by obdds. In Proceedings of theInternational Society for Augmentative and Alternative Communication, volume 3827 of Lec-ture Notes in Computer Science, pages 1132–1142, Hainan, China, 2005. Springer.

[57] OMG. Unified modeling language (uml) version 1.5.http ://www.omg.org/technology/documents/formal/uml.htm.

[58] OMG. Corba facilities architecture specification, www.omg.org/corba/cf2.html. Technicalreport, http://www.omg/org, 1998.

[59] OMG. Corba components, www.omg.org/docs/orbos/99-02-05.pdf. Technical report,http://www.omg/org, 1999.

[60] OMG. Workflow Process Definition. OMG Document BOM/99-10-03, Novembre 1999.

[61] OMG. Workflow Management Facility Convenience Document combining dtc/99-07-05dtc/2000-02-03 (WF RTF 1.3 Report). OMG (Object Management Group), February 142000.

[62] OMG. Workflow Management Facility Specification, V 1.2. OMG (Object ManagementGroup), Avril 2000.

[63] OMG. The Common Object Request Broker - Architecture and Specifications. Revision 2.6.Omg document formal/o1-12-01, http://www.omg/org, Décembre 2001.

[64] Osworkflow. project homepage : http ://www.opensymphony.com/osworkflow/.

[65] N. Ould Ahmed M’Bareck and S. Tata. BPEL Behavioral abstraction and matching. InIn Advances in Semantics for Web services Workshop, pages 495–506, Vienna, Austria,2006.

[66] N. Ould Ahmed M’Bareck and S. Tata. Workflow semantic description for inter-organizational cooperation. In Technologies for Collaborative Business Process Manage-ment (TCoB’06) In conjunction with ICEIS 2006, pages 62–71, Paphos, Cyprus, Mai 2006.INSTICC Press.

[67] N. Ould Ahmed M’Bareck and S. Tata. How to consider requester’s preferences to enhanceweb service discovery ? In International Conference on Internet and Web Applications andServices (ICIW’07), pages 13–19, Le Morne, Mauritius, Mai 2007. IEEE Computer Society.

[68] N. Ould Ahmed M’Bareck and S. Tata. Semantic bpel process cooperation. In IADIS Inter-national Conference WWW/Internet, pages 238–242, Vila Real, Portugale, 2007.

BIBLIOGRAPHIE 189

[69] N. Ould Ahmed M’Bareck, S. Tata, and Z. Maamar. Towards an approach for enhancingweb services discovery. In 16th IEEE International Workshops on Enabling Technologies :Infrastructures for Collaborative Enterprises (WETICE’07), pages 357–364, Paris, France,2007. IEEE Computer Society.

[70] OWL-S Coalition. Bringing semantics to web services : The OWL-S Approach. In SemanticWeb Services and Web Process Composition Workshop, volume 3387 of Lecture Notes inComputer Science, pages 26–42, San Diego, CA, USA, July 2004.

[71] R. C. Read, D. G. Corneil . The Graph Isomorphism Disease. Graph Theory, 1 :339–363,1977.

[72] SAWSDL. project homepage : http ://lsdis.cs.uga.edu/projects/meteor-s/sawsdl/.

[73] W. Schulze. Fitting the workflow management facility into the object management archi-tecture. In Patel, D., Sutherland, J., Miller, J. éditeurs, 3rd Workshop on Business ObjectDesign and Implementation ( OOPSLA’97), pages 109–117, Atlanta/Georgia, USA, 1997.Springer-Verlag.

[74] W. Schulze, M. Böhm, and K. Meyer-Wegener. Services of workflow objects and workflowmeta-objects in omg-compliant environments. In Proceedings of the 1996 Object-OrientedProgramming, Systems, Languages & Applications (OOPSLA) Workshop on Business Ob-ject Design and Implementation, San Jose (CA), 1996.

[75] H. Schuster, D. Georgakopoulos, A. Cichocki, and D. Baker. Modeling and composingservice-based nd reference process-based multi-enterprise processes. In CAiSE’00 : Pro-ceedings of Advanced Information Systems Engineering, 12th International Conference,volume 1789 of Lecture Notes in Computer Science, pages 247–263, Stockholm, Sweden,Juin 2000. Springer.

[76] A. Seaborne. RDQL - a Query Language for RDF, project homepage :http ://www.w3.org/submission/2004/subm-rdql-20040109/, Consulé Juin 2008.

[77] Shark. project homepage : http ://www.enhydra.org/workflow/shark/index.html.

[78] K. Sivashanmugam, K. Verma, A. Sheth, and J. Miller. Adding semantics to web servicesstandards. In International Conference on Web Services (ICWS’03), pages 395–401, LasVegas, Nevada, June 2003.

[79] M. K. Smith, C. Welty, and D. L. McGuinness. OWL Web Ontology Language Guide.http ://www.w3.org/TR/2004/RECowlguide20040210/, February 2004.

[80] R. Snodgrass. The interface description language : definition and use. Computer SciencePress, Inc., New York, NY, USA, 1989.

[81] T. Andrews et al. Business Process Execution Language for Web Services, Version 1.1,Mai 2003.

[82] S. Thatte. XLANG - Web Services for Business Process Design. Initial public draft, MicrosoftCorporation, Mars 2001.

[83] UDDI. project homepage : http ://uddi.xml.org/.

[84] W. M. P. van der Aalst. Structural Characterizations of Sound Workflow Nets. ComputingScience Reports 96/23, Eindhoven University of Technology, Eindhoven, 1996.

[85] W. M. P. van der Aalst. The Application of Pétri Nets to Workflow Management. The Journalof Circuits, Systems and Computers, 8(1) :21–66, 1998.

190 BIBLIOGRAPHIE

[86] W. M. P. van der Aalst. Interorganizational workflows : An approach based on messagesequence charts and pétri nets. Systems Analys is - Modelling - Simulation, 34(3) :335–367, 1999.

[87] W. M. P. van der Aalst and T. Basten. Inheritance of workflows : an approach to tacklingproblems related to change. Theoretical Computer Science, 270(1-2) :125–203, 2002.

[88] W. M. P. van der Aalst, B. Kiepuszewski, and A. P. Barros. Workflow patterns. Distributedand Parallel Databases, 14(1) :5–51, Juillet 2003.

[89] W. M. P. van der Aalst, D. Moldt, R. Valk, and F. Wienberg. Enacting interorganizationalworkflow using nets in nets. In M. R. Jörg Becker, Michael zur Mühlen, editor, WorkflowManagement ’99, pages 117–136. Universität Münster, Task Force Workflow, Münster, 111999.

[90] W. M. P. van der Aalst and A. H. M. ter Hofstede. YAWL : Yet another workflow language.QUT Technical report FIT-TR-2003-04, Queensland University of Technology, Brisbane,2002.

[91] W. M. P. van der Aalst, K. M. van Hee, and G. J. Houben. Modelling workflow managementsystems with high-level Pétri nets. In G. de Michelis, C. Ellis, and G. Memmi, editors,Proceedings of the second Workshop on Computer-Supported Cooperative Work, Pétrinets and related formalisms, pages 31–50, 1994.

[92] W.-M.-P. van der Aalst and M. Weske. The p2p approach to interorganizational workflows.In Proceedings of the 13th International Conference on Advanced Information SystemsEngineering, pages 140–156. Springer-Verlag, 2001.

[93] M. Weber and E. Kindler. The Pétri Net Markup Language. In H. Ehrig, W. Reisig, G. Rozen-berg, and H. Weber, editors, Pétri Net Technology for Communication-Based Systems, vo-lume 2472 of Lecture Notes in Computer Science, pages 124–144. Springer-Verlag, 2003.

[94] WfMC. Workflow Reference Model, Workow Management Coalition, www.wfmc.org, Janvier1995.

[95] WfMC. Workflow standard - interoperability abstract specification version 1.0. Wfmc-tc-1012, Workflow Management Coalition, Octobre 20th 1996.

[96] WfMC. Audit data specification. Wfmc-tc-1015, WfMC (Workflow Management Coalition),Septembre 1998.

[97] WfMC. Terminology & glossary, WFMC-TC-1011, Version 3.0, Février 1999.

[98] A. Wombacher and B. Mahleko. Finding trading partners to establish ad-hoc businessprocesses. In CoopIS/DOA/ODBASE, volume 2519 of Lecture Notes in Computer Science,pages 339–355, Irvine, California, USA, 2002. Springer.

[99] Workflow Management Coalition. WfMC : Process Definition Language : XPDL 2.0. Speci-fication TC-1025, Workflow Management Coalition, 2005.

[100] WSMO. project homepage : http ://www.wsmo.org/.

[101] WSMX. project homepage : http ://www.wsmx.org/.

[102] Xflow. project homepage : http ://xflow.sourceforge.net/.

[103] J.-L. Zhao. Workflow management in the age of e-business. In Tutorial at the 35th HawaiiInternational Conference on System Sciences, Waikoloa, Hawaii, Janvier 2002.

une approche sémantique pour la description, …tata/pdf/these-nomane.pdfla démocratisation de la...

Documents