Upload
aubin-tardy
View
126
Download
6
Embed Size (px)
Citation preview
Les processus métiers :concepts, modèles et systèmes
1
Claude Godart
Université de lorraine. [email protected]
Organisation du cours
• Introduction• Concepts et notations• Modélisation des processus• Analyse qualitative des processus• Analyse quantitative des processus• Systèmes de gestion de processus• Processus transactionnels• Découverte de processus• Conclusion
Contenu
• Processus transactionnel : définition– La cohérence transactionnelle, les transactions
ACID– Relâcher les propriétés ACID : les modèles de
transactions avancés– Modèle de processus transactionnels– Patron transactionnel de processus
• Infrastructures pour la mise en oeuvre des processus transactionnels
4
Processus transactionnel
Définiton
5
La cohérence transactionnelle• Objectifs :
– Décharger les programmeurs des problèmes liés aux pannes matérielles, aux erreurs logicielles, à la concurrence d’accès aux données
• Moyens– Encapsuler les programmes dans des transactions
pour :• Contrôler les accès concurrents aux données • Respecter les contraintes d’intégrité• Récupérer un état cohérent en cas de problème logiciel ou
matériel• Préserver les données en cas de panne matérielle
• Mise en œuvre : le modèle des transactions ACID
6
Le modèle des transactions ACID• Une Transaction ACID est un ensemble d’opérations de
lecture/écriture dans une BD qui respectent les propriétés suivantes :– soit toutes les opérations s’exécutent, soit aucune
(Atomicité)– une transaction seule, qui prend la BD dans état
cohérent, la rend dans un état cohérent (Cohérence)– dans le cas d’une exécution concurrente, toute
transaction a le même effet que si elle s’exécutait seule (Isolation)
– les données sauvegardées ne peuvent pas être modifiées qu’en exécutant de nouvelles transactions (Durabilité)
7
Mise en oeuvre du modèle ACID(contexte centralisé)
• Une transaction est dite centralisée si elle agit sur une seule base de donnée
• Difficultés de la mise en oeuvre: assurer les propriétés d’atomicité et d’isolation– Assurer l’atomicité :
• « Défaire » les modifications qui ont été faites en cas de problème en cours d’exécution
– Assurer l’isolation : • Préserver la transaction des mises à jour des autres
transactions• Cacher les mises à jour de la transaction aux autre
transactions
8
Mise en oeuvre du modèle ACIDLe protocole de verrouillage à deux phases
• Toute transaction qui veut modifier une donnée doit poser un verrou de type « exclusif (X) »
• Toute transaction qui veut lire une donnée doit poser un verrou de type « partagé (P) »
• Si la donnée possède un verrou incompatible, alors la transaction demandeuse est mise en attente jusqu’à ce que la donnée soit libérée (voir table de compatibilité)
• Une transaction qui a acquis un verrou ne peut plus en acquérir d’autres
9
Mise en oeuvre du modèle ACID Compatibilité entre verrous
OK
NO
P
P
X
X
NO
NO
Rien
OK
OK
10
Garanties du 2PL
• Toutes les exceptions acceptées sont sérialisables
• Toutes les exécutions sérialisables ne sont pas acceptées
Exécution sérialisables
Exécution acceptées par le 2PL
11
Mise en oeuvre du modèle ACID(Contexte décentralisé)
• Une transactions est dite distribuée si elle modifie plusieurs base de données
• Composée de sous transaction, chaque sous transaction est semblable à une transaction centralisée
• ACIDité dans un contexte distribué:– Isolation/durabilité
• si chaque sous transaction est isolée/durable, la transaction globale est isolée/durable
– Cohérence:• chaque sous transaction peut ne pas être cohérente mais la transaction globale
doit l’être• Nécessiter de coordonner l’exécution des sous-transactions pour assurer la
cohérence– Atomicité : l’atomicité doit être assurée au niveau local et global
• Le protocole de terminaison à deux phases assure une terminaison atomique
12
Mise en oeuvre du modèle ACIDLe protocole de terminaison à deux phases (ou
plus)
13
Les limites du modèle ACID
• Les propriétés ACID restreignent l’application du modèle ACID aux applications base de données (classiques)– de courte durée où le principe de tout ou rien est
acceptable– avec contraintes d’intégrité numériques et
déterministes– de nature non collaborative
14
Les limites du modèle ACID
• De nouvelles applications avancées (comme les processus métiers) avec de nouveaux besoins veulent bénéficier de la simplicité des transactions pour assurer des exécutions fiables
• Mais sont :– De longue durée– D’un développement incertain : pas de programme a priori (pas
possible de vérifier la cohérence a priori)– Collaborative par nature : le principe d’isolation est antagoniste
• Question : comment dépasser les limites du modèle ACID tout en préservant leur généralité et leur simplicité pour résoudre les problèmes de défaillance logicielle et physique ?
15
Modèles de transaction avancés
• But : étendre le modèle ACID pour supporter des applications avancées
• Approche : relâcher les propriétés ACID– Structure plus complexe – Compensation– Semi-atomicité
• états intermédiaires• alternatives d’exécution
– Correction définie par les concepteurs
16
Le modèle des SAGA(Notion de compensation)
• Une SAGA est une transaction ACD composée de sous transactions AID– S = T1; T2; ... ; Tn; Tn+1
• Le mécanisme de recouvrement d’un état cohérent est basé sur la notion de compensation– à chaque sous transaction Ti, le concepteur associe une activité
de compensation (Ci) qui « défait » les modifications faites par Ti– « défaire » signifie ramener la transaction à un état acceptable
qui n’est pas forcément un état antérieur– « défaire » ne signifie pas que Ti n’a pas eu d’effets
• Exécution d’une SAGA en cas d’échec d’une sous transaction Ti– S = T1; T2; ... ; Ti;Ci;Ci−1; . . . ;C2;C1
17
Le modèle des SAGA: exemple
S = Spécification des besoins du client; Réservation d’hôtel;Réservation de vol; Paiement en ligne; Envoi de document via Expéditeur 1
avec :
compensation(Spécification des besoins du client) =envoyer message (« Voyage annulé »);
compensation(Réservation d’hôtel) = Annulation de réservation d’hôtelcompensation(Réservation de vol) = Annulation de réservation de volcompensation(Paiement en ligne) = Rembourser PaiementCompensation(Envoi de document via Expéditeur 1) = rien
Plusieurs « Sagas » peuvent être définies pour le même exemple,mais aucune ne correspond exactement au processus« Réservation de voyage en ligne » : en particulier,Il n’y a pas de parallélisme possible
18
Le modèle des transactions flexibles(Transactions typées et alternatives) • Objectif : dépasser les limites des SAGA
– Structure de contrôle pauvre– Principe de tout ou rien maintenu
• Transaction flexible– Tolérer la défaillance de certaines sous-transactions en revenant à un
état amont cohérent par compensation, – Puis en exécutant un chemin alternatif
• Repose sur :– le typage des sous-transactions (compensable, pivot et rejouable)– et des règles de bonne structuration :
• Après une activité pivot plusieurs chemin alternatifs sont possibles: ces chemins sont ordonnés, la dernière alternative doit être sûre de terminer (constituée uniquement de transactions rejouables)
• Les transactions entre deux activités pivots doivent être compensables
19
Types d’activités(Par la suite on assimilera sous-transaction et activitédans les processus transactionnels)
20
Transaction flexible (Exemple)
SBC RH RV
EDD1
AR
EDD3
AR
EDD2
AROA
CompensablePivotRejouable
EDD1 , et sont des alternatives préférées dans cet ordreEDD2 EDD3
21
Le modèle des transactions flexibles
• Est mieux adapté aux transactions de longue durée en tolérant la défaillance de « sous-transactions »
• Permet aux concepteurs de spécifier une certaine forme de correction
• Cependant nécessite un effort additionnel pour structurer les transactions en respectant les règles de bonne structuration
• Introduit une structure plus développée que celle des SAGA mais moins expressive que celle des processus métiers (mais aussi moins expressive)
22
Correction définie par les concepteurs
• Dans les modèles classiques, la correction est « syntaxique » (indépendante de l’application)
• Dans les modèles avancés, les concepteurs utilisant la connaissance de l’application pour structurer des transactions correctes (Sagas, transactions flexibles)
• La notion de correction dépend de l’application (Correction « sémantique »)
• (Voir les Etat de Terminaison Acceptés des processus transactionnels)
23
Notion de processus transactionnels
• Modèles transactionnels et processus métiers ont des objectifs assez proches– La gestion d’un ensemble d’activités à la fois en
concurrence (s’exécutant en parallèles) et en interaction (explicite ou implicite)
• On distingue entre deux approches :– La mise en œuvre des modèles transactionnels
avancés comme des workflows– Considérer un processus comme une transaction
distribuée où les activités sont les sous transactions
24
Un processus comme une transaction distribuée
• Un processus transactionnel est un processus dont les activités exposent – des propriétés transactionnelles: compensable, pivot, rejouable– des états transactionnels: terminé, avorté, compensé– des flots transactionnels de compensation, d’exécution
alternative, d’annulation• Exemple : en cas d’échec de l’activité A, annuler l’exécution de
l’activité B
• On assimile un processus à une transaction distribuée et les activités à des sous-transactions
25
Exemple de processus transactionnel
26
Correction définie par le concepteur (Etats de Terminaison Acceptés)
• La correction est définie par les états acceptables dans lesquelles les sous-transactions de la transaction distribuée peuvent terminer
• Plusieurs combinaisons d’états peuvent être acceptables
• Il y les états de terminaison avec « succès » et ceux en « échec »; dans un état acceptable avec succès, une ou plusieurs sous-transaction peuvent avoir échoué
27
Correction définie par le concepteur(Exemple)
28
Validation de processus transactionnel
• But: garantir la fiabilité d’un processus transactionnel en assurant que toute instance se termine dans un état accepté
• Permettre aux concepteurs de spécifier le flot de contrôle des processus et l’ensemble des états de terminaison acceptés ({ETA})
• À partir du flot de contrôle et de l’{ETA} générer les propriétés de validation que tout processus valide doit respecter
• La génération des propriétés se fait en deux étapes:– calcul du flot transactionnel induit par l’{ETA}– génération des propriétés de validation
29
Calcul du flot transactionnel induit par ETA
• Un flot de contrôle peut engendrer plusieurs processus transactionnels qui – partagent le même flot de contrôle ({ET} sans échecs)– se distinguent par leurs flots transactionnels respectifs ({ET}
avec échecs)
• Ainsi l’{ET} avec échecs (y compris celui défini dans {ETA}) induit le flot transactionnel du processus
• Principe du calcul du flot transactionnel induit par {ETA} : un état de terminaison avec échec garde la trace de l’échec produit et l’ensemble des mécanismes de recouvrement appliqué à la suite
30
Génération des propriétés de validation
• Les propriétés de validation visent à assurer que tout processus valide respecte deux principes:– Il accepte, au plus, les échecs acceptés par le flot
transactionnel induit par ETA– Il définit pour chaque échec accepté les même
mécanismes de recouvrement que ceux définis dans le flot transactionnel induit par ETA
31
Exemple de processus transactionnel non valide
Processus non valide car il permet d’atteindre l’état :{SBC.terminé, RH.terminé, RV.échoué, PL.abandonné, ED1.abandonné,
ED2.abandonné, ED3.abandonné} qui n’appartient pas à l’ETA
32
Exemple de processus transactionnel valide
33
Les patrons transactionnels
• Un patron de workflow est une abstraction d’une classe d’interactions récurrente caractérisée par les dépendances d’activation entre les activités composantes
• La notion de patron de processus en général considère d’autres dépendances que les dépendances d’activation comme les dépendances transactionnelles
• => Idée de patron transactionnel
34
Les patrons transactionnels
• Les dépendances transactionnelles :– dépendances de compensation– dépendances d’annulation– dépendances d’alternative
• Chaque patron de workflow (pat) possède un flot transactionnel potentiel qui inclut tous les dépendances transactionnelles qui peuvent être définies selon pat
35
Les patrons transactionnels
36
Les patrons transactionnels
• Un patron transactionnel dérivé d’un patron pat est une instance de pat qui est enrichie par des dépendances transactionnels incluses dans son flot transactionnel potentiel
37
Modéliser avec des patrons transactionnels.
• Composition de patrons transactionnels– Utiliser les patrons transactionnels comme
briques de base pour spécifier des processus transactionnels
– Plusieurs modèles de processus peuvent être dérivés à partie du même flot de contrôle en fonction des flots transactionnels sélectionnés dans le flot transactionnel potentiel
38
39
Infrastructure pour la mise en oeuvre des processus
transactionnels
40
L’interface X/Open XA
• L’interface XA est un standard pour interfacer un gestionnaire de ressource et un gestionnaire de transactions
• Un gestionnaire de transaction gère une ou plusieurs transactions pour le compte d’une application
• Une transaction peut exploiter des ressources gérées par plusieurs gestionnaires de ressources
• L’interface XA définit comment le gestionnaire de transactions et les gestionnaires des ressources interagissent ensemble pour exécuter le protocole 2PC qui permet une terminaison atomique des transactions
41
L’interface X/Open XA
42
Interopérabilité dans un contexte intra-entreprise : l’approche «CORBA»
• Le module OTS (Object Transaction Service) de Corba met en œuvre le protocole 2PC
• Il est compatible avec l’interface XA
43
OTS Corba (1)
BD App A App B BD
Service de transactions
ORB
(a) commencer une transaction
BD App A App B BD
Service de transactions
ORB
(d) Invoquer App B
BD App A App B BD
Service de transactions
ORB
(b) enregistrer base de donnéés
BD App A App B BD
Service de transactions
ORB
(id, ctx)
(c) exécuter transaction (sans validation)
(bd_a, ctx)
(ctx)
44
OTS Corba (2)
BD App A App B BD
Service de transactions
ORB
BD App A App B BD
Service de transactions
ORB
App A App B BD
Service de transactions
ORB
BD App A App B BD
Service de transactions
ORB
(h) exécuter 2PC
BD
(e) enregistrer base de donnéés
(bd_b, ctx)
(f) exécuter transaction (sans validation)
(g) terminer transaction
(commit ctx)
45
Le protocole de terminaison à deux phases
46
Interopérabilité dans un contexte métier inter-entreprise.
L’approche «Services Web »
• On ne peut plus utiliser simplement l’interface XA :– besoin d’une interface Web– XA est très spécifique au protocole 2PC ce qui est insuffisant
dans le contexte des processus métiers (besoin des idées de compensation, alternative …)
• Généralisation de l’interface XA– Gestion décentralisée (plusieurs gestionnaires transactionnels)– Considérer des protocoles transactionnels plus sophistiqués que
2PC
47
Coordination « transactionnelle » des services Web
• Deux niveaux :– Les interactions d’activation et d’enregistrement, qui sont indépendantes
du protocole de coordination (protocole transactionnel)– Les interactions transactionnelles qui sont indépendantes des
protocoles transactionnels mis en œuvre– Distinction d’un niveau « Coordination » et d’un niveau « transaction »
• Deux approches concurrentes :– WS-Coordination et WS-CF– Qui présentent globalement les mêmes concepts : les entités de base
sont les coordinateurs et les participants• Tous les deux se basent sur la notion de contexte
– pour la corrélation des messages d’activation et d’enregistrement (proche du concept de contexte dans CORBA)
– Tous les messages SOAP échangés entre les participants incluent dans leurs entêtes les contextes de coordination appropriés
48
Coordination « transactionnelle » de services Web :
le niveau coordinateur et le niveau protocole transactionnel
49
Coordination « transactionnelle » des services Web
• WS-Coordination et WS-CF distinguent trois formes d’interactions entre un coordinateur et ses participants
• Activation: un participant demande à un coordinateur de créer un nouveau contexte de coordination– Ceci se produit quand un participant initie une
instance d’un type de coordination (transaction atomique par exemple)
50
• Enregistrement: un participant s’enregistre à un protocole de coordination :– rôle qu’il va jouer au sein du protocole– port sur lequel il va recevoir les messages de
coordination
• Interaction: ceci correspond aux messages de coordination spécifique à un protocole transactionnel particulier
Coordination « transactionnelle » des services Web
51
Scénario d’interactionavec WS-Coordination
52
Coordination « transactionnelle » des services Web
• Dans le contexte des services Web, WS-Transaction et WS-TXM deux propositions bâties respectivement sur WS-Coordination et WS-CF définissent des protocoles transactionnels
• Ils définissent des variantes des modèles transactionnels avancés
53
Coordination « transactionnelle » des services Web
• WS-Transaction hérite de WS-Coordination la distinction entre << Protocole de Coordination >> et << Type de Coordination >>
• Un protocole de coordination est un ensemble de règles génériques contrôlant les conversations entre un coordinateur et ses participants
• 2PC est un exemple de protocole de coordination
54
Coordination « transactionnelle » des services Web
• Un type de coordination comprend un ensemble de protocoles de coordination logiquement liés les uns aux autres
• Par exemple une transaction atomique est un type de protocole qui regroupe le protocole 2PC et le protocole de notification du résultat
• Une instance d’un type de coordination peut impliquer l’exécution de plusieurs instances d’un même protocole ou de plusieurs protocoles
55
Coordination « transactionnelle » des services Web
• WS-Transaction distingue deux types de protocoles:– Les transactions atomiques: WS-Atomic Transaction– Les activités métiers: WS-Business Activity
56
Exemple de protocole Web ad-hoc :le protocole «Tentative Hold»
• Principes de base : – La réservation (du coté demandeur et du côté
fournisseur) est non contraignante et sans blocage des ressources (« j’envisage d’utiliser la ressource … mais je ne me décide pas maintenant »)
– Permet une forme de conscience de groupe entre les fournisseurs et les demandeurs sur le niveau de concurrence d’accès aux ressources
– Mais n’est pas vraiment un protocole pour maintenir la cohérence : doit être combiné à un protocole transactionnel (de WS-Transaction par exemple) pour réserver effectivement des ressources
57
Scénario d’utilisation du protocole « Tentative hold »
Exemple de l’organisation d’un voyage en ligne : – Plusieurs demandes de réservation de vol et d’hôtels pourraient
être autorisées (l’agence pourrait évaluer les différentes alternatives)
– Mais c’est le premier qui valide sa demande ferme (par exemple en payant) qui gagne
– Lorsque l’agence modifie un choix non validé, elle en informe l’hôtel ou la compagnie aérienne, qui en informe elle-même les concurrents qui peuvent réagir …
58
Conclusion
• Les idées de « processus » et de « transaction » sont intimement liées
• Par rapport aux transactions classiques, il est nécessaire de « programmer » la logique transactionnelle des processus
• Il existe des propositions dans le cadre des services Web, mais peu mises en pratique
• Certainement un des facteurs les plus bloquant pour la mises en œuvre des processus interentreprises
59
Références• [ALO 96] ALONSO G., AGRAWAL D., ABBADI A. E., KAMATH M., GÜNTHÖR R.,
MOHAN C., « Advanced Transaction Models in Workflow Contexts », Proceedings of the Twelfth International Conference on Data Engineering, Nouvelle Orléans, Etats-Unis, IEEE Computer Society, p. 574-581, 1996
• [ALO 05] ALONSO G., « Transactional Business Processes », Process-Aware Information Systems book, Springer-Verlag, Heidelberg, 2005.
• [ARJ 06] ARJUNA, FUJITSU, IONA, ORACLE, SUN, Web Services Composite Application Framework (WS-CAF), www.arjuna.com/standards/ws-caf, 2006.
• [BHI 05a] BHIRI S., Approche transactionnelle pour assurer des compositions fiables de services Web, thèse, Université Henri Poincaré - Nancy 1, LORIA, 16 mai 2005.
• [BHI 05b] BHIRI S., PERRIN O., GODART C., « Ensuring required failure atomicity of composite Web services », Proceedings of the 14th international conference on World Wide Web, WWW 2005, Chiba, Japon, ACM, mai 2005.
• [ELM 90] ELMAGARMID A., LEU Y., LITWIN W., RUSINKIEWICZ M., « A multidatabase transaction model for InterBase », Proceedings of the sixteenth international conference on Very large databases, Morgan Kaufmann Publishers, San Francisco, 1990.
• [GAR 87] GARCIA-MOLINA H., SALEM K., « Sagas », Proceedings of the ACM Special Interest Group on Management of Data 1987 Annual Conference, San Francisco, Californie, ACM Press, mai 1987.
• [GAR 91] GARCIA-MOLINA H., GAWLICK D., KLEIN J., KLEISSNER K., SALEM K., « Modeling Long-Running Activities as Nested Sagas », IEEE Data Eng. Bull., vol. 14, n° 1, p. 14-18, 1991.
60
Références• [GRA 78] GRAY J., « Notes on Data Base Operating Systems », Advanced Course :
Operating Systems, Springer-Verlag, Londres, p. 393-481, 1978.• [GRA 93] GRAY J., REUTER A., Transaction Processing : Concepts and Techniques,
Morgan Kaufmann, San Francisco, 1993.• [LEY 95] LEYMANN F., « Supporting Business Transactions Via Partial Backward
Recovery In Workflow Management Systems », btw, p. 51-70, 1995.• [OAS 07a] OASIS, Web Services Atomic Transaction (WS-AT) Version 1.1,
docs.oasis-open- org/ws-tx/wstx-wsat-1.1-spec/wstx-wsat-1.1-spec.html, 2007.• [OAS 07b] OASIS, Web Services Business Activity (WS-BA) Version 1.1, docs.oasis-
open- org/ws-tx/wstx-wsba-1.1-spec/wstx-wsba-1.1-spec.html, 2007.• [OAS 07c] OASIS, Web Services Coordination (WS-Coordination) Version 1.1,
docs.oasisopen. org/ws-tx/wstx-wscoor-1.1-spec-os/wstx-wscoor-1.1-spec-os.html, 2007.
• [OAS 07d] OASIS, Web Services Transaction (WS-TX) Version 1.1, www.oasis-open.org/- committees/tc_home.php ?wg_abbrev=ws-tx, 2007.
• [OG 94] OG, OPEN GROUP, Distributed Transaction Specifications : the XA interface, rapport, www.opengroup.org/onlinepubs/009680699/toc.pdf, 1994.
• [OMG 07] OMG, OBJECT MANAGEMENT GROUP, CORBA Transaction Service, www.omg.org/technology/documents/formal/transaction_service.htm, 2007.
• [SHE 93] SHETH A. P., RUSINKIEWICZ M., « On Transactional Workflows », Data Engineering Bulletin, vol. 16, n° 2, p. 37-40, 1993.
• [W3C 01] W3C, Tentative Hold Protocol, www.w3.org/TR/tenthold-1/, 2001.
61