# Server zu Client Kommunikation



## raptor09 (18. Jul 2012)

Hallo zusammen 

Ich habe eine Frage zur Kommunikation zwischen Client und Server. In der klassischen Client-Server-Kommunikation ist es ja so, dass der Server auf Anfragen von Seiten des Clients wartet, bevor er in Aktion tritt. Also wenn ich eine Tabelle habe, die ich sekündlich aktualisiert haben möchte, dann muss der Client jede Sekunde eine Anfrage an den Server schicken: "Schick mir doch die aktuellsten Daten". 

Jetzt meine Frage: 
Wie funktioniert es, dass die ganze Sache andersherum läuft? Sprich also, der Server tut folgendes: Warten, bis Daten vorhanden sind und dann selbstständig einen Datensatz an den Client schicken. 

Ich habe nun Daten, die sekündlich aktualisiert werden sollen, und Daten, die unregelmäßig aktualisiert werden. Der Server soll nun die Ersteren jede Sekunde selbstständig schicken, bei dem zweiteren soll er schicken, sobald diese vorhanden sind. 

Ist das überhaupt möglich? Und wenn ja, wie (in Java)?

Vielen Dank euch bereits an dieser Stelle für eure Hilfen 


P.S.:
Falls so ein Thema in diesem Forum bereits existiert: Ich war nicht zu faul die Suche zu benutzen - nur leider habe ich keine Ahnung, nach was ich hier genau suchen soll. Die Suchbegriffe, die mir eingefallen sind ergaben nichts in diese Richtung. Dasselbe mit Google 

P.P.S.:
Ich freue mich auch schon über die genaue Bezeichnung dieser Kommunikationsweise, sodass ich mich auf eigene Faust danach erkundigen kann


----------



## FArt (18. Jul 2012)

Was du haben möchtest nennt sich Callback.
Ich empfehle die Verwendung einer guten API wie Apache Mina oder JBoss Remoting. Interessant könnte auch JGroups sein.


----------



## Swoop (18. Jul 2012)

raptor09 hat gesagt.:


> Hallo zusammen
> 
> Ich habe eine Frage zur Kommunikation zwischen Client und Server. In der klassischen Client-Server-Kommunikation ist es ja so, dass der Server auf Anfragen von Seiten des Clients wartet, bevor er in Aktion tritt. Also wenn ich eine Tabelle habe, die ich sekündlich aktualisiert haben möchte, dann muss der Client jede Sekunde eine Anfrage an den Server schicken: "Schick mir doch die aktuellsten Daten".


Das nennt sich Pollen und wird auch bei kleinen Anfragen häufig verwendet...


----------



## TheDarkRose (18. Jul 2012)

Wenn der Server nicht gerade ein HTTP-Server ist, sondern ein selbstprogrammierter, kannst du einfach die Verbindung offen lassen und der Server sendet sekündlich die neuen Daten an den Client. 

Gesendet von meinem GT-I9000 mit Tapatalk 2


----------



## Zeeu (18. Jul 2012)

Ich denke das Entwurfsmuster "Observer" könnte hier recht hilfreich sein, ein Client meldet sich beim Server an, und sobald der Server eine Änderung wahrnimmt, schickt der eine Nachricht an alle angemeldeten Clienten. 
Triffts das, was du brauchst ? Wenn ja google mal nach Observer oder Beobachter


----------



## tuxedo (19. Jul 2012)

Ergänzend zur MINA oder JBOSS Remoting Empfehlung:

* Java RMI
* SIMON
* <irgend ein anderer RPC Mechanismus>


----------



## raptor09 (19. Jul 2012)

Hallo und vielen Dank für die vielen hilfreichen Antworten! 

Ich habe die letzten zwei Tage seehr viel Info in meinen Kopf hineingeprügelt  Bevor ich noch ein paar Fragen habe, möchte ich das hier mal zusammenfassen, dann hat vielleicht auch ein zukünftiger Leser des Forums noch einen Mehrwert davon. Und vielleicht ist jemand so nett und berichtigt mich, wenn ich etwas grundlegendes nicht richtig verstanden habe 

*Long-Polling:* AJAX-Requests werden an den Server geschickt. Wenn neue Information verfügbar ist, wird diese direkt zurück geschickt. Ist keine neue Information verfügbar, verändert sich das Vorgehen im Vergleich zu klassischen AJAX-Requests: Anstatt dass die (meistens nutzlose) Antwort geschickt wird, dass keine neuen Informationen verfügbar sind, wartet der Server mit der Antwort, bis neue Information eintrifft und sendet erst dann eine Antwort. Der Client schickt sofort wieder eine Anfrage und das Spiel beginnt von vorn.

