I can enumerate if that is what you want. Rereading your fiirst post, I believe that is what you want.
Assum there is a producer P (of documents/events) and a consumer C (of documents/events). They can interact in four general modes:
Deliver - P says to deliver a doc explicitly to C
Publish/Subscribe - P says to publish a doc; C subscribes
a) can subscribe by doc type
b) can filter by predicate on doc content
Request/Reply - P says to publish a doc; C subscribes; C delivers a reply doc to P
Conversation - P and C deliver documents back and forth
The broker handles the delivery and publish, as well as the subscribe and filter. The interface for programs (adapters, agents, tools, et.al.) is a broker client, which can offer queues (for incoming docs) and subscriptions (to define what comes in the queues). Can create many incoming queues. Sending docs (deliver, publish) essentially goes into one broker queue, which it processes to figure out where the docs go.
There are many nuances to receiving docs in a queue. A series of docs can contain a sequence number - the order is maintained, and the receiver can tell when the last doc is received. Docs can be tagged and thus a reply containing a tag copied from the request doc allows the requestor to match replies with requests — handy when sending out many requests.
A receiver can get a doc but not have it leave the queue until another operation, an acknowledge. There is an API call that publishes one or more docs, and does the ack of the input doc … allowing agents (esp. ATC) to use the queue as a restart buffer … until the resulting docs are gone the original incoming doc is still queued.
A receiver can get docs out of order, by type, and by subscription. These nuances tend to be hidden under the hood of the adapters and tools.
All of this and more is in the documentation. If this is not the answer then I suspect you need to read more documentation to frame the question, or get with someone who knows for an hour on a white board.
Alodar Systems, Inc.