2. Model de référence des SGWF
Le modèle de référence, Figure 2.7,
présente l'architecture générale de l'environnement
proposée par la WfMC, il identifie les interfaces couvrant cinq domaines
de fonctionnalités entre le système Workflow et son
environnement.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
28
Figure 2.7 - Model de référence
Workflow
a. Interface avec les Outils de définition de
procédures
Cette interface, située entre les outils de
modélisation/définition et le logiciel de gestion du Workflow
pendant l'exécution, est nommée interface d'import/export de
définition de processus. Cette interface définit le format
d'échange et d'appels des APIs, qui permettent l'échange
d'informations de définition de procédures sur une
variété de médias d'échange : physiques ou
électroniques. Cette interface permet l'échange d'une
définition de processus complète ou d'un sous-ensemble. Par
exemple le changement de définition d'un ensemble de procédures
ou plus simplement la modification des attributs d'une activité
particulière dans une définition de procédures.
b. Interface avec les applications clientes Workflow
La liste des tâches (Worklist) à exécuter
par une ressource est généralement définie et
gérée par le service d'exécution du Workflow. Cette liste
doit pouvoir déclencher des appels à des applications clientes
diverses et des ressources. La solution retenue pour respecter cette exigence,
consiste à encapsuler la variété d'application qui peut
être utilisée derrière un jeu standard d'API (le WAPI
Workflow Application Programming Interface). Ce jeu permet ainsi d'utiliser une
communication standardisée entre les applications clientes, le moteur de
Workflow et les Worklist, indifféremment de la nature de
l'implémentation réelle des produits clients.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
29
c. Interface avec les applications invoquées
Il est évident que le système Workflow ne peut
pas intégrer l'invocation automatique de toutes les applications qu'il
peut être amené à utiliser pendant l'exécution d'un
Workflow. Par exemple les applications dont les données sont fortement
typées. Dans ce cas un composant externe supplémentaire,
nommé agent d'application, est ajouté, il est chargé de la
traduction des informations dans un format compréhensible par le
standard WAPI.
Dans le cas le plus simple, l'invocation d'application est
traitée localement par un moteur de Workflow, mais les applications
invoquées peuvent être utilisées par plusieurs moteurs de
Workflow et peuvent se situer sur des machines distantes, il convient donc de
définir un format commun d'utilisation des ces applications entre les
Workflow dans le but de communiquer correctement et de synchroniser l'appel
à ces applications.
| 
