D’année en année, les utilisateurs souhaitent voir les données de leurs applications évoluer en temps réel quelque soit la nature de l'application !! Malheureusement, le mode de communication HTTP classique a montré ses limites en termes d'interactions même que AJAX a permis quelques améliorations en terme de rafraîchissement à la volée. Je vous invite à découvrir la super spécification Java (JSR 356), le nouveau protocole WebSocket (RFC 6455) et un panel technologique super intéressant

1. REAL-TIME APPLICATIONS
JSR-356
Java API for WebSocket
Par : Ouadie LAHDIOUI
RFC-6455
WebSocket Protocol
Le : 29/10/2015

2. CE QUE VOUS VERREZ PENDANT CETTE PRÉSENTATION
SOMMAIRE
1
+ Les limitations du protocole HTTP 101
+ Les techniques de push de données
+ WebSocket - Kézako ?
+ La spécification IETF RFC 6455 « The WebSocket Protocol »
+ Le standard W3C « WebSocket JavaScript API »
+ JSR 356 « Java API for WebSocket »
+ Performances : WebSocket vs REST
+ Implémentations des WebSockets
+ Backend as service : La suite de la guerre du temps réel
+ Challenges d’une Application temps réel
+ Démonstration
FireBase, PubNub, Pusher et RethinkDB
Polling, Long-polling, Streaming, Comet, SSE(Server-Sent Events)
benchmark
Grizzly, Tomcat, Netty, Atmosphere, GlassFish, Tyrus Project et Jetty
HTTP pipelining et Keep Alive
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

3. 1/4
LES LIMITATIONS DU PROTOCOLE HTTP 101
2
+ HTTP 101 = HTTP 1.0 et HTTP 1.1
+ Le HTTP 1.0 crée une connexion TCP pour chaque requête (page, image, etc …)
+ Le HTTP 1.1 des connexions persistantes pour obtenir les autres éléments de la page
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)
connexion persistante (keepalive)

4. 2/4
LES LIMITATIONS DU PROTOCOLE HTTP 101
2
+ Pipelining HTTP : une technique qui consistant à combiner plusieurs requêtes HTTP dans
une seule connexion TCP
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

5. 3/4
LES LIMITATIONS DU PROTOCOLE HTTP 101
3
+ HTTP est un protocole sans état (stateless protocol) qui fonctionne sur le modèle
requête/réponse :
+ HTTP n’est pas optimisé pour les applications qui ont d’important besoins de
communication temps réel bi-directionnelle (duplex)
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)
HTTP est unidirectionnel : Le server ne peut pas initier un transfert de données

6. 4/4
LES LIMITATIONS DU PROTOCOLE HTTP
4
+ Half duplex :
Le client envoie une requête au serveur qui répond en lui renvoyant une réponse.
Le client doit attendre la réponse.
La transmission de données ne peut se faire que dans une direction en même temps.
+ Verbeux :
Chaque requête et réponse HTTP doit avoir des en-têtes (headers).
Ce qui augmente le trafic sur le réseau.
+ Il n'est pas possible d'utiliser un mode push de la part du serveur :
Le serveur envoie à son initiative des données au client.
+ HTTP a été conçu pour obtenir des éléments du web. Il répond à de nombreux besoins
mais il possède plusieurs inconvénients notamment pour une utilisation dans une
application web interactive :
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

7. 1/5
LES TECHNIQUES DE PUSH DE DONNÉES
5
+ Plusieurs techniques ont été développées pour contourner les limitations du protocole
HTTP :
+ Polling :
Le client effectue périodiquement des requêtes synchrones au serveur pour obtenir des données.
Elle nécessite beaucoup de connexions selon la fréquence utilisée par le client.
Cette technique peut être intéressante si les données sont périodiquement modifiées côté
serveur.
+ Ajax Polling
+ JSONP Polling
+ Piggyback
+ …
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

8. 2/5
LES TECHNIQUES DE PUSH DE DONNÉES
6
+ Long polling :
Le client ouvre une connexion et envoie une requête HTTP au serveur qui ne renvoie la réponse
que si un événement force l'envoi de données au client ou après un certain timeout.
Le nombre de requêtes/réponses peut ainsi être réduit sauf si le nombre d'événements est très
important.
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

9. 3/5
LES TECHNIQUES DE PUSH DE DONNÉES
7
+ Streaming :
Le client envoie une requête au serveur qui maintient le flux de la réponse ouvert en y envoyant
des données au besoin.
Cette technique repose sur l’utilisation de connexion http persistantes.
Elle pose généralement des soucis avec certains éléments réseaux comme les firewalls ou les
proxys
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

10. 4/5
LES TECHNIQUES DE PUSH DE DONNÉES
9
+ Reverse Ajax ou bien Comet:
Une technique combinant Ajax et long polling
Un concept dont le but est de permettre à un serveur d'envoyer à son initiative des données à un
navigateur.
Plusieurs techniques sont utilisées pour répondre au concept Comet :
+ Forever Iframes
+ Multi-part XMLHttpRequest
+ Hidden Iframes
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

11. 5/5
LES TECHNIQUES DE PUSH DE DONNÉES
8
+ Server Side Event :
Un mécanisme de communication comparable à JMS : les clients s'inscrivent à un bus de
messages auprès du serveur, qui peut alors leur transmettre des données de manière
asynchrone via HTTP (= unidirectionnelle)
L'API SSE est normalisée dans le cadre de HTML5 par le W3C.
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

