Règles de transformation

Le résultat de la transformation est un ensemble de processus BPEL qui utilisent de façon intensive les liens de partenaire. Dans le cas de cette transformation, le mécanisme des liens est utilisé pour diriger les requêtes émises par un processus du filtre vers lui-même ou vers d’autres processus du filtre. Chaque structure d’une spécification ASTD est transformée en une activité flow (une activité BPEL qui exécute ses sous-activités en parallèle) avec les sous-activités suivantes.

– La première activité fonctionne comme un contrôleur pour la structure ASTD et implémente la sémantique opérationnelle décrite dans le rapport technique du langage ASTD [21]. Cette implémentation inclut, entre autres, la redirection de requêtes et le refus immédiat d’une requête si une condition n’est pas respectée. – Les autres activités si elles existent, encodent la logique des sous-structures

ASTD.

Le contrôleur dirige les requêtes vers le code BPEL correspondant pour la sous-structure ASTD à travers ses liens de partenaire. Au niveau de la sous-structure ASTD, la transformation est effectuée par une fonction récursive T. Cette fonction retourne deux valeurs. La première valeur est une activité BPEL et la seconde un ensemble de sous-processus BPEL utilisés par cette activité.

5.3.1 Le contrôleur

Le contrôleur mentionné précédemment a la même forme pour toutes les structures ASTD. Les différences suivant la structure ASTD apparaissent dans les activités des branches de l’activité pick du contrôleur. L’algorithme qui crée ce contrôleur est listé dans le programme 5.1 et la figure 5.2 schématise son fonctionnement. Le para-mètre TAR de la routine décrite fournit la branche spécifique à la structure ASTD. Cette branche implémente des redirections des requêtes d’autorisation aux activités compagnons du contrôleur, ou même des réponses immédiates aux requêtes si cela est possible. La branche TS permet de terminer l’activité liée à la structure ASTD elle-même. Cette branche est utile lorsque que l’état d’une structure ASTD ne per-met plus d’accepter des actions (et donc toutes les requêtes suivantes se voient refuser

5.3. Règles de transformation 1 Tctrl(astd, TS, TAR): 2 result ← 3 <repeatUntil> 4 <pick> 5 <@ TS @> 6 <@ TAR @> 7 </pick> 8 <condition> 9 RepeatVar<@Name(astd)@> = true() 10 </condition> 11 </repeatUntil>

Programme 5.1 – Algorithme de création du contrôleur BPEL

T_S T_AR

Figure 5.2 – Schéma du contrôleur l’autorisation d’être exécutées). La variable de l’activité de répétition repeatUntil de la ligne 9 est positionnée à la valeur true par la branche TS, pour empêcher le contrôleur d’attendre des requêtes pour des structures ASTD. Par exemple, lorsque l’état d’une structure ASTD séquence passe du premier composant au second com-posant, l’état du premier devient inutile et les ressources qui l’implémentent peuvent être alors libérées. Dans le cas de l’encodage BPEL d’une structure ASTD séquence, cette libération correspond à la terminaison de l’activité implémentant la première sous-structure de cette structure. Le traitement d’une requête pour l’opération Stop — sur l’activité BPEL encodant la première sous-structure — pour terminer l’acti-vité de la première sous-structure, termine ses éventuelles sous-structures et arrête la boucle repeatUntil du contrôleur.

5.3.2 Les opérations des processus

Les processus BPEL issus de la transformation de spécifications ASTD implé-mentent l’opération AR (pour Authorization Request en anglais) décrite à la fi-gure 4.19. Cette opération est de type requête/réponse. La requête SOAP de l’opé-ration comporte comme paramètres l’action ciblée par la demande d’autorisation et la liste des paramètres de l’action (paramètres de contrôle d’accès et paramètres mé-tiers). Le type de la requête est le même pour toutes les opérations correspondant à chaque structure ASTD encodée. La réponse SOAP, dont le type est lui aussi

iden-tique pour toutes les structures ASTD, contient la décision d’autorisation, c’est-à-dire

granted ou denied.

Les processus implémentent aussi l’opération Commit. Cette opération valide l’exé-cution par le système d’information de l’action autorisée par le filtre de contrôle d’ac-cès. En utilisant cette opération, le composant PEP du PEM peut gérer les cas où une action autorisée par le PDP n’est pas exécutée par le système d’information. Lorsque cette opération est appelée avec la valeur false, l’instance de processus qui implémente la politique de contrôle d’accès revient dans l’état précédant la décision d’autorisation

granted à laquelle est associée l’appel à Commit. Pour un appel avec la valeur true,

