Let me see if I understood your question(s) correctly.
(1) You have a client server application where in the client is fat (rich).
(2) You have to support 5000 clients and you donít want the clients to peek at each other.
(3) Server has to reach out to an individual client.
When it comes to the applicability of JMS with Dynamic Queues, it should matter whether the client is thin or rich, what matters is that you need a static queue for the handshake. You can then process the request and reach out to a client individually using JMSReplyTo header, as discussed in the article.
Regarding you question as to how many Dynamic Queues we can create, it depends on the JMS infrastructure that is available to you. For instance, I have used Tibco in the past and have used other Business Integration/JMS vendors like Vitria and have not seen any issues, as far the number of temporary queues are concerned. I was able to create 50 thousand!! Keep in mind that these queues only exist as long as the session is alive, and hence you should take all the necessary action to close the session gracefully, as soon as you are done.
As far as performance is concerned, in the past I have used Swing clients in lieu with WebSphere and WebLogic and was able to guarantee 2 seconds response SLA. Again, it largely depends upon the complexity of the server side processing.
From the monitoring perspective, Dynamic queues donít pose any treat, since they are cleaned up as soon as the session is closed.
Hope this helps.