8 ms·
Thank you, it's clearer now. From what I understand, messaging can also be useful as a way to simplify client/server communication in client-server architecture
by _exec 14y ago
Thank you, it's clearer now. From what I understand, messaging can also be useful as a way to simplify client/server communication in client-server architectures, correct?
- rwmj 14y agoFor me, the radically interesting thing about messaging is that it's asynchronous. You send a message, and the message could be picked up and acted upon hours later (although usually it's more like milliseconds, or in pub/sub, it could be never). This is unlike client-server, where basically you always sit waiting for a reply immediately. However there are some people using messaging for client-server. Notably OpenStack is using RabbitMQ this way. Another aspect to this is scaling: you might send a message to a mailbox, and on the other end [the sender doesn't know this] there could be a whole set of worker processes picking messages and working on them. Of course client-server can do that, but it requires changes to the client usually to make that happen. On the subject of ZeroMQ: while broker systems (qpid, RabbitMQ, etc) might seem a bit "boring" and "old fashioned", there's a good reason for setting up mailboxes and persisting messages, particularly when you're trying to make scalable, safe architectures.