Du WS-BPEL vers le BP-calcul

Pour chaque primitive WS-BPEL nous fournissons dans ce qui suit sa traduction en BP-calcul. Processus nul : L’´el´ement <empty/> est exprim´e par l’interm´ediaire du processus nil :

J𝑒𝑚𝑝𝑡𝑦K𝑏𝑝= 0

R´eception : La r´eception d’une information 𝑖 du partenaire 𝑟 est traduite par une r´eception sur le canal 𝑥 qui repr´esente l’op´eration WS-BPEL :

J𝑟𝑒𝑐𝑒𝑖𝑣𝑒(𝑥, 𝑟, 𝑖)K𝑏𝑝 = 𝑥(˜𝑦) o`u ˜𝑦 inclut le canal de r´eponse 𝑟 et l’information re¸cue 𝑖.

´

Emission : Un ´el´ement <invoke> qui consiste en une ´emission de l’information repr´esent´ee par 𝑜 au partenaire 𝑟 est traduite par une ´emission sur le canal 𝑥 qui repr´esente l’op´eration WS-BPEL et qui est annot´e par le litt´eral ’inv’ qui permet de le diff´erencier d’une r´eponse (<reply>)

J𝑖𝑛𝑣𝑜𝑘𝑒(𝑥, 𝑟, 𝑜)K𝑏𝑝= 𝑥

o`u ˜𝑦 inclut le canal de r´eponse 𝑟 et l’information transmise 𝑜.

De la mˆeme mani`ere une r´eponse <reply> est traduite par une ´emission annot´ee par le litt´eral ’rep’.

J𝑟𝑒𝑝𝑙𝑦(𝑥, 𝑟, 𝑜)K𝑏𝑝= 𝑥

𝑟𝑒𝑝_⟨˜𝑦⟩

Composition parall`ele : L’´el´ement de composition parall`ele est ainsi sp´ecifi´e grˆace `a l’op´era- teur ∣ :

J𝑓 𝑙𝑜𝑤(𝐴1, 𝐴2)K𝑏𝑝 = J𝐴1K𝑏𝑝 ∣J𝐴2K𝑏𝑝

Il est `a noter que WS-BPEL permet l’utilisation de liens (links) qui expriment des d´ependances de synchronisation entre les activit´es. Cependant ces d´ependances peuvent ˆetre exprim´ees en utilisant uniquement les ´el´ements de base du BP-calcul. Le concepteur qui d´esire malgr´e cela utiliser ces liens devra les inclure manuellement dans le code g´en´er´e.

Composition s´equentielle : Des informations de synchronisation peuvent s’av´erer n´ecessaires pour r´ealiser proprement une s´equence de deux processus. C’est le cas notamment des informations concernant les variables li´ees dans le processus initial qui ne doivent pas ˆetre captur´ees dans le processus suivant. La traduction dans le 𝜋-calcul de l’´el´ement <sequence> est bas´ee sur l’op´erateur de s´equence ⊳ introduit sp´ecialement dans ce but. La traduction est donc :

J𝑠𝑒𝑞𝑢𝑒𝑛𝑐𝑒(𝐴1, 𝐴2)K𝑏𝑝 = J𝐴1K𝑏𝑝 ⊳𝑀 J𝐴2K𝑏𝑝)

Choix : L’´el´ement <pick> se traduit ais´ement grˆace `a l’op´erateur de choix du BP-calcul, comme suit :

J𝑝𝑖𝑐𝑘((𝑥1, ˜𝑖1, 𝑙1, 𝐴1), (𝑥2, ˜𝑖2, 𝑙2, 𝐴2))K𝑏𝑝 = 𝑥1( ˜𝑗1)J𝐴1K𝑏𝑝 + 𝑥2(˜2)J𝐴2K𝑏𝑝 o`u ˜𝑗1(𝑟𝑒𝑠𝑝 ˜𝑗2) contient 𝑙1 et ˜𝑖1 (resp 𝑙2 and ˜𝑖2).

Conditions : L’´el´ement de condition du langage WS-BPEL s’exprime ais´ement grˆace `a son ´

equivalent dans le BP-calcul :

J𝑖𝑓 (𝑥, 𝐴1, 𝐴2, 𝐴3)K𝑏𝑝 = 𝑖𝑓 (𝑥 = 𝑎1) J𝐴1K𝑏𝑝 𝑒𝑙𝑠𝑒 𝑖𝑓 (𝑥 = 𝑎2) J𝐴2K𝑏𝑝 𝑒𝑙𝑠𝑒 _J𝐴3K𝑏𝑝

