Interprozesskommunikation zwischen einer Java-Anwendung und einem lokalen Server

9

Zunächst Prost für alle Programmierer [Heute = Programmierer Tag :)]

Zweitens, Ich arbeite an einem Projekt, bei dem die Spezifikationen die Verwendung eines Servers als Frontend und einer Anwendung im Backend erfordern. Das Projekt ist ein fortgeschrittenes Smart-Home-System . Der Server wird Befehle vom Client über das Internet (sagen wir wie eine Fernbedienung von außerhalb des Hauses) handhaben und sie (über einen Kommunikationskanal) an die Anwendung senden (Planung der Verwendung der JAVA-Anwendung), die die Hauptlogik behandelt wie das Steuern von Hardware-Sachen (Lichter ...), Lesen von einem Mikrofon (lokales Mikrofon) und Zugreifen auf eine Datenbank, um als ein Spracherkennungssystem (offline) zu agieren.

Jetzt bin ich noch in der Planungsphase und ich bin mir nicht sicher, welche Technologien für dieses Projekt die besten sind. Ich denke, Node.js oder Apache als Server und eine JAVA -Anwendung als Back-End und jede SQL-Datenbank zu verwenden für die SRS der Anwendung.

Ich hoffe, diese Abbildung zeigt deutlich, wie das System funktioniert:

Die Hauptfrage lautet:

Wie kann die Java-Anwendung am besten mit dem Server kommunizieren (Kommunikationskanal [muss bidirektional sein])?

und empfehlen Sie einen anderen Server als die genannten für diesen Job?

Was ist mir bisher in den Sinn gekommen:

1 - JSP und Servlets (damit ist der Server auch die Anwendung). Aber ich möchte nicht, dass ein Server mit dem Offline-Kram fertig wird, und ich bin mir nicht sicher, ob Java-Servlets auf die Hardware-Schnittstelle zugreifen können. Ich möchte auch, dass der Server von kritischen Entscheidungen getrennt ist (verschiedene Layer aus Sicherheitsgründen und nicht so häufig wie das lokale [Offline] -System).

2 - Kommunikationskanal:

A - Eine freigegebene Datei , aber es ist eine schlechte Idee , da ich die Anwendung nicht möchte um zu überprüfen, ob sich der Dateiinhalt von Zeit zu Zeit geändert hat (Befehl empfangen) oder nicht (exzessive Operationen).

B - Eine Interprozess-Kommunikation über einen Port ( Socket-Kommunikation ) scheint die beste Lösung zu sein, aber ich weiß es nicht wie sich dies in Bezug auf Betriebskosten und Kommunikationsfehler auswirken würde.

Verwendeter Betriebssystem: Linux Raspbian

BEARBEITEN:

Ich bin sicher, ZMQ + Apache ist gut genug für diese Aufgabe, aber wie ist es im Vergleich zu WebServices (wie SOAP)? Wären WebServices eine bessere Lösung in Bezug auf Standardimplementierung und Sicherheit?

Alle damit verbundenen Vorschläge sind willkommen, TQ

    
CME64 13.09.2013, 20:02
quelle

1 Antwort

3

ZeroMQ eignet sich hervorragend für die interne Kommunikation oder andere ähnliche Kommunikationslösungen.

Für Ihren speziellen Fall kann ich sehen, dass ZeroMQ am besten passt.
Gründe:

  • Ihr Offline-Server muss von der Web-Lösung unabhängig sein.
  • Kommunikation kann zuverlässig und bidirektional sein, möglicherweise ein anderes Muster wie (pub & gt; sub, req & lt; & gt; res, etc).
  • Beim Neustarten von Seiten müssen die Sockets (Verbindungen) auf der anderen Seite nicht neu gestartet werden, da Nachrichten in die Warteschlange gestellt werden.
  • Möglichkeit, nicht nur auf der gleichen Hardware, sondern auch im lokalen Netzwerk oder sogar über das Internet zu skalieren.
  • Große Gemeinschaft der Unterstützung. Es mag ein bisschen schwierig aussehen, aber in Wirklichkeit ist es ganz einfach, einfach zu den Beispielen zu gehen und das Konzept einmal zu verstehen - es ist sehr einfach und gut damit zu arbeiten.
  • ZeroMQ hat viele Treiber für die gängigsten Sprachen, darunter Java und Node.js .

Überlegungen:

  • Sie müssen über Pakete nachdenken und Daten werden gesendet. So sind einige beliebte Datenprotokolle wie XML oder JSON eine gute Denkweise.
  • Verantwortlichkeiten über verschiedene Dienste - stellen Sie sicher, dass sie nicht zu sehr voneinander abhängig sind. Wenn der Haupt-Offline-Server ein Kern des Systems ist, stellen Sie sicher, dass er nicht vom Web-Service abhängt, so dass das Web-Gesicht entfernt / ersetzt / verbessert werden kann usw.

Noch ein paar Punkte zum Nachdenken :
Warum Java und was ist mit modularem Ansatz? Zum Beispiel, wenn Sie erweitern und skalieren möchten - fügen Sie mehr Sensoren in Smart-Home-Lösungen hinzu, dann würde es eine gigantische Anwendung erfordern, sie zu ändern, es ist schwieriger zu pflegen und verschiedene Clients mit eigenen Bedürfnissen zu verwalten. Denk nach dem modularen Prinzip - einige Kernfunktionen für Offline-Sachen, aber viele Aggregatorprozesse, die mit verschiedenen Sensoren kommunizieren würden. Dies erleichtert die Unterstützung verschiedener Setups und Umgebungen und die Wartung des Systems als Ganzes durch die Verbesserung unabhängiger Komponenten.

    
moka 13.09.2013 20:57
quelle