An application needs to consume Messages, but it wants to control when it consumes each message.
How can an application consume a message when the application is ready?
The application should use a Polling Consumer, one that explicitly makes a call when it wants to receive a message.
This is also known as a synchronous receiver, because the receiver thread blocks until a message is received. We call it a Polling Consumer because the receiver polls for a message, processes it, then polls for another. As a convenience, messaging API’s usually provide a receive method that blocks until a message is delivered, in addition to methods like receiveNoWait() and Receive(0) that return immediately if no message is available. This difference is only apparent when the receiver is polling faster than messages are arriving.
A Polling Consumer is an object that an application uses to receive messages by explicitly requesting them. When the application is ready for another message, it polls the consumer, which in turn gets a message from the messaging system and returns it. (How the consumer gets the message from the messaging system is implementation-specific and may or may not involve polling. All the application knows is that it doesn’t get the message until it explicitly asks for one.)
... Read the entire pattern in the book Enterprise Integration Patterns
Competing Consumers, Durable Subscriber, Event-Driven Consumer, Message, Message Dispatcher, Selective Consumer, Transactional Client