Web Service et Appli sur Serveur

bonjour,

alors je vais essayer d'etre claire pour exprimer mon probleme. qui a mon avis est plus un probleme de comprehension des Web Service que de codage vraiment. un shema de la structure de ce que je veux faire repondrais a ma question, mais je n'y arrive pas.

je dois faire un Service Web pour un client.
Or si j'ai bien compris ce service Web fourni des methodes que peut utiliser le client.

Paralellement je dois develepper une gestion de files d'attente sur mon serveur dans une applie qui tournera dessus et fera des requetes cliente sur une 3 ieme machine. mais bref.

donc le probleme que j'ai c'est que j'aimerais que la classe Proxy que je fourni au client puisse envoyer des parametres a mon applie que je normerais de principale.

En gros, j'ai une applie qui tourne, elle recoit des requetes du client,  les traites, fait tout un ramdam avec (communication avec une autre machine, utilisation de divers Classes, sauvegarde de parametre en memoire et sur une base...), puis renvois une message comme quoi c'est ok ca c'est bien passé.

j'ai vraiment du mal a visualiser le service Web dans tout ca, car j'ai l'impression qu'un service Web Fonctionne un peut en "stand alone". comme les nombreux exemple qu'on trouve sur le net ou il s'agit d'un methode Add(a, b) qui additionne a et b  et renvois le resultat.
Dans mon cas pour faire simple, j'aimerais que a et b soient envoyer a mon programme principale.
----------------------------------------------------------------------------------------------------

j'ai actuellementun programme qui fonctionne, mais sans service Web, il possede juste un HttpListener et HttpWritter et donc recuperes les parametres dans sont code et fait ca moulinette.
J'aimerais ne pas avoir a me soucier du protocolle, et fournir au client un WSDL plutot que de lui specifier le format des requetes qu'il doit envoyer...

----------------------------------------------------------------------------------------------------

j'espere avoir été claire

Bonjour,

Je suis dans le même cas que toi, et je ne pense pas que ce soit possible de communiquer avec le serveur WebService depuis une appli locale qui tourne sur la même machine que ce serveur.
On ne peut pas non plus lancer explicitement le serveur WebService depuis une appli, c'est exclusivement IIS qui s'en charge...

Bref, je crois que je vais être obligé de revenir à ma première idée : faire écrire des données en base par le serveur WebService et les faire lire par mon appli, mais ça va m'obliger à scruter la base (ou alors à faire un trigger) pour savoir si le serveur WebService a été appelé par un client et qu'il a des nouvelles données à me fournir. J'aurai préféré pouvoir appeler une méthode maison, ou déclencher un événement dans mon appli...
Ça ne fonctionnerait pas le partage d'événements (event .NET je parle) entre le serveur WebService et une application ? Un peu comme les mutex nommés partagés entre processus, y-a-t'il un moyen de nommer un événement et de le partager ?

Merci de vos réponses !

Hello,

Il y a deux solutions à votre problème.

Si les opérations que le WebService devrait appeler n'ont pas besoin d'être directement dans un programme, tu peux les mettre dans une librairie que le WebService utilisera. C'est la solution la pus simple, et rien ne devrait s'y opposer.

Si malgré tout pour d'obscure raisons tu ne peux pas séparer le code de l'application et celui que devrait appeler le WebService, il te reste la solution du Remoting.

Amicalement, SharpMao

"C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!"
(Coluche / 1944-1986 / Pensées et anecdotes)

Merci pour la réponse.

Je ne crois pas que je puisse utiliser une librairie. En fait, j'ai une appli qui tourne en local, qui récupère sur un réseau de communication des données d'un automate. Je transmets certaines de ces données à une appli "maitre" distante, qui me répond de manière asynchrone via webservice (d'où le serveur webservice que j'implémente en local). Mon appli met l'automate en "attente" le temps de recevoir la réponse via webservice, mais continue de fonctionner (l'ihm, et aussi d'autres threads pour d'autres automates). Du coup, l'idéal aurait été que je puisse agir dès la réception par le serveur webservice de la réponse de l'appli "maitre" distante, pour débloquer l'automate. Et pour agir, il me faut récupérer les valeurs passées en paramètre de la webméthode de mon serveur webservice lors de son appel par le client du webservice (= l'appli "maitre" distante).
Donc dans ce cas, l'utilisation d'une librairie ne m'arrange pas trop, car elle est déconnectée du processus d'exécution de mon appli locale.

Quant au Remoting, le problème est que je dois absolument fournir une interface de serveur WebService (je ne maitrise pas l'appli "maitre" distante) ; il faudrait alors que je réimplémente une interface webservice classique via Remoting (en instanciant et fabriquant du SOAP et tout ça), alors que tout est dispo "off-the-box" dans .NET pour les webservices... ce serait dommage (et pénible !).


L'idée de passer par une base de données intermédiaire parait-elle la meilleure dans mon contexte ?

salut,

-> avec le remoting, on peut préciser un format SOAP sur un channel TCP ou HTTP...
-> tu peux implémenter un SAO singleton dans ton appli locale que le webservice local pourra utiliser, comme ca ton appli locale saura que le web service est appelé
-> tu peux aussi faire ca par les files de messages COM+

ShareVB

Merci pour ta réponse, ShareVB !

J'ai effectivement implémenté un serveur .NET Remoting dans mon appli locale, et avec une interface commune disponible dans une librairie partagée, mon serveur webservice se comporte comme un client vis-à-vis de ce serveur .NET Remoting et transmet ainsi à mon appli les infos reçues lorsqu'un client webservice l'invoque !
Ça fonctionne très bien, même si c'est sûr que ça fait un peu lourd (une chaine de deux serveurs).

Pour les détails, j'ai implémenté un serveur .NET Remoting sur un canal TCP (bien penser à le désenregistrer après chaque appel dans le serveur webservice, sinon il ne fonctionne qu'une seule fois, le serveur webservice fonctionnant sans mémoire de variables locales de session). Je l'ai mis en mode "Singlecall".

Hello,

Deux petites choses encore.
Est-ce toi qui à développé l'appli maître distante ?
Si oui, est-ce qu'elle ne pourrait pas servir elle-même de serveur Remoting.
Depuis ton applli locale, tu peux lors appeler une de ses méthode en asynchrone, et plus besoin de Web service.

Autrement, si tu restes avec ton architecture actuelle. Si ton WebService et ton appli de communication son sur la même machine, tu peux utiliser des cannaux IPC (Inter Process Communication) pour le Remoting entre le WS et l'appli. C'est un peu plus léger au niveau resources que HTTP ou TCP.


Amicalement, SharpMao

"C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!"
(Coluche / 1944-1986 / Pensées et anecdotes)

Merci SharpMao pour les conseils.

Je n'ai pas développé l'appli maitre distante, je ne peux malheureusement pas décider quelle techno employer (les web services ne me ravissent pas ici, ils ne sont pas utilisés à bon escient...). Ceci dit, si je devais implémenter le Remoting en direct entre mon appli locale et l'appli distante (sans passer par un webservice), ce serait dans l'autre sens : mon appli locale en serveur, dont une méthode serait appelée en asynchrone par l'appli distante.

Du coup, sur ton conseil, j'ai modifié mon Remoting pour faire de l'IPC au lieu de faire du TCP, puisqu'effectivement les deux (appli locale et serveur webservice) sont sur la même machine. Si c'est plus léger, je prends !

Merci à tous les deux pour votre aide, mon problème est résolu.