Hi,
Correct.
There is a reason why there are three options, and they have nothing to do with your requirement to respond to particular message types. They are relevant to the messaging infrastructure itself, and are used to ensure that messages do not fail delivery.
You need to either use a queue for each different type of message, and listen to each separate queue. You are able to create as many queues as you need. Send different message types down different queues. You are also able to take messages off the queue, and multiplex them yourself. You can check the type of each message, and process it accordingly. A message queue is specifically designed to be a FIFO infrastructure. The messages are placed onto the queue at one end and read off the queue at the other end. Queues are not a database. Obviously you may hack and change the infrastructure to cater for your specific needs in any way you deem fit, however, this will have consequences to performance and stability.
To guarantee maximum throughput and transaction integrity you should place messages on the queue one at a time in a transaction. You should then remove the messages from the queue in the order they are presented to you one at a time in a transaction. If you need to check the type and process accordingly, then by all means do that. If the message is not what you expect and you wish to place it on another temporary queue, or to the back of the existing queue, then that is also an acceptable pattern. Attempting to remove messages based on an application specific message type is not a good idea. It is then better to put all the messages into a relational database with a relavent normalised structure using indexes, and read the data based on your application specific record type(s).
Think your application design and use of message queues carefully before selecting them as your enabling technology.
Regards
Craig
|