Echtzeitbenachrichtigungen - Welche Technik?

[TheMiller]

Hallo

das Thema war in ähnlicher Art schonmal in der Diskussion, allerdings hatte ich mich damals auf die Nutzung eines MessageBrokers festgelegt.

Doch nun möchte ich nochmal einen Schritt zurück und die Grundsatzfrage nochmal diskutieren, da vllt. ein MessageBroker "oversized" ist.

Zu den Anforderungen/Szenario: Ich habe eine Website, welche lokal im Netzwerk läuft und im MySQL-Server Daten speichert. Zu der Webseite gehören also ein Frontend, ein Backend und eine REST-API. Man kann die Daten über das Frontend eintragen, aber ebenfalls auch über die API - letzteres ist sogar der Hauptanwendungsbereich. Denn zu dem System gehört eine umfangreiche Windows-Anwendung, welche permanent von verschiedenen Arbeitsplätzen die Daten via REST-API vom Webserver liest und schreibt. Nun möchte ich, dass die Anwendung bei ClientA eine Benachrichtigung bekommt, dass ClientB im gleichen Modul was geändert hat, sodass A die Daten nachlädt (oder diese schon mitgeschickt bekommt).

Dazu stehen ja MessageBroker wie MSMQ, ApacheMQ etc zur Verfügung. Die können ja noch viel mehr als das, ich brauche aber nur dieses Feature. Daten speichern, während der Server offline ist, das ist (erstmal?) egal.

Kann ich mich dafür noch einer anderen (fertigen) Technik bedienen - zB Websockets/node.js/HTML5 - oder ist ein MessageBroker für mich unumgänglich?

Diese Anwendung wird mit ca. 10-20 Usern stets im eigenen Netzwerk gehostet.

Wie würde es aussehen, wenn ich ein solches System für eine "echte" Webseite nutzen möchte (siehe Facebook), welche Technik wäre da zu bevorzugen?

Danke vielmals im Voraus

[himitsu]

Wenn ich jetzt vom Embarcadero-Vertrieb wäre, dann
http://edn.embarcadero.com/article/41374

Im neuen coolen EMS gibt es sowas bestimmt auch.


Auch einige DBMS haben Callbacks/Alerter, wo z.B. aus Triggern eine Nachricht an einen/alle Clienten verwendet werden kann.

[BUG]

Node.js, Websockets, .... Willst du jetzt die Servertechnologie festlegen oder das Protokoll
Wenn du schon eine Rest-API hast, würde ich mir Long-Polling angucken. Vielleicht kannst du das mit dem bestehendem Backend gut umsetzten.

[Olli73]

Zitat von BUG:

Wenn du schon eine Rest-API hast, würde ich mir Long-Polling angucken.

Das hätte ich jetzt auch vorgeschlagen.

Websockets sind zwar "moderner" und haben weniger Overhead, aber in diesem Fall sollte Long Polling ausreichen.

[Valle]

Wobei es für mich fraglich ist, warum man bei der Implementation eines neuen Features denn auf solch einen "Workaround" wie Long-Polling zurückgreifen will, wenn es doch mittlerweile moderne Techniken gibt, die für deinen Einsatzzweck auch wirklich gedacht sind. Ich würde das vorher gut abwägen. Wenn Long-Polling wirklich viel schneller und einfacher implementiert ist, dann ist das durchaus ein Argument. Falls nicht, würde ich diesen Hack im Jahr 2015 nicht mehr neu programmieren.

[TheMiller]

Danke schonmal für die Antworten.

Longpolling hab ich eigentlich tatsächlich deswegen schon ausgeschlossen, aber lasse mich ja auch gerne von anderen Argumenten wieder überzeugen.

Es muss ja zudem auch noch eine Lösung sein, mit der Sprachenunabhängig kommuniziert werden kann (w32-Anwendung mit Webseite). Ich hab mal quergelesen, ob das mit Websockets wirklich funktioniert.

Was stehen denn generell für Techniken hinsichtlich (bidirektionaler) Echtzeitbenachrichtigung zur Verfügung? Auf Anhieb fallen mir diese Techniken ein:

