Messaging systems need to support different communication patterns: sometimes you want one-to-one delivery (like a personal SMS), and sometimes one-to-many broadcast (like a radio station). Without distinct models, the messaging API would be ambiguous about delivery semantics.
JMS defines two messaging domains: Point-to-Point (PTP) uses Queues for one-to-one delivery (each message consumed by exactly one receiver), while Publish/Subscribe (Pub/Sub) uses Topics for one-to-many broadcast (each message delivered to all subscribers).
- Producer sends message to a Queue destination
- Message stays in queue until a Consumer receives it
- Each message is consumed by exactly one consumer (even if multiple consumers are listening)
- If no consumers are available, message remains in queue until one connects
- Publisher sends message to a Topic destination
- All active Subscribers registered to that topic receive the message
- Each subscriber gets its own copy of the message
- Durable subscribers can receive messages even if they were offline (messages persisted)
| Interface | PTP (Queue) | Pub/Sub (Topic) |
|---|---|---|
| ConnectionFactory | QueueConnectionFactory | TopicConnectionFactory |
| Connection | QueueConnection | TopicConnection |
| Session | QueueSession | TopicSession |
| Destination | Queue | Topic |
| Producer | QueueSender | TopicPublisher |
| Consumer | QueueReceiver | TopicSubscriber |
- PTP: Guarantees exactly-once delivery to a single consumer; good for load balancing work across consumers
- Pub/Sub: Broadcasts to all subscribers; good for event notification, news feeds
- PTP Queue messages persist until consumed; Pub/Sub Topic messages only go to active subscribers (unless durable)
- Same JMS code structure, different interface types for each domain
- EJB MDBs can listen to either Queues or Topics
- Built from: JMS — these are the two JMS messaging domains
- Built from: JMS Programming Model — the model applies to both PTP and Pub/Sub
- Builds into: MDB — MDBs consume from either Queues or Topics
- Related: Queue Partitioning — using multiple queues for traffic separation
- Contrasts with: RMI-IIOP — RMI is always 1:1, messaging offers both 1:1 and 1:N
- Pub/Sub with no active subscribers means messages are lost (unless durable subscriptions)
- PTP with multiple consumers: you can’t predict which consumer gets which message
- Mixing Queue and Topic interfaces (e.g., using
QueueSenderwith a Topic) causes runtime errors - Durable subscribers in Pub/Sub must be explicitly created and have a unique client ID