Les motivations

Dans cette section, nous allons exposer les motivations qui ont incité ce travail de recherche. 4.1.1 Vérification de la compatibilité des protocoles de services

La compatibilité de deux protocoles permet de tester s’ils peuvent interagir correctement et de pouvoir engager des conversations entre eux. La définition de la compatibilité (partielle ou totale) telle que décrite dans [15] restreint le critère de test de compatibilité à l’ordre des

64

opérations et à la polarité des messages. Elle n’est abordée qu’en termes de messages échangés. Bien que, dans [16] cette définition ait été étendue pour prendre en compte les contraintes temporelles liées aux messages (délai, date, heure), la compatibilité de deux protocoles ne peut être abordée sans la prise en considération des effets des opérations. La Figure 4.1, où les protocoles sont modélisés avec des automates d’états finis, illustre un scénario de test de compatibilité.

Protocole P1 Protocole P2

Début Début Identif (+) Identif (-)

Identif (+) Accès-système Identif (-) Identification-faite Saisie-Mt(+) Saisie-Mt(-)

Montant-fourni Affichage-Historique

Avoir-insuffisant (+) Avoir-suffisant (+) Avoir-insuffisant (-) Avoir-suffisant (-) Retrait-abandonné Retrait-effectué Retrait-abandonné Retrait-effectué

Envoi avis(+)

Avis transmis

Figure 4.1 Deux protocoles partiellement compatibles sans considération des contraintes transactionnelles

Le chemin d’exécution (Début.Identif.Identif.saisie-Mt.Avoir-insuffisant) est une conversation correcte et supportée par les deux protocoles P1 et P2, car la séquence de messages (Identif(+).Identif(+).saisie-Mt(+).Avoir-insuffisant(+)) de P₁ est supportée par le protocole P₂. Donc les deux protocoles sont partiellement compatibles.

Cependant, cette compatibilité, même partielle, n’est pas réelle du fait que P1 et P2, lors de leurs transitions d’un état à un autre, invoquent des opérations différentes par les effets

qu’elles engendrent. Par exemple, l’opération déclenchée par le message Avoir-insuffisant(+)

de P₁ peut avoir comme effets: Compte client crédité, compte fournisseur débité, envoi avis, Bonus fidélisation. Alors que l’opération correspondante de P₂ peut avoir d’autres effets: Envoie historique des trois derniers retraits et solde, compte fournisseur débité, Bonus fidélisation. De ce fait, les protocoles P1 et P2 auront des protocoles de compensation différents en cas d’annulation des réservations.

Les conséquences d’un tel constat sont très importantes d’un point de vue:

• Modélisation: Les effets des transactions sont des caractéristiques intrinsèques des protocoles de services. Ils doivent être représentés d’une manière à permettre leur analyse et leur traitement.

• Gestion des transactions et de la compensation: Comment garantir que les protocoles de compensation sont conséquents avec les protocoles abandonnés. Ils doivent défaire sémantiquement les effets observés du coté client.

• Gestion des protocoles: La manipulation des protocoles (compatibilité, substitution, équivalence…) doit tenir compte des aspects transactionnels liés aux opérations et à leurs effets.

65

4.1.2 Inférer les propriétés transactionnelles pour les scénarios existants

Les services Web existants sont implantés via le langage BPEL qui constitue un standard de facto; suite à sont adoption par les industriels du domaine et les consortiums. Ce langage offre un moyen pour décrire le service en tant que programme exécutable aussi bien que pour décrire son comportement (Partie abstact).

Vu la disponibilité de programmes BPEL, il sera opportun de pouvoir extraire les propriétés transactionnelles de ces programmes en vue de leur analyse et de leur manipulation. En effets, les entreprises ayant déjà investi dans la technologie des services Web sont propriétaires d’un patrimoine considérable de programmes BPEL, qu’il faut faire évoluer par l’inférence et l’intégration des propriétés transactionnelles.

Dans cette perspective, un programme BPEL est analysé afin d’extraire ses propriétés transactionnelles. Les éléments « scope » définissant les activités d’un programme, peuvent être isolés (Attribut isolated= « Yes » ) pour contrôler l’accès concurrent aux ressource partagées donc, ils expriment une transaction. Par ailleurs, les éléments de gestion des erreurs et des transactions d’un programme BPEL tels que:

<compensate> ,<compensate scopes> et <compensation Handler>

Constituent des blocs d’activités liées aux propriétés transactionnelles qu’il est opportun de récupérer dans la perspective de leur modélisation et de leur traitement.

L’objectif est de pouvoir extraire toutes les propriétés liées aux transactions à partir des programmes existants, de pouvoir les modéliser, de modéliser aussi leurs protocoles de compensation et vérifier leur consistance en termes d’effets avec le protocole à compenser. Cette action, offrira un cadre favorable à la vérification de la cohérence d’un protocole avec son protocole de compensation (ou d’autres protocoles) et permettra une gestion (compatibilité, équivalence, substitution…) des protocoles métiers avec prise en compte de leurs contraintes transactionnelles.

4.1.3 Vérifier la consistance d’un protocole existant (outils de conception)

En cas d’échec d’une transaction, il faut exécuter une autre activité de compensation ou

protocole de compensation afin d’annuler les effets engendrés.

Le protocole de compensation est différent de la simple annulation des effets générés par le protocole déclencheur ; c’est un autre protocole métier. En effet, certains fournisseurs affectent une partie de la charge liée aux transactions, qui sont de longue durée et coûteuses en ressources, aux clients. A titre d’exemple, une compagnie aérienne pénalise les clients qui annulent leur réservation en retenant un taux du montant du billet qui dépend de la classe du voyage et de la date d’annulation.

Le problème consiste, alors, à vérifier si le protocole de compensation est consistant avec le protocole déclencheur ? Autrement, est-ce que la compensation garantie une « inversion » des effets ou « Une annulation sémantique » du protocole déclencheur ?

La modélisation des effets des transactions, ainsi que la manipulation des protocoles de services avec prise en compte des contraintes transactionnelles établira une assise théorique solide pour vérifier la consistance d’un protocole de compensation avec son protocole déclencheur. Les environnements logiciels adéquats offriront aux développeurs de services

66

les outils de conception nécessaires pour les décharger de certaines tâches et tests inutiles liés à la vérification de la consistance des protocoles.

4.1.4 Vérification de la conformité d’un programme avec un évènement externe

L’extraction de la spécification du protocole à partir de son implémentation dans un langage (BPEL), peut être exploitée par des outils automatiques pour vérifier la conformité des messages en entrée avec le protocole de service extrait à partir du programme. Il s’agira de tester qu’une ou plusieurs activités décrites dans le programme sont conformes aux messages reçus.

Dans un premier temps, la partie abstract d’un programme BPEL, décrivant le comportement externe du service et qui représente la chorégraphie du service, est traduite en protocole qui sera modélisé par des automates à états finis intégrant les propriétés transactionnelles. En second lieu, les messages reçus correspondent aux transitions entre les états de l’automate sont représentés avec le même formalisme. L’intérêt est de pouvoir tester, si une ou plusieurs parties du protocole, spécifiées préalablement, sont conformes aux messages reçus et quels sont les effets observés du côté client ? Quels seront les effets sur le client après exécution du protocole de compensation ?

La représentation des propriétés transactionnelles des protocoles et la proposition d’opérateurs de manipulation prenant en compte ces propriétés, fourniront une infrastructure pour vérifier la conformité des protocoles avec les messages reçus et faciliteront par conséquent le processus de développement.