Discussion :

[r0d]

Bonjour à tous,

Voilà, je me retrouve avec 2 applis, une en java (IHM+acces bdd) et une en c++ (gestion de périphériques). Je dois me débrouiller pour que les deux puissent communiquer. En gros, l'appli java doit pouvoir exécuter des fonction de l'appli c++, en lui passant des paramètres, et en récupérant des données.

Les deux applis tournent sur le même pc, qui est sous Windows XP.

Il me semble que le plus simple pour faire ça est de passer par un client/serveur SOAP. Et c'est pourquoi je pose ma question ici.

D'après ce que j'ai compris, le serveur sera du côté de l'appli c++. J'ai donc implémenté un serveur SOAP en c++ en utilisant gSoap. Pour le tester, j'utilise xlmSpy (pas le choix), mais ça ne fonctionne pas (pourtant mon serveur fonctionne quand je l'utilise avec le client c++ généré par gSoap).

Le problème c'est que je n'y comprend pas grand chose à ces histoires de client/serveur, et que je suis un peu perdu dans les sigles qui foisonnent dans les messages d'erreurs que j'obtiens (dtd, xsi, xsd, wsdl...)

Voilà pour l'état des lieux. Ce que je voudrais savoir, c'est:
1/ Est-ce que la solution du client/serveur SOAP est la meilleure solution? N'y a-t-il pas plus simple?
2/ Mon serveur gSoap est de type "stand alone". Qu'est-ce que ça veux dire?
3/ Avez-vous des liens qui parlent de ce type de problématique pour que je puisse me documenter de façon efficace? (je ne parviens pas à trouver de la doc vraiment utile).

[alain.couthures]

L'utilisation de SOAP (c.a.d. de services web) doit permettre de simplifier le code de chaque côté puisque le client n'a qu'à appeler une fonction proposée par le serveur.

C'est un peu luxueux et gourmand pour ne tourner que sur un seul PC mais sait-on jamais si, plus tard, il n'y aura pas deux machines distantes de plusieurs centaines de kilomètres !

L'intégration de tout ça n'est jamais gagnée d'avance car les standards sont toujours sujets à interprétation dans les implémentations : il faut d'abord valider que chaque côté fonctionne bien en y mettant en face un simulateur dans le même langage. On essaie toujours de se ramener à quelque chose qui marche pour, ensuite, pouvoir progresser...

Pour autant, travailler directement par sockets n'est pas si évident non plus.

Stand-alone pour gSOAP doit vouloir dire sans nécessité d'un serveur HTTP tiers (Apache, IIS,...)

[r0d]

Merci

Stand-alone pour gSOAP doit vouloir dire sans nécessité d'un serveur HTTP tiers (Apache, IIS,...)

D'accord. Mais ce que je ne comprend pas, c'est pourquoi xmlSpy n'arrive pas à "dialoguer" avec mon serveur alors que le client gSoap y arrive. Voici l'erreur qu'il me returne:

---------------------------
XML Spy
---------------------------
HTTP error: could not POST file '/MonServeur.cgi' on server '127.0.0.1' (0).
---------------------------

MonServeur est le nom de l'executable de mon serveur gSoap stand-alone. La requête que j'envoie au serveur à l'aide de xmlSpy est générée à partir du wsdl généré par gSoap à partir du code c++ de ce serveur.

Alors ce que je ne comprend pas, c'est le ".cgi". Ca veut dire qu'il cherche un serveur type Apache, IIS, ... ?

[alain.couthures]

Effectivement le rajout de .cgi par XmlSpy est plus que suspect...

J'ai déjà eu, par le passé, beaucoup de soucis avec XmlSpy qui m'est toujours apparu être un produit de piètre qualité mais c'est un avis personnel...

[r0d]

Hum... je viens de tester avec soapUI, et j'ai exactement le même problème.

J'ai essayé de modifier le 'end point' (l'adresse du serveur), mais toujours pareil: il n'arrive pas à se connecter au serveur.
J'ai essayé:
127.0.0.1:8080 (tout court)
127.0.0.1:8080/MonServeur
127.0.0.1:8080/C:/le/chemin/MonServeur
127.0.0.1:8080/C:/le/chemin/MonServeur.exe

Rien n'y fait...

[Guybrush113]

Pourquoi ne pas tester directement avec un client JAVA au lieu de XmlSpy ?
Tu pourrais déjà voir si d'autres messages d'erreurs, ça pourrait aider.

Un lien, je ne sais pas si ca va t'aider :
http://www2.sys-con.com/ITSG/virtual...ely/index.html
Allez un autre... un gros pavé mais ya des trucs pas mal ^^
http://java.sun.com/developer/techni...rvices/fastWS/

[r0d]

Parce que c'est dans le cahier des charges: on doit pouvoir tester le serveur avec xmlSpy et soapUI

Et puis je suis tellement nul en java que je risque de mettre longtemps avant de réussir à implémenter un client soap

[Guybrush113]

Ok ok...
J'ai jamais développé de WebService en Java ni C++, mais en PHP et en .NET, le point d'entrée d'un serveur SOAP est le fichier WSDL, et c'est dans le WSDL (ou à l'appel du WSDL) que tu définis le chemin pour attaquer le serveur SOAP.

Je peux pas t'aider d'avantage désolé...