Une approche sémantique pour la description, l abstraction et l interconnexion de workflows dans un contexte inter-organisationnel

Transcription

1 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 avec l 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 National des 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étiers M. Charoy, François HDR, Maître de Conférences à l Université de Nancy Examinateurs : M. Benslimane, Djamal Professeur à l Université de Lyon M. Vincent, Hugues Architecte Système à Thales Communications France M. 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

2

3

4 Résumé La démocratisation de la technologie de l information et des moyens de communication ouvre la voie aux entreprises pour réaliser, via la coopération, certaines tâches complexes qui n étaient pas à 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 des workflows. Cette approche doit supporter la description, l abstraction et l interconnexion de workflows. Pour ce faire, nous proposons premièrement de décrire les sémantiques métiers et comportementale des workflows. Une telle description permet le partage des données d une part, et facilite l interconnexion automatique d autre part. Deuxièmement, les workflows sont publiés dans un annuaire commun. Nous proposons dans cette thèse des structures de donnés permettant de stocker efficacement les workflows dans l annuaire. Troisièmement, afin de préserver le savoirfaire des différents partenaires participant à une coopération, nous proposons deux méthodes formelles 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 le comportement. Enfin, après l abstraction et la publication de workflows, nous procédons dans la dernière étape à leur interconnexion. Pour faciliter cette interconnexion nous proposons un service de courtage pour la découverte des workflows. Ce service prend en compte les sémantiques métier et comportemental des workflows. Nous avons validé les solutions proposées à l aide d un prototype permettant l interconnexion dynamique des compositions de services Web BPEL. Mots-clés : workflows interentreprises, description sémantique, abstraction, coopération, services Web.

5 Abstract The democratization of information technology and the mean of communication opens the way for the companies to carry out, via the co-operation, certain complex tasks which were not with their range, either because of their size (they are often small or medium-sized companies), or because 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 interconnection on the other hand. Secondly, the workflows are published in a common registry. We propose in this thesis structures of data allowing to effectively store the workflows in the directory. Thirdly, in order to preserve the know-how of the different partners taking part in a co-operation, we propose two formal methods for the abstraction of the workflows. The first method is based on structural reduction rules while the second is based on the reduction of the graph representing the behaviour. Lastly, after the abstraction and the publication of workflows, we proceed in the last step to their interconnection. To facilitate this interconnection we propose a broker for the discovery of the 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 of the compositions of Web services BPEL. Keywords : Web services. semantic description, interorganizational workflows, abstraction, cooperation,

6

7 Table des matières I Problématique et État de l art 1 1 Introduction 3 2 Contexte et problématique Contexte général Préliminaire Définitions Les workflows vus par la WfMC Les workflows vus par l OMG Approche ascendante vs approche descendante Principes à préserver par l approche de la coopération choisie Coopération dans le cadre de l approche CoopFlow Point de départ : L approche CoopFlow Abstraction et publication de workflow Appariement et interconnexion de workflows Coopération et surveillance de workflows Limites de CoopFlow Objectif de la thèse Exemple support Synthèse Langages de description de workflows et de services Web Description syntaxique de workflows BPEL4WS YAWL (Yet Another Workflow Language) XPDL vii

8 viii TABLE DES MATIÈRES 3.2 Description sémantique de services Web OWL-S Motivations de OWL-S Ontologie supérieure de OWL-S SAWSDL Motivations de SAWSDL Annotation sémantique WSMO Motivations de WSMO Les facettes de WSMO Synthèse Appariement comportemental de workflows Introduction Préliminaire sur les réseaux de Pétri Définitions Séquence de franchissement et conflit Propriétés des réseaux de Pétri Propriétés dynamiques Propriétés structurelles Agglomération structurelle Post-agglomération structurelle Les propriétés de la réduction post-agglomération La propriété HF-interchangeabilité La propriété F-indépendance La propriété F-continuation Pré-agglomeration structurelle Les propriétés de la réduction pre-agglomération La propriété H-indépendance La propriété de non divergence structurelle La propriété de quasi-persistance structurelle La propriété de H-similarité Appariement de workflows

