Rufen Sie uns nicht an, wir rufen Sie an!
Server-Sent Events und WebSockets im Java Enterprise Umfeld
Sebastian Reiners
op...
Inhalt
1. HTTP: Wer nicht fragt bleibt dumm
2. Alternative Ansätze
3. Server-Sent Events
4. WebSockets
5. Probleme beim Ei...
Funktionsweise von HTTP
• Klassische Funktionsweise des Web:
1. Client stellt Anfrage an Server
2. Server verarbeitet Anfr...
Funktionsweise von HTTP
• Standard-Verhalten, seit es HTTP gibt (seit 1991)
• Dokumenten-basiert
• ein Request => ein neue...
Es kommt Bewegung rein
• sehr starres Konstrukt
• Dynamik? 
• Wechsel von Dokumenten zu Anwendungen im Web
• zunächst mit...
Asynchrone Requests
• Auflockern, noch kein Aufbrechen
• lösen vom dokumenten-basierten Ansatz
• Übertragung von
• ... Tei...
Asynchrone Requests
• Vorteile asynchroner Requests:
• mehr Dynamik in Webseiten
• geringeres Datenvolumen im Transport
• ...
Asynchrone Requests
• in vielen Fällen immer noch unpraktisch
• Was ist bei Änderungen auf Serverseite?
• Änderungen könne...
Welche Ansätze gibt es?
• zeitlich getaktet, immer wieder beim Server anfragen
• Wie kurz takte ich?
• über Applets
• Long...
Welche Ansätze gibt es?
• Nachteile:
• haben Sicherheitsprobleme
• holprige Integration mit dem Rest der Seite
• benötigen...
Wäre doch schön wenn ...
... der Server von sich aus
Bescheid sagen könnte.
Server-Sent Events und WebSockets
• beides standardisiert durch das W3C
• beides in Java Webanwendungen einsetzbar
• Serve...
Server-Sent Events
• Client "registriert" sich beim Server
• kann danach vom Server "Events" empfangen
• Event-Nachrichten...
Server-Sent Events
• in vielerlei Hinsicht ähnlich zu Longpolling Verfahren
• allerdings fehlender Ab-/Aufbau der Verbindu...
Server-Sent Events - Client
var source = new EventSource('/sse_xyz');
source.onmessage = function(event) {
if (event.type ...
Server-Sent Events - Server
• Gibt es einen JSR für Server-Sent Events?
• Nein, brauchen wir aber auch nicht. 
• Die Stan...
Server-Sent Events - Server
@WebServlet(urlPatterns={"/sse_xyz"})
public class SSEServlet extends HttpServlet {
@Override
...
Server-Sent Events
• möglich mit jedem Servlet-Container
• keine Unterstützung durch IE / Edge
• bringen u.U. Skalierungsp...
WebSockets
• bidirektionale Kommunikation
• sowohl Client als auch Server können selbstständig
Nachrichten schicken
• Clie...
WebSocket - Handshake
GET /chat/connect HTTP/1.1
Host: localhost:8080
Accept: text/html,application/xhtml+xml,application/...
WebSocket - Handshake
HTTP/1.1 101 Switching Protocols
Origin: http://localhost:8080
Upgrade: WebSocket
Sec-WebSocket-Acce...
WebSockets
• die mächtigste der hier vorgestellten
Kommunikationsarten
• kann alles erfüllen, was über Server-Sent Events ...
WebSockets – JavaScript Client
var socket = new WebSocket("ws://host:8080/path/");
socket.onopen = function(event) {...}
s...
WebSockets - Serverseite
• Gibt es dazu einen JSR? (Oder braucht man ihn hier
auch nicht?)
• Ja, gibt es. JSR 356
• Seit J...
WebSockets - Serverseite
• WebSocket Unterstützung schon vor JSR
• große Unterschiede in der Umsetzung
• sehr rudimentär: ...
WebSockets - Serverseite
• Wie funktioniert das denn nun?
• Zwei Ansätze:
• Interface-basiert
• Annotation-basiert
WebSockets - Serverseite
• (nahezu) beliebige POJOs als Endpoint
• @ServerEndpoint("/pathForEndpoint")
• @OnOpen an Method...
WebSockets - Serverseite
• @OnClose an Methoden für Verbindungsabbau
• mit folgender Signatur:
public void method(Session ...
WebSockets - Serverseite
• @OnMessage an Methode, die auf Client-Nachrichten
reagieren soll
• Signatur
public void method(...
WebSockets - Serverseite
• Für Textnachrichten:
• String, Java Primitives
• Reader
• Für Binärnachrichten:
• byte[],
• Byt...
WebSockets – Ein einfaches Beispiel
• Genug Theorie ;-)
• Angenommen wir wollen folgenden Service schreiben:
• Erreichbar ...
WebSockets – Ein einfaches Beispiel
@ServerEndpoint("/upper")
public class MySocketEndpoint {
@OnOpen
public void open(Ses...
WebSockets – Ein einfaches Beispiel
@OnMessage
public void sendUpper(String message, Session se) {
for(Session session : s...
WebSockets – Abseits von Text und Bytes
• Was wenn ich nicht auf Text- oder Binärdaten arbeiten
will?
• Decoder und Encode...
Abseits von Text und Bytes - Encoder
public interface Encoder {
void init(EndpointConfig var);
void destroy();
[...]
publi...
Abseits von Text und Bytes - Decoder
public interface Decoder {
void init(EndpointConfig var);
void destroy();
[...]
publi...
WebSockets – Abseits von Text und Bytes
public class Converter implements Decoder.Text<Message>,
Encoder.Text<Message> {
p...
WebSockets – Abseits von Text und Bytes
• Wie geschieht die Anbindung an den Endpoint?
@ServerEndpoint(value="/endpoint",
...
WebSockets – Ist das schon alles?
• Streaming-Unterstützung
• Encoder.TextStream, Decoder.TextStream
• Reader bzw. Writer
...
WebSockets – Ist das schon alles?
• Pfad-Parameter
• ähnlich wie man es aus REST APIs gewohnt ist
@ServerEndpoint("path/{p...
WebSockets – Ist das schon alles?
• Java-Client:
@ClientEndpoint
public class WebsocketClientEndpoint {
private MessageHan...
Einsetzbarkeit im Java EE Bereich
Okay ... Möglich ist das alles ...
Aber geht das auch wirklich gut?
Einsetzbarkeit im Java EE Bereich
• Server-Sent Events:
• ältere, bewährte Technologie-Basis
• Technologie immer noch Grun...
Einsetzbarkeit im Java EE Bereich
• WebSockets:
• neuer JSR
• Unterstützung durch alle neueren Browser
• ggf. Alternative ...
Wo ist das Problem mit CDI?
@ServerEndpoint("/ws_connect")
public class MyEndpoint {
@Inject
@SessionScoped
private MySess...
Wo ist das Problem mit CDI?
• Warum nicht aktiv? Wir haben doch eine Session ... Ô_ó
• Ja, aber ...
• im Web-Container geb...
Die ServerEndpoint Konfiguration
public class SessionAccessConfig extends
ServerEndpointConfig.Configurator {
@Override
pu...
Die ServerEndpoint Konfiguration
@ServerEndpoint(value="/upper",
configurator=SessionAccesConfig.class)
public class MySoc...
Was bringt mir das alles?
• stärkeres "Feeling" einer Desktopanwendung
• zunächst immenser Geschwindigkeitsgewinn
• höher,...
Fazit
• WebSockets und Server-Sent Events in modernen
JavaEE Umgebungen einsetzbar
• schwer mit JSF und CDI integrierbar
•...
Fazit
• beides wird nicht "die Welt verändern"
• Server-Sent Events:
• mangelnde Unterstützung durch IE
• WebSockets:
• hä...
Fazit
• sind eine interessante Ergänzung
• läuft neben klassischen Enterprise Anwendungen
• wenn es auf Geschwindigkeit an...
Fragen?
Vielen Dank
Sebastian Reiners
open knowledge GmbH
www.openknowledge.de
facebook.com/openknowledge
twitter.com/_openknowled...
Nächste SlideShare
Wird geladen in …5
×

Rufen Sie nicht an – wir rufen Sie an! | Server-sent Events und Web-Sockets im Java EE-Umfeld

612 Aufrufe

Veröffentlicht am

Speaker: Sebastian Reiners

Seit Java EE 7 stehen auch Enterprise-Entwicklern Server-Sent Events und WebSockets in standardisierter Form zur Verfügung. Höchste Zeit also, sich diese andere Art der Kommunikation im Web einmal näher anzusehen. Was sind Server-Sent Events und WebSockets überhaupt, was sind ihre Vorteile und wo bieten sich sinnvolle Anwendungsbereiche?

Im Rahmen der Vorstellung der unterschiedlichen Ansätze werden praktische Erfahrungen und Fallstricke, insbesondere im Zusammenspiel mit JSF und CDI veranschaulicht, sowie ein erstes Resümee gezogen.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
612
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
5
Aktionen
Geteilt
0
Downloads
4
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Clientscript als Ausgangsbasis
  • Request/Response -> in den Hintergrund geschoben
  • Bayeux-Protokoll durch Dojo-Foundation
    Skalierung: konventionelle Servlet Engines sind nicht unbedingt darauf ausgelegt Requests so lange offen zu halten
  • WebSocket Protokoll setzt auf TCP auf

    Anfangen mit Server-Sent Events
  • kein erneuter Ab-/Aufbau => weniger Delay
  • Natürlich nicht von sich aus
  • Collaboration: Etherpad als Beispiel
  • Grizzly API beim Glassfish
    Jetty mit "spezialisierten" Servlets
  • Interface-Ansatz: javax.websocket.Endpoint implementieren
    Warum Interface weniger schön: MessageHandler in onOpen registrieren
  • OnOpen und OnClose als Pendants zu den jeweiligen JavaScript Event-Handlern
    @PathParam => vielen vllt. aus REST bekannt
    für andere: später im Detail
  • WAS FÜR VARIABLE PARAMETER?
  • Etwas sinnfreie OnOpen und OnClose Methoden
  • Worauf muss ich achten? Gibt es Pitfalls?
  • neuer JSR: schon unterstützt durch die Server-Umgebung?
  • ApplicationScoped funktioniert
    Request und SessionScoped machen Probleme
  • Normalerweise die Servlet API aus der WebSocket API rauslassen
  • modern: Ohne ältere Browser, bei WebSockets: neuer JavaEE Stack
    Alternative: proprietäre Lösungen

    Umdenken => anderes Konzept =>
  • CRUD => setzt nur bedingt komplexere Kommunikationsmuster vorraus
    Low-Level => vieles muss man selber On-Top implementieren
  • Vor zweitem Klick: Wenn meine Rahmenbedingungen passen:
  • Rufen Sie nicht an – wir rufen Sie an! | Server-sent Events und Web-Sockets im Java EE-Umfeld

    1. 1. Rufen Sie uns nicht an, wir rufen Sie an! Server-Sent Events und WebSockets im Java Enterprise Umfeld Sebastian Reiners open knowledge GmbH
    2. 2. Inhalt 1. HTTP: Wer nicht fragt bleibt dumm 2. Alternative Ansätze 3. Server-Sent Events 4. WebSockets 5. Probleme beim Einsatz mit JavaEE 6. Fazit
    3. 3. Funktionsweise von HTTP • Klassische Funktionsweise des Web: 1. Client stellt Anfrage an Server 2. Server verarbeitet Anfrage 3. Server schickt Antwort 4. Client verarbeitet Antwort • Motto: Wer nicht fragt bleibt dumm. <= Request <= Response
    4. 4. Funktionsweise von HTTP • Standard-Verhalten, seit es HTTP gibt (seit 1991) • Dokumenten-basiert • ein Request => ein neues Dokument • zugeschnitten auf damaligen Verwendungszweck • Austausch von Dokumenten >
    5. 5. Es kommt Bewegung rein • sehr starres Konstrukt • Dynamik?  • Wechsel von Dokumenten zu Anwendungen im Web • zunächst mit synchroner Verarbeitung • nächster, großer Schritt: Auflockern des Request/Response Cycles • unterstützt durch clientseitige Skript-Sprache • Asynchronous JavaScript and XML
    6. 6. Asynchrone Requests • Auflockern, noch kein Aufbrechen • lösen vom dokumenten-basierten Ansatz • Übertragung von • ... Teildokumenten • ... dokumentenunabhängiger Information • 1998 durch Microsoft angestoßen worden • 2006 durch W3C standardisiert als XMLHttpRequest
    7. 7. Asynchrone Requests • Vorteile asynchroner Requests: • mehr Dynamik in Webseiten • geringeres Datenvolumen im Transport • Loslösung von reiner Formularverarbeitung • Es ist aber immer noch das Request/Response Prinzip!
    8. 8. Asynchrone Requests • in vielen Fällen immer noch unpraktisch • Was ist bei Änderungen auf Serverseite? • Änderungen können erst bei nächster Anfrage mitgeteilt werden. • zeitliche Verzögerung
    9. 9. Welche Ansätze gibt es? • zeitlich getaktet, immer wieder beim Server anfragen • Wie kurz takte ich? • über Applets • Longpolling • Grundlage: langlaufende Requests • wiederholter, erneuter Aufbau
    10. 10. Welche Ansätze gibt es? • Nachteile: • haben Sicherheitsprobleme • holprige Integration mit dem Rest der Seite • benötigen ein weiteres Protokoll, aufsetzend auf HTTP • Skalierungsprobleme
    11. 11. Wäre doch schön wenn ... ... der Server von sich aus Bescheid sagen könnte.
    12. 12. Server-Sent Events und WebSockets • beides standardisiert durch das W3C • beides in Java Webanwendungen einsetzbar • Server-Sent Events: unidirektional • über eine HTTP Connection • WebSockets: bidirektional • über eine Socket-Verbindung
    13. 13. Server-Sent Events • Client "registriert" sich beim Server • kann danach vom Server "Events" empfangen • Event-Nachrichten haben ein bestimmtes Format: event:addn data:1500n data:600n n • Übermittlung mittels HTTP
    14. 14. Server-Sent Events • in vielerlei Hinsicht ähnlich zu Longpolling Verfahren • allerdings fehlender Ab-/Aufbau der Verbindung • gut geeignet für beständige Aktualisierungen • Aktienkurse • Newsfeeds • wann immer der Client lange warten müsste
    15. 15. Server-Sent Events - Client var source = new EventSource('/sse_xyz'); source.onmessage = function(event) { if (event.type === 'add') { ... } else if (event.type === 'remove') { ... } } ... source.close();
    16. 16. Server-Sent Events - Server • Gibt es einen JSR für Server-Sent Events? • Nein, brauchen wir aber auch nicht.  • Die Standard Servlet API ist bereits vollkommen ausreichend.
    17. 17. Server-Sent Events - Server @WebServlet(urlPatterns={"/sse_xyz"}) public class SSEServlet extends HttpServlet { @Override protected void doGet( HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException { res.setContentType("text/event-stream"); res.setCharacterEncoding("UTF-8"); PrintWriter writer = res.getWriter(); ... writer.write("data: " + msg + "nn"); writer.flush(); } }
    18. 18. Server-Sent Events • möglich mit jedem Servlet-Container • keine Unterstützung durch IE / Edge • bringen u.U. Skalierungsprobleme mit sich
    19. 19. WebSockets • bidirektionale Kommunikation • sowohl Client als auch Server können selbstständig Nachrichten schicken • Client "registriert" sich beim Server • Request über "ws://" bzw. "wss://" • Handshake über HTTP • Danach eigentlicher Protokollwechsel
    20. 20. WebSocket - Handshake GET /chat/connect HTTP/1.1 Host: localhost:8080 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Sec-WebSocket-Version: 13 Origin: http://localhost:8080 Sec-WebSocket-Extensions: permessage-deflate Sec-WebSocket-Key: M+Le93PunXLSl33Vpip98Q== Connection: keep-alive, Upgrade Upgrade: websocket
    21. 21. WebSocket - Handshake HTTP/1.1 101 Switching Protocols Origin: http://localhost:8080 Upgrade: WebSocket Sec-WebSocket-Accept: zH6VNxS6o1H/X1ZRqv4a213BanQ= Connection: Upgrade Sec-WebSocket-Location: ws://localhost:8080/chat/connect Content-Length: 0
    22. 22. WebSockets • die mächtigste der hier vorgestellten Kommunikationsarten • kann alles erfüllen, was über Server-Sent Events möglich ist • hat einen zusätzlichen Kanal für Nachrichten des Clients • gut geeignet für: • Chats • Collaboration-Tools
    23. 23. WebSockets – JavaScript Client var socket = new WebSocket("ws://host:8080/path/"); socket.onopen = function(event) {...} socket.onmessage = function(event) { alert("Received message: "+event.data); } socket.onclose = function(event) {...} socket.send("Message-Inhalt"); ... socket.close();
    24. 24. WebSockets - Serverseite • Gibt es dazu einen JSR? (Oder braucht man ihn hier auch nicht?) • Ja, gibt es. JSR 356 • Seit Java EE 7 verfügbar • Server-Support: • Glassfish 4 • Wildfly 8 • Jetty 9.1 • ...
    25. 25. WebSockets - Serverseite • WebSocket Unterstützung schon vor JSR • große Unterschiede in der Umsetzung • sehr rudimentär: Glassfish • sehr weit fortgeschritten Jetty • Umsetzung des JSR => Jetty-Version + • Ein-/Ausgabe Konverter • Standardisierte Schnittstelle zum Versand von Text, Binärdaten, usw.
    26. 26. WebSockets - Serverseite • Wie funktioniert das denn nun? • Zwei Ansätze: • Interface-basiert • Annotation-basiert
    27. 27. WebSockets - Serverseite • (nahezu) beliebige POJOs als Endpoint • @ServerEndpoint("/pathForEndpoint") • @OnOpen an Methoden für Verbindungsaufbau • mit folgender Signatur: public void method(Session session, EndpointConfig cfg, @PathParam(...) String param)
    28. 28. WebSockets - Serverseite • @OnClose an Methoden für Verbindungsabbau • mit folgender Signatur: public void method(Session session, CloseReason reason, @PathParam(...) String param)
    29. 29. WebSockets - Serverseite • @OnMessage an Methode, die auf Client-Nachrichten reagieren soll • Signatur public void method([Variiert] message, Session session, @PathParam(...) String param)
    30. 30. WebSockets - Serverseite • Für Textnachrichten: • String, Java Primitives • Reader • Für Binärnachrichten: • byte[], • ByteBuffer
    31. 31. WebSockets – Ein einfaches Beispiel • Genug Theorie ;-) • Angenommen wir wollen folgenden Service schreiben: • Erreichbar unter ws://hostname:8080/chat/upper • Texte die hingeschickt werden, sollen Uppercase an alle Clients weitergeleitet werden, die verbunden sind
    32. 32. WebSockets – Ein einfaches Beispiel @ServerEndpoint("/upper") public class MySocketEndpoint { @OnOpen public void open(Session newSession) { System.out.println("Open:"+newSession.getId()); } @OnClose public void close(Session closedSession) { System.out.println("Close:"+closedSession.getId()); }
    33. 33. WebSockets – Ein einfaches Beispiel @OnMessage public void sendUpper(String message, Session se) { for(Session session : se.getOpenSessions()) { try { session.getBasicRemote() .sendText(message.toUpperCase()); } catch (IOException | EncodeException e) { // Error handling } } } }
    34. 34. WebSockets – Abseits von Text und Bytes • Was wenn ich nicht auf Text- oder Binärdaten arbeiten will? • Decoder und Encoder um Ein- und Ausgabedaten in ein eigenes Objektmodell umzuwandeln • Bereitgestellte Interfaces: • Decoder.Text, Decoder.Binary • Encoder.Text, Encoder.Binary
    35. 35. Abseits von Text und Bytes - Encoder public interface Encoder { void init(EndpointConfig var); void destroy(); [...] public interface Text<T> extends Encoder { String encode(T var) throws EncodeException; } }
    36. 36. Abseits von Text und Bytes - Decoder public interface Decoder { void init(EndpointConfig var); void destroy(); [...] public interface Text<T> extends Decoder { T decode(String var) throws DecodeException; boolean willDecode(String var); } }
    37. 37. WebSockets – Abseits von Text und Bytes public class Converter implements Decoder.Text<Message>, Encoder.Text<Message> { public void destroy() {...} public void init(EndpointConfiguration conf) {...} public Message decode(String messageStr) {...} public String encode(Message message) {...} public boolean willDecode(String messageStr) {...} }
    38. 38. WebSockets – Abseits von Text und Bytes • Wie geschieht die Anbindung an den Endpoint? @ServerEndpoint(value="/endpoint", encoders=Converter.class, decoders=Converter.class) @OnMessage public void handleMessage(Message m, Session s) { for(Session session : s.getOpenSessions()) { session.getBasicRemote().sendObject(m); } }
    39. 39. WebSockets – Ist das schon alles? • Streaming-Unterstützung • Encoder.TextStream, Decoder.TextStream • Reader bzw. Writer • Encoder.BinaryStream, Decoder.BinaryStream • InputStream bzw. OutputStream
    40. 40. WebSockets – Ist das schon alles? • Pfad-Parameter • ähnlich wie man es aus REST APIs gewohnt ist @ServerEndpoint("path/{param}/endpoint") @OnMessage public void onMessage(String s, @PathParam("param") String par, Session session) {...}
    41. 41. WebSockets – Ist das schon alles? • Java-Client: @ClientEndpoint public class WebsocketClientEndpoint { private MessageHandler messageHandler; public WebsocketClientEndpoint(URI endpointURI) { try { WebSocketContainer container = ContainerProvider.getWebSocketContainer(); container.connectToServer(this, endpointURI); } catch (Exception e) {...} }
    42. 42. Einsetzbarkeit im Java EE Bereich Okay ... Möglich ist das alles ... Aber geht das auch wirklich gut?
    43. 43. Einsetzbarkeit im Java EE Bereich • Server-Sent Events: • ältere, bewährte Technologie-Basis • Technologie immer noch Grundlage vieler neuer APIs • keine letztendliche Integration mit JSF • keine Unterstützung durch Internet Explorer • auch nicht in neuen Versionen
    44. 44. Einsetzbarkeit im Java EE Bereich • WebSockets: • neuer JSR • Unterstützung durch alle neueren Browser • ggf. Alternative zu SSEs für Internet Explorer • keine letztendliche Integration mit JSF • unvollständige Integration mit CDI
    45. 45. Wo ist das Problem mit CDI? @ServerEndpoint("/ws_connect") public class MyEndpoint { @Inject @SessionScoped private MySessionObject mso; ... org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.SessionScoped
    46. 46. Wo ist das Problem mit CDI? • Warum nicht aktiv? Wir haben doch eine Session ... Ô_ó • Ja, aber ... • im Web-Container gebunden an HTTP-Session • WebSockets haben eigene Sessions, da nicht mehr HTTP • Komme ich irgendwie an die HTTP-Session ran? • Ja, wir haben ja den anfänglichen Handshake!
    47. 47. Die ServerEndpoint Konfiguration public class SessionAccessConfig extends ServerEndpointConfig.Configurator { @Override public void modifyHandshake(ServerEndpointConfig cfg, HandshakeRequest request, HandshakeResponse response) { HttpSession session = (HttpSession) request.getHttpSession(); cfg.getUserProperties().put("httpSession", session); } }
    48. 48. Die ServerEndpoint Konfiguration @ServerEndpoint(value="/upper", configurator=SessionAccesConfig.class) public class MySocketEndpoint { private String valueFromHttpSession = null; @OnOpen public void open(Session newSession, EndpointConfig cfg) { HttpSession httpSes = (HttpSession)cfg.getUserProperties .get("httpSession"); valueFromHttpSession = httpSes.getAttribute("xyz"); } ... }
    49. 49. Was bringt mir das alles? • stärkeres "Feeling" einer Desktopanwendung • zunächst immenser Geschwindigkeitsgewinn • höher, je mehr Nachrichten • bis zu 400% höher • relativiert sich, beim Einsatz "in freier Natur" • Netzlatenzen (lediglich 10% bis 25%)
    50. 50. Fazit • WebSockets und Server-Sent Events in modernen JavaEE Umgebungen einsetzbar • schwer mit JSF und CDI integrierbar • problemlos für kleine, losgelöste Features • als Anwendungs-Grundlage: Umdenken erforderlich
    51. 51. Fazit • beides wird nicht "die Welt verändern" • Server-Sent Events: • mangelnde Unterstützung durch IE • WebSockets: • häufig wird man gerade auf CDI nicht verzichten wollen • Low-Level Protokoll
    52. 52. Fazit • sind eine interessante Ergänzung • läuft neben klassischen Enterprise Anwendungen • wenn es auf Geschwindigkeit ankommt unschätzbar • sorgen für einen intuitiveren Ablauf von Kommunikation "Rufen Sie nicht den Server an, der Server ruft Sie an!"
    53. 53. Fragen?
    54. 54. Vielen Dank Sebastian Reiners open knowledge GmbH www.openknowledge.de facebook.com/openknowledge twitter.com/_openknowledge

    ×