Je dois creer un web service, seuleument je suis un peu perdu et je trouve pas toujours les informations dont j’ai besoin.
Je me permet de poster mes quelques questions ici, en esperant avoir des reponses:
mon webservice est ecrit en c# .net, est-ce que si il est correctement fait, il peut etre interoge par des clients qui utilise n’importe quel language ?
pour cela il faut que je recoive les donnees sous forme de fichier SOAP c’est bien ca ?
je voudrais pouvoir identifier les personnes qui utilisent mon webservice pour compter leurs appels: comment je fais ? mon idee est de rajouter dans mon fichier SOAP un attribut avec une sorte de login specifique a chaque “client”, comme ca je peux voir qui fait quoi, mais il y a peut etre une methode plus integre ?
ou puis je trouver une documentation complete et des exemples de comment faire ces fameux fichiers SOAP ? vous avez des bonnes adresses ?
Oui, un webservice .net peut être appellé depuis n’importe quel langage permettant d’appeller des webservices au format SOAP (java, php & cie).
Euh, les requêtes au format SOAP c’est simplement des requêtes xml envoyées par HTTP. Donc n’importe quel serveur web est capable de recevoir des requêtes de webservice au format SOAP.
Plusieurs méthodes :
Méthode très simple : il te suffit de rajouter un paramètre de type chaîne sur chaque méthode et de donner à chaque client une clé unique qu’il doit passer comme paramètre. Tu stockes ensuite en base le nombre d’appels pour chaque clé.
A voir aussi : tu peux aussi te baser sur l’auth HTTP classique (si tu es dans un cas d’intranet par ex.)
Si tu souhaites que chaque client se connecte avec un couple identifiant/mot de passe, le problème est tout autre et tu vas devoir coder pas mal de choses.
Pour la doc : MSDN (avec les fundamentals)et w3c (mais vraiment si t’as la foi).
Concernant les outils qui pourront t’aider, je citerais :
Fiddler pour faire proxy http et regarder ce qui est transféré/renvoyé (assez ultime mais il a du mal avec les connexions http persistantes)
Ton navigateur en pointant directement vers l’url de ton webservice en localhost (genre http://localhost/monwebservice/toto.asmx) et voir les contrats WSDL et le tester avec un formulaire en ligne.
mais tant qu’a faire mon “assisté”, est-ce qu’il existe un exemple complet de webservice + son interogation avec SOAP
j’y arrive en “full .net” (client + webservice), mais la je galere a utiliser en passant par soap.
Comme tu le dis, en interogeant http://localhost/monwebservice/toto.asmx je vois tout ce qu’il faut, mais concretement : je l’utilise comment en .net ou php cote client, ce code ?
Tu fais clic droit sur ton projet client => “Add Web Reference”, et tu tapes l’url de ta page .asmx.
Ca te génère un proxy client “tout fait” et qui marche.
Ensuite, si tu veux fouiller voir comme c’est fait, tu vas voir à la mano dans ton dossier “Web References” de ton projet, et tu ouvres le fichier .cs.
Ceci dit, il y a plusieurs styles de web services (2 paramètres document/rpc & encoded/literal, donc 4 possibilités au final). A des fins d’interropérabilité, le choix conseillé est document/literal
[quote=« Styx31, post:2, topic: 31254 »]- Plusieurs méthodes :
Méthode très simple : il te suffit de rajouter un paramètre de type chaîne sur chaque méthode et de donner à chaque client une clé unique qu’il doit passer comme paramètre. Tu stockes ensuite en base le nombre d’appels pour chaque clé.
A voir aussi : tu peux aussi te baser sur l’auth HTTP classique (si tu es dans un cas d’intranet par ex.)
Si tu souhaites que chaque client se connecte avec un couple identifiant/mot de passe, le problème est tout autre et tu vas devoir coder pas mal de choses.[/quote]
Grosso modo d’accord aussi, pour préciser je vois trois choix pour s’authentifier sur un WS :
Authentification applicative, c’est la méthode simple présentée par Styx. L’avantage c’est justement que c’est simpe, l’inconvénient c’est que tu « teintes » tes services d’une information technique. Du coup c’est ton service qui doit se charger de dire « Joe a le droit de m’appeller mais Bob ne peut pas », chose qui pourrait etre fait en amont en utilisations d’autres types d’authent.
Authentification couche de transport : concrètement tu utilises un des mécanismes d’authentification proposés par HTTP (si http est bien ta couche de transport, ce dont je ne doute pas) : basic, digest, SSLv2 ou SSLv3. Avantage : ca reste neutre au niveau de tes services, désavantage : il faut que le client soit capable de s’authentifier en utilisant ces options (tout le monde sait causer Basic, peu savent causer digest, et ssl ca dépend …)
Authentification web services : c’est à mi-chemin entre les 2 solutions ci-dessus. Tu utilises WS-Security pour authentifier le client, mais la franchement c’est que tu cherches les ennuis ^^
Exact, mais comme par défaut c’est du document/literal, pas de problème en général.
[quote=« viewww, post:7, topic: 31254 »]Grosso modo d’accord aussi, pour préciser je vois trois choix pour s’authentifier sur un WS :
Authentification applicative, c’est la méthode simple présentée par Styx. L’avantage c’est justement que c’est simpe, l’inconvénient c’est que tu « teintes » tes services d’une information technique. Du coup c’est ton service qui doit se charger de dire « Joe a le droit de m’appeller mais Bob ne peut pas », chose qui pourrait etre fait en amont en utilisations d’autres types d’authent.
Authentification couche de transport : concrètement tu utilises un des mécanismes d’authentification proposés par HTTP (si http est bien ta couche de transport, ce dont je ne doute pas) : basic, digest, SSLv2 ou SSLv3. Avantage : ca reste neutre au niveau de tes services, désavantage : il faut que le client soit capable de s’authentifier en utilisant ces options (tout le monde sait causer Basic, peu savent causer digest, et ssl ca dépend …)
Authentification web services : c’est à mi-chemin entre les 2 solutions ci-dessus. Tu utilises WS-Security pour authentifier le client, mais la franchement c’est que tu cherches les ennuis ^[1]
D’accord avec les 3 possibilités.
L’autre problème que je trouve à l’auth HTTP, c’est que cela demande aussi quelques possibilités côté serveur : l’auth est dans ce cas gérée par le serveur web, donc, dans un cas classique IIS, les utilisateurs seront authentifiés contre la liste des users du serveur, ce qui pose souvent problème.
L’auth webservices peut aussi se faire à la mano en utilisant les Headers SOAP. C’est ce que j’ai retenu pour mes développements, notamment parce que je maitrisais le client (et donc pas besoin de faire une doc sur comment utiliser les entêtes.
Conclusion : tu as plein de possibilités, mais toutes ne répondent qu’à des conditions bien précises. A toi donc de choisir selon l’ouverture de ton web service et selon les personnes qui seront susceptibles de l’utiliser.
Effectivement j’ai pas d’expérience avec un serveur .NET
En J2EE il y a les notions de Realm (grosso modo une base d’utilisateurs et de rôles) que l’on peut redéfinir (ou carrément réimplémenter) pour aller chercher les utilisateurs dans un fichier, une base, un LDAP ou ce qu’on veut …
En fait, je ne veux pas dire de bêtise, mais je pense qu’il est possible de feinter avec IIS 6.0 (en attendant le 7 qui permet d’implémenter soi même la base user au travers des MembershipProviders de .net)
On doit pouvoir dans les paramètres de IIS désactiver toute forme d’atuh HTTP (en autorisant l’accès anonyme), puis implémenter un HttpModule asp.net qui va se charger de gérer l’auth HTTP. Des gens semblent l’avoir fait. Et donc derrière, on peut alors utiliser un MembershipProvider existant.
Donc j’ai dit une “bêtise” dans le sens où c’est faisable. Mais je ne le recommanderai pas pour un développement “débutant” tant il y a de concepts à assimiler.
(Et j’arrête d’en rajouter de peur d’effrayer l’initiateur de ce sujet B))
je crois qu’on a bien fait de renommer l’endroit “geekzone” !!
Trève de plaisenteries!
Merci pour toutes ces informations, je suis en stage on va donc faire la premiere methode, “vite et bien”! et si ils veulent des precisions je donne vos contacts ou je demande des sous!