Flux d’informations explicites - Politique de contrôle de flux d'information définie par les ut

FIGURE5.12 – Communication avec les services

FIGURE5.13 – Syntaxe des affectations

l’information cb. Le label associé à outputVariable doit refléter la politique de sécurité de cb et de rep. C’est donc la jonction des labels de cb et rep.

5.3 Flux d’informations explicites

5.3.1 Les affectations

Les affectations permettent de transférer des données d’une expression, d’une variable ou d’un point d’accès vers un service3, ou vers une variable, ou un point d’accès vers un service. L’activité <assign> permet d’englober une ou plusieurs commandes <copy>. Une commande <copy> est composée d’une partie source <from>et d’une partie destination <to>. La syntaxe d’une affectation est pré- sentée sur la figure 5.13.

L’opération <copy> produit un flux d’informations de la source <from> vers la destination <to>. A la fin de l’opération <copy> le label associé à la destination <to> est plus restrictif que le label associé à la source <from> par définition de la propagation des labels.

L’opération d’affectation permettant de modifier à la fois les variables et les points d’accès vers les services, il est donc nécessaire de propager la politique de sécurité à la fois aux variables mais aussi aux points d’accès vers les services afin d’éviter la création d’un canal caché.

Les sources <from> et destinations <to> doivent avoir les mêmes structures. Dans le cas de feuilles d’un arbre XML, le label associé à la feuille <to> doit être plus restrictif que le label associé à la feuille <from>. Par contre si la source <from> est un arbre XML, alors cette source possède un arbre des labels. En effet, dans ce cas, nous pouvons distinguer explicitement les différentes informations contenues dans les variables. A cet effet un label est associé à chacune des informations contenues dans la variable. Dans ce cas la destination <to> est aussi un arbre XML, et l’arbre des labels associé à la destination <to> doit être plus restrictif que l’arbre des labels associé à la source <from> à la fin de l’exécution de la fonction <copy>. C’est ainsi la politique de flux associée à chaque feuille qui est propagée et non la politique de flux globale associée à l’arbre XML. Cela permet ainsi de propager une politique de flux au niveau des informations quand cela est possible et non au niveau des variables.

Les formes possibles de la source <from> sont présentées sur la figure 5.14. La première forme représente soit une variable complète, soit une partie d’un message WSDL. La seconde forme est identique à la première tout en permettant l’exé- cution de requête sur la variable permettant d’extraire une partie de l’arbre XML d’une variable. Le langage de base utilisé pour spécifier les requêtes est XPath4_.

Dans ces deux cas le label associé à la source est un arbre des labels, celui associé à la variable ou une restriction de celui-ci. La troisième forme représente un point d’accès à un service. Dans ce cas le label est celui associé à ce point d’accès. La quatrième forme permet d’accéder à une partie de l’arbre XML d’une variable en fonction de propriétés. La cinquième forme est une expression. Il s’agit la plupart du temps d’expressions forgées à l’aide du langage de requêtes XPath. Dans ce cas le label associé est calculé à partir de l’union des arbres des labels associés à l’expression. Enfin la dernière forme permet d’utiliser des expressions littérales qui ne sont pas associées à des labels puisque ce sont des constantes qui ne varient pas au cours de l’exécution du programme BPEL.

Les formes possibles de la destination <to> sont présentées sur la figure 5.15. Les formes de la destination <to> sont une restriction des formes possibles de la source. Elles permettent de spécifier une variable, une partie d’une variable ou un lien vers un service.

(Exemple 22)

Revenons à l’exemple 18 présenté sur la figure 5.6. Considérons la requête <from>suivante :

4. XPath est le seul langage de requête étudié dans le cadre de cette thèse. D’autres langages de requêtes sont néanmoins utilisables avec BPEL.

5.3 Flux d’informations explicites 111

<from> . . . literal value . . . </from>

FIGURE5.14 – Formes possibles d’une source <from>

FIGURE5.15 – Formes possibles d’une destination <to>

Dans ce cas la variable "paiement" complète est copiée. La requête <from> est donc associée à l’arbre des labels de la variable "paiement" présenté sur la figure 5.6.

La destination <to> correspondante est alors par exemple une copie vers une variable présentant la même structure XML. Dans ce cas c’est l’arbre des labels complet qui est transféré.

Considérons maintenant la variable présentée sur la figure 5.9. Il s’agit d’un message XML suivant le schéma de la figure 5.4. Considérons maintenant la requête <from> suivante :

Dans ce cas seule une partie de la variable requete est utilisée dans la re- quête from. C’est pourquoi seul le label associé à cette partie est transmis à la variable (ou partie de variable) associée à la requête <to>, c’est à dire : [produit : http://client :

http://monVendeur/ ; http://maBanque/] La navigation à l’intérieur d’un arbre XML se faisant le plus souvent à l’aide du langage XPath, des exemples présentant des affectations de parties de variables sont présentés dans la section 5.3.2.

bpws :getVariableData ( ’v a r i a b l e−name’,

’part−name’,

’l o c a t i o n−path’ )

FIGURE5.16 – Syntaxe de la fonction getVariableData

5.3.2 Les requêtes et expressions XPath

Xpath est un langage de requêtes permettant en particulier d’extraire une por- tion d’un arbre XML. C’est le langage de requêtes par défaut de BPEL. Une expression XPath est un chemin de localisation permettant d’accéder à tout ou partie d’un arbre XML. Le résultat de l’évaluation d’une expression XPath est une séquence contenant des nœuds et des valeurs atomiques (textes, booléens...).

En fonction de la nature (nombre, booléen, texte) des valeurs sélectionnées, XPath offre un certain nombre de fonctions. Ces fonctions sont limitées car elles sont plus destinées à être utilisées dans les prédicats que pour effectuer un traite- ment sur les données sélectionnées. Les fonctions les plus utilisées qui s’appliquent aux nombres sont : sum(), count() et les opérateurs arithmétiques. Les fonctions les plus utilisées qui s’appliquent aux chaines sont : subtring(), string-length(), concat().

Des variables sont le plus souvent utilisées dans les expressions XPath dans BPEL. BPEL fournit plusieurs extensions aux fonctions natives XPath. L’exten- sion relative aux données d’une variable est la fonction getVariableData, qui permet d’extraire tout ou partie d’une variable BPEL. Cette fonction prend en en- trée jusqu’à trois paramètres. Le premier, obligatoire, est le nom de la variable. Le second peut-être le nom d’une partie de message et le troisième la localisation du chemin. La syntaxe de cette fonction est présentée sur la figure 5.16.

(Exemple 23)

Revenons à l’exemple 18 présenté sur la figure 5.6. Dans cet exemple la variable possède deux éléments <montant> et <carteBancaire>, chacun des éléments étant associé à un label. Considérons la requête <from> suivante :

<f r o m e x p r e s s i o n =

" g e t V a r i a b l e D a t a ( ’ p a i e m e n t ’ , ’ / P a i e m e n t / m o n t a n t ’ ) " / > Cette requête renvoie le contenu de la partie <montant> de la variable "paiement". C’est donc un type simple XML Schema qui est alors renvoyé. Dans ce cas c’est le label associé au montant qui est renvoyé, c’est à dire :

[produit : http://Client :

Dans le document Politique de contrôle de flux d'information définie par les utilisateurs pour les orchestrations de services. Mise en oeuvre dans un orchestrateur BPEL (Page 126-130)