Les outils de workflow fédérés et systèmes coopératifs

Dans les années quatre vingt dix, un terme nouveau, "les systèmes d'information coopératifs

(SIC)" est né, qualifiant la prochaine génération des systèmes d'information [Papazoglou et

Schlageter 1998]. Le manifeste [De Michelis et al. 1998] trace un cadre de travail et d'étude

pour les SIC, selon trois axes inter-liés :

1. l'axe système recouvrant l'information, les outils de workflow et d'autres systèmes

logiciels offrant un support à certaines tâches. Cet axe recoupe les problèmes

d'hétérogénéité et d'interopérabilité des systèmes concernés ;

2. l'axe de la collaboration de groupes qui recouvre comment les personnes travaillent

ensemble sur un processus commun ou autres projets. Cet axe est aussi traité par la

communauté de recherche portant sur les systèmes d'information collaboratifs et les

collecticiels

³¹

;

3. l'axe organisationnel qui recouvre l'organisation au sens général incluant la gestion

des objectifs, le plan d'affaire, les stratégies, la gestion des projets et les flux résultant.

Ce découpage montre en fait que ce domaine ne s'occupe pas simplement de la gestion des

échanges d'information mais également de la coordination des différents acteurs (personnes,

systèmes, etc.). [De Michelis et al. 1998] montrent que la gestion des changements, la prise en

compte de l'évolution sont deux dimension orthogonales à chacun de ces axes et sont deux des

aspects importants des futures recherches.

Les architectures de ces systèmes sont basées sur les modèles que nous avons déjà présentés

dans ce chapitre (courtiers, médiateurs, etc.).

En fait, la question de l'interopérabilité d'outils de workflow pour constituer une fédération a

été étudiée sous le même angle que celui des bases de données fédérées que nous avons vues :

les deux approches ont pour objectif l'intégration de composants hétérogènes à l'intérieur d'un

système global (appelé fédération). La différence principale est que les différents composants

d'une fédération de bases de données peuvent avoir différents modèles de données alors que

les composants de workflow peuvent avoir différents modèles (conceptuels) de workflow

[Geppert et al. 1998] ; il n'est pas toujours possible/souhaitable de considérer un modèle

unique s'appliquant à l'ensemble des composants contrairement aux bases de données

fédérées. Le cas d'un modèle unique partagé à été l'objet des approches WfMC [WfMC 1995,

WfMC 1996a, WfMC 1996b]. D'autres en revanche, comme [Casati et al. 1996] prennent une

optique inverse à savoir que les composants gardent leur autonomie et ne partagent pas de

modèle commun. La solution du modèle commun est irréaliste dans le cas d'entreprises

distribuées et autonomes [Geppert et al. 1998, Tombros et Geppert 2000]. On en déduit

qu'une fédération de systèmes de workflow doit s'affranchir des contraintes suivantes :

• aucune supposition sur l'existence d'un modèle homogène et global ;

• les spécifications d'un système de workflow restent privées à ce système ;

• l'exécution d'un processus de workflow reste sous le contrôle de chacun des systèmes

de workflow.

Différentes architectures possibles

Outils de workflow 1 Outils de workflow 2

a. Intégration point-à-point à partir d'une API

Outils de workflow 1

b. l'échange d'information se fait à partir une plate-forme commune

Plate-forme commune

Outils de workflow 1 Outils de workflow 2

c. fédération utilisant un système global

Système global de workflow

schéma global du workflow

Outils de workflow 1

d. fédération basée sur la médiation

Niveau médiation

base de données globale

Outils de workflow 2 Outils de workflow 2

Figure III.27 Différents choix d'architecture pour les fédérations de workflow

Dans le premier cas (Figure III.27.a.), les systèmes de workflow interagissent entre eux

directement via leurs API. Le principal problème de ce mode de fonctionnement est qu'ils