l’état du processus avance pour attendre les prochaines requêtes d’autorisation. Enfin, les processus BPEL implémentent l’opération Stop. Cette opération, de type requête, permet à l’activité BPEL d’une structure ASTD d’interrompre l’activité d’une sous-structure ASTD lorsque, par exemple, cette activité n’est plus nécessaire pour les décisions d’autorisation. Cette opération est offerte à la fois au composant PEP du PEM par le filtre et à toutes les activités contrôleur par les activités contrôleur imbriquées dans les processus BPEL qui encodent la politique de contrôle d’accès.

Pour permettre au composant PDP d’initialiser une instance du processus BPEL de plus haut niveau (celui du contrôleur de la structure ASTD principale), ce processus offre l’opération Init. L’appel à cette opération prépare une instance du processus pour qu’elle puisse recevoir les requêtes des opérations AR, Commit et Stop.

5.3.3 Les liens de partenaire

Les processus BPEL utilisent les liens de partenaire pour communiquer avec leurs pairs, que ceux-ci soient d’autres processus, des services Web ou les mêmes processus (dans le cas d’un appel d’opération réflexif ). Le processus BPEL d’une structure ASTD peut recevoir des requêtes pour les opérations mentionnées dans la section précédente, à travers le canal des liens de partenaire. Lorsque le contrôleur BPEL d’une structure ASTD transmet une demande d’autorisation au contrôleur d’une sous-structure ASTD (par exemple une sous-structure séquence dont l’état est dans la première

5.3. Règles de transformation

A

B

(a) Structures ASTD

Controller B

invoke ^receive_reply

type=PtrLnkTypeB

PtrLnkCallerB PtrLnkCalleeB (b) Utilisation des liens de partenaire

Figure 5.3 – Exemple de liens de partenaire

sous-structure), cette transmission correspond à une activité invoke, qui utilise un lien de partenaire dans le contrôleur de la structure parent, et une paire d’activités

receive/reply ou onMessage/reply, qui utilisent le même lien de partenaire dans le contrôleur de la sous-structure, ou plus simplement une activité receive ou

onMessagesi l’opération est à sens unique et n’attend pas de réponse. La figure 5.3a illustre les structures ASTD parent et enfant et la figure 5.3b montre l’échange par un lien de partenaire déclaré pour la sous-structure. La déclaration du type de lien de partenaire dans le fichier des interfaces WSDL est explicité dans le programme 5.2. Son utilisation dans les contrôleurs pour les structures parent (appel) et enfant (réponse) sont illustrés respectivement dans les programmes 5.3 et 5.4.

Dans l’algorithme de transformation, les liens de partenaire pour les contrôleurs

appelants (respectivement appelés) sont déclarés par la fonction PtrLinkCaller

1 <partnerLinkType name="PtrLnkTypeB"> 2 <role name="RoleB" portType="�"/> 3 </partnerLinkType >

1 � 2 <partnerLink name="PtrLnkCallerB" partnerLinkType="PtrLnkTypeB" partnerRole="RoleB" �/> 3 � 4 <invoke operation="AR" partnerLink="PtrLnkCallerB" �/> 5 �

Programme 5.3 – Utilisation d’un lien de partenaire dans le contrôleur parent

1 � 2 <partnerLink name="PtrLnkCalleeB" partnerLinkType="PtrLnkTypeB" myRole="RoleB" �/> 3 � 4 <receive operation="AR" partnerLink="PtrLnkCalleeB" �/> 5 � 6 <reply operation="AR" partnerLink="PtrLnkCalleeB" �/> 7 �

Programme 5.4 – Utilisation d’un lien de partenaire dans le contrôleur enfant (respectivement PtrLnkCallee). Le programme 5.5 explicite ces fonctions, ainsi que les fonctions qui fournissent les noms de ces liens de partenaire, permettant leur utilisation dans les activités receive, onMessage, reply et invoke. La fonction Root, définie aux lignes 1 à 5, retourne la chaîne de caractères ’Root’ ou la chaîne vide (’’) selon que transformation de la structure ASTD passée en paramètre donne lieu à un processus BPEL. C’est le cas lorsque la structure en question est la structure principale de la spécification ou que celle-ci a pour structure parent une structure

ap-1 Root(astd):

2 if astd has no parent or

3 has Call, Kleene or Quantified synchronization as parent 4 then result ← ’Root’

5 else result ← ’’ 7 PtrLinkCalleeName(astd): 8 result ← <@Name(astd)@>PtrLnkCallee 10 PtrLinkCallee(astd): 11 result ← 12 <partnerLink name="<@PtrLinkCalleeName(astd)@>" partnerLinkType="<@Root(astd)@>ASTDPartnerLinkType" myRole="<@Root(astd)@>ASTDRole" /> 14 PtrLinkCallerName(astd): 15 result ← <@Name(astd)@>PtrLnkCaller 17 PtrLinkCaller(astd): 18 result ← 19 <partnerLink name="<@PtrLinkCallerName(astd)@>" partnerLinkType="<@Root(astd)@>ASTDPartnerLinkType" partnerRole="<@Root(astd)@>ASTDRole" />