Qu’attendez-vous de JMS 2.0?

Ce post est écrit par Julien Dubois, membre de l’expert group JMS 2.0, et directeur du pôle conseil d’Ippon Technologies.

JMS est une spécification très utilisée en entreprise, mais son API est relativement ancienne, ce qui est vite frustrant lorsqu’on l’utilise. C’est d’ailleurs l’une des raisons du succès de Spring JMS. Heureusement, l’expert group JSR 343 (“JMS 2.0″) vient d’être formé afin de mettre à jour la spécification:

http://java.net/projects/jms-spec/pages/Home

Ce type de spécification a tendance à durer de nombreuses années: JMS 1.1 date de 2002, cela va donc bientôt faire une dizaine d’années! D’où l’importance de participer à son élaboration.

En tant que membre de l’expert group qui met en place cette spécification, je vous propose donc de participer sur ce blog, en Français, et de nous dire ce que vous voulez voir apparaître (et disparaître!) de la spécification JMS.

Voici ma proposition actuelle:

  1. Configuration de JMS
    • l’API JMS ne devrait pas dépendre de JNDI, afin qu’elle soit utilisable en dehors d’un serveur d’application complet (on pourrait alors l’utiliser sans problème dans Tomcat, un batch, ou un ESB léger).
    • Le pooling des ressources JMS devrait être inclus dans cette configuration
    • Il y a aujourd’hui un débat sur la configuration dans JEE 7, lancé par Antonio Goncalves, et JMS 2.0 devrait y participer.
  2. Simplification de l’API JMS
    • Certaines parties de l’API JMS ne sont pas claires, par exemple sur ce qui concerne l’acknowledgement des messages. Nous devrions juste avoir ”auto”, “client”, “dups-ok” et “transacted”, comme ce qui est proposé dans Spring JMS.
    • Il devrait y avoir une API plus simple pour envoyer et recevoir des messages, comme fourni par le JMSTemplate de Spring. Des librairies utilitaires et des wrappers ne devraient pas être nécessaires pour des cas d’utilisation simples.
  3. Les annotations
    • Comme toute spécification moderne, il faut pouvoir utiliser les annotations pour la configuration.
  4. Des MDB partout
    • Les Message-Driven Beans ne devraient pas être réservés aux seuls serveurs d’application. Nous devrions avoir des “message-driven POJOs” tels que fournis par Spring JMS, en utilisant des annotations sur un objet Java simple.
  5. Le clustering et le failover
    • Le thème de JEE 7 étant “le cloud”, il devrait y avoir des options de configuration du clustering et du failover dans la spécification. Par exemple, il faudrait pouvoir configurer le failover comme proposé par ActiveMQ dans sa documentation. Il faudrait également avoir un système de callback pour gérer les cas d’erreurs.
  6. Les batchs
    • Il faudrait pouvoir envoyer les messages par batch et non un par un.

Une autre proposition, qui revient régulièrement mais que nous n’avons pas repris, est celle de pouvoir envoyer des messages avec une date définie de réception. Par exemple, un producteur de message pourrait envoyer tous ses messages dans la journée, en disant qu’ils ne devront être délivrés que à minuit au destinataire.

TwitterFacebookGoogle+LinkedIn
  • http://twitter.com/jetoile Khanh

    Bonjour,

    Bonne initiative de demander l’avis aux utilisateurs pour la JSR.
    Sinon, je me disais qu’au vu de la montée des EIP, il pourrait être pas mal d’incorporer certains patterns comme, par exemple, le dead-Letter-Channel ou autre.
    En effet, pour l’instant, cela dépend de l’implémentation mais il pourrait être pas mal de le spécifier. 
    Qu’en pensez vous?

  • http://www.jroller.com/dmdevito Dominique De Vito

    J’ai tenté un début de critique de JMS ici: http://www.jroller.com/dmdevito/entry/jms_api_is_a_bit mais du point de vue performance seulement.

    Céci étant dit, ma plus grande “critique” est que le modèle JMS est, au fond, proche des JavaSpaces et du modèle “acteur”, mais qu’il faille des API différentes dans chacun de ces cas: http://www.jroller.com/dmdevito/entry/about_message_driven_beans_mdb

    Bref, l’idéal serait une seule API, et un modèle de POJO associé, permettant de faire soit du JMS, soit du JavaSpaces, et supportant le modèle de programmation par acteur.
    Pour quelles raisons ? Parce que le modèle JavaSpaces est plus simple/performant/agréable à utiliser pour divers cas, comme la réalisation d’un framework maitre/esclave, et parce que le modèle “acteur” est un modèle de plus en plus courant, et apte à capturer le parallélisme applicatif pour exploiter au mieux les archis multi-core.

    Par ex, une implémentation JMS 2.0 pourrait ainsi inclure une lib standalone (à inclure au sein d’une appli métier, sans besoin de faire tourner un serveur JMS externe), permettant ainsi d’offrir des files d’attente à des POJO/MDB métier, au sein d’une appli métier (sans besoin de serveur JMS externe). Et la même API pourrait être (ré)utilisée dans le cadre d’une archi multi-serveur cette fois-ci si, par ex, la charge de travail ne peut pas être assurée par une seule machine.
    Mais pour cela, il faudrait singulièrement réduire tout le code de plomberie de JMS… De sorte que l’on puisse, par ex, envoyer un message JMS à un MDB @annoté, et que, de manière sous-jacente, cela se traduise par l’envoi d’un message JMS à une file d’attente au nom dérivé du nom du MDB.

    Bref, l’idéal serait une seule API “d’event bus”, utilisable dans divers contextes : applis Swing/JavaFX (pour gérer l’asynchronisme), contexte “acteur”, applis JMS “traditionnelles”, JavaSpaces-like, etc.

  • http://pulse.yahoo.com/_PW6FGXHVLIJOA6UFR733UMS7FI rachid

    Le problème central véhiculé par la spécification JMS 1.1  se situerai plutôt dans son manque flagrant d’affinement: plutôt d’aspect généraliste ,elle laisse tout le loisir aux différents éditeurs d’affiner certains points et non des moindres: résultat des courses: un code non portable nécessitant quasi constamment des adaptations lors des différents changements de l’Editeur JMS .
    JMS: it means Je Me Souviens

    with no comment.

  • Vladislav Pernin

    De l’interopérabilité entre fournisseurs d’implémentation de JMS afin de ne pas être obligé de mettre en place des bridges pour faire communiquer deux systèmes en JMS basés sur des implémentations différentes. Pour cela, sans doute faudrait il revoir pas mal de choses en particulier définir non seulement une API mais aussi un protocole complet.

  • http://twitter.com/agoncal Antonio Goncalves

    Il faudrait un couplage entre JMS et les évènements CDI. Par exemple, un message qualifié (@Qualifier) est envoyé dans une file d’attente et au lieu d’être consommé par un JMSListener, il est consommé par un @Observes CDI.

  • Pingback: Tab Sweep – State of Java EE, Dynamic JPA, Java EE performance, Garbage Collection, …