*Observer-Pattern:* Ein Beobachtendes Objekt ("Observer") registriert sich bei einem zu beobachtenden Objekt ("Subject"). Das Subject speichert alle Observer in einer Liste. IdR implementieren die Observer ein Interface, das eine Methode zur Aktualisierung des Observer-Objekts beinhaltet. Ändert sich etwas am Subject, werden alle Observer über die Aktualisierungsfunktion über die neuen Informationen unterrichtet. 

*Java RMI (Remote Method Invocation):* Die Kommunikation zwischen Client und Server funktioniert so, als seien beide in der selben JVM (Java Virtual Machine). Client und Server implementieren beide Methoden, die der jeweils andere aufrufen kann / soll. Damit das JVM-übergreifend funktioniert, implementieren Client und Server Stellvertretermethoden der aufrufbaren Methoden des jeweils anderen. Über die Stellvertretermethoden wird die Methode des Servers (oder vom Server aus die des Clients) so aufgerufen, als sei diese lokal vorhanden. Die Stellvertretermethode übernimmt dabei die Kommunikation zwischen Server und Client über das RMI Wire Protocol. Damit Methoden und Objekte von anderen Systemen aufrufbar sind, müssen diese sich bei einem Adressdienst registrieren. 



Das mit den Server-Sockets habe ich nicht ganz verstanden. Abstrakt gesagt öffnet man in Javascript eine Verbindung zum Server und überwacht diese auf Nachrichten vom Server, die Events in Javascript auslösen. Hat das denn eine relevante Alternative, wenn auf Clientseite eine Java-Applikation läuft und die Informationen nicht über den Web-Browser angezeigt werden? 

Das Obersver-Pattern ist vermutlich für die Kommunikation zwischen Client und Server nur relevant, wenn man es in Verbindung mit der RMI-Mechanik verwendet, oder sehe ich das falsch?

Vielen Dank schonmal an dieser Stelle für eure hilfreichen Antworten 

P.S.: Vielleicht als Randinfo interessant: ich arbeite an einer GUI eines Callcenters, das seine Daten von einem in Java geschriebenen Callcenter-Core im JSON-Format bezieht. Nun ist meine Aufgabe, alternative Kommunikationsmöglichkeiten zu finden und zu evaluieren.


----------



## tuxedo (20. Jul 2012)

> P.S.: Vielleicht als Randinfo interessant: ich arbeite an einer GUI eines Callcenters, das seine Daten von einem in Java geschriebenen Callcenter-Core im JSON-Format bezieht. Nun ist meine Aufgabe, alternative Kommunikationsmöglichkeiten zu finden und zu evaluieren.



Das hättest du wohl gleich zu Beginn erwähnen sollen.

Daraus ergeben sich ganz neue Frage:

1. Ist es angedacht bei Bedarf den Callcenter-Core um eine andere Schnittstelle als JSON (bis jetzt vermutlich über HTTP?) zu erweitern?

2. Das jetzige "GUI" ist eine Webanwendung? PHP, JSP/JSF, ...? Wenn ja: Muss das "neue" wieder eine Webanwendung sein?



Unter der Vorraussetzung dass der Callcenter-Core nicht angefasst werden darf/soll, sind die Möglichkeiten natürlich etwas eingeschränkt. RMI und Jboss Remoting fallen weg, da JSON hier nicht ins Konzept passt. Dinge wie MINA wohl auch (ich geh davon aus dass der Core JSON via HTTP ausliefert, da macht es keinen Sinn MINA einzusetzen).


----------



## raptor09 (20. Jul 2012)

tuxedo hat gesagt.:


> 1. Ist es angedacht bei Bedarf den Callcenter-Core um eine andere Schnittstelle als JSON (bis jetzt vermutlich über HTTP?) zu erweitern?



Mir sind in diesem Punkt alle Freiheiten gegeben. Ich liebäugel momentan mit Java RMI, da sich das nach einiger Recherche sehr vielversprechend anhört und sich anbietet, da der Callcenterclient und -core beide in Java geschrieben sind. 




> 2. Das jetzige "GUI" ist eine Webanwendung? PHP, JSP/JSF, ...? Wenn ja: Muss das "neue" wieder eine Webanwendung sein?



Das jetzige GUI ist eine Webanwendung, das neue GUI ist bisher ein normales Java-Programm, mit Verwendung des JAvaFX-Frameworks. Es ist nach meinem Informationsstand möglich, eine JavaFX-Anwendung in den Browser auszuführen. Wie genau das geht, da habe ich mich bisher nur flüchtig informiert, aber die Sprache des GUI bleibt Java mit JavaFX. 


