• Aucun résultat trouvé

Interprétation d’une politique de contrôle d’accès ASTD par des

6.4 Interprétation de spécifications ASTD

Filter.Execute <c:PId>T101</c:PId> ASTD.Execute <c:PId>T101-QChoice-QC</c:PId> QChoice.Execute <c:PId>T101-QChoice-QC-B-clerk</c:PId> ASTD.Execute �

Figure 6.17 – Évolution des identifiants des processus

lise l’opération Execute du processus ASTD, elle utilise le même identifiant. L’ins-tance du processus ASTD est alors identifiée par l’identifiant T101. Cette insL’ins-tance crée ensuite l’identifiant T101-QChoice-QC qu’elle utilise pour appeler l’opération Execute du processus QChoice.

6.4 Interprétation de spécifications ASTD

Comme il a été mentionné précédemment, le filtre comporte dix processus BPEL qui permettent d’interpréter des spécifications ASTD. Les processus BPEL Automaton, Sequence, Choice, KleeneClosure, Synchronization, Guard, QChoice, QSynchronization et également Call implémentent les règles sémantiques for-melles du langage ASTD, tandis que le processus ASTD permet d’aiguiller les appels d’opérations entre ceux-ci. Dans cette section, l’implémentation faite de l’interpréta-tion des structures ASTD est décrite à travers l’exemple de la figure 6.8.

Lorsque le processus QChoice reçoit la requête SOAP de l’opération Execute avec un nouvel identifiant de processus unique, une nouvelle instance de processus est créée puisque la requête est récupérée par une branche onMessage. La branche fait partie d’une activité pick marquée avec l’attribut createInstance et la valeur

1 <soap:Envelope 2 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 3 xmlns:t="http://gril.udes.ca/astd/schema/Types" 4 xmlns:a="http://gril.udes.ca/astd/schema/ASTD" 5 xmlns:c="http://gril.udes.ca/astd/schema/Common"> 6 <soap:Header/> 7 <soap:Body> 8 <t:ExecuteRequestType> 9 <c:PId>T101-QChoice-QC</c:PId> 10 <t:ASTD> 11 <a:QChoice a:Name="QC">...</a:QChoice> 12 </t:ASTD> 13 <t:State> 14 <a:QChoiceState a:V="">...</a:QChoiceState> 15 </t:State> 16 <t:Event c:Name="deposit">...</t:Event> 17 <t:Environment/> 18 </t:ExecuteRequestType> 19 </soap:Body> 20 </soap:Envelope>

Programme 6.10 – Requête SOAP de l’opération Execute

yes pour cet attribut. Comme le montre le programme 6.10, la requête contient l’encodage XML de la spécification (lignes 10 à 12) et son état courant (lignes 13 à 15), l’événement (ligne 16) pour lequel un nouvel état est calculé et un environnement vide (ligne 17).

Le traitement de la requête SOAP pour l’opération Execute dans le processus QChoice est illustré à la figure 6.18. À la réception de la requête, l’environnement initialement vide est mis à jour (comme décrit à la section 6.2.3) pour insérer la variable de quantification de la structure ASTD. Deux situations peuvent se présenter ensuite : une valeur a été attribuée à la variable de quantification ou pas (attribut a:V de la ligne 14 du programme 6.10) dans l’état courant de la spécification. Dans les deux cas, une liste de valeurs est constituée, avec soit la valeur attribuée à la variable de quantification, soit la liste des valeurs du type de la variable de quantification obtenue en utilisant la feuille de style GetTypeValues.xsl (voir la section 6.2.4). Dans une activité while, chacune des valeurs de cette liste est insérée dans l’environnement pour la variable de quantification, un nouvel identifiant de processus est créé et une nouvelle requête SOAP est préparée.

6.4. Interprétation de spécifications ASTD

Début Requête

Execute(structure, état, événement, environne-ment)

Mettre à jour l’environne-ment avec la variable de quantification

Valeur va-riable = ⊥

Créer une liste avec cette

valeur Créer une liste des valeursdu type de la variable

Pour chaque valeur de la liste

Placer la valeur dans l’en-vironnement

Créer un nouvel ID de processus

Créer une nouvelle requête avec : - le nouvel ID - la sous-structure ASTD - le sous-état - l’événement - l’environnement Appeler ASTD.Execute avec la nouvelle requête

