Un Protocole de communication dynamique pour les services Web (DynWes
Un Protocole de communication dynamique pour les services Web (DynWes)
DynWes, Protocole de communication dynamique pour les services Web Tari et al[31, 32, 38] proposent un modèle de communication dynamique pour les services web à base d’agents. Dans cette approche, Chaque site serveur publie les détails permettant aux agents clients d’interagir avec lui. Cela implique la publication des spécifications de protocoles représentées sous forme d’une communication d’automates d’états finis(CAEF). Un agent client télécharge cette spécification, la valide pour sa correction et implémente le protocole dynamiquement. Cela peut être vue comme une négociation de protocoles où le client négocie pour implémenter toutes les exigences d’un serveur. Les avantages d’implémenter un protocole de conversation dynamiquement sont: 1. La spécification du protocole est séparée de son code compilé car chaque client utilise son propre code d’implémentation. 2. L’interopérabilité à la demande est assurée et par conséquent ceci offre une interaction possible avec un très grand nombre de services sur Internet. DynWES implémente un service web particulier en utilisant un agent (écrit dans un langage de programmation) et un agent différent le lendemain (écrit probablement dans un langage de programmation différent). Les agents échangent les données dans le format XML (c-à-d, automates d’états téléchargés) et communiquent avec des opérations bien définies. II-3) Conversation juste à temps En utilisant une approche de conversation dynamique, nous pouvons modéliser l’interopérabilité entre agents comme une communication entre automates. Si le processus d’un agent serveur est modélisé sous forme d’un automate d’états finis (AEF) alors cette spécification doit être disponible à l’agent client. Cette spécification décrit le service fournit et le comportement que dois avoir un client désirant utiliser ce service. Ceci signifie qu’un agent client peut interagir avec un agent serveur sans connaissance initiale du niveau de conversation du protocole. L’approche client/serveur est plus simple pour implémenter dynamiquement et juste à temps (JIT5 ) les protocoles de conversation car un client a besoin seulement d’apprendre du protocole exigé par le serveur, ou de multiples serveurs. Bien sûr, Dans un environnement ouvert (Internet), il est possible qu’une relation << many-to-many >> soit requise pour l’implémentation dynamique du protocole.
Modèle de Communication d’Automates d’Etats Finis (CAEF)
Le modèle de CAEF permet la représentation d’un protocole de communication, les entités impliquées dans cette communication ainsi que les différents canaux qui relient ces entités entre elles. Ce modèle de représentation rend l’analyse des protocoles plus facile et très complète, en plus il facilite la détection de tout type d’erreur de conception que peut contenir une spécification de protocoles. Le modèle de CAEF modélise une communication entres des entités dont le comportement est spécifié sous forme d’un Automate d’Etat Fini (AEF). Un AEF est un ensemble d’états, et un ensemble de transitions définies sur ces états. Un état représente la situation d’une entité à un instant donné de la communication. A un instant donné, une entité du protocole ne peut être en deux états différents. Une entité exécute une transition et passe d’un état vers un autre lors de l’envoi ou de la réception d’un message. Formellement, un AEF peut être représenté par un quintuple (S,S0,Sf ,A,∆) tel que : – S : ensemble des états de l’automate. – S0 : état initial de l’automate S0∈S. – Sf : ensemble des états finaux Sf⊂S. – A : alphabet de l’automate, elle représente les messages qui peuvent être utilisés dans la conversation. – ∆ : l’ensemble des transitions de l’automate. La relation de transition peut être représentée par un quadruplet (d,f,m,e) tel que : -d∈S représente l’état de départ de la transition. – f∈S l’état où se termine la transition. – m∈A représente le message envoyé ou reçu. – e représente la nature de l’événement de la transition ((-) émission et (+) réception). Un exemple d’une modélisation sous forme d’AEF est donné sur la figure2.2. Le processus modélisé est une opération de réservation de billet d’avion en ligne. L’ensemble des états de cet automate S, est composé des états IDLE, Reservation, Formulaire, Valid.Res, Confirmation, Val.Final et Ebillet. L’état initial S0 de l’automate est IDLE. L’ensemble des états finaux Sf contient le seul état Ebillet. L’alphabet A de cet automate est constitué des messages Réserver, Envoyer Form, ValiderRes, ConfirmerRes, Virement, ModifierAnnuler et Contrat.
|
Table des matières
Liste des figures
Liste des tableaux
Abréviations
Introduction générale
Chapitre I Introduction aux Services Web
I-1) Introduction
I-2) Historique des services Web
I-3) Définition des services Web
I-4) Architecture et infrastructure des services Web
I-5) Déploiement, recherche et invocation de services Web
I-6) Conclusion
Chapitre II Un Protocole de communication dynamique pour les services Web (DynWes
II-1) Introduction
II-2) DynWes, Protocole de communication dynamique pour les services Web
II-3) Conversation juste à temps
II-4) Modélisation de protocoles sous forme d’automate d’états finis
II-4-1) Modèle de Communication d’Automates d’Etat Fini (CAEF)
II-4-2) Modèle de Communication d’Automates d’Etat Fini Complexe (CAEFC
II-5) Erreurs logiques de protocole
II-5-1) Différentes erreurs logiques de protocole
II-5-2) Types d’erreurs dans une spécification par AEFC
II-6) Validation de protocole
II-7) Conclusion
Chapitre III Etat de l’art sur les techniques de validation de protocoles
III-1) Introduction
III-2) Techniques de validation de protocole
III-2-1) Techniques de validation exhaustives
III-2-1-1) Analyse d’accessibilité
III-2-1-2) Analyse structurelle
III-2-1-3) N-tree validation
III-2-2) Techniques utilisant une exploration partielle de l’arbre de protocole
III-2-2-1) Maximal Progress State Exploration
III-2-2-2) PROVAT: PROtocol Validation Testing
III-2-2-3) Analyse d’accessibilité réversible
III-2-2-4) Exploration aléatoire des états de protocole
III-2-2-5) Analyse d’accessibilité simultané
III-2-2-6) Enhancing Compositional Reachability Analysis with Context Constraints
III-2-2-7) Analyse d’accessibilité équitable (Fair Reachability analysis)
III-2-2-8) Approche de validation de protocole basée sur l’exploration des AEFC
III-3) Conclusion
Chapitre IV Proposition d’une technique de validation de Protocoles 42
IV-1) Introduction
IV-2) Notation
IV-3) Graphe de sauts
IV-3-1) Transitions simultanément exécutables
IV-3-2) Construction du graphe de saut
IV-3-3) Exemple
IV-4) Une analyse d’accessibilité basée sur des sauts réversibles (Reverse Leaping Reachability
Analysis
IV-4-1) Transitions simultanément réversiblement exécutables
IV-4-2) Traitement des erreurs d’interblocage
IV-5) Algorithme
IV-5-1) Détection des états suspects (Phase1)
IV-5-2) Confirmation des erreurs d’interblocage (Phase2)
IV-6) Complexité de l’algorithme
IV-7) Conclusion
Chapitre V Implémentation, tests et comparaison 54
V-1) Spécification XML
V-2) Exemples de tests
V-2-1) Scénario d’interblocage simple
V-2-2) Scénario d’interblocage hybride
V-2-3) Scénario d’interblocage complexe
V-3) Comparaison
V-4) Conclusion
Conclusion générale
Références
Annexes
Télécharger le rapport complet
