Can AMQP clients be both a publisher and subscriber?

I'm just starting to research AMQP and I'm wondering if I'd be using it for something it's not designed for. Here's something like what I want to do:

ClientA does goes开发者_开发问答 about it's business and publishes it's state to some exchange (correct me if I use the wrong terms anywhere).

ClientB connects to the same broker and "says what publishers are publishing here? I choose you, clientB. What is going on?".

ClientA says "My foo is bar and my baz is true"

ClientB says "OK. Set your baz to false"

edit for a less abstract example"

ClientA talks/listens to a hardware device, say a video projector. When ClientB comes online, it wants to find any projector clients (like ClientA) that are connected and then to know the status of the projectors (is the lamp on?) and also change, if it needs to, the status (turn the lamp off). So ClientA is keeping some state (lamp is off) and can send it out when requested, and call also respond to commands from the exchange and convert and pass them to the projector (turn lamp on).

I'm finding it hard to follow your example, but it sounds like you want these A and B types to have back-and-forth conversations with each other. Is that correct?

AMQP is better suited for asynchronous message passing, and to add the kind of point-to-point style you're describing requires that you set up request and reply queues so that clients can both send and receive messages. It's certainly possible to have clients both publish and consume messages.

This is possible and it would make sense if the different actors in your example, are networked devices because AMQP would provide a loosely coupled way of messaging.

One thing to watch out for is the last abstract line where client B says "OK, set some attribute". That sounds suspiciously like a scenario where subroutine calls return some value and then the next step takes place. AMQP can certainly simulate that kind of RPC, but it works better when processes can send a message and don't have to wait for completing.

If most of your messaging doesn't involve waiting for turnaround replies, then AMQP sounds like a fit for what you are doing. But if most of your needs are RPC, then it may not be the best choice.

AMQP really shines when there are future possibilities, for instance in your scenario, if you needed to add a couple thousand projectors, 10,000 client Bs, and several other device types that also need to exchange status. The loose coupling of AMQP makes it easy to add other applications to the broker, just by declaring new exchanges.