Journal XML-RPC ou SOAP ?

Posté par  .
Étiquettes : aucune
0
10
mar.
2004
bonjour madame,

tout d'abord, le petit avertissement d'usage: pas de troll merci

bon, j'ai un petit projet qui me tient à coeur, un genre de serveur de données sur lequel on stocke différents types de données (bookmarks, contacts, que sais-je) qu'on peut retrouver en ligne par la suite. ça permet entre autre d'avoir toujours ces données sous la main quelque soit l'endroit d'où on se connecte.
A la base j'étais parti sur un CMS en PHP, et puis j'ai découvert XUL, et je me suis dit "fear" et je me suis mis en tête de faire mon truc en XUL. Après quelques lectures, je me suis dit que du XUL tout seul ce serait un peu chaud, et j'en suis maintenant à réflechir à un modèle client/serveur avec un serveur qui gère les données, et des clients qui communiquent avec le serveur (rien de bien transcendant). Cette approche est beaucoup plus souple car

- elle me détache d'un langage particulier
- cela permet de coder foultitude de clients pour tous les gouts
- c'est plus interressant a coder

bref, maintenant je me pose quelques questions:

- quel langage pour le serveur ?
j'étais resté bêtement sur PHP, parceque c'est le langage que je connais le mieux, mais finalement est-ce vraiment nécessaire ? n'y-a-t-il pas des langages plus adaptés ?

- quel backend pour les données ?
là je penche plutot pour un truc genre mysql. mais c'est surtout parceque je ne connais bien que ce SGBD.

- quel protocole pour la communication client/serveur ?
j'ai tout de suite pensé a xml-rpc parceque j'en ai pas mal entendu parler ces derniers temps, mais est-ce vraiment le bon choix ?

- comment gérer l'aspect multiuser du serveur ?
le serveur doit gérer les données pour plusieurs serveurs, hors d'après ce que j'ai compris, xml-rpc n'est pas censé gérer les cookies. envoyer un session id a chaque requete en argument est-il une solution envisageable ?

merci d'avance pour les suggestions/réponses/insultes

