© Excellent backgrounds/Shutterstock.com
Java Magazin
HTTP-Client-/Server-Eventkommunikation im Enterprise-Umfeld mithilfe von Comet

Lang lebe Comet …

Die WebSocket-Technologie ist in aller Munde, und ihr Einsatz verspricht eine Erleichterung im Umgang mit der asynchronen Programmierung und der quasi automatischen Benachrichtigung zwischen Client und Server im Webumfeld. Dieser Artikel beschreibt den pragmatischen Ansatz, wie die Client-/Server-Kommunikation auch ohne WebSockets realisiert werden kann.

Stavros Kamarianakis


Das Java Magazin berichtete in Ausgabe 5.2012 ausgiebig über die neue WebSocket-Technologie [1]. Das „automatische“ Updating von HTML-Feldern, wie z. B. Statusinformationen, Wertänderungen oder das Einblenden von Zusatzinformationen, die aufgrund eines eintreffenden Serverereignisses auf der Oberfläche eingeblendet werden müssen, werden so zum Kinderspiel. Anders als beim reinen HTTP-Request/Res­ponse-Zyklus, bleibt bei WebSocket die TCP-Verbindung zwischen dem Client (Browser) und dem Server offen. Deswegen können über diesen Kommunikationskanal Daten bidirektional ausgetauscht werden. Auch die Datenmenge, die zwischen Client und Server protokollbedingt übertragen wird, ist geringer als bei einer ­HTTP-Kommunikation. Doch diese neue Technologie hat noch einen kleinen Haken: Von den großen Applikationsserverherstellern gibt es nur wenige, die aktuell diese neue Technologie unterstützen. Es sind aber nicht nur Serverhersteller, die WebSockets unterstützen müssen, damit diese Technologie sinnvoll zum Einsatz kommen kann, sondern auch die Browserhersteller. Mit anderen Worten: WebSockets können nur dann eingesetzt werden, wenn sowohl Client als auch Server entsprechend mit dieser Technologie ausgerüstet sind.

Was ist aber, wenn in einem stark heterogenen Umfeld verschiedene und teilweise ältere Browserversionen eingesetzt werden? Oder was ist, wenn der Kunde mit der aktuellen Applikationsserverversion zufrieden ist und deshalb nicht auf eine neue Version aufrüsten möchte? Sollen wir mit unserer Implementierung so lange warten, bis sich der Kunde für einen Technologiewechsel entschieden hat? Folglich bleibt nichts anderes, als mit den gängigen und altbewährten Mitteln, wie z. B. Ajax, zu arbeiten, um einen „versteckten“ Datenaustausch zwischen Client und Server zu ermöglichen und so HTML-Elemente innerhalb einer Seite automatisch und benutzerfreundlich zu aktualisieren. In der Webanwendungsentwicklung werden in Verbindung mit der Ajax-Programmierung serverseitig meist zwei verschiedene Verfahren angewandt:

Das Polling-VerfahrenDas Long-Polling-Verfahren

Im Fall des Polling-Verfahrens fragt der Client den Server in periodischen Abständen ab, ob oder wie sich der Zustand des betroffenen Objekts oder der betroffenen Objekte geändert hat. Der Server antwortet sofort auf den Request. Somit kann der Client mit der empfangenen Response die für die Darstellung relevanten Daten extrahieren und auf der Oberfläche darstellen. Diese Vorgehensweise ist in der Regel sehr ei...

Java Magazin
HTTP-Client-/Server-Eventkommunikation im Enterprise-Umfeld mithilfe von Comet

Lang lebe Comet …

Die WebSocket-Technologie ist in aller Munde, und ihr Einsatz verspricht eine Erleichterung im Umgang mit der asynchronen Programmierung und der quasi automatischen Benachrichtigung zwischen Client und Server im Webumfeld. Dieser Artikel beschreibt den pragmatischen Ansatz, wie die Client-/Server-Kommunikation auch ohne WebSockets realisiert werden kann.

Stavros Kamarianakis


Das Java Magazin berichtete in Ausgabe 5.2012 ausgiebig über die neue WebSocket-Technologie [1]. Das „automatische“ Updating von HTML-Feldern, wie z. B. Statusinformationen, Wertänderungen oder das Einblenden von Zusatzinformationen, die aufgrund eines eintreffenden Serverereignisses auf der Oberfläche eingeblendet werden müssen, werden so zum Kinderspiel. Anders als beim reinen HTTP-Request/Res­ponse-Zyklus, bleibt bei WebSocket die TCP-Verbindung zwischen dem Client (Browser) und dem Server offen. Deswegen können über diesen Kommunikationskanal Daten bidirektional ausgetauscht werden. Auch die Datenmenge, die zwischen Client und Server protokollbedingt übertragen wird, ist geringer als bei einer ­HTTP-Kommunikation. Doch diese neue Technologie hat noch einen kleinen Haken: Von den großen Applikationsserverherstellern gibt es nur wenige, die aktuell diese neue Technologie unterstützen. Es sind aber nicht nur Serverhersteller, die WebSockets unterstützen müssen, damit diese Technologie sinnvoll zum Einsatz kommen kann, sondern auch die Browserhersteller. Mit anderen Worten: WebSockets können nur dann eingesetzt werden, wenn sowohl Client als auch Server entsprechend mit dieser Technologie ausgerüstet sind.

Was ist aber, wenn in einem stark heterogenen Umfeld verschiedene und teilweise ältere Browserversionen eingesetzt werden? Oder was ist, wenn der Kunde mit der aktuellen Applikationsserverversion zufrieden ist und deshalb nicht auf eine neue Version aufrüsten möchte? Sollen wir mit unserer Implementierung so lange warten, bis sich der Kunde für einen Technologiewechsel entschieden hat? Folglich bleibt nichts anderes, als mit den gängigen und altbewährten Mitteln, wie z. B. Ajax, zu arbeiten, um einen „versteckten“ Datenaustausch zwischen Client und Server zu ermöglichen und so HTML-Elemente innerhalb einer Seite automatisch und benutzerfreundlich zu aktualisieren. In der Webanwendungsentwicklung werden in Verbindung mit der Ajax-Programmierung serverseitig meist zwei verschiedene Verfahren angewandt:

Das Polling-VerfahrenDas Long-Polling-Verfahren

Im Fall des Polling-Verfahrens fragt der Client den Server in periodischen Abständen ab, ob oder wie sich der Zustand des betroffenen Objekts oder der betroffenen Objekte geändert hat. Der Server antwortet sofort auf den Request. Somit kann der Client mit der empfangenen Response die für die Darstellung relevanten Daten extrahieren und auf der Oberfläche darstellen. Diese Vorgehensweise ist in der Regel sehr ei...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang