Mit "lokal" meine ich, dass beide im selben Subnetz laufen, in den meisten Fällen mit dem gleichen Host / VM, daher scheinen einige standardübergreifende plattformübergreifende RPC-Mechanismen wie SOAP, XML-RPC, CORBA usw. unnötig zu sein.
Die Payload ist hauptsächlich numerisch (meist tabellarisch) mit einigen wenigen Metadaten (zum Beispiel verfügbare Datendienste, Datenbeschreibung / -typ usw.) von C ++ nach Java und Konsolen- / Skript-UI-Ereignissen von Java nach C ++ . So verhält sich das C ++ - Programm wie der Server und das Java-Programm als Client.
Ich kann mehrere Optionen aufzählen (meistens von der Suche auf dieser wundervollen Seite), aber ich habe noch nie eine in einer realen, schweren Situation benutzt oder gesehen, also hoffe ich wirklich, dass jemand, der "da war, das getan hat" erziehen kann mich über die Vor- und Nachteile der Optionen.
Ich bin mir ziemlich sicher, dass ich viele Optionen verpasst habe. Danke Ihnen allen für Ihre Hilfe!
Bearbeitet: Ich habe vergessen zu erwähnen, dass Performance keine große Rolle spielt, da der Datendurchsatz nicht riesig ist (der Server ist stark datenbankgebunden), aber es wäre wichtig zu wissen, ob eine Option besonders viel ist schneller oder langsamer. Zum Beispiel, ich denke, nichts schlägt Shared Memory (wenn richtig gemacht).
Die Optionen 3 und 4 werden in schweren Situationen in der Praxis verwendet.
Die Optionen 1,2,6 erreichen keinen anderen Host.
Option 5 ist wahrscheinlich zu schwierig für die Nicht-Java-Seite.
Ich würde mit Option 4 gehen, weil Option 3 zu niedrig ist (es sei denn, Option 4 erweist sich als zu langsam). Wählen Sie Ihr bevorzugtes plattformübergreifendes Lightweight-Messaging-Protokoll aus den aufgezählten Listen. Diese sind alle "im Kampf getestet" und haben Bibliotheken für die meisten Sprachen.
Ich würde mit Option 4 gehen. Ich würde 5. überspringen. 2 wäre klobig.
Wir reden davon, die Zahlen als einfachen Text zu übergeben, ja?
Tags und Links java c++ sockets rpc communication