Applications des protocoles de services web

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..

Le rapport de stage ou le pfe est un document dโ€™analyse, de synthรจse et dโ€™รฉvaluation de votre apprentissage, cโ€™est pour cela chatpfe.com propose le tรฉlรฉchargement des modรจles complet de projet de fin dโ€™รฉtude, rapport de stage, mรฉmoire, pfe, thรจse, pour connaรฎtre la mรฉthodologie ร  avoir et savoir comment construire les parties dโ€™un projet de fin dโ€™รฉtude.

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

Rapport PFE, mรฉmoire et thรจse PDFTรฉlรฉcharger le rapport complet

Tรฉlรฉcharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiรฉe. Les champs obligatoires sont indiquรฉs avec *