Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Java EE 7: Web Services

Pfad-Parameter verwenden

Testen Sie unsere 2016 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
WebSocket-Endpoints können Parameter auf der Ebene von aufgerufenen URLs definieren, die es möglich machen, die gleiche Basis-Adresse für unterschiedliche Funktionalitäten zu verwenden - etwa, um Chaträume bereit zu stellen.

Transkript

Es kann vorkommen, dass man gerne in dem eigentlichen Pfad zu einem WebSocket Endpoint zusätzliche Parameter mit übergeben möchte. Denken Sie an ein Chatsystem, wo wir unter demselben Stammpfad verschiedene Räume definieren wollen. In diesem Video werden wir uns den dahinterliegenden Mechanismus auf Serverseite anschauen, der es uns erlaubt, solche Pfad-Parameter zu verarbeiten. Pfad-Parameter können nämlich als Platzhalter definiert werden und zwar geschieht dies auf Ebene der @ServerEndpoint-Annotation. Zu diesem Zweck wird auf Ebene der Annotation einfach der entsprechende Pfad-Parameter in geschweiften Klammern hinter den eigentlichen festen Pfad geschrieben. Der Parameter room-name in diesem Fall ist ein dynamischer Parameter, der vom Client angegeben wird, wenn er sich mit dem Endpoint verbindet. Einen derart übergebenen Parameter können wir auch wieder auswerten. Und zwar geschieht das auf Ebene der Methoden in Form einer @PathParam-Annotation. Mit deren Hilfe kann ich die Information, die in diesem Parameter steht, dann in eine Variable übergeben. In diesem Beispiel wird der Parameter roomName an den Pfad Parameter “room-name“ gebunden. Das bedeutet, wenn in der URL ein entsprechender Parameter steht, also beispielsweise Lobby oder Java, der möglicherweise einen Chatraum kennzeichnen könnte, dann wird die Variable roomName hinterher den Wert Lobby oder Java eben haben. Die Verwaltung dieser Parameter obliegt dem Server, es gibt da keinen Mechanismus. Sie werden sich fragen, wozu muss ich die verwalten? Sie werden mir ja in der URL mit übergeben und ich kann sie zuweisen. Nun, das Problem, was wir haben, sind die Sessions der Benutzer. Wenn ich diese Informationen beispielsweise dazu benutzen möchte, um die Sessions voneinander zu trennen, um bei diesem Chatbeispiel zu bleiben, jedem Chatraum immer nur die Liste der aktive Benutzer zuzuweisen, dann muss ich das in irgendeiner Art und Weise gruppieren. Diese Logik muss ich selber leisten. Das bedeutet, eine fertige Implementierung gibt es dafür nicht. Im Folgenden werden wir uns einmal anschauen, wie wir mit Pfad-Parametern arbeiten können und ich zeige Ihnen auch, wie Sie die angesprochene Gruppierung der Sessions umsetzen können. Wir befinden uns hier auf Ebene eines serverseitigen Endpoints. Dieser Server Endpoint soll zukünftig einen dynamischen Bestandteil haben, nämlich den von mir gerade markierten Teil. Deswegen füge ich hier einen Path-Parameter ein, nämlich room-name. Bisher ist es so, dass der Parameter chatRoom fix war und zwar auf dem Wert Lobby. Das habe ich nun geändert und nun muss ich, bei den entsprechenden Methoden, immer einen Parameter chatRoom mit übergeben und den lasse ich anhand des Path-Parameters mir übergeben. Das ist zum Glück schnell implementiert und ich kann auf diese Art und Weise die Implementierung auch einfach kopieren und spare mir dadurch viel Zeit. Nun hat jede dieser Methoden die Möglichkeit, auf den entsprechenden Pfad-Parameter zuzugreifen. Was ich Ihnen ebenfalls versprochen habe zu zeigen, ist die Gruppierung der Sessions. Die erledige ich, indem ich hier eine Map vom Typ String String hält dann den eigentlichen Chatraum mit einem Set vom Typ Session kombiniere. Das bedeutet, ich halte eine Liste von Chaträumen vor und jede dieser Listen beinhaltet dann wieder untergeordnet eine Liste der zugewiesenen Sessions. Es gibt hier eine Hilfsmethode namens getSessionsForRoom, da gebe ich den jeweiligen Chatraum mit ein und dann wird geschaut, welche Sessions es in diesem Raum gibt und wenn die Sessions noch nicht existieren, weil der Raum zum Beispiel gerade erst angelegt wird, dann wird ein entsprechender Eintrag angelegt und in die Verwaltung mit hineingespielt. Auf die Art und Weise haben wir diesen Server Endpoint so gestaltet, dass er mit unterschiedlichen dynamische Pfaden klarkommen kann und die Sessions, die auf dies unterschiedlichen dynamischen Pfade zugreifen, haben wir gruppiert. Nun können wir uns einmal der JavaScript-seitigen Implementierung auf der Client Ebene widmen und uns anschauen, wie wir dort mit diesem dynamischen Namen sinnvoll umgehen. Ich habe hier ein JavaScript bereits vorbereitet. Beim Aufruf dieser Funktionalität wird eine Methode registerRoom aufgerufen. Diese Methode registerRoom ist hier definiert und zwar wird hier ein Raumname übergeben. Dieser Raumname wird dann in der anzusprechenden Adresse entsprechend mitverarbeitet, das heißt, er wird hinten dran an das Suffix chatroom geklemmt. Nun wird der WebSocket eingerichtet und die entsprechenden Methoden werden überschrieben. Wir geben zuletzt eine kleine Meldung aus, dass wir den Raum, den wir gerade eben übergeben bekommen haben, dann auch betreten hätten. Die Auswahl der Räume ist mithilfe eines HTML Select Elements auf Seiten der HTML Seite implementiert. Das HTML Select Element hat die ID “#room“ und ich reagiere hier auf eine Änderung der Auswahl und zwar mit Hilfe der jQuery Funktion change. In dem Fall, wenn sich also die Auswahl ändert, lese ich den aktuellen Raum aus dem Select Element aus und registriere mich danach für den neuen Raum, in dem ich die eben besprochene Methode registerRoom noch einmal aufrufe und dann hier die entsprechend neue Adresse anspringe. Auf die Art und Weise habe ich ein dynamisches System geschaffen. Ändert der Benutzer den Chatraum, dann wird der entsprechende, gegebenenfalls neue WebSocket Endpoint aufgerufen und die Session wird dort an diesen Raum gebunden. Das Ganze bleib so lange aktiv, bis der Benutzer entweder die Verbindung trennt oder aber den Raum verlässt. Nun können wir uns das auf Ebene der HTML Seite einmal in Aktion ansehen. ch habe die Webapplikation gestartet und bereits einen Browser aufgerufen. Hier kann ich nun mich für einen Raum registrieren und eine Nachricht hinterlegen. Die erscheint dann in diesem Raum. Wenn ich nun den Raum wechsle, dann ist das völlig problemlos möglich, auch hier kann ich jetzt eine Nachricht hinterlassen. Das können wir ganz gut beobachten, indem wir diesen Chatroom noch mal aufrufen mit einem zweiten Browser. Und wenn wir jetzt hier eine Nachricht hinterlassen, dann ist diese Nachricht für diesen Benutzer sichtbar, aber nicht für den anderen Benutzer, der sich im Chatraum Java befindet. Gehe ich zurück in die Lobby und hinterlasse dort eine Nachricht, ist sie nun auch für den anderen Benutze, der sich im selben Raum befindet,sichtbar. Sie sehen, die Verwaltung der Sessions in Abhängigkeit von dem angesprochenen Chatraum, das ist ja letztlich mit einer URL umgesetzt, funktioniert völlig problemlos. Dasselbe Prinzip können wir dann auch auf der Java Ebene nutzen. Sehen wir uns nun einmal ganz kurz eine Java Konsolen Implementierung an, die auch mit unterschiedlichen Chaträumen klarkommen kann. Wir sehen hier einen Konsolen Client. Dieser Konsolen Client ist natürlich etwas spartanisch, genauso wie es eben mit einer Applikation, die über die Konsole läuft, der Fall ist. Die Auswahl eines Chatraums ist hier nicht so interaktiv möglich, sondern beim Aufruf, beim Start dieses Clients, wird entweder der Chatraum mit übergeben oder aber er wird standardmäßig auf Lobby gesetzt. Auch hier wird die Adresse dynamisch zusammengebaut, der jeweils übergebenen Chatraum hängt hinten dran an dieser Adresse. Wenn ich nun einmal diesen Client starte, lande ich automatisch auf im Raum Lobby. Hier kann ich eine Nachricht hinterlegen, zunächst gebe ich mein Name ein, und nun kann ich die Nachricht hinterlegen. Die anderen Benutzer, die sich in diesem Raum befinden, sehen nun ebenfalls diese Nachricht und können mir darauf antworten. Ich bekomme die entsprechende Ausgabe. Wenn ich nun diesen Client wieder mit einer anderen Information starte, indem ich hier das Kommandozeilenargument Java übergebe, dann wechselt der Client automatisch in den Chatraum java. Hier eingegebene Nachrichten werden nun nur für Leute sichtbar, die sich auch im Chatroom Java befinden. Die entsprechende Kommunikation funktioniert auch hier, als Vergleich noch einmal eine weitere Nachricht, die dann hier auch erscheint, aber die nicht bei dem Benutzer erscheint, der sich im Chatraum Lobby befindet. Sie sehen, das Verarbeiten von Pfad-Parametern funktioniert sehr entspannt. Wir müssen diese lediglich einmal auf Ebene unseres Server Endpoints definieren und können danach an den entsprechenden Stellen im Code die Zuweisung dann vornehmen, mithilfe der @PathParam-Annotation. Mehr ist eigentlich gar nicht zu tun, um Pfad-Parameter einsetzen zu können. Der Rest der Arbeit obliegt dem Client, die müssen die entsprechende Logik implementieren.

Java EE 7: Web Services

Steigen Sie ein in die Java-Enterprise-Welt und lernen Sie, wie Nachrichten ausgetauscht und Dienste definiert werden.

5 Std. 13 min (30 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!