I need to create queue in Sonic MQ dynamically in runtime and send user credentials to client, that he can use to access this queue. So when client connects to SonicMQ, appropriate queue must be found using client credentials.
Is this kind of mechanism supported by SonicMQ? I have been told, that this can be done in SonicMQ, but can't find the functionality needed for it.
is it possible in Sonic MQ to create queues dynamically in runtime? I found it is possible to do it with SonicMQ Administrative API, but is this API meant to be used programmatically in runtime?
Is possible to have a queue "mapped" to user credentials? Or can user have default queue?
Yes, you can use the managment APIs to do that.
And the documentaion: http://documentation.progress.com/output/Sonic/8.0.0/releasedate/Docs8.0/books/mq_admin_program.pdf
I think it can be done with the administrative api's but I am not sure for what use case you want to do that. If the client is using the JNDI lookup you also need to provide a setup for that manually or using the API's.
Are you looking to automate Administrative tasks at MQ side?
Can you share your use case if possible?
Yes, were trying to automate administrative task, because there will be lot of queues needed. Creating them manually using Management Console would be to much administrative work, so we need to create them in ad hoc basis as the need dictates.
1) Client authenticates itself using authentication service
2) Authentication service generates username/password (if already doesn't exist, new queue for the client is created), which can be used to access specific client queue
2) Client gets back username/password
3) Client connects to SonicMQ using username and password
4) Client receives messages from queue
*every queue is client specific, so only one client must be able to access the queue, hence user/pass restriction
*number of queues ~1000
*somehow username/password must map to one specific queue (default queue?), because queue are being created dynamically and client doesn't have information to which queue it must connect
Have you considered using topics for this instead of queues? Topics don't need to created administratively (though you may still need to dynamically create ACL's for the new users/topics). A solution based on topics is also likely to scale better as the number of users increases in this scenario.