invocation n

La fusion de n invocations {i1, i2, ..in} correspond (1) soit à créer une nouvelle invoca-tion simple unificatrice et éventuellement les adaptateurs nécessaires, (2) soit à créer une invocation complexe qui coordonne les invocations simples, (3) soit à compléter une invocation complexe avec des invocations simples.

Le choix 3 s’impose en présence d’une invocation complexe.

Si entre les activités simples, l’intersection deux à deux des précédents (Pred*) avec les successeurs (Succ*) est non nulle, la seule composition autorisée est la fusion en une ac-tivité complexe respectant une politique separate. S’il existe déjà une acac-tivité composite appartenant à l’ensemble de fusion qui suit une autre politique, la fusion échoue. Cette contrainte permet d’éviter la création d’un circuit.

Dans les autres cas (uniquement des invocations simples sans détection d’un circuit po-tentiel entre elles), l’utilisateur devra choisir entre 1 et 2, et faire dans ce dernier cas le choix de la politique.

Lors de la fusion des activités receive, les variables X et Z sont unifiées, tandis que la variable Y est laissée libre.

La nouvelle activité créée est ici e1. Les transformations consistent à remplacer a1 et b1 par e1, les substitutions unifient X et Z à une nouvelle variable A.

7.2. Formalisation et composition dans le domaine des orchestrations 141 1 - Fusion en une invocation simple La figure7.7visualise différentes fusions pos-sibles d’invocations simples par unification des variables ou ajout d’un adaptateur. Nous explicitons ces fusions à présent.

La fusion des activités invoke a1 et a2 dans consiste simplement à remplacer ces activités par la nouvelle activité a3.

Dans la figure du milieu, la fusion est complétée par l’unification de v1 et v2 en une va-riable v3. Cette fusion engendre du non-déterminisme que la normalisation sur domaine lève.

Dans la figure de droite, la fusion crée un adaptateur qui fait la somme des variables v1 et v2 et s’interpose donc entre la nouvelle activité et les prédécesseurs des activités a1 et a2.

FIGURE7.7: EXEMPLES DE COMPOSITION D’ACTIVITÉS SIMPLES

Soient les n invocations simples iiqui constituent l’ensemble de fusion :

la fusion de ces n invocations simples crée une nouvelle activité simple et éventuelle-ment un ensemble d’adaptateurs qui combinent les variables d’entrées des invocations initiales. Les variables d’entrée de la nouvelle activité correspondent donc soit à l’uni-fication de variables d’entrées à la même place dans les invocations simples, soit à la valeur de retour d’une activité "adaptateur" créée. Les nouveaux adaptateurs précèdent la nouvelle activité simple et ont pour prédécesseurs tous les prédécesseurs de activités fusionnées.

La figure7.8présente un exemple de fusion introduisant un adaptateur.

Résultats de la fusion d’activités invoke simples en une activité d’invocation simple :

Activities = {i₁, i₂, ..i_n}|ii= (id_i, (invoke(service, operation), {v₁ⁱ, ..vⁱ_k}, {oⁱ})) – Nouvelles activités :

newActivities = {i} ∪Sl=z

l=1{adl} où 0 ≤ z ≤ k²et i = (id, invoke(service, operation), {v1, ..v_k}, {o}), ad_l= (id_adl, (adapt(adapter_l), {v_l1, ...v_lm}, {v_l})) – Nouveaux éléments de précédence :

newRp =Sl=z

l=1{pred(idadl, id)} ∪Si=n i=1

S

idj∈pred(Rp,idi)

Sl=z

l=1{pred(idj, idadl)} – todoR= {unif y({v¹_j, ...v_j^m}), ...} ∪ {replace_(i1,id), replace_(i2,id), ..., replace_(in,id)}

Le remplacement des variables par une nouvelle variable peut briser la propriété du domaine, qui interdit des accès concurrents en lecture et écriture à une même variable

2. Il y a au maximum autant d’adaptateurs que l’arité de l’invocations simple, mais il peut aussi n’y en avoir aucun.

(cf.figure7.7, au milieu). Un accès concurrent peut être résolu par exemple en introdui-sant une précédence entre ces activités. Cette capacité est apportée par la normalisation sur domaine, lorsque tous les ensembles de fusion ont été résolus, des accès concurrents pouvant disparaître par unification de variables par exemple.

FIGURE7.8: EXEMPLE DE FUSION D’INVOCATIONS SIMPLES AVEC INTRODUCTION D’UN ADAP

-TATEUR

2 - Fusion en une invocation complexe La fusion consiste à créer une nouvelle activité composite d’identifiant id et composée des activités idi.

Pour cela, les activités simples idisont modifiées pour leur associer l’invocation complexe. Dans le cas d’une politique separate les relations de précédence et les variables ne sont pas modifiées. Dans le cas d’une politique de synchronisation, chacune des invocations simples a pour prédécesseur l’union des prédécesseurs de toutes les activités simples. Ces relations, ne mettant pas en jeu une nouvelle activité, sont gérées par transformations. La figure7.9visualise un exemple d’une telle composition.

Les transformations à appliquer sont alors la modification des activités simples et l’ajout de précédence.

Résultats de la fusion d’activités invoke simples en une activité d’invocation complexe par Politique Separate :

7.2. Formalisation et composition dans le domaine des orchestrations 143

Les activités a2, b2 et c2 sont considérées comme ne pouvant pas être fusionnées mais devant être synchronisées. On enregistre cette information via une activité complexe, ici d6. Cette activité n’est pas connectée aux graphes des activités par une relation d’ordre parce que les relations d’ordre ont été déployées directement sur les activités appartenant à l’activité complexe.

– newActivities = {i} i = (id, invokeComplexe(service, operation, SP ), {v1..v_k}, {o}), où {v1..v_k} sont des variables libres

– newR_p = {} – todoR=Si=n

i=1{setInCompositeActivity_(idi,id)}

Résultats de la fusion d’activités invoke simples en une activité d’invocation complexe par Politique de synchronisation :

Activities = {i₁, i₂, ..i_n}/ii= (id_i, (invoke(service, operation), {vi 1, ..vi

k}, {oi}))

– newActivities = {i} i = (id, complexInvoke(service, operation, SCEP ), {v₁..v_k}, {o}), où {v1..v_k} sont des variables libres

– newRp = {} – todo_R=S_i=n

i=1{setInCompositeActivity_(idi,id)}∪ S_i=n

i=1

S

idj∈pred(Rp,idi){addP recedenceRelation_(idj,idi)}

3 - Complément d’une invocation complexe S’il existe une invocation complexe et des invocations simples faisant référence au même service et à la même opération, les activités simples sont considérées comme composant l’activité composite. Donc, seule l’étape de création de l’activité complexe est retirée de la fusion présentée précédemment, pour le reste nous avons exactement le même comportement.