Utiliser XML-RPC comme web services

**randriano** · 13/07/2011, 15h23

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** · 13/07/2011, 16h36

Euh? Y'a une question la dedans?

**randriano** · 14/07/2011, 08h03

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** · 19/07/2011, 10h11

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** · 20/07/2011, 08h22

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** · 20/07/2011, 08h33

Envoyé par 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!

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 ? (^___^) ?

**randriano** · 20/07/2011, 11h04

Euh, ça me va! Effectivement, les autres technologies à savoir SOAP et REST ne sont pas normalisées, ne disposant pas encore d'un site comme http://www.xmlrpc.com
Le petit soucis c'est que souvent on dit toujours que XML-RPC est l'ancêtre de SOAP comme si c'était démodé.

**Nathanael Marchand** · 20/07/2011, 11h17

Envoyé par randriano

Euh, ça me va! Effectivement, les autres technologies à savoir SOAP et REST ne sont pas normalisées, ne disposant pas encore d'un site comme http://www.xmlrpc.com
Le petit soucis c'est que souvent on dit toujours que XML-RPC est l'ancêtre de SOAP comme si c'était démodé.

Plait-il? SOAP est spécifié:
http://www.w3.org/standards/techs/soap#w3c_all

Par contre, REST n'est pas une technologie, c'est un concept architectural.

**randriano** · 20/07/2011, 15h38

Oui c'est vrai, W3C a préféré SOAP parmi les protocoles existants. REST n'étant qu'une architecture

Enfin, j'ai également lu le blog de So@t blog.soat.fr, voilà un autre lien intéressant que je n'ai pas trouvé par recherche, effectivement il faut mieux aller voir côté xml-rpc.net pour faciliter les choses

**danuz** · 20/07/2011, 15h39

Envoyé par randriano

Oui c'est vrai, W3C a préféré SOAP parmi les protocoles existants. REST n'étant qu'une architecture

Enfin, j'ai également lu le blog de So@t http://blog.soat.fr/2011/07/wp7-utiliser-une-api-xmlrpc-part1/, voilà un autre lien intéressant que je n'ai pas trouvé par recherche, effectivement il faut mieux aller voir côté xml-rpc.net pour faciliter les choses

Haha, c'est mon article :-). La 2ième partie arrive avec XmlRpc.NET justement. je la publie lundi ou mardi. Reste à l'écoute :-).

**randriano** · 28/07/2011, 13h35

Je relance encore le sujet car je ne veux pas créer un nouveau sujet pour la question suivante.

Comment sécuriser l'utilisation du XML-RPC? En fait, je veux que seules les applications dotnet de notre réseau aient le droit d'accéder aux procédures distantes. Or XML-RPC a le risque que si quelqu'un connait les URL des procédures, il peut les utiliser à sa guise.

Est-ce XML-RPC.NET supporte une connexion SSL c'est à dire l'adresse du serveur commence par https:// ?

Merci d'avance

**danuz** · 28/07/2011, 13h40

Xml-Rpc.net supporte les Headers. (^__^)

Cela veut dire que tu peux par exemple utiliser une authentification HTTP basique pour pouvoir sécuriser ton serveur. A voir !

Concernant les URL en https, ouii !

**randriano** · 28/07/2011, 16h26

C'est souvent la solution qui est proposée sur le net: l'authentification http basique! Le soucis c'est qu'il faut donc configurer une partie site web et une partie qui n'est accessible que par user:password@www.monsite.com

Puisque le SSL est supporté c'est déjà bien

danuz>J'ai un petit soucis si tu peux m'aider:
J'ai créé un nouveau projet avec xml-rpc.net et j'ai bien ajouté le dll assembly mais l'erreur suivante persiste:

