Tutoriel sur l'intégration de CDI, EJB et WebSocket

| Soat | Renaud MALDONADO (Soat) |

Cet article présente l'intégration de CDI, des EJB et de WebSocket dans un même projet.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum. Commentez .

- Titre : Tutoriel sur l'intégration de CDI, EJB et WebSocket

- Auteurs : Soat, Renaud MALDONADO (Soat)

- Parution : 29 octobre 2015

- Licence : Copyright ® 2015 Renaud MALDONADO (soat). Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Rappel sur les WebSocket

- III. WebSocket côté JavaScript

- IV. WebSocket Côté JEE

- IV-A. Déclaration d'une classe en tant que WebSocket

- IV-B. Déclaration d'encoders/decoders

- IV-C. Déclaration des méthodes du WebSocket

- IV-D. Premier bilan

- V. Pattern de communication entre EIB, CDI et WebSocket

- V-A. Rappel sur CDI

- V-B. Déclaration du TIMER

- V-C. Déclaration de l'Observer

- VI. Conclusion

- VII. Remerciements

I - Introduction

L'arrivée de Java EE 7 a permis l'introduction native des WebSocket dans nos applications Web. Ces WebSocket, côté serveur, viennent répondre aux nouveautés apportées notamment par HTML5. Cependant, un problème se pose en voulant y intégrer d'autres mécanismes JEE7.

C'est le cas notamment des EJB3 qui ne peuvent pour l'instant pas être injectés directement (constaté sur le serveur Wildfly 8.1.0 de Jboss). Cela pose évidemment un problème si l'on souhaite pouvoir accéder à un ou plusieurs services applicatifs à partir d'une classe WebSocket.

II - Rappel sur les WebSocket

Très rapidement, un WebSocket, qu'est-ce que c'est ? Le terme WebSocket désigne avant tout un protocole. Ce protocole permet au serveur et au client de dialoguer de manière bidirectionnelle.

Par exemple, le protocole HTTP est unidirectionnel. Le client interroge, le serveur répond. D'autres protocoles orientés événements vont permettre au client de « s'abonner » aux publications du serveur. L'utilisation de WebSocket permet aux deux entités de dialoguer en « full-duplex ».

Cela signifie que les intervenants ont la possibilité d'émettre à tout moment, sans devoir attendre une réponse. Ex. :

Ceci permet techniquement la réalisation d'interfaces beaucoup plus réactives et dynamiques. On peut facilement envisager l'utilisation de ce protocole pour la réalisation d'un simple chat, ou même d'un jeu web où le serveur pourra lui-même forcer le client à se rafraîchir (plus de boucles while).

III - WebSocket côté JavaScript

L'implémentation de l'API WebSocket en JavaScript est assez simple et ne pose normalement pas de problème. Voici un exemple très rapide :

1. // on crée l'URL qui nous intéresse

2. _wsUri = "ws://" + (document.location.hostname == "" ? "localhost" : document.location.hostname) + ":" +(document.location.port == "" ? "8080" : document.location.port) + "/monappli_front/postWebSocket";

4. // on déclare notre object WebSocket en lui transmettant l'URI

5. _websocket = new WebSocket(_wsUri);

7. // puis on définit les fonctions onopen, onmessage et onerror.

8. // onopen sera appelé lors de l'envoi du premier message

9. _websocket.onopen = function(evt) {

10. console.log("Websocket connected ");

12. sendPost("test");

14. };

16. _websocket.onmessage = function(evt) {

17. console.log("WebSocket event received" );

18. var jsonData = jQuery.parseJSON(evt.data);

19. /** Ici, on place le code permettant à notre application web de se rafraîchir

20. **/

22. };

24. _websocket.onerror = function(evt) {

25. console.log("lol");

27. };

28. // on peut désormais communiquer via ce websocket avec la méthode send

29. _websocket.send(message);

IV - WebSocket Côté JEE

IV-A - Déclaration d'une classe en tant que WebSocket

À présent que le client est prêt, intéressons-nous au côté serveur. Pour déclarer une classe Java comme étant un point d'entrée WebSocket, il suffit de renseigner l'annotation @ServerEndpoint.

Ex. :

1. @Singleton

2. @ServerEndpoint(value = "/postWebSocket", decoders = { PostDecoder.class }, encoders = { ListMarkerEncoder.class, SessionIdEncoder.class })

3. public class PositionWebSocket {

4. ……

5. }

Ici, le point d'accès de mon WebSocket sera :

ws://localhost:8080/monApplis/postWebSocket

IV-B - Déclaration d'encoders/decoders

Les paramètres decoders et encoders vont nous permettre de désigner des classes en charge de l'encodage/décodage des messages reçus et envoyés par le serveur.

L'encodage doit être réalisé par une classe implémentant l'interface javax.websocket.Encoder :