ps: question bonus: ça existerait pas déjà quelque part desfois ?
  • # Re: XML-RPC ou SOAP ?

    Posté par  . Évalué à 1.

    si c'est des bookmarks et des contacts à stocker, ldap me parait très adapté

    pour les contacts les schémas existent déjà et sont standards (objet inetOrgPerson), ça te permet de configurer ton client mail pour qu'il aille chercher ses contacts dans l'annuaire automatiquement.

    pour les bookmarks tu peux créer tes propres objets, quoique le nécessaire existe peut être déjà. Ensuite il faudra coder un client qui récupèrera les données. Tous les langages répandus possèdent une API LDAP (C, C++, Java, python, ruby, etc etc)
    • [^] # Re: XML-RPC ou SOAP ?

      Posté par  . Évalué à 1.

      le truc c'est que le serveur doit être modulaire. on doit pouvoir ajouter des types d'informations simplement. par exemple on peut imaginer un module qui permettrait de stocker des fichiers, des textes, etc

      c'est possible aussi avec LDAP ça ?
      • [^] # Re: XML-RPC ou SOAP ?

        Posté par  . Évalué à 1.

        hum... LDAP c'est pas trop fait pour stocker des fichiers
        en revanche tu peux stocker dans LDAP des références vers ses fichiers (nom du fichier, joli nom à afficher, description, type, date de création/modification...), et stocker les fichiers dans un répertoire du serveur.

        Pour les transferts de fichiers un logiciel coté serveur est nécessaire.
        Tu peux peutêtre utiliser une interface web

        un module serveur devrait rajouter dans la config du serveur ldap un fichier de définition de schéma apportant à l'annuaire les objets nécessaires pour stocker les nouvelles infos, ainsi que le composant logiciel éventuel.
        Avec OpenLDAP un reboot du service est nécessaire pour une mise à jour du schéma.
  • # Re: XML-RPC ou SOAP ?

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Tu connais PHP, Mysql, et tu t'interresse à xul et donc à mozilla. Choisi donc SOAP. Mozilla intégre de base un objet javascript pour faire du soap.

    Coté php, il existe des api pour faire du soap, tant pour client que serveur
    ( nusoap : http://dietrich.ganx4.com/nusoap/index.php(...) )

    Et voilà.
    • [^] # Re: XML-RPC ou SOAP ?

      Posté par  . Évalué à 1.

      J'aimerais bien avoir des retours d'expérience avec nusoap.

      Je l'avais testé il y a deux mois, en comparant avec PEAR::SOAP, et franchement, je trouvais qu'il n'y avait pas photo : nusoap n'est plus mis à jour depuis plus d'un an, n'est pas franchement stable et lent, alors que la librairie de PEAR est nettement plus à jour, et surtout, plus simple à utiliser.

      Quelqu'un pour [in|con]firmer ?

      Quant à différencier XML-RPC et SOAP : si SOAP permet de communiquer plus simplement des types plus complexes (quoique, en encapsulant des données en utilisant WDDX dans une chaine via XML-RPC), c'est nettement plus lent que XML-RPC (question d'implémentation, je sais, mais avec celles testées, c'était ce qui ressortait).
      • [^] # Re: XML-RPC ou SOAP ?

        Posté par  . Évalué à 1.

        D'ailleurs y a aussi moyen de faire du xml-rpc avec mozilla.
  • # Re: XML-RPC ou SOAP ?

    Posté par  . Évalué à 1.

    ca m'interresse aussi !

    a mon avis un melange de soap pour les infos, webdev pour le partage de fichier ca peut le faire.

    les moteurs soap, implementent de base un mecanisme de sessions, mais en général c'est une surcouche http...ce qui est d'un point de vue puriste plutot moche...mais ca marche. (on pout au pire le gerer nous meme via une entete soap (c'est pas normalisé je crois d'ou probleme de compatibilté), ou meme dans le corps du message)

    le backend, une base de données quelconque, faudrait pas faire de spécifique.

    le langage server...php a l'avantage d'etre facile a heberger, java ca serait pas mal aussi (axis pour le soap, les jsp2.0 c'est du bonheur pour le web, hibernate pour l'acces aux données parce que le sql c'est chiant ... a voir)

    le front...de tout ! un frontal web php, une interface xul, une interface webstart java ... c'est le truc interressant d'avoir un protocole bien neutre : on peut faire des clients differents \o/

    un genre de http://www.universalvillage.net/UVCOnline/Features.shtm(...)
    en libre, et multi client ca serait une bonne idée.
    (faut bien sur integrer un logiciel de moulage sur tribune !)
    • [^] # Re: XML-RPC ou SOAP ?

      Posté par  . Évalué à 1.

      si ça t'interresse et que tu veux te joindre au projet, n'hésites pas :)
      je vais aller me renseigner un peu sur soap, tu aurais quelques urls qui trainent par hasard ?
  • # Re: XML-RPC ou SOAP ?

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Je suis en train de faire quelque chose d'un peu similaire.
    Pour la langage j'ai chosis python après avoir fait du php et je ne regrette absolument pas ce choix bien que ce ne soit pas un lnagage très usité part des hébergeurs gratuits.
    Le backend pour les données ne doit pas être un problème ton CMS doit etre conçu de telle sorte qu'il soit indépendant d'un support de données (important).
    D'un certain coté j'ai pensé qu'il fallait mieux définir des specs réutilisables par un autre CMS écrit lui en php et adapté aux hébergeurs gratuit plateforme LAMP (linux+apache+mysql+php).
    XML-RPC est le plus simple à mettre en place et le plus utilisé.
    Bon là tu poses une question très spécifique qui ne devrais venir que plus tard dans ton devel.
    Les choses importantes dans un CMS sont:
    - sa gestion des modules et leur capacité à communiquer entre eux
    - la séparation entre contenu, forme et services
    - l'utilisation de web services pour ne pas être lié à une interface web
    - la conformité aux standarts
    - la facilité de maintenance, d'extensibilité et d'installation
    - un langage d'écriture d'articles uniformisé (déjà documenté) ou l'indépendance par rapport au format des documents
    - une interface de publication ergonomique
    - une gestion robuste du cache de l'autentification
    - la richesse des fonctionnalitées
    Il existe déjà des tonnes de CMS mais aucun ne me satisfait réllement.
    Pour écrire un CMS tu peux utiliser des serveurs d'applications ou des librairies; en python: Zope, twisted et d'autres; en php PEAR.
    vala il est tard dodo.
    • [^] # Re: XML-RPC ou SOAP ?

      Posté par  . Évalué à 1.

      > Pour la langage j'ai chosis python après avoir fait du php et je ne regrette absolument pas ce choix

      tu peux expliciter un peu plus ?

      > XML-RPC est le plus simple à mettre en place et le plus utilisé.

      il me semble aussi, mais le problème reste celui des sessions :\

      > une gestion robuste du cache de l'autentification

      du cache de l'authentification ? c'est-à-dire ?
      • [^] # Re: XML-RPC ou SOAP ?

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        oula tu veux dire pourquoi python est mieux ?
        Il y a tellement de raison que ça ferait un bon bouquin,
        la plupart se découvrent en pratiquant python ou alros à lire un peu de doc.
        Mais en gros: programmation plus claire, plus "structurée", vraiment agréable.
        je vois pas pourquoi tu veux faire passer des sessions par xml-rpc !
        Regarde un peu les apis déjà existantes comme celle de blogger qui est très simple (voire simpliste).
        le cache ça veut dire par regénérer à chaque fois des données qui n'ont pas changée. Et l'authentification c'est la manière dont tu vas gérer la façon dont les modules (ou applications ou plug ins ou ce que tu veux) vont discuter entre elle et savoir qui est l'user, et récupérer/écrire des infos sur lui.
  • # Re: XML-RPC ou SOAP ?

    Posté par  . Évalué à 1.

    Salut,

    Je suis sur un projet ou je dois choisir entre XML-RPC et SOAP
    j'ai aussi entendu parler de REST
    mais je n'arrive pas a voir les différences de possibilités entre ces 3 choix si ce n'est que SOAP apparait comme le plus complexe/abouti par rapport aux 2 autres.

    Je dois consolider des données de plusieurs serveurs sur un seul serveur.
    L'aspect sécurité est trés important !

    Avez vous des conseils ?

    merci !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.