We have an application where clients need to be notified.
We opted to use JMS, i.e. the client creates a temporary queue and can register itself to the server using this queue. Whenever a notification is needed the server sends a message to the registered temporary queues (unregistering is not needed, if a temporary queue can not be reached the client is assumed to be gone).
At the server we have some processing which produces notification. In order to decouple the processing part from the notification part the processing sends notification messages to a notification queue.
From there the notifications are picked up and send further to the client (using temporary queues as described above), filtering of notifications etc... is by thus decoupled from processing.
We have a mdb listening to the notification queue on the server and sending messages to the client temporary queues. Is this the best way to do this?
I don't see how I can have a mdb which picks up the same message more than once (i.e. once for each client), filter them and optionally send it to the client temporary queue. So the only thing I see is to have a singleton mdb (in order to send notifications in the right order), this means one thread which handles all client notifications.
Furthermore then I need a way to loop over the client queues. For this we use a @Service in which the temporary queues are registered.
I know this architecture is working but I'm wondering if there is a possibility to have multiple threads for notification (for which I need the mdb or something else to pick up the same message once for each client...)
