J'ai deux machines sur un réseau. Je souhaite à partir d'un programme Java sur la machine 1, demander à la machine 2 de lancer une impression.
 
Grâce à gatorette, LetoII, VisualC++ et chrisbk j'ai un programme C qui sait imprimer un document, pourvu que je lui spécifie le pathname (local) vers ce document.
 
Mon but est donc d'appeler via Java sur la machine 1, le programme C, en lui spécifiant en paramètre un fichier de la machine 2.
 
Quelle techno utiliseriez-vous ? Quel moyen ai-je pour récupérer le résultat du programme C (code de retour...) ?

Regarde du coté de RMI mais attention il faut installer java sur ton 2eme PC.
Je suppose que ton programme c est compilé tu souhaites lancer un executable. Dans ce cas Runtime et Process sont tes amis.

 
C émouvant je suis dans les crédits :'
 

 
T'as RPC aussi mais ça risque de pas être facile.

RMI me paraît mieux. Autrement dit j'aurai un programme Java sur la machine 2, lequel fera les traitements localement.

J'fais ça au boulot. Prog C++ sur une machine qui démarre sur la demande de ma servlet et qui lui renvoie le résultat. C'est un "énorme" système de messages sur protocole HTTP. Côté serveur Java, y a une gestion de queues de messages et chaque client C++ s'y connecte en permanence pour vérifier qu'il n'a pas de nouveau message. S'il en a (moi j'balance du XML mais bon), alors il fait ce qu'il a à faire et il rebalance le résultat dans un tableau de char.

Le prog C++ qui démarre sur la demande de ta servlet, tu le démarres comment ? RMI, sockets, RPC ?

A la mano C'est un demon qui tourne tout le temps, si tu préfères : service sur Windows et daemon sur Unix.

Mais le daemon c'est toi qui l'a écrit ? Peux-tu m'en dire plus, je sens que la solution savoureuse est au bout de ton explication.

Ba au total, j'ai un exécutable en C++. Avec un main et tout ça. Pour le lancer, soit l'admin de la machine le lance à la main, soit il l'enregistre en tant que service auprès de Windows. Sous Unix, il suffit de le mettre dans les .rc de /etc de façon à ce qu'il soit lancé au boot.

Oui c'est pas con ça. L'enregistrer en tant que service. Je vais regarder ça. Et pour les appels, ta servlet elle procède comment ?

Ba pour les appels, le C++ se connecte en HTTP sur une ôt servlet (j't'ai dit, c'est un gros mécanisme). Cette servlet gère des queues de messages et met le process C++ en attente. Ma servlet à moi appelle cette servlet de messages et lui envoie le nom de la commande à contacter, ainsi que le message qui va bien. La servlet de message retrouve la commande C++, lui refile le message et zou.

Autrement dit ton programme C++ est communiquant.

Bin ui, y a une partie qui cause en HTTP avec la servlet en face

Et pkoi ta 2eme servlet ne lancerai pas directement les autres progs?

Bin passke la servlet et le prog sont pas sur la même machine (ni parfois le même OS). Pis de toute façon, depuis un environnement WebSphere, chu jamais arrivé à lancer un exécutable depuis une servlet (sécu à la con ?)

Eclairez ma lanterne, j'ai une petite question :    
 
Pourquoi ne pas utiliser du SOAP pour dialoguer entre les deux machines ?
 
La mis en place est assez rapide pour un dialogue SOAP, non ?
 
client Java et serveur C..

Ba c'est à peu près l'idée, hein, transmission d'XML via HTTP pour exécuter des process à distance... sauf que ba SOAP ça requiert un serveur HTTP, non ? Bin moi, mon process C++ il est indépendant, je veux pas qu'il ait besoin d'un serveur HTTP et tout le tremblement pour tourner
Qui dit SOAP dit serveur (ou alors j'ai pas tout bien pigé au mécanisme) ; ici, on est dans le cas machine cliente <-> machine serveur d'appli (WebSphere, etc...) <-> machine extérieure lançant une commande spécifique.
L'objet du topic est l'appel de la commande spécifique par le serveur. S'il faut intégrer un serveur SOAP pour chaque machine devant lancer la commande spécifique, on a pas gagné la guerre

Non, ça on l'a pas gagné.

Et surtout bonne chance