Cette section présente une liste des différents cas d’interférences détectés à l’intégration des aspects. Chaque interférence a été introduite dans la chaine d’aspects du côté client, ser- veur primaire, serveur secondaire par inadvertance. Elle relève toutes du "vécu" et m’ont causé quelques soucis.
5.6.1 Détection d’interférences côté serveur primaire
Du côté serveur, dans la gestion du mode primaire plusieurs aspects sont appliqués avant le point de jonction correspondant à l’exécution du service. Dans la section précédente nous avons présenté la spécification de chacun de ces aspects. Nous détaillons maintenant les in- terférences qui se sont produites lors de l’intégration de ces aspects dans un ordre qui viole la spécification d’un aspect.
Les greffons ACheckMode.getMode, AForwardRequest.forward, ACheckPoint.buildCheckPoint, ANumbering.remove, AIdentifier.remove sont appliqués avant l’exécution du service. L’ordre d’application permettant de réaliser le comportement attendu du protocole duplex et de réali- ser la spécification de chacun des aspects est ACheckMode.getMode < AForwardRequest.forward < ANumbering.remove < AIdentifier.remove < service <ACheckPoint.buildCheckPoint. Nous sup- posons ici que le serveur est en mode primaire. Cette séquence d’aspects a pour conséquence de transmettre la requête au serveur secondaire, de préparer le traitement de la requête, d’exé- cuter le service. Enfin une fois le service exécuté, un point de reprise est construit et envoyé au serveur secondaire.
Cependant, l’intégrateur peut introduire une faute en appliquant les aspects dans l’ordre
suivant : ACheckMode.getMode < ANumbering.remove < AIdentifier.remove < AForwardRequest.forward < service <ACheckPoint.buildCheckPoint.
α β γ δ ε Τ Join%point%% Variable% msgContent) msg) service AChecker Join%point% Variable% msgContent) msg)
Join%point% Variable% Value%
msgContent) msgContent) «)msg)») ACheckPoint . Forward Request 1 2 4 5 6 3 variablesToStor e variablesToChec k storedVaraibles AIdentifier. remove ANumbering. remove Storer Arrivée au point de jonction jpi α Ai commence son exécution β Ai finit son exécution γ Suppression du point de jonction jpi Φ L’exécution de jpi commence
dans le code de base
δ δ’ Jpi finit son exécution
Legende)
FIGURE5.10 – Interférence de type CB entre le greffon Anumbering.remove et le greffon ACheck-
Point.forward
Il y a une modification de la variable du code de base msgContent utilisé par forward, par un autre aspect exécuté avant forward. Cette interaction viole la spécification du greffon. Le com- portement induit par l’ordre d’exécution des aspects est problématique dans la mesure où le contenu de la requête est modifié avant l’envoi au serveur par les aspects ANumbering.remove et AIdentifier.remove. Du côté du serveur secondaire la requête arrive sans identifiant de re- quête ni de client, ce qui induit des erreurs dans la récupération de la requête.
Du côté du secondaire l’aspect ACheckPoint.buildCheckPoint s’appuie sur ces identifiants pour stocker dans une structure de données l’identifiant client, le numéro de séquence de re- quête, requête et le résultat et mettre à jour l’état. En l’absence d’identifiant dans la requête ACheckDuplicate.check ne peut pas décider si la requête est dupliquée ou s’il s’agit d’une mise à jour de l’état par un point de reprise. En l’absence d’identifiant aucune action correcte n’est entreprise du côté du serveur secondaire.
La figure5.10illustre cette interférence. Lors de l’activation de la chaîne d’aspect, lors de la transition Æ la valeur de la requête est capturée et sauvegardée dans une structure de données par un greffon dédié. Avant l’exécution de ACheckPoint.buildCheckPoint, les greffons ANum- bering.remove et AIdentifier.remove sont exécutés. Ces deux greffons modifient la valeur de la requête. Lors de la transition Ø le greffon AChecker compare la valeur au moment de l’activation de la chaine d’aspect (Æ ) et la valeur actuelle à Ø. Le contenu de la requête ayant été modifiée le greffon AChecker écrit alors dans le fichier de trace CB (core.server.service().java, msgContent ), ce qui signifie qu’une interférence de type CB a été détectée autour de l’appel à la méthode service sur la classe server.
5.6.2 Détection d’interférences côté client
Du côté client, la gestion du recouvrement est géré par des greffons appliqués avant les points de jonction send() et receive(). Nous détaillons maintenant une interférence qui s’est produite lors de l’intégration de ces aspects dans un ordre qui viole la spécification des gref- fons présentée dans la section précédente et qui a requis d’élargir le spectre des interférences auquel nous nous sommes initialement intéressé.
Les greffons ANumbering.insert, AIdentifier.insert, ACacheManager.addIn sont appliqués avant l’exécution de la méthode send(). L’ordre d’application permettant de réaliser le comportement attendu est ANumbering.insert > ACacheManager.addIn > AIdentifier.insert. Cette séquence d’aspects ajoute à la requête un numéro de séquence, la sauvegarde à des fins de recouvre- ment, ajoute un numéro de client à la requête.
L’intégrateur peut introduire une faute en appliquant les aspects dans l’ordre suivant : ANum- bering.insert > AIdentifier.insert > ACacheManager.addIn.
Dans ce cas il y a une modification de la variable du code de base msgContent utilisé par ACacheManager.addIn, par AIdentifier.insert exécuté avant ACacheManager.addIn. Cette inter- action viole la spécification du greffon. Le comportement induit par l’ordre d’exécution des aspects est problématique dans la mesure où le contenu de la requête est modifié avant ACa- cheManager.addIn.
Le problème vient du fait que la requête en s’appuie sur le délimiteur inséré par le greffon ANumbering.insert pour la stoker dans une structure de données. Par exemple, comme l’illustre la partie supérieure de la figure5.11, pour invoquer une commande appelée service() sur le serveur, la requête initiale est la suivante : "service()". Le greffon ANumbering.insert insère un numéro de séquence de requête ce qui transforme la requête comme suit : "36 : service()". Le greffon ACacheManager.addIn récupère ensuite le premier élément à gauche du caractère " :" pour initialiser un champ d’une structure de données correspondant au numéro de séquence de la requête. L’élément à droite du caractère " :" est utilisé pour initialiser un champ corres- pondant au contenu de la requête.
Analysons maintenant le cas ou le greffon AIdentifier.insert est appliqué après ANumbe- ring.insert comme illustré dans la partie inférieure de la figure5.11; le contenu de la requête est alors : "client1 : 36 : service()". Le numéro de séquence de requête stockée est "client1" et le contenu de la requête stocké est "36".
Les conséquences de cette erreur se propagent alors comme suit :
– Du côté du serveur primaire, la requête "36" ne peut pas être interprétée, car elle ne cor- respond pas au nom d’un service fournit par la serveur.
– Du côté du serveur primaire, pour la requête "36", le serveur ne fournit pas de réponse, il est considéré comme défaillant. Le recouvrement est lancé. Le client renvoie le requête au secondaire devenu primaire. Ici encore la requête n’est pas interprétée.
La figure5.12illustre cette interférence. Après l’activation de ANumbering.insert, lors de la transition Æ la valeur de la requête est capturée et sauvegardée dans une structure de données par un greffon dédié. Avant l’exécution de ACheckPoint.buildCheckPoint, les greffons ANum- bering.remove et AIdentifier.remove sont exécutés. Ces deux greffons modifient la valeur de la requête. Lors de la transition Ø le greffon AChecker compare la valeur au moment de l’activation
ACacheManager., addIn,, Send(service()), Code non-fonctionnel Code fonctionnel Legende :
Greffon de type après Greffon de type avant AIden5fier.insert,
ANumbering.insert,,
B A Client
idRequête) Requête) réponse) minuteur)
36, service(), 0, 20, 36 : service() service() client 1 : 36 : service() client1 : 36 : service() B B B ACacheManager., addIn,, Send(service()), AIden5fier.insert, ANumbering.insert,,
idRequête) Requête) réponse) minuteur)
Client,1, 36, 0, 20, 36 : service() service() client 1 : 36 : service() client1 : 36 : service() B B B Client
FIGURE5.11 – Illustration de l’interaction entre les greffons ANumbering.insert, ACacheMana-
ger.addIn, AIdentifier.insert deux ordres de prècèdence
le greffon AChecker écrit alors dans le fichier de trace CB (service, msgContent ), ce qui signi- fie qu’une interférence de type CB a été détectée autour de l’appel à la méthode service sur la classe server.
Cependant, même en implémentant un resolver réalisant l’ordre de précédence escompté il s’avère que la vérification de l’évitement d’une interférence de type CA sur le greffon ANum- bering.insert est problématique. En appliquant les greffons dans l’ordre ANumbering.insert > ACacheManager.addIn > AIdentifier.insert l’instrumentation pour la détection de CA est activée alors qu’il s’agit bien du comportement attendu de la composition.
Nous avons dû spécifier plus finement le comportement désirée de la composition de ces greffons. Deux éléments sont à distinguer dans le comportement attendu :
– le premier est la vérification d’une dépendance entre ANumbering.insert et ACacheMa- nager.addIn en effet afin que ACacheManager.addIn sauvegarde la requête envoyée elle doit comporter des informations préalablement insérer par ANumbering.insert.
– le deuxième élément est une spécialisation d’une interférence de type CB tel que nous l’avons défini. Il s’agit cependant d’une interférence de type CB entre de point de la chaine d’aspect et non entre le début de la chaine.
Les propriétés qui sont attendues de la composition peut donc se résumer comme suit : – pas de changement de la variable msgContent entre l’exécution de ANumbering.insert et
ACacheManager.addIn.
α β γ δ ε Τ Join%point%% Variable% send()' msgContent' service AChecker Join%point% Variable% send()' msgContent'
Join%point% Variable% Value%
send()' msgContent' Client1':'36':'service()'
Acache Manager. addIn 1 2 4 5 6 3
variablesToStore storedVaraibles variablesToCheck
ANumbering. insert AIdentifier. insert Storer Arrivée au point de jonction jpi α Ai commence son exécution β Ai finit son exécution γ Suppression du point de jonction jpi Φ L’exécution de jpi commence
dans le code de base
δ δ’ Jpi finit son exécution
Legende'
FIGURE5.12 – Interférence de type CA entre le greffon ANumbering.insert et le greffon AIdenti-
fier.insert
En nous appuyant sur l’approche d’instrumentation présentée précédemment nous avons instrumenté l’observation de cette propriété de la manière suivante :
– La détection d’une interférence de type CB entre ANumbering.insert et ACacheMana- ger.addIn est instrumentée en insérant deux greffons dans la chaine d’exécution. Le pre- mier greffon est inséré après l’exécution de ANumbering.insert qui capture la valeur de la variable msgContent. Le second greffon est inséré avant l’exécution de ACacheMana- ger.addIn et vérifie que la valeur de la variable msgContent n’a pas été modifiée.
– La vérification que la dépendance entre ANumbering.insert et ACacheManager.addIn réa- lisé est instrumenté en insérant deux greffons dans la chaine d’exécution. Un premier greffon est inséré après l’exécution de ANumbering.insert, un deuxième greffon est in- séré avant l’exécution de ACacheManager.addIn.
Cet exemple montre que notre approche d’instrumentation peut être étendue pour vérifier d’autres propriétés. Rappelons que cette thèse se concentre sur un sous ensemble des interfé- rences en aspects.