[Editor: Another update on the "cloud ESB." This is an interesting take on security issues when running complex transactions in the cloud.] When designing and implementing cloudMQ, security was one of our primary concerns. The overall philosophy that we took was to implement security that is simple to understand and to implement. We also focused on creating layered security mechanisms , so that even failure of one type of security barrier does not necessarily lead to the compromise of the system. Another design goald was to re-use existing proven security mechanisms for authentication and encryption Download the complete cloudMQ Security White Paper here...

Probably the only thing that I hated in the JMS API was createQueueConnection(userName, password). So, I am glad to see a proper mechanism. Couple of things I wanted to ask: 1. Is there a way to run queries to select messages that have not been delivered etc? 2. To pause message delivery in JBossMQ (even WebsphereMQ), I had to get hold of the MBean that represents the Queue or Topic and invoke methods on it. Is there a way to do that in cloudMQ? In one of my previous jobs, a mainframe system was shutdown daily at night, so the ability to stop and start message delivery came in handy.

Probably the only thing that I hated in the JMS API was createQueueConnection(userName, password). So, I am glad to see a proper mechanism.

Couple of things I wanted to ask:
1. Is there a way to run queries to select messages that have not been delivered etc?
2. To pause message delivery in JBossMQ (even WebsphereMQ), I had to get hold of the MBean that represents the Queue or Topic and invoke methods on it. Is there a way to do that in cloudMQ? In one of my previous jobs, a mainframe system was shutdown daily at night, so the ability to stop and start message delivery came in handy.

Hey. Thanks! The control panel shows unconsumed messages sitting on the queue. For Pub/Sub, one could do durable or non-durable. Using non-durable subscriptions will in effect cause suspension of delivery when client is disconnected. Not sure I answered your question though. Let me know.

Thanks for the reply. Regarding the answer to the second question, I am asking whether you can explicitly “tell” the Queue/Topic to stop delivering messages temporarily. For example, let’s say my MessageListener inserts message data into a DB but the DB is shutdown after 6pm and comes up at 8AM the following morning. During this time Queue/Topic delivers the message and the MessageListener will have to rollback (because DB isn’t available so it can’t complete the transaction). And this probably goes on for a while until the message is classified as poison message (I am assuming). Anyway, instead of rolling the message back in this manner, I’d want a way to proactively pause message delivery to the listener. Hope you understand my point.

This functionality is part of the JMS API: connection.stop(); connection.start();

Not true, that only stops and starts delivery on that clients connection. There is no standard JMS way to stop and start delivery of messages for all consumers of a queue. Regards, Colin.

Ok, that's true (I was assuming he meant start/stop of a single consumer). Because pausing a destination spans multiple clients, it should be an administrative function anyway, maybe accessible through a programmatic interface. So calling a JMX bean's method seems to be a proper way.

Yes, that was my question - are Queues & Topics instrumented as MBeans?