Java EE 7 a introduit un certain nombre de nouvelles API et de changements aux API existantes qui permettent aux développeurs d'utiliser HTML5. Il y a trois domaines : une nouvelle API pour traiter le JSON, une mise à jour importante de JSF pour traiter de nouveaux attributs et une nouvelle API pour travailler avec le protocole des WebSockets.
Le protocole des WebSockets change la manière dont un serveur web réagit aux requêtes d'un client : au lieu de fermer la connexion, il envoie un message avec le code HTTP 101 et laisse la connexion ouverte. Les deux parties s'attendent ensuite à recevoir des données et à en écrire sur le flux. Contrairement à HTTP, le protocole supporte une communication bilatérale complète de telle manière que le client (typiquement un navigateur) et le serveur peuvent s'échanger des messages en même temps.
Le protocole est défini dans le document IETF RFC 6455.
Pour établir une connexion WebSocket, le client envoie une demande de connexion WebSocket (WebSocket handshake), et le serveur renvoie une réponse comme dans l'exemple ci-dessous:
GET /mychat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
Origin: http://example.com
Réponse du serveur :
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
Une fois que l'initialisation de la connexion a été faite entre le client et le serveur, ceux-ci sont connectés et appairés ; les deux peuvent envoyer, recevoir des messages et fermer la connexion.
Coté Javascript, la connexion est gérée en utilisant l'API définie par W3C.
Les applications Java WebSockets contiennent des points d'entrée WebSocket (WebSocket endpoints) qui sont des objets Java représentant une extrémité de la connexion entre les 2 pairs.
L'API Java WebSocket modèle chacune des parties de la session en une instance de endpoint avec une implémentation de l'interface RemoteEndpoint. Cette interface et ses deux sous types (RemoteEndpoint.Whole et RemoteEndpoint.Partial) contiennent un grand nombre de méthodes pour envoyer des messages WebSocket entre les pairs.
Il y a deux manières de créer le endpoint. La première est d'implémenter certaines classes de l'API Java WebSocket avec le comportement nécessaire pour gérer le cycle de vie du endpoint, consommer et envoyer des messages, se publier et se connecter à un pair :
session.addMessageHandler(new MessageHandler.Whole() {
public void onMessage(String text) {
try {
remote.sendText("Got your message (" + text + "). Thanks !");
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
La seconde manière est de décorer des Plain Old Java Object (POJO) avec certaines annotations de l'API WebSocket. L'implémentation prend alors ces classes annotées en charge et crée les objets nécessaires à l’exécution pour déployer les POJOs en tant que endpoint WebSocket.
@ServerEndpoint("/hello")
public class MyHelloServer {
@OnMessage
public String handleMessage(String message) {
return "Got your message (" + message + "). Thanks !";
}
}
L'API limite l’enregistrement de MessageHandlers par Session à un MessageHandler par type de message WebSocket (texte, binaire, pong) mais cela devrait évoluer dans le futur.
Le endpoint participe à l'ouverture et l'initialisation de la connexion (handshake). Il va alors envoyer et recevoir une variété de messages WebSocket. Le cycle de vie se termine une fois que la connexion est fermée.
Si une connexion active sur un endpoint WebSocket est sur le point d’être fermée pour quelques raisons que cela soit (sur un événement de fermeture WebSocket du pair, ou parce que l’implémentation l'a décidée, l'implémentation du WebSocket doit appeler la méthode onClose() du endpoint.
Il était bien sûr possible d'implémenter des applications WebSocket en Java avant l'arrivée de Java EE7, mais toutes les API qui étaient disponibles présentaient leurs petites spécificités, de telle sorte qu'une application WebSocket écrite pour Apache Tomcat 7 devait être modifiée pour fonctionner avec Jetty, JBoss ou Resin. Avoir un standard pour faire cela avec Java EE est une amélioration particulèrement bienvenue.