Présentation de WebSocket, protocole de communication réellement bidirectionnel pour le web, et mise en oeuvre de son API JavaScript dans le navigateur ainsi que l'API apportée par Java EE 7 dans le serveur.
• Short polling : • Requêtes périodiques courtes sur le serveur • Comet : • Long polling : • Requêtes sur le serveur qui bloquent en attente de réponse • Streaming : • Requête longue sur le serveur avec plusieurs contenus retournés • Limitations : • Temps de requête/connexion • Overhead HTTP • Buffering des proxy Historique @fbeaufume
• Server-Sent Event (SSE) : • Push uniquement, en texte, pas de streaming • SPDY : • HTTP amélioré par Google : compression des headers, multiplexage des requêtes, etc • Push de ressources (pas d'API JS de callback) • Upgradable en WebSocket • HTTP/2 : • Standard basé sur SPDY : compression, multiplexage, upgradable en WebSocket, etc • Push de ressources Historique @fbeaufume
• Protocole de communication full-duplex sur connexion TCP • RFC 6455 • Texte ou binaire • Crypté ("wss:") ou pas ("ws:") • Web friendly : • Upgrade d'HTTP ou indépendant • API JavaScript par W3C • Supporté par les browsers : Ch 16, FF 11, IE 10, Saf 6 • Sous-protocoles, e.g. XMPP, STOMP, SIP • Cible : applications temps réel, event-driven • Bénéfices : réduction de bande passante et latence WebSocket @fbeaufume
• JavaScript : • API JavaScript standard du W3C • SocksJS : émulation WebSocket • Socket.io : wrapper WebSocket, AJAX long-polling, etc, utilisable aussi sur Node.js • Java : • Les API propriétaires des serveurs d'application • Java API for WebSocket 1.0 (JSR 356, dans Java EE 7) • Spring : fallback transparent sur SocksJS • Atmosphere : framework Java et JS supportant Comet, SSE, WebSocket, etc. API @fbeaufume
• Cryptage via "wss:" • Authentification : • Pas de mécanisme spécifique • Solutions HTTP possibles, par ex cookies • Ou par message applicatif • Pas de Same-Origin Policy • Cross-Site WebSocket Hijacking (CSWSH) : • Similaire à CSRF • Vérifier le header "Origin" • Générer un token aléatoire pour l'upgrade Sécurité
Codes de fermeture Code Nom Description 0-999 Réservés 1000 CLOSE_NORMAL Fermeture normale 1002 CLOSE_PROTOCOL_ERROR Erreur de protocole 1003 CLOSE_UNSUPPORTED Type de message pas supporté 1009 CLOSE_TOO_LARGE Data frame trop grosse 3000-3999 Pour les librairies et frameworks 4000-4999 Pour les applications … … … @fbeaufume
• Cible Java EE 8 • Pas encore final • Améliorations envisagées : • Support des scopes CDI • API bas niveau pour gérer les frames • Amélioration des extensions • API de filtrage • Amélioration sur les sous-protocoles • API cliente : support de proxy, modes d'AH HTTP, etc. • Broadcast • Sécurité, par exemple @RolesAllowed • Cluster • Etc. API WebSocket.NEXT @fbeaufume
Couches applicatives Games Game Results Endpoints Contrôleurs V1 Play Play V3 Services Games Games Games Game Results Games Game Results V2 Games Games Game Results Play Games Game Results Pages /games /game/{id} /results/{id} /games /game/{id} /results/{id} /play Métier Métier Métier Réceptions Sécurité Session WS Emissions Session WS Emissions Réceptions Sécurité Réceptions Sécurité Session WS Emissions @fbeaufume
• Pas lié à WebSocket mais au push : • Besoin d'indentification et catégorisation des clients • Plusieurs états à coordonner : • Session HTTP • Session WebSocket • Etat applicatif • Web vs WebSocket : manque de solutions intégrées à ce jour Impacts sur la conception @fbeaufume
• Un path d'endpoint WebSocket doit commencer par "/", pas nécessaire pour JAX-RS • WildFly 8.0.0 : codes d'erreur pas supportés (corrigé en 8.1.0) • Quelques limitations d'héritage • Injection de @Singleton ok, mais pas @RequestScoped • Clustering pas spécifié : • Load-balancing, réplication de session, fail-over ? • L'API Spring semble aller plus loin API Java @fbeaufume
fbeaufume
tomokusaba
k0kubun
akitotsukahara
ivargrimstad
numeroanddev
nsuz
totokit4
soutaro
octu0
takesinoda
naokimrmt
ledsun
eitanlees
jlugia
jensimmons
tanoku
erikaheidi
mraible
dougneiner
danielanewman
kneath
ddemaree
productmarketing
vanstee