MDB ou pas MDB

Bonjour tout le monde
J'ai une application web (JSF EJB JPA) qui doit gérer différent profils et de gérer les notifications entre eux.
par exemple si un profil change un état dans une donnée, un deuxième profil doit être notifié en temps réel sur ce changement.
J'ai lu que :

Citation:

---

L'EJB MDB favorise en couplage faible entre deux applications. Il apporte une solution aux problèmes des communications synchrones. Ci-dessous l'application 'client' dépose un message dans une file de message. L'application EJB traite le message. Ces 2 applis 'ne se connaissent pas'.

---

Pourtant j'ai une seule application mais c'est au niveau des profils que je veux gérer les messages asynchrones.

En sachant que l'application en question est constituée d'un seul JAR et d'un WAR.
Je voudrais savoir si :
L'utilisation des MDB est elle logique dans ce genre de situation?
Si oui comment ça va ce passé?
Si non y a t'il d'autre alternative pour résoudre le probleme?
Merci a vous :D

Non, utiliser JMS et un MDB est 'overkill' pour ce besoin, JMS étant premièrement fait pour l'intégration entre applications. C'est d'ailleurs pour ça que Java EE 6 a introduit les méthodes asynchrones dans EJB3.1 et Servlet 3.0, pour que JMS ne soit plus nécessaire pour des besoins simples.

Pour ton besoin par contre, le design pattern Observer est plus adapté pour assurer du "loose coupling" entre tes composants. Je te conseille de jeter un oeil sur l'implémentation très réussie de ce pattern dans CDI(JSR299) de JavaEE6: cdi event model
http://docs.jboss.org/weld/reference...ml/events.html
http://www.adam-bien.com/roller/abie..._observer_with

Weld (impléméntation de référence de cdi) peut aussi être installé sur un serveur d'applications ou conteneur non EE6, au cas où tu ne serais pas encore passé à Java EE6

Sinon, Seam 2.x offre une fonctionnalité identique, mais celle dans CDI est encore plus simple à utiliser.

+1 Pour le patron de conception observateur, dès qu'il y'a une situation d'ecoute/notification faut tout de suite penser à l'implementer, un exemple ici

Il restera la problématique d'aviser les clients légers (navigateur).
Il faudrait que le serveur avise ces clients et là, c'est une autre histoire.
Avec JSF, il me semble que certaines bibliothèques permettent de faire un push côté serveur, sinon, il faudra périodiquement envoyer une requête ajax pour détecter un éventuel changement.