Transformation d’une spécification ASTD

Vue globale de l’algorithme de transformation

L’algorithme qui transforme une spécification ASTD d’une politique de contrôle d’accès en un ensemble de processus BPEL est récursif. L’algorithme crée les proces-sus BPEL en même temps que les interfaces WSDL et les définitions de type XSD. Les interfaces WSDL, requises par le moteur d’exécution BPEL, décrivent les interactions avec les processus et permettent de les exposer comme des services Web. Les docu-ments XSD décrivent les types des paramètres passés dans les messages échangés par les processus BPEL. La transformation est basée sur les événements dans le sens que les processus BPEL imitent les flots d’événements décrits par la spécification ASTD.
L’algorithme de transformation génère des processus BPEL pour des spécifications ASTD qui comportent certaines limitations. La première concerne les cycles dans les structures ASTD automate. En effet, la transformation d’une telle structure procède au parcours de ces transitions à l’instar du parcours d’un arbre. Dans l’éventualité où il est indispensable d’utiliser un cycle dans une structure automate, une étape de prétraitement de la spécification permet simplement de transformer le graphe de transition en utilisant les structures ASTD choix, séquence et fermeture de Kleene. L’exemple de la figure 5.1 illustre bien ceci. La figure 5.1a montre une spécification avec un cycle et la figure 5.1b un possible équivalent. L’équivalence entre les expressions régulières et les automates dans la théorie des langages assure qu’un tel prétraitement est toujours possible (voir [47]).
La seconde limitation concerne l’utilisation de macro-états dans les structures ASTD automate. Cette restriction empêche l’utilisation de transitions de type from et to dans les automates. Toutefois cette limitation n’est pas handicapante dans l’ex-pression de règles de contrôle d’accès puisque les macro-états ne sont pas utilisés dans les patrons de règles.

Évolution de l’algorithme de transformation

L’algorithme décrit dans ce chapitre en est à sa troisième itération. La première, décrite dans [16], est étroitement liée aux patrons de règles de contrôle d’accès. Dans cette version, la transformation utilise un squelette d’activités BPEL spécifique pour chaque patron de règle. Ces squelettes sont ensuite rendus concrets par une explo-ration de la spécification ASTD vue comme un arbre. L’algorithme procède en deux phases. La première consiste en la transformation de la spécification en un arbre syn-taxique abstrait annoté. Les annotations aux nœuds de l’arbre sont des résultats de calcul qui sont utilisés pour créer les activités BPEL dans la seconde phase.
L’itération suivante de l’algorithme de transformation a été publiée dans [15]. Elle permet d’éliminer l’étape du calcul de l’arbre syntaxique abstrait. De plus, elle pré-cise mieux de façon algorithmique le passage des structures ASTD vers les activités BPEL, toujours dans le contexte des patrons des règles de contrôle d’accès. La troi-sième itération, présentée dans cette thèse, comporte moins de limitations que les précédentes. En effet cette transformation n’est plus restreinte aux seuls patrons de règles de contrôle d’accès, mais peut être appliquée à toute spécification ASTD pour autant que celle-ci se conforme aux restrictions exposées à la section 5.1.

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 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é.

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

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 identique 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.

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 structure séquence dont l’état est dans la première 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 onMessage si 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.