Vous avez peut-être entendu dire que les services Web peuvent, comme par magie, faire tout communiquer librement : des programmes RPG aux applications Java. Même si la réalité n’est pas aussi simple, il est vrai que les services Web peuvent mettre en relation des applications tournant sur différents systèmes d’exploitation et écrites en divers langages. Les services Web sont particulièrement appréciés pour offrir un service automatisé aux partenaires commerciaux (clients, fournisseurs ou autres).La magie de programmation qui anime les services Web est un groupe de standards interdépendants. SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) et UDDI (Univerval Discovery and Description Information). Comme tous ces standards sont fondés sur XML, il vous sera beaucoup plus facile de saisir le principe de fonctionnement des services Web si vous connaissez la syntaxe XML élémentaire.
Les détails de SOAP, WSDL et UDDI sont quelque peu mystérieux mais, heureusement, il existe de nombreux outils capables de générer des composants de services Web. Mais même si vous envisagez d’utiliser des outils pour générer tout ou partie du code des services Web, il est utile de comprendre les principes de base des standards des services Web et leur mode d’interaction.
Les services web
Les messages chargés d’invoquer un service Web ou de délivrer une réponse de service Web sont des documents XML conformes au standard SOAP. L’élément Body d’un message SOAP indique le service que vous demandez ou qui renvoie une réponse, et il inclut les valeurs de chaque paramètre. L’enveloppe est l’élément le plus externe, ou racine, d’un message SOAP.
Quand vous envoyez un message demandant un service Web, le message en question est contenu dans une enveloppe SOAP, tout comme un message envoyé par la poste est contenu dans une enveloppe papier. Mais l’analogie avec le service postal s’arrête là, car il vous appartient de déterminer comment faire parvenir le message SOAP au partenaire.
Le plus souvent, les messages SOAP sont délivrés via HTTP, souvent par exécution d’une application de type Web, par exemple. Cependant, on peut aussi envoyer des messages SOAP par courriel, par FTP, ou en les envoyant à un serveur accessible aux deux applications : celle du service Web et celle qui demande le service. Bien sûr, évitez d’envoyer des informations sensibles via un message SOAP sans vérifier sa protection (pour en savoir plus sur la sécurité des services Web, voir l’article « WSSecurity : rôle et fonctionnement » dans ce numéro).
XML-RPC peut se substituer à SOAP et par conséquent, c’est un autre standard dont vous entendrez parler s’agissant de services Web. Un RPC (Remote Procedure Call) est un moyen d’invoquer un processus sur une autre plate-forme. Plus précisément, on peut considérer XML-RPC comme une version simplifiée de SOAP qui accepte des types de données limités et est toujours envoyé comme une requête HTTPPOST. SOAP a aussi beaucoup d’autres possibilités (avec la complexité inhérente) dont XML-RPC est dépourvu. Pour plus de détails sur XML-RPC, voir xmlrpc.com.
Téléchargez cette ressource
Sécurité et gouvernance des applications d’IA
Les applications d’IA se multipliant dans les entreprises, ces dernières se doivent d’établir un cadre de gouvernance qui tient compte des risques de sécurité et des défis associés. Ce livre blanc vous offre les connaissances et les outils nécessaires à une gouvernance garante de la sécurité de vos applications d’IA.
Les articles les plus consultés
- Et si les clients n’avaient plus le choix ?
- Cybersécurité Active Directory et les attaques de nouvelle génération
- Activer la mise en veille prolongée dans Windows 10
- Afficher les icônes cachées dans la barre de notification
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