The type or namespace name 'IXmlRpcProxy' could not be found (are you missing a using directive or an assembly reference

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
using System;
using CookComputing.XmlRpc;
 
[XmlRpcUrl("http://127.0.0.1/monsite/xmlrpc_server")]
public interface IMyApi : IXmlRpcProxy
{
    [XmlRpcMethod("IsUserValid")]
    int IsUserValid(string request);
}

**danuz** · 28/07/2011, 16h47

Alors, déjà, tu ne peux pas pour la version mobile utiliser IXmlRpcProxy. Tu dois faire ton proxy hériter de XmlRpcClientProtocol (obligé pour la version Windows Phone et Silverlight aussi je crois).

Ensuite, ne mets pas les attributs XmlRpc sur ton interface. ça ne sert à rien et ça ne fonctionnera pas. Il faudra les mettre que sur ton proxy.

Et parce que des exemples visuels parlent mieux (en attendant que je finisse de rédiger mon article), voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
public interface IPostServiceProxy
    {
        IAsyncResult BeginGetThread(string topic_id, int start_num, int last_num, AsyncCallback callback);
 
        IAsyncResult BeginGetThread(string topic_id, int start_num, int last_num, bool return_html, AsyncCallback callback);
 
        XmlRpcStruct EndGetThread(IAsyncResult iasr);
    }
 
 
    [XmlRpcUrl("http://www.monurl.com")]
    public class PostServiceProxy : XmlRpcClientProtocol, IPostServiceProxy
    {
        [XmlRpcBegin("get_thread")]
        public IAsyncResult BeginGetThread(string topic_id, int start_num, int last_num, AsyncCallback callback)
        {
            object[] parameters = new object[] { topic_id, start_num, last_num };
            return this.BeginInvoke(MethodBase.GetCurrentMethod(), parameters, callback, null);
        }
 
        [XmlRpcBegin("get_thread")]
        public IAsyncResult BeginGetThread(string topic_id, int start_num, int last_num, bool return_html, AsyncCallback callback)
        {
            object[] parameters = new object[] { topic_id, start_num, last_num, return_html };
            return this.BeginInvoke(MethodBase.GetCurrentMethod(), parameters, callback, null);
        }
 
        [XmlRpcEnd]
        public XmlRpcStruct EndGetThread(IAsyncResult iasr)
        {
            var result = (XmlRpcStruct)this.EndInvoke(iasr);
            return result;
        }
    }

ça te montrera quelle approche avoir.

Concernant la méthode qui permet de finaliser l'appel de ta méthode asynchrone, le type de retour dépend de ce que te renvoie ta méthode XmlRpc. Dans mon cas ici, c'est un objet de type struct (Rpc). C'est pour ça que j'ai un XmlRpcStruct.

ça devrait t'aider davantage.

Bon courage!

**randriano** · 28/07/2011, 17h18

Merci danuz pour ces réponses

Je ne développe pas sur mobile mais sur un PC, le soucis c'est vraiment que l'assembly reference semble être mal ajouté alors c'est bien présent dans la liste des références du projet.

J'ai pas bien compris c'est qu'il faut procéder d'une autre manière pour accéder à un serveur local?

**danuz** · 28/07/2011, 17h27

C'est ma faute, je réponds à plusieurs threads dans des forums différents (^__^).

Sinon, si tu ne trouves pas cette interface, c'est que tu as la mauvaise version de la librairie. Tu dois absolument avoir la version 3.0.0.241

Sinon, le code va un peu changer. Tu n'auras pas besoin de client proxy.

Concernant ton interface, c'est comme tu avais déjà si bien commencé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
[XmlRpcUrl("http://tonurllocale")]
    public interface IPostService : IXmlRpcProxy
    {
        [XmlRpcBegin("get_thread")]
        IAsyncResult BeginGetPosts(string id, int start, int last);
 
        [XmlRpcBegin("get_thread")]
        IAsyncResult BeginGetPosts(string id, int start, int last, bool shouldReturnHtml);
 
        [XmlRpcEnd]
        XmlRpcStruct EndGetPosts(IAsyncResult iasr);
    }

et pour son utilisation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
    var proxy = XmlRpcProxyGen.Create<IPostService>();
    var asyncResult = proxy.BeginGetPosts("4671", 0, 30);
    var result = proxy.EndGetPosts(asyncResult);

Utiliser XML-RPC comme web services

Services Web

Discussions similaires

Partager

Partager