Pouvez-vous donner des conseils sur l'utilisation de SoapRMI-C++ pour envoyer/recevoir des objets entre les couches C++ (en haut) et Java (en bas) d'une application.SOAP RMI C++ - Communication Java et C++
Veuillez me faire connaître sa faisabilité et sa complexité de mise en œuvre.
Merci, Gtk
Ne pas. Utilisez quelque chose comme Protocol Buffers.
Le savon est verbeux et lent. Et RMI conduit à une conception de programme médiocre lorsque des messages qui auraient pris des nanosecondes à envoyer à la place deviennent des messages qui prennent des microsecondes (si les deux programmes sont sur la même boîte, ou peut-être sur le même LAN) ou même des millisecondes à envoyer. Et il est impératif que la nature tende aussi à encourager les conceptions dans lesquelles le client et le serveur dépendent l'un de l'autre de manière assez imbriquée, tout comme l'appelant et l'appelé font un appel de méthode ordinaire. Il encourage la taille de l'horizon d'état pour englober la latence de bout en bout du client qui parle au serveur, ce qui peut le ralentir considérablement et entraîner des erreurs.
Utilisez des techniques dans lesquelles le passage de message est explicite et qui vous encouragent à vous concentrer sur les données transmises au cours de l'opération qui doit être effectuée par le côté distant. Encore une fois, cela indique une solution comme les tampons de protocole.
J'ai écrit un papier il y a longtemps sur pourquoi RPC (and by extension RMI) was a bad idea. J'y distingue CORBA, mais la plupart de mes arguments s'appliquent à presque toutes les formes de RPC. De plus, l'existence et la popularité de langages comme Erlang montrent que le passage de message explicite est bon même pour les communications entre différents threads sur le même CPU où la latence et les retards de réseau ne sont pas un problème. C'est parce qu'il diminue considérablement le couplage entre les threads. Les threads n'ont plus à accepter de toujours acquérir un mutex avant de faire certaines choses ou quelque chose comme ça. L'horizon d'état d'un thread individuel n'inclut plus celui des autres threads du système. Il réduit également le comportement synchrone dans lequel plusieurs threads veulent contrôler le même mutex ou morceau d'état partagé.