1. public class ListMarkerEncoder implements Encoder.Text<List<Marker>>{

3. Logger _l = Logger.getLogger(ListMarkerEncoder.class);

5. @Override

6. public void destroy() {

7. // TODO Auto-generated method stub

9. }

11. @Override

12. public void init(EndpointConfig arg0) {

13. // TODO Auto-generated method stub

15. }

17. /**

18. *Méthode appelée lors de l'envoi d'un message par le WebSocket serveur. On transforme une liste d'objets

19. * Marker en chaine Json.

20. **/

21. @Override

22. public String encode(List<Marker> arg0) throws EncodeException {

23. JsonArray result;

24. JsonArrayBuilder builder = Json.createArrayBuilder();

25. // construction de la réponse au format JSON

26. result = builder.build();

27. return result.toString();

28. }

Le décodage doit être réalisé par une classe implémentant l'interface javax.websocket.Decoder :

1. public class PostDecoder implements Decoder.Text<Post>{

3. Logger _l = Logger.getLogger(PostDecoder.class);

5. @Override

6. public void destroy() {

7. // TODO Auto-generated method stub

9. }

11. @Override

12. public void init(EndpointConfig arg0) {

13. // TODO Auto-generated method stub

15. }

17. @Override

18. public Post decode(String arg0) throws DecodeException {

19. Post post = null;

20. final JsonParser parser = Json.createParser(new StringReader(arg0));

21. // lecture du message au format JSon

22. return post;

23. }

IV-C - Déclaration des méthodes du WebSocket

La partie serveur aura besoin de déclarer trois méthodes appelées lors des événements suivants :

- nouvelle connexion ;

- nouveau message ;

- fermeture de connexion.

Ces événements vont être implémentés par annotations de la manière suivante :

1. @OnOpen

2. public void onOpen(Session session) {

3. _l.info("Websocket session created !!! session : "                           + session.getId());

4. MonappliWebSocketSessionHolder sessionHolder = new

5. MonappliWebSocketSessionHolder();

6. sessionHolder.set_session(session);

7. _webSocketSessionHolderMap

8. .put(session.getId(), sessionHolder);

9. _l.info("Actually "

10. + _webSocketSessionHolderMap.size()

11. + " existing ");

13. try {

14. session.getBasicRemote()

15. .sendObject(session);

16. } catch (EncodeException e) {

17. //TODO

18. } catch (ClosedChannelException e) {

19. //TODO

20. } catch (Exception e) {

21. //TODO

22. }

24. }

26. /*

27. * (non-Javadoc)

28. *

29. * @see

30. * com.ccrcsoft.monappli.ws.websocket

31. * .PositionWebSocket#onClose(javax.websocket.Session,

32. * javax.websocket.CloseReason)

33. */

34. @OnClose

35. public void onClose(Session session, CloseReason reason) {

36. this.closeSession((monappliWebSocketSessionHolder)                            _webSocketSessionHolderMap

37. .get(session.getId()));

38. _l.info("Websocket session closed !!! reason : "

39. + reason.getReasonPhrase());

40. }

42. @OnMessage

43. public String receivingPost(String post) {

44. _l.info("Receiving message from outtaspace !!! post : " + post);

45. return "received " + post;

46. }

IV-D - Premier bilan

Pour l'instant, on n'a pas encore de réelle problématique. Lors de l'affichage de la page contenant le code JavaScript, la connexion entre le client et le serveur se réalise.

Cependant, sous cette forme, le serveur n'envoie pas encore de données, à part un message lors de la connexion. Ce qui ne correspond pas vraiment à ce que l'on cherche, à savoir une communication bidirectionnelle où le serveur peut rafraîchir lui-même le client si l'envie lui prend.

On pourrait donc vouloir réaliser un pattern dans lequel un processus coté serveur s'exécuterait en boucle pour mettre à jour régulièrement le client.

De plus, on aimerait bien pouvoir, à partir de la classe WebSocket, contacter des services déjà développés dans notre application.

NOTE : on part du principe que nos services sont détenus par des EJB3 (nous sommes dans un contexte Java EE 7 sans utilisation de Spring).

Hélas, l'injection (via @EJB où @Inject) d'EJB3 dans une classe déjà annotée @WebSocket n'est pas implémentée et ne fonctionne pas (sur WildFly 8.1.0).

MAIS !

Les outils Java EE 7 permettent de répondre à ces deux problématiques. Il est possible d'utiliser pour cela :

- un Timer EJB pour déclencher un processus périodique ;

- les événements CDI pour permettre aux couches EJB de communiquer avec la classe WebSocket.

V - Pattern de communication entre EIB, CDI et WebSocket

En utilisant CDI et un Timer EJB on peut obtenir le pattern suivant :

On va donc :

- déclarer un EJB contenant une méthode annotée @Schedule. Ceci va permettre de définir une période de réactivation de l'envoi d'événements ;

- déclarer un événement, dans une classe TimeEvent, qui sera envoyé périodiquement. Cette classe va contenir les informations à transmettre au WebSocket ;

- Déclarer dans la classe WebSocket une méthode annotée @Observer. Cette méthode va « écouter » la production d'événements pour les traiter ensuite.

V-A - Rappel sur CDI

Pour comprendre la suite, un petit rappel sur CDI est nécessaire. CDI (Context and Dependency Injection) est une spécification Java EE 6+ qui permet notamment l'injection de dépendances par annotations au sein d'un conteneur JEE.

CDI amène également l'utilisation des mécaniques suivantes :

- la détermination de qualificateurs permettant un typage des objets injectés ;

- la gestion des scopes des objets injectés (session, request…) ;

- la déclaration de méthodes @Observer qui vont « écouter » les événements d'un type donné. Cela va nous permettre notamment d'écouter les événements de notre Timer ;

- la déclaration de méthodes @Producer qui vont être appelées lors de l'injection d'objets qualifiés (qui sont typés par un qualificateur) ;

- et beaucoup d'autres…

Il y aurait beaucoup de choses à dire sur CDI ici, mais afin de ne pas trop digresser, je me permets de vous renvoyer vers ce lien.

V-B - Déclaration du TIMER

Et donc, revenons à nos moutons. Déclarer le Timer revient à créer un EJB contenant une méthode annotée @Schedule :

1. @Stateless

2. public class MyEJBTimer implements EventTimer {

4. // la période définie ici envoie un événement toutes les 3        // 0 secs

5. @Schedule(second="*/30", minute="*", hour="*")

6. public void produceWebSocketTimeEvent(Timer t){

7. // ma cla

8. TimeEvent event = new TimeEvent();

9. event.set_value(new Date());

10. // production de l'évènement

11. _timeEvent.fire(event);

12. }

14. // Objet de la classe javax.enterprise.event.Event qui per        // met de gérer mes TimeEvent

15. @Inject @TimeEventQual Event<TimeEvent> _timeEvent;

17. }

On crée donc une méthode qui va, toutes les 30 secondes, envoyer un événement TimeEvent.

Les annotations CDI @Inject et @TimeEventQual signifient que _timeEvent va être injecté et initialisé par CDI et qu'il sera qualifié par @TimeEventQual.

Pour déclarer le qualificateur @TimeEventQual, il faut créer une annotation qui contiendra le code suivant :

1. // définit l'annotation comme un qualificateur

2. @Qualifier

3. @Retention(RetentionPolicy.RUNTIME)

4. // l'annotation peut être appliquée aux méthodes, aux champs et au// x paramètres

5. @Target({ElementType.METHOD,ElementType.FIELD,ElementType.PARAMETER,ElementType.TYPE})

6. public @interface TimeEventQual {

8. }

La classe TimeEvent peut être un simple POJO :

1. package com.ccrcsoft.geovote.common.util.event;

3. import java.util.Date;

5. public class TimeEvent extends Event<Date> {

6. ....

7. }

V-C - Déclaration de l'Observer

Enfin, dans notre classe WebSocket, nous pouvons déclarer une méthode @Observer :

1. public void onTimeEvent(@Observes @TimeEventQual TimeEvent eventt) {

2. _l.info("Nouveau timer event reçu!!!!! ");

3. try {

4. session.getBasicRemote().sendObject(“Nouvel evènement!!!!”);

5. } catch (Exception e) {

6. }

7. }

On note l'utilisation des annotations CDI @Observes et @TimeEventQual. @Observes définit notre méthode onTimeEvent comme la cible d'un événement de type @TimeEventQual.

Ce qui nous permet donc de communiquer de manière périodique les informations souhaitées aux clients. De plus, notre Timer étant un EJB nous avons accès aux autres services de l'application et pouvons donc transmettre via des événements les données souhaitées.

VI - Conclusion

On pourrait dire que pour exploiter complètement JEE, il est primordial d'avoir une vision d'ensemble sur ce que les différents frameworks du standard ont à offrir. La création de WebSocket, de services Rests (pas présentée ici), d'EJB3 de CDI nous permet de réaliser des patterns extrêmement puissants (sans compter Java 8) à condition d'avoir une idée de comment les utiliser. Concrètement, j'ai trouvé cette technique sur le site suivant après avoir essuyé plusieurs échecs à vouloir implémenter de fumeuses solutions moi-même. Donc, pour finir, n'oublions jamais de regarder ce qui se fait ailleurs.

NOTE : CDI est aujourd'hui implémenté jusqu'à la version 1.2 (Weld 2.2), la version 2.0 est spécifiée, mais pas encore implémentée.

VII - Remerciements

Cet article a été publié avec l'aimable autorisation de la société Soat.

Nous tenons à remercier f-leb pour sa relecture attentive de cet article et milkoseck pour la mise au gabarit.