12. 1/1
WEBSOCKET - KÉZAKO ?
10
+ Une technologie permet d'ouvrir une connexion bi-directionnelle permanente entre un
client et un serveur utilisant un canal en mode full duplex.
+ Permet le développement de véritables applications temps-réel performantes : application
de suivi des cours boursiers, ou des applications multi-utilisateurs (chat, jeux en ligne...).
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

13. 1/1
COMPATIBILITÉ NAVIGATEUR
11Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)
+ http://caniuse.com

14. 12Source des images : kaazing.com

15. 1/4 THE WEBSOCKET PROTOCOL
LA SPÉCIFICATION IETF RFC 6455
13
+ Le protocole WS permet l'échange de données entre un client et un serveur de manière
asynchrone, bidirectionnelle en mode full duplex utilisant une connections TCP
+ La spécification du protocole WebSocket est définie dans la RFC 6455, publiée en
décembre 2011 par Internet Engineering Task Force (IETF)
+ WS est :
+ basé sur 1 unique connexion TCP entre 2 peers
+ bi-directionnel : le client peut envoyer un message au serveur et le serveur peut envoyer
un message au client
+ full-duplex : le client peut envoyer plusieurs messages vers le serveur et le serveur vers le
client sans attendre de réponse l’un de l’autre
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

16. 2/4 THE WEBSOCKET PROTOCOL
LA SPÉCIFICATION IETF RFC 6455
14
+ Le protocole WebSocket fonctionne en 2 phases : handshake et data transfer
+ HTTP half-duplex
+ WebSocket full-duplex
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

17. 3/4 THE WEBSOCKET PROTOCOL
LA SPÉCIFICATION IETF RFC 6455
15
+ Handshake :
Unique échange requête/réponse HTTP entre l’initiateur de la connexion (peer client) et le peer serveur.
Cet échange HTTP utilise le mécanisme HTTP Upgrade
L’Upgrade HTTP permet au client de communiquer avec le serveur pour lui demander de changer de
protocole de communication
+ Requête HTTP Handshake
+ Réponse HTTP Handshake
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

18. 4/4 THE WEBSOCKET PROTOCOL
LA SPÉCIFICATION IETF RFC 6455
17Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)
+ Data transfer
Une fois le handshake acceptée, une gestion de callback est activée pour initier la communication
Les 2 peers s'échangent des messages dans une communication bi-directionnelle et full-duplex

19. WEBSOCKET JAVASCRIPT API
LE STANDARD W3C
18
+ Pour communiquer avec un serveur via le protocole WS, il est nécessaire d’utiliser une
API cliente en Javascript.
+ L’interface WebSocket propose des gestionnaires d'évènements pour s’adapter aux
méthodes du cycle de vie des WebSocket :
+ l’Event-Handler onopen est appelé lorsqu’une nouvelle connexion est initiée
+ l’Event-Handler onerror est appelé lorsqu’une erreur est reçue pendant la communication
+ l’Event-Handler onmessage est appelé lorsqu’un message est reçu
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

20. JAVAAPI FOR WEBSOCKET
JAVA SPECIFICATION REQUESTS 356
19
+ Le W3C définit comment utiliser WebSocket en Javascript, le Java Communitee Process
(JCP) fait de même pour le monde Java via la JSR 356
+ La spécification JSR 356 définit une API Java pour WebSocket qui propose :
+ La création d’un WebSocket Endpoint
+ L’utilisation l’approche par annotation Java ou par programmation
+ La possibilité d’envoyer et de consommer des messages en synchrone ou en asynchrone
+ La configuration et la gestion des sessions WebSocket (timeout, cookies…)
+ Une intégration dans Java EE Web Profile
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

21. JAVA SPECIFICATION REQUESTS 356
20
JAVAAPI FOR WEBSOCKET
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

22. 1/1
PERFORMANCES : WEBSOCKET VS REST
21
+ Benchmark publié par Arun Gupta sur GitHub
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

23. 1/1
IMPLÉMENTATIONS DES WEBSOCKETS
22
+ Plusieurs implémentations des WebSockets sont disponibles :
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

24. 1/1 BACKEND AS SERVICE
LA SUITE DE LA GUERRE DU TEMPS RÉEL
23
+ Certaines solutions proposent du temps réel et le stockage de fichiers décentralisé sur
leur infrastructure :
+ Concept de « room » pour publier et retrouver les messages
+ BaaS : Backend as service
Real-Time applications avec la spécification Java pour les WebSockets (JSR 356) et le protocole WebSocket (RFC 6455)

25. PROXY, REVERS PROXY, FIREWALL, LOAD BALANCING…
CHALLENGES D’UNE APPLICATION TEMPS RÉEL
24Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

26. LIVRES
25
+ Java WebSocket Programming + The Definitive Guide to HTML5 WebSocket
Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

27. MERCI POUR VOTRE ATTENTION
Real-Time applications avec la spécification Java pour les WebSockets (JSR 356) et le protocole WebSocket (RFC 6455) 26
Références :
• Internet Engineering Task Force (IETF) RFC 6455: http://tools.ietf.org/html/rfc6455
• W3C The WebSocket API : http://www.w3.org/TR/websockets/
• Java Specification Requests 356 “Java API for WebSocket” : http://jcp.org/en/jsr/detail?id=356
• HTML5 Web Sockets Specification: http://dev.w3.org/html5/websockets/
• Server Sent Events : http://www.w3.org/TR/2011/WD-eventsource-20110208/