WS-BPEL autorise l’usage des <if> imbriqu´es grˆace `a l’´el´ement <elseif>.

Scopes : Dans le langage WS-BPEL, les scopes sont utilis´es pour fournir un contexte d’ex´ecution `

a chaque activit´e. Un scope peut contenir diff´erents gestionnaires : d’erreurs, d’´ev`enements de compensation ou de terminaison. Il contient aussi des variables, locales au scope et des ensembles de corr´elation. Nous consid´erons le scope comme une enveloppe qui encapsule des processus et qui

permet de traiter des ´ev`enements asynchrones et les pannes. La traduction d’un scope se fait de mani`ere hi´erarchique et commence par la traduction des chacune de ses composantes.

- Variables : Un scope qui ne contient que des variables se comporte comme l’op´erateur de restriction du 𝜋-calcul. Nous pouvons d’ailleurs utiliser la mˆeme notation ((𝜈 𝑥)𝐴) pour re- pr´esenter un tel scope qui ne contient pas de gestionnaires. Ainsi, si 𝐴 est l’activit´e encapsul´ee dans le scope,

J𝑠𝑐𝑜𝑝𝑒(𝑥, 𝑦)K𝑏𝑝 = {{𝑥, 𝑦} 𝑄𝐴, ∅} peut ˆetre d´enot´e par

J𝑠𝑐𝑜𝑝𝑒(𝑥, 𝑦)K𝑏𝑝 = (𝜈 𝑥)(𝜈 𝑦) 𝑄𝐴 - Scopes : Un scope plus g´en´eral est sp´ecifi´e par :

J𝑠𝑐𝑜𝑝𝑒(𝑥, 𝑦)K𝑏𝑝 = { {𝑥, 𝑦}, 𝑄𝐴, 𝐻} o`u 𝐻 = {𝑊𝐹 𝐻(𝐴𝐹) ∣ 𝑊𝐸𝐻(𝐴𝐸) ∣ 𝑊𝐶𝐻(𝐴𝐶) ∣ 𝑊𝑇 𝐻}

Chaque processus de la forme 𝑊𝐻(𝐴) est une enveloppe pour un gestionnaire 𝐻 et 𝐴𝐻

repr´esente la principale activit´e du scope 𝐻.

Les sp´ecifications d´etaill´ees de chaque gestionnaire ont ´et´e pr´esent´ees `a la Section 3.3.2 du Chapitre 3.

Nous pr´esentons maintenent les ´el´ements qui compl´etent la s´emantique du langage WS-BPEL : Boucles : Les boucles sont formellement sp´ecifi´ees en BP-calcul en utilisant la r´ecursivit´e. Nous les formalisons dans ce qui suit :

- L’activit´e contenue dans un ´el´ement <while> s’ex´ecute un nombre arbitraire de fois en fonction de la condition sp´ecifi´ee. La traduction d’un ´el´ement <while> est donn´ee par l’utilisation d’une d´efinition param´etrique r´ecursive :

J𝑤ℎ𝑖𝑙𝑒(𝐶 𝑜𝑛𝑑, 𝑃 )K𝑏𝑝 = 𝐴𝑃(𝑥) o`u

𝐴𝑃(𝑥) = if 𝐶𝑜𝑛𝑑 thenJ𝑃 ∣𝐴𝑃(𝑥)K𝑏𝑝 else 0

Exemple : Le processus WS-BPEL suivant : <while

condition="getVariableData(’i’) != 5"> <sequence>

<invoke partnerLink="A" .../> <assign>

<copy> <from expression="getVariableData(’i’)+1"/> <to variable="i"/> </copy> </assign> </sequence> </while> se traduit ainsi : 𝑃 = if 𝑖 = 5 then 0 else 𝑥 ⟨𝐴, 𝑖⟩ ⊳ 𝑃 𝑙𝑢𝑠1(𝑖) ∣ 𝑃

- Un ´el´ement <repeatuntil> est identique `a <while> `a la seule diff´erence pr`es qu’il s’ex´ecute au moins une fois. Sa traduction est donn´ee par la formule r´ecursive suivante :

J𝑟𝑒𝑝𝑒𝑎𝑡𝑢𝑛𝑡𝑖𝑙(𝐶 𝑜𝑛𝑑, 𝑃 )K𝑏𝑝 = {𝑣, (𝑃, ¯𝑣 𝑖𝑛𝑣_{⟨ ⟩ ∣ 𝑣().𝐴} 𝑃(𝑥)).∅ o`u 𝐴𝑃(𝑥) = if 𝐶𝑜𝑛𝑑 thenJ𝑃 ∣𝐴𝑃(𝑥)K𝑏𝑝 else 0 - <foreach>