* MessageBroker (bidirektional)
* Websockets (bidirektional)
* LongPolling (unidirektional)
* Polling (unidirektional)

Wenn wir über eine echte Webseite sprechen, welche von mir aus 500-1000 User gleichzeitig hat und ebenfalls solche Nachrichten getauscht werden sollen, fällt LongPolling schon raus, sodass man dann zu MBs oder WS greifen sollte, nicht wahr?

Wichtig ist halt in beiden Fällen (lokale Webseite bis 10 User / "echte" Webseite mit unbegrenzten Usern), dass die Nachrichtentechnik stets auch im Windows-Programm funktioniert. Damit meine ich, dass im Desktop-Client Daten sofort nachgeladen werden, wenn sich im Web etwas geändert hat.

Habe sowas natürlich noch nie umgesetzt, daher frage ich so nach. Mache mir aber schon seit längerem Gedanken, jetzt seit kurzem auch genauere.

[BUG]

Es war halt der Gedanke, dass du auf Client-Seite vielleicht besser zu einer "guten" Long-Polling Variante basierend auf HTTP kommst als zu einer hingewurschtelten Websocket-Lösung basierend auf TCP. Keine Ahnung was Delphi da mittlerweile anbietet
Auf Serverseite muss dir bewusst sein, dass Websockets kein normales HTTP sind, und du damit eventuell Probleme mit Proxies (usw.) haben kannst.

Message-Broker fallen ein bisschen aus deiner Aufzählung von Protokollen heraus. Sie sind eher Middleware und können selbst unterschiedliche Protokolle (OpenWire, STOMP, usw.) anbieten.

[Valle]

Zitat von BUG:

Es war halt der Gedanke, dass du auf Client-Seite vielleicht besser zu einer "guten" Long-Polling Variante basierend auf HTTP kommst als zu einer hingewurschtelten Websocket-Lösung basierend auf TCP. Keine Ahnung was Delphi da mittlerweile anbietet

Da stimme ich dir allerdings zu.

Ich hatte gerade dummerweise nur Browserlösungen im Kopf. Da klappt das gut. Wenn's für Delphi da nix gibt, dann doch lieber ne andere Lösung suchen.

[Mavarik]

Zitat von TheMiller:

Zu den Anforderungen/Szenario: Ich habe eine Website, welche lokal im Netzwerk läuft...

Es geht Dir darum auf eine HTML Seite eine Benachrichtigung zu zeigen?

lokales Netzwert?

Ein ActiveX Control - im lokalen Netz gibt es ja dafür keine Sicherheitsbedenken...
Das ist dann eine Delphi Anwendung und die kann alles...

Fertig

[TheMiller]

Es geht mir darum, dass in beide Richtungen Nachrichten ausgetauscht werden können und die jeweils andere Seite darauf reagiert. Auf der Seite der WebApp sollte es idealerweise so sein, wie bei Facebook. Bekommt jmd. eine Nachricht, soll eine (1) erscheinen - wenn man gerade im Chat drin ist, soll gleich der gesendete Text erscheinen.

Das Chat-Beispiel ist gut: Zwei Leute unterhalten sich, der eine ist auf der Webseite, der andere im Windows-Programm. Ohne neuzuladen sollen die Nachrichten hüben wie drüben sofort angezeigt werden. (Es soll zwar kein Chat werden, aber das beschreibt die Problemstellung bestens.)

Ich mache bei der Anforderungsbeschreibung zugegebenermaßen einen Fehler: Ich arbeite parallel an zwei verschiedenen Projekten. Beide sollen aber eine solche Technik implementiert bekommen. Das eine Projekt ist eine große öffentliche Webseite und Windows-Programm (Webseite steht im Vordergrund), das andere Projekt stets eine Webseite im lokalen Netz mit mehreren Windows-Programmen (Programme stehen im Vorderund, < 30 User).

Vllt. macht es vor diesem Hintergrund nämlich doch Sinn, sich für eine Lösung zu entscheiden um nicht das gleiche System zwei Mal verschieden implementieren zu müssen - oder man arbeitet letztlich über Interfaces...