If every message sent my A needs to be processed by X, Y & Z then a topic would be more appropriate, durable if need be.
If there is a one to one for messages sent from A to X, Y or Z, then either a single queue w/message selector or queue per host will work. It depends alot on your administrative needs and the desired through put. For example if you expect a high through put for processing on the X/Y/Z side, then seperate queues can potentially be faster (depending on the provider impl), because the resource will only be locked for write 1/3 the time (by A) and will only be locked for read by X, Y or Z.
If you plan to have a very dynamic system, where you add/remove Xn/Yn/Zn nodes then it might be easier to handle one destination and use message selectors to filter.
If you abstract the destination configuration then it should be fairly simple to switch between the different schemes with little effect on the design of the application.
Thanks for the response.
As you suggest, all messages need to be processed by X, Y and Z, so following your suggestion a durable topic would be more appropriate. To be honest I haven't really dealt with durable topics yet, so will need to do some reading, but... I assume that with a durable topic, I'll need to make sure I get the subscription set up, before any messages start arriving, yes? From the name, I assume that if the connection dies, the client (X) will be able to reconnect, and get any 'missed' messages. Therefore, it will be up to me to ensure that the connection exists before any messages come in.
X,Y and Z are on a different box because they are expected to be slow, and are not time critical, so any performance gain from having multiple queues would probably be eroded pretty quickly.
So in this case, we will have a topic on box A, and have X, Y and Z have durable subscriptions to that topic.
thanks for the help.