T H E S E - LIFL

38 Travaux sur la gestion de la Qualité de Servicepour leur plateforme.Mise en oeuvre Selon le Transparent shaping, des hooks sont insérées dans le codede base afin d’appeler du code adaptatif. Les auteurs définissent une application avecdes indirections comme une application adapt-ready. Cette adaptation est transparentecar elle préserve les fonctionnalités liées au comportement original de l’application etne mélange pas le code fournissant un nouveau comportement avec le code de base.Dans le cadre de la prise en charge de l’adaptation des processus BPEL, les auteursont développé un framework, appelé TRAP/BPEL, qui permet de générer des processusBPEL adapt-ready. De tels processus sont alors capables d’observer les invocationsvers les services Web partenaires et sont augmentés par des invocations vers un proxygénérique qui a pour rôle de fournir la logique d’adaptation. Ce proxy redirige alorsdes messages SOAP vers d’autres services lorsqu’un service Web échoue. Il est utilisépar tous les partenaires du processus et contient la logique de sélection des services.Pour cela, les politiques spécifiées dans le document de configuration sont chargées statiquement(au déploiement) dans le proxy. Les auteurs envisagent de pouvoir modifierces politiques dynamiquement. Une politique s’applique à une activité d’invocation, cequi permet au proxy de faire le lien entre une politique et un message SOAP losqu’ilreçoit un appel. Ces politiques permettent de spécifier trois types d’action : invoquerun service particulier, rechercher et invoquer un autre service, et réessayer l’invocationen cas d’échec. Le listing 3.4 exhibe une politique effectuant des rappels à un serviceen cas d’erreur.2 < InvokeName value ="WS - Invoke "/>< WsdlUrl preferred =" true " value =" http ://.../ WS - Description . wsdl "/>< Timeout seconds ="2"/>< MaxRetry value ="2"/>7 < RetryInterval seconds ="5"/> ... Listing 3.4: Exemple de politique TRAPPar ailleurs, des indirections sont insérées aux endroits sensibles du processus BPELoriginal. Lors de leur premier prototype, RobustBPEL, les auteurs avaient introduit desactivités scope autour des activités d’invocations de manière à pouvoir récupérer leserreurs dans un « fault handler » lorsqu’une invocation échouait, comme décrit dans lelisting BPEL 3.5. Un service du proxy était alors appelé pour informer le comportementlié à cet événement.< faultHandlers >< invoke name =" InvokeProxy " ../ >5 < eventHandlers >< onAlarm for =" PT15S ">< invoke name =" InvokeProxy " ../ >10 < invoke name =" invokeApprover " .."/>Listing 3.5: Modification du BPEL en fonction de la politiquePour la nouvelle version de leur prototype, les auteurs ont choisi d’intégrer davantagela logique d’adaptation dans le proxy et donc les activités d’invocations sont