Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Si vous vous posez une question, vous n'êtes peut-être pas le premier...Les traductions en français des bibles XML.Ces articles sont des références dans leur domaine.Tout ce qu'il faut savoir pour démarrer sur un sujet XML...


Services Web: SOAP ou REST?

Le mécanisme mis en place pour gérer les sondages de XMLfr est un exemple concret de Service Web simple pour lequel une architecture REST peut s'avérer plus facile à mettre en place qu'un Service Web classique basé sur SOAP ou XML-RPC.

Eric van der Vlist, Dyomedea (vdv@dyomedea.com).
vendredi 15 novembre 2002

Le site XMLfr étant hébergé sur deux serveurs distants avec partage des connections utilisant la fonction DNS connue sous le nom de "round Robin", la gestion des sondages posait le problème de la consolidation des réponses recueillies par les deux serveurs.

Compte tenu d'un taux de disponibilité des deux machines honorable et du caractère non stratégique de ces sondages, j'ai décidé d'implémenter cette fonctionnalité sur une base de données PostgreSQL unique située sur une des machines mise à jour par les deux serveurs et d'utiliser un document XML remis à jour périodiquement et jouant le rôle de cache pour l'affichage du sondage en page d'accueil.

Après avoir rapidement éliminé la possibilité d'utiliser le middleware PostgreSQL entre serveurs sur Internet (pour des raisons de sécurité évidentes, je ne souhaitais pas ouvrir mes firewalls au trafic PostgreSQL et n'ai pas non plus envie de gérer le VPN (Virtual Private Network) permettant une communication sécurisée entre les deux machines), le choix d'une architecture de Services Web s'imposait de lui-même et ma première idée a été d'utiliser SOAP ou XML-RPC.

Après analyse, la mise en place d'un tel Service Web qui reste pourtant très simple s'est avérée plus coûteuse qu'on ne pourrait l'imaginer. XMLfr est en effet un site où la présentation est réalisée dynamiquement par une transformation XSLT réalisée dans un servlet par le processeur XT. L'appel d'un Service Web SOAP ou XML-RPC aurait donc demandé l'écriture d'une extension XSLT en Java utilisant une API cliente SOAP ou XML-RPC et renvoyant les résultats sous forme d'évènements SAX. L'écriture d'un deuxième client utilisable en mode batch pour mettre à jour le document XML jouant le rôle de cache aurait également été nécessaire ainsi bien entendu que la mise en place du Service Web lui même et des fonctions permettant de l'administrer et de logger les appels.

Il n'y a bien entendu là rien d'impossible ni même de très difficile à mettre en place, mais la charge de travail aurait dépassé le temps que je souhaitais consacrer à cette opération.

J'ai donc choisi d'utiliser l'architecture "REST" pour implémenter de Service Web de la manière suivante:

  • Ecriture d'un script CGI très simple gérant les insertions dans la table des réponses aux sondages et présentant les résultats sous forme d'un document XML. Ce script écrit en Python n'est long que de 68 lignes, commentaires compris, et implémente les contrôles d'intégrité nécessaires pour garantir la qualité des informations insérées dans la base de données.
  • Installation de ce script sur le serveur HTTPS déjà installé sur le serveur hébergeant la base de données et configuration du mécanisme d'authentification.
  • Utilisation directe de l'URL de ce script CGI avec ses paramêtres d'appel dans la transformation XSLT au moyen de la fonction standard "document()" de XSLT 1.0.
  • Utilisation de "wget" pour mettre à jour le document XML servant de cache.
  • Utilisation des fonctions standards du serveur HTTPS qui journalise les appels et pourrait au besoin faire des contrôles supplémentaires, servir de proxy et rediriger les requêtes ou utiliser la fonction de "rewriting" pour les réécrire.

Au bilan, une application qui n'est pas plus complexe à écrire au niveau du serveur, pour laquelle le développement d'applications clientes spécifiques a été évité et qui s'administre avec les outils d'administration déjà en place.

Sans prétendre que ce soit toujours le cas, nous avons là un exemple d'application simple pour laquelle l'utilisation inconsidérée de l'architecture dominante (du moins dans les médias) s'avère beaucoup plus complexe que l'utilisation des technologies existantes et déjà déployées sur nos serveur Web sans l'on ne semble en retirer à court terme aucun avantage concret.

Autres articles:

Copyright 2002, Eric van der Vlist.


 

Mots clés.



L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.


Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org