doivent se connaître mutuellement (et donc ils doivent implémenter autant d'interfaces que de

composants, ce qui est très pénalisant en terme de maintenance et d'évolution).

Le second cas (Figure III.27.b.)est basé sur l'intégration de données entre différents systèmes

de workflow: les systèmes interagissent via le SGBD (voir Wide [Casati et al. 1996]). Cette

configuration ne se prête pas à la problématique des fédérations de composants distribués

pour laquelle les entreprises sont réfractaires à autoriser les accès à leurs données. Ce mode

n'est donc pas adapté aux fédérations inter-entreprises.

Dans le troisième cas (Figure III.27.c.), il existe un niveau d'intégration global tel qu'il est

décrit dans [Sheth et Larson 1990] pour le cas des fédérations de bases de données ; cette

couche est un système de workflow à part entière. Les spécifications de ce dernier sont

transcrites en types/concepts de chaque composant local. Le fait est que la plupart des

entreprises disposent déjà de leurs propres outils de workflow et que, dans ce cas, il faut leur

installer le système de la couche intermédiaire.

Le dernier cas (Figure III.27.d.)mentionne une fédération construite sur une couche de

médiation permettant à chaque système/composant d'invoquer les autres composants.

Contrairement au cas précédent, cette couche intermédiaire n'est pas elle-même un système de

workflow complet.

La spécification globale des systèmes de workflow est telle qu'un flux (workflow) wf est

appelé global si au moins un de ses sous-flux est exécuté par un système de workflow

différent du système exécutant wf. Pour pouvoir spécifier les workflow globaux il faut :

1. que les différents systèmes puissent connaître quels sont les types/concepts offerts par

les autres systèmes ;

2. que les types d'un système puissent être représentés par les autres systèmes ;

3. que les composants logiciels soient représentés comme des entités de calcul et que

l'allocation des tâches puisse être spécifiée.

La première condition est satisfaite s'il existe une base de donnée pour la fédération contenant

l'ensemble des informations portant sur les types exportés par les différents systèmes de

workflow de la fédération. Pour chacun de ces types, les informations suivantes leurs sont

associées :

• son nom ;

• un ensemble de paramètres typés d'entrée ;

• un ensemble de paramètres typés de sortie ;

• un ensemble de systèmes de workflow qui implémentent et qui exportent ce

type ;

• un ensemble de systèmes de workflow qui importent ce type.

Pour pouvoir satisfaire le second point, un système de workflow doit pouvoir importer les

types qui sont définis dans la base de données commune.

Modéliser la fédération revient donc à définir un processus de workflow global selon la

connaissance (incomplète) que l'on possède des différents systèmes de workflow, participants

de la fédération. Les invocations des différents systèmes sont alors réalisés par la couche de

médiation et les conversations sont opérés par les systèmes eux-mêmes.

Les composants de médiation constituent la "colle" entre les systèmes de workflow locaux

[Geppert et al. 1998]. Ces composants sont de deux types :

• du côté du client (c'est-à-dire où le processus global de workflow s'exécute), d'autres

composants de workflow appelés entités de calcul

³²

qui fournissent les fragments de

workflow importés sous la forme de services ;

• du côté du serveur (c'est-à-dire les composants de workflow distants où des

sous-processus du sous-processus global de workflow peuvent être exécutés) ou des clients sont

les médiateurs entre les clients et les systèmes locaux de workflow.

Ainsi, pour exécuter un fragment de workflow distant (auprès d'un système de workflow

distant SW1), l'entité de calcul communique avec le client approprié (le client du système de

workflow SW1). Ce dernier peut automatiquement démarrer le processus via l'interface

cliente de son système de workflow et, une fois le processus terminé, reçoit les résultats et les

retourne à l'entité de calcul à l'origine de l'invocation (qui elle-même retourne le résultat au

système de workflow initial).

Les technologies utilisées pour implémenter cette architecture reposent sur CORBA-OMG

[Miller et al. 1996, Geppert et al. 1998] et les composants sont des objets distants.

III.5.4 Evaluation

Nous remarquons que les travaux sur les systèmes fédérés diffèrent peu des travaux portant

sur les bases de données fédérées et possèdent un certain nombre de leurs caractéristiques (du

à l'importance et à la place centrale des sources de données dans les systèmes d'information).

Ces travaux ont permis de considérer les systèmes fédérés avec les trois dimensions que sont

l'autonomie des participants, la distribution et l'hétérogénéité. D'autre part, les points suivants

ont été particulièrement abordés :

• formes, modèles et formalismes canoniques ;

• technologies permettant aux différents participants d'une fédération d'interopérer (nous

retrouvons en particulier, les bus logiciels, les technologies supportant les applications

réparties, etc. – OMG-CORBA, etc.).

Particulièrement, les types d'architectures ("serrée" ou "lâche"), dans les bases de données

notamment, sont une déclinaison de la notion de contrôle (un contrôle rigide ou alors lâche).

En revanche, dans le domaine des bases de données fédérées, les composants sont, par nature

des composants dont leur univers de discours respectif varie peu (il s'agit toujours de

composants de base de données). En ce sens, les solutions proposées ne permettent de

résoudre qu'un sous ensemble de notre problématique (à savoir les formes canoniques et les

moyens de les obtenir en partant des composants vers le schéma commun et vice versa). Pour

autant, il n'existe pas de solution automatique à ce jour.

Nous noterons également que les propositions ont surtout considéré les problèmes

d'intégration de schéma, d'interopérabilité sous les aspects syntaxiques et sémantiques. En

revanche, la question considérant la flexibilité du contrôle (et de l'autonomie) des composants

n'a pas été une des priorités. Les approches bases de données et workflow ont fait l'hypothèse

que l'autonomie des composants devait être garantie sans en mesurer le degré.

Les approches dans les domaines des processus (de workflow, logiciel, …) doivent en plus,

traiter les problèmes de recouvrements, de cohérence entre les états locaux des participants et

l'état global de la fédération. Cette notion d'état global ne fait d'ailleurs pas l'objet de

consensus à ce jour.

La section suivante va dresser un bilan de l'ensemble des travaux abordés au cours de ce

chapitre pour voir, en quoi certains points restent ouverts et en quoi la problématique que

nous exposons dans cette thèse est toujours un problème de recherche. Nous verrons ensuite

les solutions qui peuvent se dégager, pouvant servir de base à notre proposition en vue de

résoudre tels ou tels aspects de notre problématique.

III.6 Bilan et conclusion

Dans le document Conception et construction de fédérations de progiciels (Page 92-95)