I'm having a hard time understanding what the usefulness of 'messaging' is. Could someone point them out or point me to a few real world applications? I've checked the wiki and I'm still puzzled.
For example, a process can do part of a job, and pass it along to a mailbox. Another process can (perhaps later, or on a different machine) pick up work from this mailbox and finish it. This can hide the network topology (although in practice, that's not really so true) and also makes it easier to manage because you can take down or restart systems without losing work.
Messaging systems like Apache / Red Hat's qpid are getting very advanced, for example offering guaranteed latency, guarantees against loss of messages, and multiple ways to set up communications. You can set it up so one process "publishes" data while other processes "subscribe" to that feed of data. You can have 1-N, N-1 and N-M mailboxes. You can have edge-triggered or level-triggered data in some message systems.
In the majority of messaging systems, you have a process known as the "broker" which runs on all/most machines, and basically acts as the mailbox, persistent storage and router. It's kind of like sendmail on steroids.
Zero MQ is unusual because there is no broker, and it acts more like an advanced sockets library. There are reasons why this is both good and bad compared to ordinary broker systems.
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.
An alternative in the same space is remote procedure call (RPC). RPC is synchronous while messaging is asynchronous.
http://highscalability.com/strategy-flickr-do-essential-work...