Autre va-leur dans la liste ? État de la réponse = EmptyState

Préparer la réponse avec EmptyState

Préparer la réponse avec le nouveau sous-état Réponse Execute avec la nouvelle réponse Fin oui non non oui oui non

Figure 6.18 – Organigramme de l’opération Execute du processus QChoice La nouvelle requête SOAP contient le nouvel identifiant, la sous-structure ASTD

garde, le sous-état inclus dans l’état du choix quantifié (par exemple, les lignes 4 à

10 dans le programme 6.2), l’événement reçu dans la requête qui a permis de créer l’instance courante du processus et enfin l’environnement avec la valeur courante de la liste. L’instance de processus émet ensuite la nouvelle requête SOAP au processus ASTDpar le lien de partenaire SubASTDPtrLnk et reçoit la réponse SOAP contenant l’état de la structure ASTD garde pour l’événement considéré. Si ce nouvel état de la garde est différent de EmptyState, la recherche s’arrête et une réponse SOAP, est préparée contenant l’état de la garde, puis retournée. La réponse préparée contient un état de type QChoiceState dont le sous-élément XML a:S est le sous-état retourné par l’appel précédent à Execute. Dans le cas contraire les valeurs suivantes de la

Début Requête

IsFinal(structure, état, environnement)

Mettre à jour l’environne-ment avec la variable de quantification

Valeur va-riable = ⊥

Créer une liste avec cette

valeur Créer une liste des valeursdu type de la variable Pour chaque valeur de la liste

Placer la valeur dans l’en-vironnement

Créer un nouvel ID de processus

Créer une nouvelle requête avec : - le nouvel ID - la sous-structure ASTD - le sous-état - l’environnement Appeler ASTD.IsFinal avec la nouvelle requête

Autre va-leur dans la liste ? La réponse contient false

Préparer la réponse avec

false Préparer la réponse avec true

Réponse IsFinal avec la nouvelle réponse Fin oui non non oui oui non

Figure 6.19 – Organigramme de l’opération IsFinal du processus QChoice liste sont explorées de façon similaire. À l’issue de l’exploration de toutes les valeurs de la liste, une réponse SOAP contenant l’état spécial EmptyState est préparée, puis retournée à l’instance de processus ASTD appelant. Cette réponse indique qu’un nouvel état de la spécification n’a pas pu être atteint pour l’événement considéré.

Les opérations IsFinal et IS (voir respectivement les figures 6.19 et 6.20) sont implémentées de façon similaire, toujours en exploitant la sémantique formelle du langage ASTD.

6.5. Conclusion

Début Requête IS(structure, en-vironnement)

Créer un nouvel ID de processus

Créer une nouvelle requête avec :

- le nouvel ID

- la sous-structure ASTD - l’environnement Appeler ASTD.IS avec la nouvelle requête

Préparer la réponse avec le nouveau sous-état Réponse IS avec la nou-velle réponse

Fin

Figure 6.20 – Organigramme de l’opération IS du processus QChoice

6.5 Conclusion

La solution présentée dans ce chapitre repose sur une méthode d’interprétation de spécifications formelles écrites en ASTD. Tout comme la solution du chapitre précédent, elle constitue une approche de calcul des décisions d’autorisation pour des politiques de contrôle d’accès dynamique. Cette solution semble plus élégante que celle du chapitre précédent car elle est calquée sur la sémantique opérationnelle du langage ASTD, aussi bien pour les traitements que pour les structures des données. Sa mise en œuvre demeure néanmoins complexe considérant les formats d’encodage des spécifications ASTD et des messages émis ainsi que des détails de programmation des processus BPEL déployés dans un environnement SOA.

Chapitre 7

Expérimentation

Une expérience réalisée à partir d’un banc d’essai a permis de valider la faisabilité et d’évaluer la performance des deux méthodes d’implémentation du filtre de contrôle d’accès dynamique (simplement nommé filtre dans la suite). La validation est faite sous la forme de tests unitaires qui sont aussi utilisés pour une partie de l’évalua-tion de la performance. L’expérience inclut également l’intégral’évalua-tion du filtre dans un PEM qui interagit avec un système d’information simplifié d’une banque, tous deux déployés dans un environnement SOA. Cette partie du banc d’essai permet d’évaluer la performance globale d’un système sécurisé.