This section discusses how event messages move through
Topics
Topics are central to how PubSub+ event brokers move events from publishers to subscribers. For more general information about PubSub+ topics, see Understanding Topics.
In PubSub+, topics follow a hierarchical structure consisting of multiple levels, each of which provides contextual details about the event. This structure both describes the event and effectively routes events across an event-driven system and ensures consumer applications have the flexibility to selectively consume only the events they want.
To learn about best practices for constructing your topic architecture, see Topic Architecture Best Practices.
For information about general topic syntax, see Solace Message Format Topics.
You can use wildcards in topic subscriptions to refine the information received by message consumers. For more information, see Wildcard Characters in Topic Subscriptions.
PubSub+ event brokers also have a number of reserved or special topics that are used to configure a range of capabilities such as queue routing, message promotion and demotion, and disaster recovery. For more information, see Reserved Topics.
Direct and Guaranteed Messaging
PubSub+ event brokers support both Direct messaging and Guaranteed messaging.
Direct messaging is meant for use with high-rate or very low-latency message messaging applications that can tolerate occasional message loss. Producers can publish messages to a topic and, when the messages are received by the event broker, they can be delivered efficiently to a large number of clients with matching topic subscriptions. Direct messaging has the following characteristics:
- Clients subscribe to topics directly.
- Messages are not retained for a client when that client is not connected to an event broker.
- Messages can be discarded when congestion or system failures are encountered.
- Messages are not acknowledged upon delivery.
For more information, see Direct Messages.
Guaranteed messaging is most appropriate for messaging applications that require persistent storage of the messages they send or intend to receive. Guaranteed messaging has the following characteristics:
- Topic subscriptions are associated with an endpoint (queue or topic endpoint) on the event broker rather than consuming clients.
- Messages can't be lost once they are acknowledged by the event broker.
- When messages are delivered to a durable endpoint, they are retained until they are consumed by a client.
- Delivery to a client is acknowledged.
For more information, see Guaranteed Messages.
Persistence and Durability
Although the terms persistent and durable are related, the concept of persistence applies to event messages, and durability applies to endpoints.
Persistence refers to the quality-of-service (QoS) of event messages. Event messages are considered persistent if they are placed onto non-volatile storage media after they arrive on the event broker. Persistent messages are also known as Guaranteed messages. The event broker's data plane stores a message if the message arrives with the Persistent Delivery Mode set to Persistent, or if a queue or durable topic endpoint has subscribed to a topic where messages are persisted regardless of the Persistent Delivery Mode flag setting in the message. Messages flagged as Persistent result in an acknowledgment message being sent back to the producer after the message is stored.
If an event message is sent with Persistent Delivery Mode set to Direct, the message is only placed onto the non-volatile storage media if the message topic is subscribed to by a queue or a durable topic endpoint.
In some cases a message may have a Persistent Delivery Mode of Non-Persistent if it is published using JMS APIs or it is promoted from a Direct message. For more information, see Topic Matching and Message Delivery Modes.
Durability
Endpoint Durability is a characteristic of a PubSub+ queue or topic endpoint. Durable endpoints operate whether or not consumers are active. For example, queue messages are still available if an event broker fails or there is a high availability (HA) or disaster recovery (DR) failover. Messages are considered to be persistent in a general sense if they are associated with a durable queue because they remain on the event broker regardless of the life span of particular client session or event broker restart.
Temporary queues aren't considered to be durable. Messages sent to temporary queues are persisted to storage, but they're deleted if the active temporary queue consumer unbinds or disconnects. Therefore, the endpoint is not durable beyond the life of the consumer.
To learn more about durable and non-durable queues, see Topic Endpoints and Queues.
Messaging Patterns
PubSub+ supports a array of messaging patterns to suit a wide variety of needs. Commonly used patterns include:
- Publish-Subscribe Exchange Pattern
- Request-Reply Exchange Pattern
- Competing Consumer Scaling Pattern
- Consumer High Availability
- Event Messaging Overview
Publish-Subscribe Exchange Pattern
With publish-subscribe messaging, messages sent by the producer (publisher) can be processed multiple times by different consumers (subscribers). A published event can be delivered to multiple consumers based on the topic subscriptions they have defined. Each consumer receives its own copy of the message for processing.
Request-Reply Exchange Pattern
With request-reply messaging, applications achieve two-way communication using separate point-to-point channels: one for requests, and another for replies. In a request-reply pattern, the applications are both producers and consumers.
Competing Consumer Scaling Pattern
Competing consumers is a scalability pattern in event-driven architecture that involves distributing the workload of processing events among multiple instances of the same application to improve throughput and reduce processing time. In this mode, the queue has a non-exclusive access type, which facilitates the delivery of messages to all bound consumer flows in a round-robin fashion. This pattern is commonly used when message order is not important and you need to scale consumers to keep up with the message throughput.
Consumer High Availability
When you implement a high availability (HA) consumer scaling pattern, you have multiple instances of the same consumer application available to process events. One instance of the consumer is chosen to be active and receives all events, while the other instances are on standby. If the active instance crashes or goes down, the broker automatically elects another instance to activate and starts sending all events to the new consumer. This pattern ensures that event processing continues as long as you have one instance connected and processing. This pattern is also sometimes referred to as Primary / Secondary or Primary / Secondary / Tertiary depending on how many levels of redundancy are required.
To implement this pattern, the queue has the exclusive access type. This access type allows multiple consumers to connect, but the event broker delivers events to only one of them. If the active consumer disconnects, the next consumer to receive events is randomly selected from the waiting pool of consumers. This pattern is commonly used when all messages in a queue must be processed in order.
Partitioning
Partitioning is a design pattern in event-driven architecture that helps to improve scalability while also maintaining message order where it’s required. You effectively split up a stream of events into partitions, which can then be processed in parallel. Order is maintained by partition instead of across the entire event stream. This pattern is common when you need to scale your consumers, but you also care about message order.
In PubSub+, this pattern is implemented using partitioned queues. Partitioned queues are a type of non-exclusive queue that delivers to many consumers at once to enable scaling. Partitioned queues use a partition key to split ingress events into partitions. All events within a partition are always delivered to the same consumer, thus enabling scalability while maintaining the message order. For more information, see Partitioned Queues.