As I have said, message queues are the basis for asynchronous drawbridges. This situation is changing, but that's where we are today. So an overview of message queues is a good starting point for understanding asynchronous drawbridges . A message queue is like a postal service. Someone puts messages into a receiving mailbox. Someone else takes them out of a delivery mailbox. Messages are not sent to a person, but rather to a specific delivery mailbox. Anybody who can access that mailbox can receive the message. How the postal service chooses to route the message from one mailbox to the other is not your problem. You care only that when you send a message, somehow it gets there. Whereas a message queue overall is like a postal system, an individual queue is like a mailbox. Queues have names that uniquely identify them, and when we send or remove messages, we do so to specific named queues, just as we send and receive mail to and from specific mailboxes. In the software fortress architecture, a named queue typically maps to a specific drawbridge used to connect two fortresses . The time required to deliver a queued message is indeterminate for two reasons. First, like the postal service, the message queue doesn't make any guarantee about how long it will take to move messages from one end to the other. Second, even if the queue has the message ready for delivery, it has no authority over when that message will be read. Just as the postal service cannot force you to check your mailbox, the message queue cannot force you to check for queued messages. |