Transformation d’une description BPEL en langage IF

 Transformation d’une description BPEL en langage IF

Activités de communication

Les activités de communication sont utilisées dans les échanges de messages entre un processus BPEL, son client et ses partenaires. Ce sont les activités , et . Elles sont transformées en un processus IF utilisant des actions de communications (émission et réception de signaux). Dans notre méthode de transformation, toutes les actions de réception sont paresseuses et ne bloquent jamais l’écoulement du temps. Elles sont associées à une échéance lazy (cf. § 4.2.2). Note 4.3. Nous appelons un processus de communication tout processus décrivant une activité de communication ou les éléments et . Nous donnons ci-dessous la transformation respective de deux activités de communication : et synchrone. Exemple 4.9 (Transformation de ). Le processus IF résultant de la transformation de l’activité suivante est illustré dans la Figure 4.16. t1 est une transition paresseuse (lazy) qui attend la réception d’un signal mess et envoie un message de terminaison done au processus parent. t2 est une transition urgente (eager) permettant d’interrompre l’exécution du processus en cas de réception d’un signal terminate. Exemple 4.10 (Transformation de synchrone). Le processus IF résultant de la transformation de l’activité synchrone suivante est illustré dans la Figure 4.17 cidessous : t1 est une transition urgente (eager) qui envoie un message mess1 et passe à l’état intermédiaire inter. t2 est une transition urgente (à la différence de toutes les transitions de réception des autres processus décrivant une activité de communication) qui reçoit immédiatement un signal mess2 et envoie un message de terminaison done au processus parent. t2 et t4 sont des transitions urgentes permettant d’interrompre l’exécution du processus en cas de réception d’un signal terminate. Note 4.4. Toutes les actions de réception des processus des activités ou éléments de communication (e.g. , ) sont paresseuses (associées à une urgence lazy) à l’exception de l’action de réception d’un processus synchrone qui est urgente.

Activités structurées

 Les activités structurées décrivent l’ordre d’exécution de leurs sous-activités [1]. Les activités , , et fournissent un contrôle séquentiel. L’activité décrit une exécution concurrente et permet la synchronisation de ses activités. L’activité permet un choix contrôlé par l’arrivée d’événements. Nous présentons ci-dessous la transformation de chacune de ses activités structurées. Dans la suite, nous appelons sous-processus le processus de toute sous activité. Activité sequence L’activité est transformée en un processus IF (illustré par la Figure 4.18 ci-après) pouvant exécuter séquentiellement les processus des sous-activités de . Le processus crée, dans l’ordre d’apparition, le processus de chacune de ces sous-activités (par l’action fork spi dans les transitions t1 et t2) et attend à chaque fois sa terminaison (spi ?done(self) de t2) avant de créer le processus de la sous activité suivante. Il se termine normalement quand son dernier sous-processus termine normalement son exécution (spn ?done(self) de t3). Le processus est interrompu par la réception d’un signal fault (dans t4) ou terminate (dans t5). Dans ce cas, il arrête son exécution et applique une terminaison forcée à son sous-processus actif.process invoke(0) ; fpar parentId pid ; var iv mess1Type ; var ov mess2Type ; var pl plType ; state inState #start ; deadline eager ; output mess(pl,iv) via {toLink}0 ; next interState ; deadline eager ; input terminate() ; next outState ; endstate ; state interState ; deadline eager ; input mess(pl,ov) ; next outState ; deadline eager ; input terminate() ; next outState ; endstate ; state outState ; deadline eager ; output done(self) to parentId ; stop ; endstate ; endprocess ;

Activité if

 L’activité définit une liste ordonnée de choix conditionnels permettant de sélectionner une seule activité à exécuter [1]. Le processus (présenté dans la Figure 4.19) sélectionne une de ses branches dans l’ordre de leur apparition si sa condition est satisfaite (comme dans les transitions t3 et t4). Ensuite, il crée le processus de la sous activité associée à cette branche et attend sa terminaison (spj ?done(self) de t5). Le process peut être aussi interrompu par la réception d’un signal fault (comme dans t6) ou terminate (comme dans t7)). Dans ce cas, si aucune branche n’a été choisie il termine immédiatement son exécution, sinon la terminaison forcée est appliquée à son sousprocessus décrivant l’activité associée à la branche déjà choisie. Notons que les deux transitions t1 et t2 permettent de parcourir les conditions associées aux branches de jusqu’à la satisfaction de l’une d’elles.

Activités while et repeat until 

Les activités et permettent une exécution répétée de leur sous activité [1]. Elles sont transformées en un processus IF. Le processus est illustré par la Figure 4.20 ci-après. A chaque itération, le processus crée le processus de sa sous-activité (son sous-processus) tant que sa condition est satisfaite (comme dans les transitions t1 et t3). Le processus crée répétitivement le processus de sa sous-activité jusqu’à la satisfaction de sa condition. Les processus et attendent avant chaque itération la terminaison de leur sous-processus (par l’action sp ?done(self) de t3). Ces deux processus se terminent normalement dès que leur condition est évaluée respectivement à false (comme dans t4) et à true. Leur itération peut être interrompue par un signal fault (comme dans t5) ou terminate (comme dans t6), et cela sera suivi par une terminaison forcée de leur sous-processus.

Activité flow 

L’activité permet une exécution concurrente d’un ensemble d’activités [1]. Le comportement d’une activité est décrit par un processus IF qui crée simultanément le processus de ses sous-activités. Chaque sous-processus est associé à deux variables booléennes (relatives à leurs états de création et de terminaison) : start et end. Le processus gère ainsi la liste de ses sous-processus et leurs états. La synchronisation des liens est effectuée par le processus linksManager qui est décrit dans la Section 4.3.4. Le processus se termine quand tous sous-processus terminent normalement leur exécution. En recevant un signal terminate ou fault, le processus arrête son exécution et force la terminaison de tous ses sous-processus actifs.

Activité pick 

L’activité attend l’occurrence d’un événement et exécute par conséquent l’activité qui y est associée [1]. Ce comportement est décrit en IF par un processus (représenté dans la Figure 4.21 ci-dessous) qui attend l’arrivée d’un événement, crée ensuite le processus de la sous-activité associée (comme dans la transition t3) et attend sa terminaison (comme dans t5). L’événement est décrit par un process car il est considéré comme étant une réception de message (InterEnv ?mess(pl,v) dans t3). L’événement est considérée comme une attente d’une échéance ou l’écoulement d’une certaine période ; Il est alors décrit par un process (garde temporelle [c=d] dans t3). La terminaison du processus est similaire à celle de l’activité (cf. § 4.3.7). Notons que les actions de réception d’un signal de communication ne sont jamais urgentes et elles sont associées à l’échéance lazy (cf. § 4.2.2). A la différence, les transitions du processus sont toutes urgentes et sont associées à l’échéance eager.