Discussion :

[kanzarih]

Salut a tous
j'ai à dévélopper une application Clin serveur j'ai opter pour la solution web service. la communication Client vers Serveur s'éfféctue normalement mais J'ai une lacune sur l'autre sens Serveur -> client c-a-d je veut que le serveur peut demander une tache au client alors est ce que quelqun peut m'aider.

merci

[Guybrush113]

Je ne sais pas si cela peut t'aider, je ne sais pas si cela répond vraiment à ta question. Je ne suis qu'un newbie
Désolé pour le pavé, un simple copié-collé d'une doc qui traine dans mes dossiers :

Choix du modèle d'interaction
La spécification WSDL en version 1.1 définie quatre modèles standards d'interactions entre le noeud appelant (client) et le noeud destinataire (fournisseur du service) :
• One-way : Le client envoie une requête SOAP au fournisseur du service mais n'attend pas de réponse en retour,
• Request-response : Le client envoie une requête SOAP au fournisseur du service et attend une réponse en retour,
• Solicit-response : Cette fois, c'est le fournisseur du service qui envoie une requête SOAP au client et qui attend une réponse en retour,
• Notification : Le fournisseur du service envoie une requête SOAP au client.

Attention, ne vous méprenez pas, ce n'est pas parce que la spécification WSDL décrit ces quatre modèles que ceux-ci sont réellement implémentés dans la spécification SOAP : Dans les faits, seuls les deux premiers modèles sont implémentés. Pour enfoncer le clou, la spécification WS-I n'autorise de toute façon l'utilisation que des deux premiers modèles et exclu explicitement l'implémentation des deux autres.

Si vous souhaitez tout de même implémenter les deux derniers modèles ou mettre en place un mode de réponse asynchrone, cela ne sera pas chose aisée car cela inverse de facto le modèle client-serveur synchrone de SOAP basé en général sur le protocole HTTP.

Plusieurs solutions sont toutefois possibles avec un peu d'astuce :
• Pour implémenter les modes solicit-response ou notification :
• Vous pouvez mettre en place un serveur SOAP sur votre client et croiser les requêtes (pas forcément aisé si ce n'est parfois impossible),
• Vous pouvez mettre en place un algorithme de polling avec un client qui interroge à intervalle régulier le serveur pour y récupérer des messages et éventuellement y répondre,
• Vous pouvez implémenter un mode request-response "asynchrone" en retournant au client un numéro de ticket pour la réponse (par exemple dans l'en-tête) et une évaluation du temps de traitement : Lorsque le temps de traitement est révolu, le client se reconnecte et présente son ticket ; si la réponse n'est pas encore prête, on retourne au point de départ avec un
nouvelle temporisation.

En résumé, bien que spécifiés mais non-implémentés, tous ces modèles peuvent donc être conçus par abstraction des modes one-way et request-response dans le cas du protocole SOAP.
Il est tout à fait probable que le protocole SOAP implémente à terme ce type de fonctionnalité dans une énième version ce qui le rapprochera alors un peu plus d'un véritable bus logiciel, ce qui est loin d'être le cas à l'heure actuelle (et souvent source de confusion dans l'esprit de certains).

Extrait de l'article publié dans GNU/Linux Magazine France, numéro 76 (Octobre 2005).
Initiation au couple gagnant WSDL/SOAP par Lionel Tricon


Donc des requetes Serveur -> Client, ne s'opère pas de la même façon. Je n'ai jamais testé ceci, donc je ne pas pas t'aider d'avantage

Bon courage !