Discussion :

[randriano]

Bonjour,

Bien que n'étant pas considéré comme une référence en matière de web services par rapport à REST et SOAP, j'ai choisi de l'utiliser car il a été facile de l'implémenter au niveau de mon serveur PHP.

Le cas est donc que le serveur n'est pas de la technologie .NET mais PHP mais c'est le client qui est .NET, la plupart des CMS ou frameworks PHP offrent des librairies préfabriquées pour implémenter XML-RPC!
De plus, j'ai trouvé un lien intéressant pour l'implémenter en C# et vb.net: http://www.xml-rpc.net

Dommage, .NET regorge de fonctionnalités pour faire du web services SOAP (et REST) surtout sous Visual Studio, la technologie du serveur est mon facteur de blocage.

[Nathanael Marchand]

Euh? Y'a une question la dedans?

[randriano]

Bonne question!

En principe, je ne fais que narrer mais je me pose aussi la question de viabilité et "standardibilité" (mot qui n'existe pas) de mon système, est-ce que vous me conseillerez de migrer vers Soap plus tard?

[danuz]

Ton intervention n'est pas très claire... Tu parles de PHP, .NET. Tu veux savoir quoi utiliser pour une technologie précise ? Comment mettre en place l'infrastructure ?

En fait, pour pouvoir répondre à ce genre de question (après ce que j'ai compris de ton oratoire...), il y a plusieurs questions à se poser au préalable.

Question Infrastructure ?
C'est à dire, qu'est-ce que j'ai comme serveur (serveur PHP, IIS), quel langage, quelle base de données. Est-ce que mon infrastructure va changer, si oui, les langages. Pour quels clients ?

Tu vas privilégier l'utilisation d'une technologie / création de services en fonction de ce que tu as, en fonction des clients qui consommeront tes services aussi.


A propos du protocole XmlRpc, il a la chance d'être implémenté proposé dans plusieurs CMS en PHP, c'est vrai (WordPress, PHPBB, etc...).

Pour d'autres CMS, des APIs sont implémentées (te retournant du json, du xml au choix). Ce qui facilite leur utilisation.

Pour ma part, j'aime beaucoup quand des apis existent et renvoie par exemple du json (flux léger) ou du Xml. C'est plus simple pour récupérer les réponses et les transformer en des objets utilisables dans nos applications.

XmlRpc recommande l'utilisation d'un proxy pour pouvoir effectuer des appels et récupérer les réponses.


Le choix de la technologie, et des services à créer dépend de tes besoins, du temps, des ressources.

Pose toi les bonnes questions quoiqu'il en soit !

Bon courage .

[randriano]

Merci danuz pour cette analyse.

Le cas est donc que l'on a déjà commencé à développer un serveur XML RPC (en PHP). Les clients sont des applications Windows sous .NET!

J'ai créé ce fil car je me suis posé la question fondamentale: devrait-on utiliser un protocole applicatif existant (XML-RPC) ou développer un protocole adapté à nos besoins c'est à dire notre propre format XML? Vu qu'il y a déjà ce http://www.xml-rpc.net/ on a opté pour cet ancêtre du SOAP qu'est xml-rpc!

[danuz]

Merci danuz pour cette analyse.

Le cas est donc que l'on a déjà commencé à développer un serveur XML RPC (en PHP). Les clients sont des applications Windows sous .NET!

J'ai créé ce fil car je me suis posé la question fondamentale: devrait-on utiliser un protocole applicatif existant (XML-RPC) ou développer un protocole adapté à nos besoins c'est à dire notre propre format XML? Vu qu'il y a déjà ce http://www.xml-rpc.net/ on a opté pour cet ancêtre du SOAP qu'est xml-rpc!

Etant donné que XMLRPC a de très bonnes spécifications, que vous avez déjà commencé à bosser dessus (implémentation du serveur), c'est le meilleur choix que d'implémenter votre propre format.
En plus, XmlRpc.NET vous facilitera la vie pour vos clients.

Tu attends d'autres réponses ou ça te va ? (^___^) ?