Un ´el´ement <foreach> s´equentiel it`ere s´equentiellement l’activit´e imbriqu´ee exactement 𝑛 + 1 fois. Chaque activit´e s’ex´ecute quand celle qui la pr´ec`ede se termine. En ce sens sa s´emantique est similaire `a celle de l’´el´ement <while>.

Un ´el´ement <foreach> parall`ele est plus complexe. Toutes les instances des interactions sont ex´ecut´ees simultan´ement. De mani`ere informelle, 𝑛 + 1 copies du scope imbriqu´e sont cr´e´ees et s’ex´ecutent en parall`ele.

Quand l’´el´ement <completionCondition> n’est pas sp´ecifi´e, l’activit´e <forEach> se termine lorsque tous ses <scope> enfants sont termin´es. Si l’´el´ement <completionCondition> est sp´ecifi´e il force la terminaison anticip´ee de certains des enfants (dans le cas parall`ele).

La condition exprim´ee dans l’´el´ement <completionCondition> est ´evalu´ee `a chaque fois qu’une activit´e enfant se termine et si elle est `a true, l’activit´e <forEach> se termine de la mani`ere suivante :

– Dans le cas d’un <forEach> parall`ele, toutes les activit´es encore en cours d’ex´ecution doivent se terminer par un appel au gestionnaire de terminaison, donc.

– Dans le cas d’un <forEach> s´equentiel, aucun <scope> enfant ne doit plus ˆetre instanci´e, et l’activit´e <forEach> se termine.

– Cas s´equentiel : la formalisation de ce cas est bas´ee sur la r´ecursion et s’exprime comme suit :

J𝑓 𝑜𝑟𝑒𝑎𝑐ℎ𝑠𝑒𝑞(𝐴, 𝑛)K𝑏𝑝 = [𝑐𝑝𝑡 ← 1].if (𝑐𝑝𝑡 = 𝑛) then ¯𝑐

𝑖𝑛𝑣_{⟨⟩ else}

o`u

𝐴𝑟𝑟𝑒𝑡(𝐴, ˜𝑦) = ∏

𝑧∈𝑆𝑛(𝐴)

𝑧⟨˜𝑦⟩

Le canal 𝑐 est utilis´e pour indiquer la terminaison du processus. La fonction 𝐴𝑟𝑟𝑒𝑡() indique `

a toutes les instances encore en cours d’ex´ecution repr´esent´ees par 𝑆𝑛(𝐴) qu’elles doivent

s’arrˆeter.

– Cas parall`ele : Toutes les instances sont cr´e´ees et s’ex´ecutent en parall`ele. A chaque fois qu’une instance se termine, la condition sur <CompletionCondition> est ´evalu´ee. Si elle est `

a true, toutes les instances doivent s’arrˆeter.

J𝑓 𝑜𝑟𝑒𝑎𝑐ℎ𝑝𝑎𝑟(𝐴, 𝑛)K𝑏𝑝 = ∏

𝑧∈𝑆𝑛(𝐴)

([𝒞, 𝑃 ]𝑐𝐴𝐴.𝑅)

o`u

– 𝒞 est l’ensemble de corr´elation et 𝑃 les instances d´ej`a existantes, – 𝑅 = if 𝐶𝑜𝑚𝑝𝑙𝑒𝑡𝑖𝑜𝑛𝐶𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛 =′ 𝑡𝑟𝑢𝑒′ then 𝐴𝑟𝑟𝑒𝑡(𝐴, ˜𝑦) ,

– 𝐴𝑟𝑟𝑒𝑡(𝐴, ˜𝑦) =∏

𝑧∈𝑆𝑛(𝐴)𝑧

𝑖𝑛𝑣_⟨˜𝑦⟩

Remarque : Les ´el´ements qui font appel au m´ecanisme de corr´elation, seront compl´et´es au chapitre 5 pour tenir compte de ce concept. Il s’agit des ´el´ements : ´emission synchrone et asynchrone (<invoke>), r´eception (<receive>), r´eponse (<reply>) et choix (<pick>).