9 TABLE DES MATIÈRES ix Exemple Approches d appariement comportemental des workflows Types d équivalence des workflows Equivalence des traces Equivalence par bissimulation Equivalence par simulation Utilisabilité des workflows Découverte de services en utilisant la spécification du comportement Transformation de WSCL en graphe La décomposition des interactions Règles de comparaison Synthèse Conclusion II Contributions 59 5 Description sémantique de workflows Introduction Exemple d ontologie modélisant le domaine de l assurance Comptabilité Interaction Client Location Expert Annotation sémantique de XPDL (SAXPDL) Principe de l annotation sémantique Les mécanismes d annotation L attribut modelreference de SAXPDL L attribut schemamapping de SAXPDL Annotation des documents XPDL Annotation des activités Annotation des types de données Capacités des activités OWL-Ontologie pour les workflows inter-organisationnel

10 x TABLE DES MATIÈRES Limites du méta-modèle des workflows de WfMC Ontologie de workflows Exemple Inference sur l ontologie des workflows Règles générales Règles métier Synthèse et conclusion Abstraction structurelle et comportementale de workflows Introduction Graphe de marquage Abstraction structurelle Préservation de la trace du workflow projetée sur ses activités coopératives Formalisation des règles d abstraction définies dans [15] Deuxième catégorie de règles d abstraction Propriété particulière des workflows Règles d abstraction Abstraction comportementale Construction des graphes d observation symboliques Exemple Préservation du langage Conclusion Appariement métier et comportemental de workflows Introduction Appariement de la sémantique métier Introduction Exemple Requête par l exemple (QBE ) Préférences utilisateurs Différencier entre les entrées et les sorties lors de l appariement Algorithme d appariement sémantique Appariement de concepts Impact des préférences utilisateur sur l appariement

11 TABLE DES MATIÈRES xi L appariement global : calcul du résultat final Appariement comportemental Propriété Candidat à la coopération Algorithme d appariement comportemental Exemple Conclusion Mise en œuvre Introduction Approche Architecture Diagramme de classe Structures de données pour le stockage des workflows Matrice d adjacence Liste d adjacence Diagramme de décision binaire Logique propositionnelle Syntaxe Expression Booléenne Forme normale If-Then-Else (INF) Construction d un diagramme de décision binaire Règles de réduction Diagramme de décision binaire réduit Représentation d un graphe par un BDD Synthèse Abstraction et publication de workflow Appariement et interconnexion des workflows Interconnexion dynamique des services Web composés (BPEL) L annuaire Abstracteur Apparieur (MatchMaker) Parseur Superviseur Inférence sur les workflows Conclusion

12 xii TABLE DES MATIÈRES 9 Conclusions et perspectives Conclusions Perspectives Amélioration de l appariement Abstraction structurelle ou abstraction comportementale Cohérence de propriétés Vérification de propriétés non fonctionnelles A Code source de l exemple 163 A.1 Code source de l ontologie en OWL A.2 Code source du workflow de l assuré en XPDL A Construction du graphe de marquage 177 Bibliographie 184

13 Table des figures 2.1 Abstraction d activités internes séquentielles Les workflows d un assuré et d une société d assurance Exemple de spécification de workflows de services en BPEL description XPDL du l activité devis L ontologie supérieure de OWL-S Service OWL-S de l assuré Le profil de l assuré Le processus de l assuré Opération devis de l assuré Description de l opération devis de l assuré en SAWSDL Description d un concept en WSMO Description d une instance en WSMO Description en WSMO du service devis de l assuré Description en WSMO du service devis de l assuré Comparaison de OWL-S, SAWSDL et WSMO Exemple de réseau de Pétri Principe de la post-agglomération Exemple illustrant le principe de la pre-agglomération Description 1 : Workflows du service et celui de l usager Description 2 : Workflows du service et celui de l usager Description 3 : Workflows du service et celui de l usager Graphe de marquages des workflows de l usager (a) et du service (b) Graphe de communication de la description 1 du service Graphe de communication de la description 2 du service xiii

