SAAFA-76-MRRRCH
Applications des protocoles de services web
Caractéristiques et avantages
Les services web constituent un cadre robuste pour assurer l’interopérabilité entre des applications hétérogènes, accessibles en ligne, car ils n’imposent pas de restriction sur les caractéristiques techniques de l’application qui implémente le service. Les services web ont des objectifs similaires aux autres solutions. Cependant, leurs mise en oeuvre est un peu différente et ils présentent des avantages plus intéressants. Les services web sont basés sur des standards ouverts Le fait que le Web est constitué de plates-formes totalement hétérogènes où les intérêts des différents acteurs du marché s’entremêlent ne l’a pas empêché de se développer et d’être universel, Ce succès est dû essentiellement à l’utilisation d’un ensemble de standards ouverts, dont le plus connu est le protocole HTTP. Les services web suivent la même approche que le Web en se basant sur des standards ouverts. Ceci permet de réduire le coût d’intégration des applications qui est essentiellement dû au fait que les modules interactifs ont des interfaces différentes, supportent différents protocoles de communication et différents formats de données et modèles d’interaction [5]. Les services web sont faiblement couplés Récemment, la comparaison entre les approches d’intégrations à couplage faible et à couplage fort a attiré beaucoup d’attention. D’un point de vue technologique, ceci est principalement guidé par la capacité des services web à découvrir et invoquer dynamiquement d’autres services. D’un point de vue métier, ceci est guidé par le besoin croissant de l’entreprise à augmenter la flexibilité en fonction des changements de ses processus métiers et des manières avec lesquelles elle interagit avec ses partenaires [18]. Le couplage fort est une source de plusieurs problèmes de maintenance. Dans les environnements distribués traditionnels, les composants logiciels fonctionnent de manière fortement couplée. C’est-à-dire, chaque composant est connecté avec les autres à travers une combinaison d’interfaces et de protocoles propriétaires. Ce qui rend les modifications dans le système difficiles, et coûteuses. Par contre, les services web sont faiblement couplés. Par couplage faible, on désigne minimiser le nombre de choses que le code de l’application cliente et le code de l’application fournisseur connaît l’un sur l’autre [27]. L’interface du service web fournit une couche d’abstraction entre le client et le serveur. Ainsi, un changement dans l’un ne force pas nécessairement un changement dans l’autre. Le couplage faible minimise l’impact des changements aux applications. Cette abstraction de l’interface rend aussi facile la réutilisation du service dans une autre application.
Architecture des services web
Les services web sont basés sur une architecture SOA (Service-Oriented Architecture) dans laquelle les systèmes logiciels sont distribués sous forme d’un ensemble de services faiblement couplés et dynamiquement accessibles. Un service est une fonction bien définie, autonome et indépendante du contexte ou de l’état d’un autre service [6]. L’un des aspect les plus importants de SOA est la séparation entre l’implémentation du service et son interface. En d’autres termes, elle sépare entre quoi et comment [32]. Un service expose sa fonctionnalité à travers une interface qui cache son fonctionnement interne. Une application cliente n’a pas besoin de comprendre la façon dont le service exécute son travail, elle a besoin uniquement de comprendre comment utiliser l’interface. La vraie puissance de SOA et des services web devient évidente quand plusieurs constituants sont ajoutés, enlevés, remplacés, ou améliorés sans affecter défavorablement le système entier. Ceci est difficilement possible lorsque chaque partie de l’architecture se fonde sur une connaissance approfondie du fonctionnement interne des autres parties. En conclusion, l’architecture SOA sert de base pour des applications interopérables, flexibles et fortement réutilisables. 1.4.2 Modèle de fonctionnement Une architecture orientée service fait intervenir trois acteurs [28] [31] : Chapitre 1. Les services web 8 1. Fournisseur de service (provider) : Le fournisseur correspond au propriétaire du service, sa tâche consiste à implémenter les fonctions du service web, décrire l’interface de ces fonctions en utilisant une manière standard puis publier l’interface dans un annuaire de service pour permettre aux consommateurs de découvrir les services. D’un point de vue technique, le fournisseur est constitué par la plate-forme d’accueil du service. 2. Le client ou consommateur (requester) : Le client correspond au demandeur du service. D’un point de vue technique, il est constitué par l’application qui va rechercher et invoquer le service. Le client peut être lui-même un service web. 3. L’annuaire (Service registry) : L’annuaire du service peut être considéré comme une bibliothèque de services web. Il permet de publier des nouveaux services et de découvrir des services existants. Ainsi, il permet au consommateur de trouver les informations qui lui permettent d’invoquer le service web. La dynamique de l’architecture est en général la suivante : – Le fournisseur publie le service dans un annuaire (publish). – Le client contacte l’annuaire pour chercher les services dont il a besoin (find). – L’annuaire fournit au client l’interface de ce service et la référence du fournisseur. – Le client contacte le fournisseur puis invoque le service web (bind et invoke). – Le service web effectue l’opération demandée puis renvoie le résultat au client. Chaque service web a un consommateur et un fournisseur, la présence de l’annuaire n’est pas toujours indispensable pour que l’échange ait lieu [33]. La figure (Fig. 1.1) synthétise les aspects statiques et dynamiques du modèle des services web. La communication entre les trois acteurs se fait en général par échange de messages SOAP..
|
Table des matières
Introduction générale
1 Les services web
1.1 Introduction .
1.2 Définition et objectifs des services web
1.3 Caractéristiques et avantages
1.4 Architecture des services web
1.4.1 L’architecture SOA
1.4.2 Modèle de fonctionnement
1.4.3 Pile protocolaire
1.5 Infrastructure basique des services web
1.5.1 WSDL 1.5.2 SOAP
1.5.3 UDDI
1.6 Conclusion
2 Protocoles de services web
2.1 Introduction
2.2 Applications des protocoles de services web
2.3 Modèle de protocoles
2.3.1 Présentation
2.3.2 Définition Formelle
2.3.3 Représentation XML
2.4 Propriétés d’activation et contraintes temporelles
2.4.1 Propriétés d’activation
2.4.2 Contraintes temporelles
2.5 principaux types d’analyse de protocoles
2.5.1 Compatibilité (compatibility)
2.5.1.1 Compatibilité totale (Full compatibility)
2.5.1.2 Compatibilité partielle (Partial compatibility)
2.5.2 Remplaçabilité (Replaceability)
2.5.2.1 Equivalence
2.5.2.2 Subsumption
2.6 Présentation des dépôts de protocoles
2.7 conclusion
3 Publication et recherche des descriptions WSDL
3.1 Introduction
3.2 Description WSDL
3.2.1 Interface de service
3.2.2 Implémentation de service
3.3 Publication
3.3.1 Publication des interfaces de service
3.3.2 Publication des implémentations de service
3.4 Recherche
3.4.1 Recherche des descriptions d’interface de service WSDL
3.4.2 Recherche des descriptions d’implémentation de service WSDL
3.4.3 Conclusion
4 Les bases de données XML
4.1 introduction
4.2 XML
4.3 Stockage de documents XML
4.3.1 SGBD à support relationnel
4.3.2 SGBD XML natif
4.4 Le langage XQuey
4.4.1 Présentation
4.4.2 Expression XPath
4.4.3 Les expressions FLWOR
4.5 Conclusion
5 Etude expérimentale et implémentation
5.1 Introduction
5.2 Etude de persistance
5.2.1 Critères de choix
5.2.2 Bases de données testées
5.2.2.1 MySQL
5.2.2.2 Xindice
5.2.2.3 Berkeley
5.2.3 Presentation des tests
5.2.3.1 Description des données
5.2.3.2 Description des requêtes
5.2.4 Résultats et Interprétation
5.2.4.1 Test d’ajout
5.2.4.2 Test de recherche
5.2.5 Résumé des résultats de l’étude de persistance
5.3 implémentation
5.3.1 Stockage des documents XML
5.3.2 Implémentation de la bibliothèque
5.3.3 Exposition de dépôts
5.3.3.1 Service web
5.3.3.2 Application web
5.4 Conclusion
Conclusion générale et Perspectives
A.1 Exemples de DTD
A.2 Exemple de protocoles de services
Bibliographie
Télécharger le rapport complet
