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


Vous avez trouvé cette publication utile? Cliquer sur
Ippon
Ippon est un cabinet de conseil en technologies, créé en 2002 par un sportif de Haut Niveau et un polytechnicien, avec pour ambition de devenir leader sur les solutions Digitales, Cloud et BigData.

Ippon accompagne les entreprises dans le développement et la transformation de leur système d’information avec des applications performantes et des solutions robustes.

Ippon propose une offre de services à 360° pour répondre à l’ensemble des besoins en innovation technologique : Conseil, Design, Développement, Hébergement et Formation.

Nous avons réalisé, en 2016, un chiffre d’affaires de 24 M€ en croissance organique de 20%. Nous sommes aujourd’hui un groupe international riche de plus de 300 consultants répartis en France, aux USA, en Australie et au Maroc.
FRANCE Website LinkedIn