This is especially useful when a consumer is subscribed to many destinations, as it helps identify the exchanged data.Ī message may also contain headers.

When a consumer receives this message, it can use this information to know which destination held this message. When a producer sends a message to a destination, the name of the destination is put inside the message. A set of brokers can constitute a cluster, and messages can flow from one to another before they are finally delivered to a consumer. Producers and consumers need to know about the broker to connect to it, but they may not even connect to the same broker. At that moment, the broker will deliver the message to the consumer. The message will be held by the broker until a consumer subscribes to the same destination. The producers can send a message and exit. Producers and consumers do not even need to be online at the same time. The consumed message could contain enough information to identify the application, but that is not required (and more often than not, it is not necessary). Likewise, when an application consumes a message, it does not know which application sent it, as they never communicate directly.

It is also possible that the message will not be consumed at all if nobody has registered any interest for it. There may be one or many consumers that will receive the message. When one application produces a message, it has no knowledge of when or where the message will be consumed.

The producer and consumer know nothing about each other. One key aspect of messaging is that it loosely couples its participants. In this book, I will always use the general terms producer and consumer. Likewise, the consumer may be called receiver or subscriber. Depending on the messaging protocol or model, the producer is sometimes called sender or publisher.

Messaging for web