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
Rapport Forrester sur la sécurité des workloads cloud (CWS)
Dans son rapport, Forrester Consulting passe au crible et note les produits des 13 principaux fournisseurs de solutions de sécurité des workloads cloud (CWS). Bénéficiez d’un état des lieux complet du marché, explorez tous les enjeux associés à la convergence des fonctions de sécurité cloud et les avantages des solutions complètes.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Quel impact d’une cyberguerre sur les organisations ?
- Menaces cyber sur le secteur énergétique européen !
- Les stratégies IA pour la survie de l’entreprise !
- Protégez l’accès non authentifié de vos réunions
- Télécommunications et durabilité : les défis d’une transition verte dans un secteur en mutation
