| |
YAWL, la base de comparaison des langages |
Pour appréhender les fonctionnalités portées par les divers langages, il est indispensable de disposer d’une série exhaustive de fonctionnalités nécessaires à la distribution du travail. YAWL, qui est aussi un langage de programmation de workflow, a édité une telle liste, que l’équipe de recherche de ProcessSoft considère comme un must :
http://is.tm.tue.nl/research/patterns/patterns.htm
Les 21 comportements possibles d’un moteur de distribution du travail sont expliqués. Sur cette base, une première analyse des langages présentés peut être faite. Le premier critère de comparaison est donc le taux de couverture des patterns YAWL.
|
| Répondre simplement aux situations complexes |
| Cependant, répondre aux critères YAWL ne signifie pas nécessairement qu’un langage de description de wokflow est efficace.
Un exemple est éclairant : la manière de traiter le parallélisme des activités. Certaines outils/méthodes anciens (Mega, Aris, Qualigramme, Ossad) considèrent que le parallélisme consiste à envoyer deux (ou plusieurs) demandes de travail depuis une procédure de départ, puis d’en re-synchroniser les résultats, plus bas dans le processus, par une procédure de synchronisation.
Une méthode plus efficace comme Mercutio permet de mettre en attente une procédure en attendant que toutes les recherches d’informations « parallèles » lui reviennent.
« L’absence de norme effective dans le paramétrage des workflows traduit l’incompatibilité des fonctionnemnents prévus» |
On comprend ainsi qu’il n’est pas possible à ces modes de distribution du travail d’être représentés par la même norme ou le même langage.
En répondant aux mêmes contraintes YAWL, Mercutio divise par deux le nombre de symboles de représentation tout en illustrant des fonctionnements que les méthodes classiques ne peuvent rendre.
Le deuxième critère est donc le nombre d’objets du metamodèle et le nombre d’instances de ces objets nécessaires pour traiter une situation type. |
|
|
Permettre l’initiative |
Chaque fois qu’un langage prévoie de substituer un automatisme à la décision de l’opérateur, il diminue de facto la flexibilité de la distribution. Autrement dit, automatiser les enchaînements oblige à spécifier la totalité des cas de gestion et à exclure les cas imprévus.
Le troisième critère est la capacité d’initiative laissée aux opérateurs pour prendre en compte le réel.
|
Interagir avec les applications |
Il existe plusieurs tentatives de normalisation dans le domaine de la distribution du travail, comme:
 |
BPMI, langage de normalisation des échanges de travail entre applications |
|
BPEL, normalise les serveurs qui distribuent le travail |
La normalisation porte ici sur l’interopérabilité entre systèmes. Très peu d’applications réelles et d’offres logicielles appliquent ces «normes». Deux raisons à cela : comme expliqué par l’exemple précédent, les comportements des applications sont trop diverses. Et surtout, l’utilisation d’un langage pour décrire le workflow entre applications et le workflow entre équipes est d’une incroyable complexité ; c’est cependant le piège dans lequel tombent nombre de langages classiques.
Choisir entre modélisation du travail et/ou modélisation de l’interaction entre applications est le quatrième critère.
|
| |
|