Den Callcenter Core selbst fasse ich nicht an, ich simuliere diesen, in dem ich mir einen eigenen Mini-Core bastle. Meine Aufgabe ist es auch nicht, dass das GUI später voll implementiert wird, sondern einen Prototyp zu bauen, der es möglich macht, die neue GUI zu testen. Dabei geht es eben auch um alternative Kommunikationsmöglichkeiten, weg vom "klassischen" Pull-Mechanismus, also dem normalen AJAX-Request. 
Von diesen Alternativen soll ich 1-2 prototypisch implementieren, um dann eine Evaluation und einen Vergleich zur aktuellen IST-Situation durchführen zu können.

Mein Favorit ist wie gesagt Java RMI. Auch in Verbindung mit dem Observer Pattern ließe sich da sicherlich eine Interessante Alternative bauen, oder was meint ihr? 

Vielen Dank euch schonmal!


----------



## tuxedo (20. Jul 2012)

Hört sich ganz interessant an. Interessant finde ich vor allem dass ihr offenbar vom Webinterface zu einer "Desktop" Anwendung wollt (ich rechne jetzt mal eine JavaFX Anwendung im Browser ebenfalls zur Desktop-Anwendung). In vielen anderen Bereichen möchte man nämlich weg von der Desktop-Anwendung hin zur Webanwendung. 

Zu RMI:

RMI ist nur eine mögliche RPC Implementierung. Daneben gibt's auch noch andere mit weiteren Vor- und Nachteilen. Schau mal in meine Signatur oder google mal nach RPC.


----------



## raptor09 (20. Jul 2012)

Hallo Tuxedo, 

über den Link in deiner Signatur bin ich auf SIMON gestoßen, und es hat mich zugegebenermaßen neugierig gemacht. 
Bist du der Autor dieses Projekts?

Falls nein, du scheinst auf jeden Fall einen guten Draht dazu zu haben, vielleicht kannst du mir dazu ein paar Fragen beantworten. 

Meine Benutzung von SIMON fiele ja nicht unter die GPL-Lizenz. Besteht für mich trotzdem die Möglichkeit, das ganze mal auszuprobieren und zu testen? 
Da ich mich noch in der Ausbildung befinde wird mein Arbeitgeber sicherlich nicht, nur weil ich diese kommunikationsmöglichkeit mal ausprobieren möchte, bereit sein, die Katze im Sack zu kaufen, ohne dass wir wissen, ob das wirklich die Lösung für uns wäre.


----------



## tuxedo (20. Jul 2012)

Jepp, ich bin der Autor. Sost hätte ich's wohl weniger in meiner Signatur verlinkt.

Support gibt's eigentlich nur über's Support-Forum. Aber um die wichtigsten Fragen schnell zu klären:



> Meine Benutzung von SIMON fiele ja nicht unter die GPL-Lizenz.



Keine Ahnung. Die GPL sagt nur: Wenn du das Programm weitergibst, dann musst du das Programm zusammen mit den Quellen und den von GPL geforderten Rechten weitergeben.

Wenn die Callcenter-Software ein Firmeninternes Produkt ist, das von der Firma für die Firma entwickelt wurde, wird das Programm ja nicht weitergegeben. Dann kannst du die GPL Lizenz nutzen. 

Wenn das Programm aber von einer Firma für das Callcenter entwickelt wird, dann musst du entweder die GPL einhalten und die Sourcen mitgeben/veröffentlichen, oder eben eine kommerzielle Lizenz erwerben.



> Besteht für mich trotzdem die Möglichkeit, das ganze mal auszuprobieren und zu testen?



Ausprobieren und testen geht mit der GPL in jedem Fall. 



> Da ich mich noch in der Ausbildung befinde wird mein Arbeitgeber sicherlich nicht, nur weil ich diese kommunikationsmöglichkeit mal ausprobieren möchte, bereit sein, die Katze im Sack zu kaufen, ohne dass wir wissen, ob das wirklich die Lösung für uns wäre.



Mir scheint du solltest mal recherchieren wie die GPL funktioniert und was dahinter steckt. Wikipedia ist hier ein erster guter Anhaltspunkt. Im Netz gibt's auszugsweise ein Buch das die GPL erklärt: Die GPL kommentiert und erklärt Online-Version

Weitere Fragen darfst du gerne stellen. Aber dann bitte im Support-Forum. Dann haben andere Hilfesuchende auch etwas davon.

Gruß
Alex


----------