14 xiv TABLE DES FIGURES 4.10 Architecture Ontologie supérieure d une compagnie d assurance Ontologie simplifiée de la comptabilité d une compagnie d assurance Ontologie simplifiée de l interaction client/compagnie d assurance Ontologie simplifiée de ce que loue la compagnie d assurance Ontologie simplifiée des domaines d expertise de la compagnie d assurance Annotation sémantique d un type de message dans un workflow Définition du schéma XML de de l attribut modelreference Définition du schéma XML de l attribut schemamapping Workflow d un assuré Noms XPDL des activités du workflow de l assuré Définition XPDL de l activité Decl Annotation sémantique de l activité Decl Annotation sémantique de l activité Acc Définition du type de donné DeclarationInfo Annotation sémantique du type de données DeclarationInfo Correspondance entre la structure du DeclarationInfo et le concept grâce à schemamapping Exemple d ontologie de capacités Définition du schéma XML de de l attribut capacity Annotation sémantique de l activité Acc Méta-modèle des workflows XPDL Ontologie des workflows Hiérarchie des propriétés de l ontologie des workflows Instance de l ontologie : Workflow de l assuré Instance de l ontologie : les activités et leurs entrées Instance de l ontologie : les activités et leurs sorties Règle exprimant la transitivité de la propriété estcomposede Règle définissant la symétrie entre la propriété estcomposede Règles pour les propriétés estreliee et corresponda Règles pour définir la disponibilité d un workflow Règles conditionnant la validité d un workflow Exemple d activités ne pouvant pas être coopératives dans le même workflow... 84

15 TABLE DES FIGURES xv 5.32 Règles conditionnant la validité d un workflow Les graphes de marquages de l assuré (a) et d une société d assurance (b) Le workflow de l assuré Abstraction d activités internes séquentielles Abstraction d activités internes et coopératives séquentielles Abstraction d activités alternatives suivies d une même activité interne Abstraction d une activité interne suivie d activités alternatives Union des traces des workflow Abstraction d activités internes alternatives Abstraction d activités internes et sous workflow alternatives Abstraction d activités internes et coopératives alternatives Construction du graphe d observation de la société d assurance, étape Construction du graphe d observation de la société d assurance, étape Construction du graphe d observation de la société d assurance, étape Construction du graphe d observation de la société d assurance, étape Construction du graphe d observation de la société d assurance, étape Construction du graphe d observation de la société d assurance, étape Construction du graphe d observation de la société d assurance, étape Graphe d observation de l assuré (a) et celui de la société d assurance (b) (a) Séquence observé infinie (b) Séquence maximale finie (c) Séquence divergente Exemple montrant l utilité des préférences lors de l appariement Description sémantique de l activité Offre Description sémantique de l activité Offre Description sémantique de l activité Offre Description sémantique de l activité Offre Définition du schéma XML de de l attribut modelreferenceprop Découverte des offres de bienvenue transmises par virement Définition du schéma XML de l attribut preference Découverte des offres de bienvenue transmises par virement Découverte des offre de bienvenue payable en espèce ou autre Découverte des offres de bienvenue payable en espèce Difference entre les entrées et les sorties lors de l appariement

16 xvi TABLE DES FIGURES 7.13 Appariement des requêtes des assurés et des activités offertes Graphes d observation symbolique de l assuré (a) et de la compagnie d assurance (b) Graphes d observation symbolique renommés Les occurrences d une même transition coopérative sont exécutées exclusivement Appariement des workflows de l assuré et de la compagnie d assurance-etape Appariement des workflows de l assuré et de la compagnie d assurance-etape Appariement des workflows de l assuré et de la compagnie d assurance-dernière étape Architecture Diagramme de classe Représentation d un graphe avec une matrice d adjacence Représentation d un graphe avec une liste d adjacence Graphe de décision binaire avant réduction Suppression des nœuds Graphe de décision binaire réduit Un graphe G = (V, E) et un codage χ : E {0, 1} Le BDD représentant le graphe Workflows codés sur un nombre de bits différents Ontologie des workflows Codage des concept et nouveau codage des arcs Diagramme de séquence montrant l interaction entre deux BPEL Interaction dynamique entre deux BPELs sous Orchestra Le Builtin définissant la suppression d une propriété d un concept A.1 Structures de données de l algorithme de construction de graphe de marquage A.2 Marquage accessible depuis la transition Declaration A.3 Marquage accessible depuis la transition Accuse A.4 Marquages accessibles depuis la transition Etablir Devis A.5 Marquages accessibles depuis la transition Devis A.6 Marquages accessibles depuis la transition Avis A.7 Marquage accessible depuis la transition Facture A.8 Marquages accessibles depuis les transitions Evaluation et Reparer A.9 Marquage accessible depuis la transition Evaluation A.10 Marquage accessible depuis la transition Reparer A.11 Marquage accessible depuis la transition Paiement

