Soap

188 vues

Publié le

principes des services web SOAP

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
188
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
6
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Soap

  1. 1. Web Services« Services Web en français » Représentent un mécanisme de communication entre applications distantes à travers le réseau internet indépendant de tout langage de programmation et de toute plate- forme d'exécution : A. utilisant le protocole HTTP comme moyen de transport. Ainsi, les communications s'effectuent sur un support universel, maîtrisé et généralement non filtré par les pare-feux ; B. employant une syntaxe basée sur la notation XML « WSDL et SOAP ou XML- RPC » pour décrire les appels de fonctions distantes et les données échangées ; C. organisant les mécanismes d'appel et de réponse. Grâce aux services web, les applications peuvent être vues comme un ensemble de services métiers,structurés et correctement décrits, dialoguant selon un standard international plutôt qu'un ensemble d'objets et de méthodes entremêlés. Couches du Web Services Le fonctionnement des services web repose sur un modèle en couches, dont les trois couches fondamentales sont les suivantes : Invocation : visant à décrire la structure des messages échangés par les applications, « SOAP ou XML-RPC » Découverte : pour permettre de rechercher et de localiser un service web particulier dans un annuaire de services décrivant 1- le nom de la société, 2- l'objectif de chaque service, etc. Le protocole standard le plus utilisé pour la découverte de services est UDDI. Description : dont l'objectif est la description des interfaces (paramètres des fonctions, types de données) des services web. Le protocole standard le plus utilisé pour la description de services est WSDL. Le standard pour les WebServices et WSDL + SOAP + UDDI Quel que soit le standard utilisé, le principe de programmation est le même : ***** l'appel de méthode distante est réalisé grâce à une bibliothèque cliente qui transmet la demande au fournisseur de service en la formattant en XML de manière transparente; ***** au niveau du serveur une bibliothèque serveur décode la requête, le serveur fait ses traitement, puis répond grâce à cette même bibliothèque; ***** la bibliothèque client décode enfin la réponse afin qu'elle puisse être utilisée par l'application client.
  2. 2. SOAP SOAP (Simple Object Access Protocol) est un protocole définit à l'origine par Microsoft, puis standardisé par le W3C, utilisant la notation XML permettant de définir les mécanismes d'échanges d'information entre des clients et des fournisseurs de services web. Le mécanisme de transport des messages SOAP peut être le protocole HTTP,SMTP, FTP, etc. Il existe des bibliothèques SOAP pour de très nombreux langages, dont Perl, C, C++, C#,Python, Java, Visual Basic/.NET, PHP, Ruby, etc. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur Le protocole SOAP est composé de deux parties :  une enveloppe, contenant des informations sur le message lui-même afin de permettre son acheminement et son traitement,  un modèle de données, définissant le format du message, c'est-à-dire les informations à transmettre.
  3. 3. SOAP Building Blocks A SOAP message is an ordinary XML document containing the following elements:  An Envelope element that identifies the XML document as a SOAP message  A Header element that contains header information  A Body element that contains call and response information  A Fault element containing errors and status information All the elements above are declared in the default namespace for the SOAP envelope: Syntax Rules Here are some important syntax rules:  A SOAP message MUST be encoded using XML  A SOAP message MUST use the SOAP Envelope namespace  A SOAP message MUST use the SOAP Encoding namespace  A SOAP message must NOT contain a DTD reference  A SOAP message must NOT contain XML Processing Instructions <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... </soap:Header> <soap:Body> ... <soap:Fault> ... </soap:Fault> </soap:Body> </soap:Envelope> Consumers of a Web Service do not need to know anything about the platform, object model, or programming language used to implement the service; they only need to understand how to send and receive SOAP messages (HTTP and XML)
  4. 4. Fonctionement des WebServices Côté Client :d'abord. Comme nous l'avons vu, tous nos dialogues avec le serveur exécutant le service web sont faits via SOAP. Rappelez-vous, SOAP ne spécifie pas le transport mais HTTP est commun. Cet exemple présume l'utilisation d'HTTP (mais vous pourriez tout aussi bien utiliser SMP). En tant que tels, nos messages au serveur seront des requêtes SOAP-XML enveloppées dans des requêtes HTTP. De même, les réponses du serveur seront des réponses HTTP qui renferment des réponses SOAP- XML. Maintenant, nous, développeurs côté client, nous ne voulons pas nous occuper de tous les détails de sérialisation SOAP et de l'encodage de HTTP. Nous employons alors un package SOAP qui le fera pour nous. Il s'agit typiquement d'une librairie que nous linkons dans notre propre code client. Nous invoquons ensuite le service, simplement en invoquant la méthode appropriée du package SOAP (typiquement en spécifiant l'URL du service, le nom du service et tous les paramètres requis). Le premier travail d'un package est de sérialiser l' invocation de ce service en requête SOAP. Il doit ensuite encoder ce message dans une requête HTTP et l'envoyer à l'URL spécifiée. Ce que fait le serveur avec cette requête est détaillée plus bas dans cette page. Mais pour le moment, tenons pour acquis le renvoi par le serveur d'un message encodé HTTP contenant la réponse SOAP. Nous nous reposons sur le même package SOAP pour exécuter l'inverse de ce qui fut fait au stade de la requête, c'est-à-dire que le package décode le message HTTP et extrait le message SOAP, ensuite désérialise le message SOAP et obtient la valeur de retour de l'appel de la méthode. Cette valeur de retour trouvée est ensuite passée comme valeur de retour à l'invocation originale de la méthode par le code client. Que se passe t-il dans ce diagramme: le code client crée un appel de service en invoquant la méthode appropriée du package SOAP (1). Le serialiseur SOAP du package SOAP convertit cette invocation en requête SOAP et l'envoie à l'encodeur HTTP (2). L'encodeur HTTP enveloppe le message SOAP dans une requête HTTP et l'envoie au serveur SOAP (3). La réponse est reçue par le module d'encodage/décodage HTTP du serveur SOAP(4); ce module décode et extrait la réponse SOAP qui la remet au deserialiseur SOAP (5). Le eserialiseur SOAP deserialise le message et passe le résultat au code client (6) comme valeur de retour de l'invocation originale (1).
  5. 5. Côté Serveur : C'est légèrement plus complexe car nous avons besoin d'un process "listener" (Le Listener est le process serveur qui est en attente de connexion client). Nous avons également besoin d'une implémentation du service lui-même. A part cela, nous nous reposons sur un package SOAP de la même façon que du côté client. Le listener est souvent implémenté au travers d'un servlet qui s'exécute comme une application web sur un appserver (serveur d'application web) (comme c'est le cas lorsque nous utilisons Apache SOAP du côté serveur). L'appserver sera configuré pour passer toutes les requêtes destinées à une certaine URL (l'URL du service SOAP) à un servlet particulier (appelons-le servlet SOAP). Le travail du servlet SOAP est d'extraire le message XML-SOAP de la requête HTTP, de le désérialiser (de ce fait, séparer le nom de la méthode et les paramètres fournis), et d'invoquer la méthode du service en conséquence. Le résultat de la méthode est alors sérialisé, encodé HTTP et renvoyé au demandeur. Que se passe t-il dans ce diagramme: l'appserver (le serveur d'application web) reçoit une requête HTTP du Client SOAP destinée à l'URL de service SOAP(1) et, en conséquence de quoi, le passe au servlet SOAP (2). Le servlet SOAP utilise les fonctionnalités de décodage SOAP et HTTP incluses dans le package pour extraire les détails de l'appel des services (3 et 4), c'est-à- dire le nom et les paramètres de la méthode. Une fois muni de ceux-ci, le servlet SOAP peut invoquer la méthode (5 et 6), encoder la réponse (7 et 8) et fournir la réponse HTTP au handler de requêtes HTTP (9), qui à son tour, répond au client SOAP (10). Notez que la boite Servlet Thread indique simplement ce qui s'exécute dans la machine virtuelle du servlet.
  6. 6. Avantages  UtiliserSOAPviaHTTPfacilite lacommunicationetévitelesproblèmesde proxyset pare-feu par rapport à destechnologiesplusanciennes  SOAPest o assezouvertpours'adapterà différentsprotocolesde transport. o indépendantde laplate-forme. o indépendantdulangage. o extensible. Inconvénients  En raisondu nombre d'informationsqu'impose le formatXML,SOAPpeutalourdir considérablementleséchangesparrapportà des middlewares comme CORBA ouICE,ce qui n'estpas forcémentunhandicapquandlesvolumesde donnéestransitésparSOAPsont faiblesparrapportau volume total de donnéeséchangées.  SOAPdécritla manière dontlesapplicationsdoiventcommuniquerentre elles,certains considèrentque le couplagereste fortentre le serveuretsesclients.Une modificationde l'API impliqueainsi une évolutioncôté client,contrairementàune architecture orientée ressourcestelle que REST.

×