Pourquoi choisir JMS comme solution asynchrone? Pourquoi est-ce mieux qu'un simple haricot d'entité?

1) Quel intérêt avons-nous à utiliser JMS? Quels sont les avantages de JMS ? 2) Dans quelle situation préférer JMS versus entité bean ?

Vous approche fonctionne bien tant qu'il est seulement un consommateur . Sinon, il faudra un système de verrouillage pour que le même message ne soit pas livré deux fois, etc. C'est ce que JMS vous offre: une production et une consommation transactionnelles avec le courtier JMS qui gère tout le des problèmes de livraison avec plusieurs consommateurs/producteurs .

les autres avantages du JMS sont qualité du service et gestion , par exemple tentative de livraison, file d'attente de messages morte, gestion de la charge, évolutivité, regroupement, surveillance, etc.

JMS prend également en charge publish-subsribe ou point-to-point.

c'est un peu comme comparer une déclaration JDBC pour insérer une rangée dans base de données contre une intégrale de l'ORM. Les deux travaillent à insérer une rangée dans le db, mais L'ORM fournira beaucoup plus, plus vous ne réinventez pas la roue pour traiter les problèmes de bas niveau... (l'analogie n'est pas si grande mais bien)

je vous suggère de regarder le FAQ .

Dans Java EE globalement, il existe 3 mécanismes pour traiter l'asynchronicité:

1. JMS
2. Le CDI événement bus
3. @Asynchrone annoté méthodes de stateless session beans

ewernli donne déjà une très bonne explication des avantages de JMS. Il s'agit d'un système très complet, mais toutes ces fonctionnalités coûtent un peu en frais généraux et en complexité de gestion, par exemple les objets administratifs impliqués.

de plus, la spécification JMS n'a pas été mise à jour depuis près d'une décennie. Il est toujours très utile montre la grande dose de prévoyance qui est allé dans la conception de L'API, mais parfois, il peut se sentir un peu arcane. La façon dont les objets administratifs comme les destinations doivent être définis, la façon dont vous avez besoin d'obtenir une connexion, de créer une session, etc, tout cela se sent un peu bas-niveau, vieux et arcane. La réception de messages si a a été grandement simplifié avec le message conduit haricots, mais l'envoi n'a pas.

ensuite, pour des raisons bizarres, les modules web sont interdits d'écouter les destinations JMS. Bien sûr, il n'y a plus de raison pour cela, mais c'est dans l'ancien J2EE 1.3 et plus tard specs. Les serveurs d'applications conformes respectent toujours cette règle, mais ils fournissent tous une configuration spécifique au fournisseur pour l'autoriser de toute façon. Cela rend cependant votre application moins portable.

A le sous-ensemble des cas d'utilisation pour lesquels JMS a été traditionnellement utilisé est une programmation basée sur des événements très simple au sein d'une seule application. Pour que le CDI événement bus est défendable mieux maintenant, c'est plus simple, plus moderne et plus légers approche.

un autre sous-ensemble de cas d'utilisation pour lesquels JMS a été utilisé consiste simplement à effectuer n'importe quel travail de façon asynchrone. Pour que les gens parfois utilisé pour faire un BMD qui serait alors tout simplement déballer les paramètres du message et l'appel la méthode de certains haricots de session apatrides passant directement dans ces paramètres. Dans ce cas, le paradigme de la messagerie n'est absolument pas nécessaire et le simple fait d'appeler une méthode annotée @asynchrone est une approche plus simple et plus directe.