17 Liste des algorithmes 1 Opération de comparaison des nœuds (VertexMatch) Construction du graphe de marquage La cloture Construction du graphe d observation MatchP ref(rqt pref, Match res ) MatchActivity(rqtAct, advact) (Rename(SOG 1 (s 0, S 1, T 1 ), SOG 2 (s 0, S 2, T 2 ))) (L(SOG 1 = s 0, S 1, E 1 ) L(SOG 2 = s 0, S 2, E 2 ))? xvii

18 xviii LISTE DES ALGORITHMES

19 Première partie Problématique et État de l art

20

21 Chapitre 1 Introduction La démocratisation de la technologie de l information et des moyens de communication ouvre la voie aux entreprises pour réaliser, via la coopération, certaines tâches complexes qui n étaient pas à leur portée, soit du fait de leurs tailles (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. Si la coopération offre aux entreprises de nouvelles opportunités, elle fait également augmenter la pression sur ces entreprises pour qu elles soient plus compétitives. Pour ce faire, les entreprises modélisent leurs activités industrielles par des processus (procédés) métier [97] et coopèrent ensuite électroniquement via un nouveau concept appelé entreprises virtuelles [75]. Une entreprise virtuelle permet, en fait, l association, autour d un projet, d un ensemble de partenaires distribués dans le temps et/ou dans l espace. La coopération dans le cadre des entreprises virtuelles peut être abordée à travers une approche ascendante ou une approche descendante. L approche descendante consiste à définir un procédé métier commun réunissant les différents partenaires. Le procédé métier commun est divisé ensuite en plusieurs sous procédés métier. Chaque participant se porte responsable de 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 locaux déjà établis au sein des entreprises. Dans ce cas, peu de contraintes sont imposées aux entreprises participantes et chacune d elles a la possibilité de joindre ou quitter la coopération quand elle 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 Issam CHEBBI [15]. CoopFlow est composée de trois étapes : (1) publication et abstraction de parties de procédés métier d entreprises pouvant être exploitées par d autres entreprises, (2) appariement 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 abstraction de CoopFlow est entièrement informelle. D autre part, l appariement proposé dans CoopFlow est syntaxique. Partant des travaux réalisés dans CoopFlow (l abstraction et la publication, l appariement et l interconnexion, et la coopération et le contrôle), l objectif de cette thèse est triple. Le premier objectif est de fournir une méthode d abstraction formelle pour les procédés métier. Le second objectif consiste à décrire les sémantiques métier et comportementale des procédés métier. Une telle description permet, entre autres, le partage des données et facilite l appariement. Le troi- 3

22 4 Introduction sième et dernier objectif concerne l amélioration de la qualité de l appariement et la proposition d 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 nos travaux ainsi que la problématique de la coopération interentreprises. La deuxième partie de cette thè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 la première partie de ce chapitre, nous définissons les procédés métier et nous présentons les différentes approches pour la coopération des procédés métier. La deuxième partie de ce chapitre est consacrée à l approche CoopFlow. Celle-ci constitue le point de départ de cette thèse. La troisième partie de ce chapitre présente nos objectifs dans le cadre de cette thèse. Enfin, dans la quatrième partie nous présentons l exemple support que nous utilisons tout au long de cette thèse. Dans la première partie du chapitre 3 nous présentons les langages de description syntaxique des workflows. La deuxième partie de ce chapitre présente les langages de description sémantique des services Web. La première partie du chapitre 4 fait un rappel sur les réseaux de Pétri. Dans la deuxième partie du chapitre nous abordons les techniques d agglomération. Ces techniques peuvent être utilisées pour abstraire les workflows. Dans la dernière partie de ce chapitre nous présentons et comparons les différentes approches proposées dans la littérature pour l appariement de workflows. Le chapitre 5 est consacré à la présentation de la première partie de notre contribution. Il s agit de la description sémantique des workflows. Nous décrivons notamment comment les workflows peuvent être décrit sémantiquement de deux manières et nous montrons les cas où l une ou l autre description est plus appropriée. La première description consiste à annoter sémantiquement 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 deux méthodes d abstraction de workflows : une comportementale et une structurelle. Le chapitre 7 présente notre mécanisme d appariement pour les workflows. Nous décrivons dans ce chapitre deux types d appariement. Le premier est pour comparer la sémantique métier des workflows et le second est pour comparer leur sémantique comportementale. Le chapitre 8 présente la mise en œ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.

23 Chapitre 2 Contexte et problématique Sommaire 2.1 Contexte général Préliminaire Approche ascendante vs approche descendante Principes à préserver par l'approche de la coopération choisie Coopération dans le cadre de l'approche CoopFlow Point de départ : L'approche CoopFlow Limites de CoopFlow Objectif de la thèse Exemple support Synthèse Dans ce chapitre nous présentons le contexte et la problématique de notre thèse. Une introduction générale de la problématique liée à la coopération interentreprises est donnée dans la Section 2.1. La Section 2.2 est consacrée à la présentation de l approche CoopFlow. Cette dernière constitue le point de départ de notre thèse. Dans la Section 2.3 nous présentons l objectif de notre thèse. La Section 2.4 présente l exemple support utilisé tout au long de cette thèse et nous concluons dans la Section Contexte général L évolution et l automatisation des procédés d entreprises combinées à la baisse de leur coût permettent aux entreprises de coopérer électroniquement pour former des entreprises virtuelles. La démocratisation des moyens de communication tels qu Internet ouvre également la voie aux entreprises pour réaliser, via la coopération, certaines tâches complexes qui n étaient pas à 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 pensons que les coopérations interentreprises à large échelle vont devenir de plus en plus fréquentes et notre 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 en créant un workflow interorganisationnel. Cependant la création de ce dernier workflow soulève un certain nombre de questions. En effet, la coopération peut être classée en deux catégories suivant 5

24 6 Contexte et problématique l attitude de celle-ci vis-à-vis des propriétés suivantes : le respect du savoir-faire de chaque partenaire, la tolérance à l égard de la flexibilité, la préservation de l autonomie de chaque participant et 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 introduit des notions de base sur les workflows. Une comparaison entre les approches ascendantes et descendantes est donnée dans la section Enfin, dans la Section nous présentons les principes qui guident le choix de l approche appropriée à notre cas Préliminaire Cette section est consacrée à la présentation des notions de base sur les workflows. Un workflow (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 workflows ou en fonction d interactions humaines 1. Les actions sont appelées également des activités. Une activité est un composant réutilisable représentant une étape d un workflow 2. Les entreprises coopèrent via leurs workflows créant ainsi un workflow interentreprises. La coopération au sein de ce 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 activité appartenant à un workflow (A) est dite productrice lorsqu elle est utilisée par (A) afin d initier une activité dans un autre workflow (B) et/ou lui fournir une entrée. Une activité appartenant à un workflow (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 de donné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 de flots de données au sein d un workflow, permettant de ce fait la synchronisation et l échange de données avec d autres workflows ainsi que la notification de changement d états des activités et leur exécution. Les activités coopératives peuvent être des activités productrices et/ou des activités consommatrices Définitions Définition 1 (Procédé) Dans [6, 10, 28, 89, 44], les auteurs définissent un procédé comme un ensemble d activités ordonnées selon un ensemble de règles procédurales pour réaliser un objectif 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és de ces personnes, la distribution des activités à travers ce groupe (par exemple, rôle, qui fait quoi ) et les critères de contrôle du bon déroulement de ces activités (par exemple, règles de cohérences, délais, délivrables, etc.). Un procédé peut être, totalement automatisé, comme il peut former une combinaison hybride de procédures automatiques, semi-automatiques et manuelles. Il existe un large panel d outils de 1. http :// 2. http ://

25 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 administration, le procédé de production, le procédé de collaboration et le procédé ad-hoc. Nous les présentons dans ce qui suit. Définition 2 (Activité coopérative productrice) Une activité coopérative productrice est une activité 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 consommatrice est une activité consommant un flot de données depuis une activité externe appartenant à un autre workflow. Définition 4 (Activité coopérative) Une activité coopérative est une activité productrice ou consommatrice. 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 les workflows internes. Dans un workflow interne, chaque partenaire commence par définir le workflow reflétant son savoir-faire et spécifiant tous les flots de données, les activités coopératives et non coopératives ainsi que les flots de contrôle correspondant. Le workflow spécifie toutes les étapes requises pour l 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 Celui-ci représente le comportement visible par un partenaire du workflow interne [18]. Dans un workflow interne, les activités et les flots de contrôle ne jouant aucun rôle direct dans la coopération sont cachés et on expose à l extérieur uniquement 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 la dé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={p 1, p 2,...,p n } de places un ensemble fini T={t 1, t 2,..., t m } de transitions (P T = ) T = T coop T int où T coop représente l ensemble des activités coopératives et T int représente l ensemble des activités internes (T coop T int = ). 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 (respectivement 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 et seulement 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.

26 8 Contexte et problématique 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 groupe de 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 par la machine. Il est constitué d un réseau d activités et de dépendances entre elles, des critères pour spécifier le démarrage et la terminaison d un procédé et des informations sur les activités individuelles (participants, applications, données informatiques associées, etc.) [94]. Les activités et les procédés ont des données en entrée et en sortie. Ces données sont représentées comme des ensembles d éléments de données, appelés conteneurs. Dans ce qui suit, nous décrivons plus en détail les différents composants du workflow selon le méta modèle proposé par WfMC 5 [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és programme 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 qui sont capables de l exécuter. Chaque utilisateur a une liste d activités qui nécessitent d être exécutées. A chaque activité est attribué un procédé. Ainsi tout procédé est exécuté quand l 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ées résultats. Flot de contrôle : un flot de contrôle définit l ordre dans lequel les activités sont exécutées en spé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 synchronisation (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écrivent toutes les informations nécessaires pour son exécution. Ces données incluent (i) des informations requises en entrée des activités, (ii) des informations requises pour l évaluation des conditions et (iii) des données qui doivent être échangées entre les activités. Ainsi, nous distinguons : 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 les activités mettant en œuvre une série de correspondance entre des conteneurs de données en sortie et des conteneurs des données en entrée permettant l échange d information entre les activités. Conditions : les conditions spécifient quand certains événements se produisent. Il y a trois types de conditions. Les conditions de transitions sont associées aux connecteurs de contrôle et spécifient quand un connecteur est évalué à vrai ou à faux. Les conditions de démarrage spécifient quand une activité va être démarrée : par exemple, quand tous ses connecteurs de contrôle entrants seront évalués à vrai, ou quand un d eux sera évalué à vrai. Les

27 2.1 Contexte général 9 conditions de sortie spécifient quand une activité est considérée terminée. Après l exécution d une activité, sa condition de sortie est vérifiée. Si elle est vraie alors l activité s est proprement terminée, sinon l activité est re-ordonnancée pour être exécutée Les workflows vus par l OMG L OMG (Object Management Group) [60, 61, 62] est une organisation internationale supportée par des centaines de membres représentant des vendeurs de systèmes, des éditeurs de logiciels et des utilisateurs. Fondée en 1989, l OMG promouvoit la théorie et la pratique de la technologie orientée objet dans le développement de logiciel. L OMG a spécifié CORBA [63, 58, 59] (Common Object Request Broker Architecture), une architecture objet pour le développement et l intégration d applications distribuées garantissant la réutilisabilité, l interopérabilité et la portabilité. CORBA est la réponse de l OMG aux besoins d interopérabilité entre les composants logiciels et matériels qui ne cessent de se multiplier. En particulier, l OMG présente un workflow comme un objet CORBA et considère l interconnexion des 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 de référence standard, des interfaces et des protocoles communs. En effet, l architecture CORBA présente les objets répartis selon quatre types : 1. les objets applicatifs sont des objets CORBA propres à l application et non concernés par la 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 (par exemple, la médecine, la finance, les télécommunications) ; 4. les utilitaires communs sont des services de plus haut niveau fournissant des fonctionnalités utiles dans de nombreuses applications (par exemple, les interfaces utilisateurs, la gestion de données, l administration des systèmes, etc.). L OMG traite la spécification du workflow comme un utilitaire CORBA de gestion des activités [74, 73, 61, 62]. La spécification OMG de l utilitaire de workflow définit les outils CORBA nécessaires au fonctionnement des gestionnaires de workflows en se basant directement sur les interfaces OMG-IDL [80] spécifiées par la WfMC pour son WAPI 3 de l interface 2 [95] et son interface 4 d interopérabilité [96]. La section suivante présente les deux types d approche de coopération des workflows 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

28 10 Contexte et problématique L approche descendante consiste à partir de la structure globale du workflow pour arriver aux détails. Il s agit, en effet, de définir un workflow commun réunissant les différents participants et établir les règles régissant la coopération. Le workflow commun est divisé ensuite en plusieurs sous workflows. Chaque participant se porte responsable de l exécution d un ou de plusieurs sous 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 approche descendante, l étude du projet, la sélection des entreprises candidates, la spécification de leurs interactions et rôles mutuels sont déterminés dès la phase de conception. A l exécution, chaque entreprise dispose de toutes les informations nécessaires à sa coopération et ne fait que suivre les 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 le début de la coopération. Deuxièmement, ce type d approche est caractérisé par le couplage fort des 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 est coûteux. Enfin, étant fortement couplés, les partenaires sont amenés à adapter leurs workflows et leurs ressources en fonction de la coopération à laquelle ils participent et par conséquent ils perdent 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 workflow global à partir des workflows locaux déjà établis au sein des entreprises. Dans ce cas, aucune contrainte n est imposée aux entreprises participantes et chacune d elles a la possibilité de joindre ou quitter une coopération quand elle veut. La coopération dans une approche ascendante se fait en trois étapes. Premièrement, lorsqu un participant souhaite coopérer, il cherche les partenaires potentiels pouvant satisfaire sa demande. Une fois, qu il récupère la liste des partenaires candidats, il sélectionne le partenaire adéquat et un contrat précisant les responsabilités des différents intervenants 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 sont pas définies à priori et peuvent changer continuellement d une coopération à l autre suivant les objectifs du projet et de l alliance à mettre en place. De plus, le nombre des partenaires ainsi que la 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 ascendantes sont plus flexibles puisque leurs structures sont évolutives et dépendent des besoins des partenaires et les relations entre les différents partenaires sont définies au moment de l interconnexion des entreprises. Il est également à noter que dans ce type d approche, les partenaires sont faiblement couplés et par conséquent sont plus autonomes puisque chacun est indépendant des autres et peut, entre deux exécutions d une coopération, changer et/ou apporter des modifications à sa structure interne sans changer son rôle dans la coopération. Étant faiblement couplé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, les entreprises 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 plus adaptée pour une coopération de courte durée.

29 2.1 Contexte général 11 Après avoir expliqué les différents types d approches pour la coopération, nous présentons dans ce qui suit les principes qui guident le choix de l approche appropriée à notre situation 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 situation générale au sein des alliances interentreprises. Plusieurs entreprises disposent déjà de leurs propres infrastructures, workflows, systèmes de gestion de workflow préétablis ainsi que des langages de spécification de workflows spécifiques. Ainsi, toute restructuration ou modification de 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 la protection du savoir-faire des participants. Les entreprises souhaitent, en effet, coopérer sans dévoiler leurs savoir-faire. Afin de permettre aux entreprises de bénéficier des compétences des autres entreprises et par conséquent augmenter leur rendement avec des coûts moindres, nous avons 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 partenaires ont la volonté de réunir leurs compétences et travailler ensemble pour atteindre un objectif commun. Or les partenaires d une alliance se méfient toujours de leurs partenaires dans le même secteur et veillent à protéger leurs procédés contre toute intrusion ou espionnage. En effet, si un partenaire arrive à déduire ou à acquérir le procédé d un autre partenaire, il lui est possible de déduire les points forts et les points faibles de son partenaire et peut donc effectuer des améliorations sur son propre procédé pour offrir de meilleurs services et gagner des marchés. Par conséquent, les entreprises n acceptent pas de divulguer leur savoir-faire par mesure de sécurité et de protection de leur expérience et technique de travail. En somme, les entreprises doivent être capables de coopérer et travailler ensemble sans 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 ensemble disposent généralement de leurs propres workflows préétablis. Or, pour des raisons de coordination de leurs activités, ces partenaires peuvent être amenés à modifier une partie ou la totalité de leurs workflows. Ce qui touche directement non seulement, à leur autonomie, puisque le partenaire est obligé de changer la logique de son workflow en fonction de l alliance qu il mène avec les autres entreprises, mais également au coût d investissement de la coopération. Or, lors de la planification d un projet, il est important de noter que tout changement aussi petit qu il soit, dans les workflows déjà établis est coûteux. Les changements s avèrent par conséquent non rentables surtout dans des alliances spontanées et dynamiques. Intégration des systèmes de gestion de workflows existants : Dans une entreprise virtuelle, chaque partenaire dispose de son propre système de gestion de workflow, outils de travail, matériels et infrastructures logicielles et de sa propre organisation interne. Ainsi, il est nécessaire de fournir des mécanismes permettant de supporter l hétérogénéité des systèmes de gestion de workflows existants des différents partenaires constituant l entreprise virtuelle afin d assurer la construction collective des compétences des entreprises à partir des infrastructures déjà existantes. Comme nous le montrons dans les chapitres suivants, ces différents besoins de coopération ne sont pas pris en compte par aucune des approches existantes. C est donc guidés par ces exi-