Hi Antti,
We're looking at JMS as a possible alternative to
Servlets so are considering something similar to you. I'm trying to get things straight in my mind so bear with me.
I don't really understand why your client would register itself in both a queue and topic. Wouldn't it make more sense to register itself in a queue for a response/request type scenerio. The queue could be open as long as the client's session is open. So then a queue would essentially be a substitute for a session. This would take care of 1)session information 2) security 3)administration- you always know how many clients are connected by the number of queues - you can dissconnect them if you don't like what they're doing (although JMX may be a better alternative)
When you say clusterize - in my mind I think of a critical service that cannot be down vs subdividing a task through multiple servers to cut down the time a task is executed. In the first case creating multiple queues in one JMS server will not be much help if your server crashes. You could create multiple jms servers that are linked (ie roundrobin) so whereever the queue is actually located it will handle the request - ie SwiftMQ.
In the second scenario, creating multiple queues on different JMS servers and sending different parts of your single task/process could speed up your total response time. Although, you have to be carefull about syncronization and the possibility of one server being down... etc.
Oops just read your last line. Perhaps you could have a switch queue that would send your request along to the least crowded queue- if you where going with your model.
I would be really interested on how you implement your system.
cheers,
Yoo-Jin.