Discussion :

[fab123]

Bonjour,

voila la situation:
J'ai une appli A developpée en C++ et une appli B developée en Java.
Je dois developper une appli C en C ou C++.
Les 3 applications seront hebergées sur un PC sous un linux temps réel et la communication doit être rapide.
Les applications A et B doivent pouvoir appeler des méthodes de l'application.
les 3 appli sont en cours de spécification/developpement, je n'ai pas particulièrement de contraintes ou d'impositions.

Mes recherches m'ont amené à 2 solutions:
- les sockets (mais il faudrait mettre en place tout un protocole d'échange entre les application, on va dire que c'est la solution de secours)
- les webservices (un serveur serait mis sur l'application C et les applications A et B appeleraient des services).

Donc premièrement, avez vous d'autres solutions plus efficaces?
Deuxièmement, si je devrais donc partir sur les webservices, pouvez-vous me donner quelques conseils et pistes car je trouve beaucoup de choses mais je suis un peu perdu.

Merci pour votre aide!

Fab

[Davidbrcz]

Tu as regarde du cote du RPC ?

Car les webservices en C++ ca se fait, mais c'est pas la panacée

[r0d]

Les WS en C++ c'est pas la panacée certes, mais ça fonctionne bien. J'utilise régulièrement cette méthode pour déployer des applis écrite en c++, et ça marche bien. J'utilise gSoap pour ça, j'en suis satisfait.
Les deux principaux avantages sont:
. pas besoin de troucher la moinde ligne de code du soft que je transforme en WS. gSoap ajoute juste une couche totalement non intrusive.
. si les specs sont claires et précises, ça peut se faire en quelques minutes.

Après, je ne sais pas si dans ton cas c'est la bonne solution, car:
. je ne connais pas RPC, donc je ne peux pas comparer
. je ne connais pas le contexte précis
. la solution gSoap concerne surtout les programmes qui sont déjà implémentés en version stand-alone.

Tu peux aussi regarder du côté de boost::interprocess, qui permet de partager de la mémoire entre différents processus.

[fab123]

Je regarde du côté de gsoap et xmlrpc.

Visiblement il existe plein de solutions, je cherche la mieux adaptée et surtout la plus simple à mettre en oeuvre. N'ayant pas d'expérience sur ces sujets, je me dis que c'est une problématique souvent abordée et que quelqu'un qui connait pourra m'aiguiller.

On me dit que RPC est vieux et "qu'il existe surement des choses plus simples"

[r0d]

En fait RPC c'est large, c'est juste un principe (remote procedure call -> appel de fonction à distance), il existe plein de solutions qui implémentent ça. Mais bon je n'ai jamais eu à utiliser ça, donc je ne peux pas me prononcer.

[jblecanard]

Salut

Ce que tu veux faire n'est pas simple. Le RPC n'est en effet qu'un concept.

J'ai jeté un oeil à gSoap. C'est une solution assez simple. Perso, je ne te le conseillerais pas, SOAP/WSQL et tous ces systèmes basés sur des XML imbitables, je trouve ce genre de trucs pas maintenables et compliqués pour rien. Ca reste une solution intéressante si tu es coutumier de ce type de WebServices, encore que ça te donne pas trop la direction à prendre pour implémenter le programme.

Le must, c'est une belle archi basée sur ZeroMQ(ou du genre) et des données sérialisées efficacement (avec Protobuf, ou du genre), mais vu le contexte, je pense que c'est un peu trop ambitieux . Si la rapidité est un critère déterminant, et je suppose que c'est le cas vu que tu veux faire tourner ça sur un système temps réel, c'est ce qui se fait de mieux.

Si on veut aller au plus simple, ce que je ferais à ta place, c'est un programme C++ en FastCGI derrière un NGINX, et de lui faire respecter une interface REST. Ca s'entendra très bien avec les écosystèmes de WebServices classiques, ce sera facile à configurer niveau réseau car c'est Nginx qui fera tout, et tu t'emmerderas pas avec des vieux XML relous.

Tout ceci étant dit, il faudrait en savoir plus sur le besoin pour t'orienter plus précisément vers un choix.

[fab123]

Merci pour ces réponses.

Je peux peut-être illustrer le contexte:

Nous sommes dans un contexte industriel, toutes les applications sont sous une seule machine linux. On reste en local, pas de problème particulier de sécurité.
L'appli C commande un process.
Les appli A et C vont lancer des fonctions de l'appli C du genre "lance un séquence de test" avec en paramètre le nom de la séquence ou "fournit moi une liste de paramètre".



Dans un monde de bisounours, j'aimerais pouvoir dire:
Mon appli C a un serveur de type xxx à l'adresse yyy et mon appli C à un fonction fct1 avec en paramètre un int.
--> et avec ces infos, un tier peut facilement appeler ma fonction.

Pardon? ce n'est pas comme ca que ca marche?

[jblecanard]

Salut

Nous sommes dans un contexte industriel, toutes les applications sont sous une seule machine linux. On reste en local, pas de problème particulier de sécurité.

Ca c'est intéressant, ça va grandement simplifier le problème ! Je pense que des webservices ici, c'est vraiment overkill, et va rajouter beaucoup de lenteur pour rien.

Si tu es vraiment en local et que la solution restera à terme en local, tu n'as même pas besoin du réseau : tu peux utiliser des named pipe pour communiquer entre les applis.

Sinon, ZeroMQ fournit de quoi réaliser de la communication interprocess, et il y a des bindings java. Tu met une socket ZeroMQ, tu balances des structures Protobuf dedans et tu répond avec une autre structure Protobuf. Tu devras peut-être te coller l'implémentation des Stubs (la partie qui contacte ton appli) en Java mais c'est pas compliqué.

De plus cette solution te laisse le choix de te tourner vers des appels asynchrones pour améliorer les perfos, ce qui n'est pas faisable en RPC. Si cela te plaît, on peut détailler plus précisément comment gauler l'architecture pour que ça marche bien.

[fab123]

Le projet a l'air d'évoluer un peu, je ne sais pas encore ce que je vais faire.

En tout cas, merci pour votre aide!