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:
- 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.
- 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.
- Les annotations - Comme toute spécification moderne, il faut pouvoir utiliser les annotations pour la configuration.
- 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.
- 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.
- 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.
