Publish-Subscribe Pattern
(Redirected from Pub/sub)
Jump to navigation
Jump to search
A Publish-Subscribe Pattern is an asynchronous messaging pattern that allows different components to communicate with each other without coupling or blocking.
- Context:
- It can (typically) be composed of Pub/Sub Publishers that generate messages that encompass information on events or changes in the system.
- It can (typically) be composed of Pub/Sub Subscribers that receive messages that align with their subscription criteria.
- It can (typically) be composed of a Pub/Sub Broker that is accountable for routing, filtering, and delivering messages from publishers to subscribers.
- It can ensure that publishers and subscribers do not require awareness of each other's identity, location, or implementation details.
- It can require an agreement on a common message format and a topic or channel to publish and subscribe to is sufficient.
- It can improve the scalability and performance of the system by allowing parallel and asynchronous processing of messages.
- It can support dynamic and flexible system configuration as it allows components to join or leave the system at any time.
- It can enable event-driven and reactive programming models, facilitating the handling of complex and unpredictable scenarios.
- It can decouple the components, reducing system complexity.
- ...
- Example(s):
- one presented in (Eugsterh et al., 2003).
- an AWS-based Pub/Sub Pattern, such as:
- one where news sources act as publishers and readers act as subscribers.
- ...
- Counter-Example(s):
- A Request-Reply pattern, which is a synchronous communication approach.
- A Point-to-point messaging pattern where only one consumer can consume a particular message, creating direct communication between the sender and receiver.
- ...
- See: Network Topology, Software Architecture, Messaging Pattern, Message Passing, Message Queue, Message-Oriented Middleware, Application Programming Interface, Scalability.
References
2023
- Bing Chat
- A publish-subscribe pattern is a asynchronous messaging pattern that allows different components to communicate with each other without coupling or blocking. The components are called publishers and subscribers, and they use a common intermediary called a broker or a bus to exchange messages. Publishers produce messages that contain information about events or changes in the system, and subscribers receive messages that they are interested in based on their subscription criteria. The broker or bus is responsible for routing, filtering, and delivering the messages from publishers to subscribers. This way, the publishers and subscribers do not need to know each other's identity, location, or implementation details. They only need to agree on a common message format and a topic or channel to publish and subscribe to .
- Some of the benefits of using a publish-subscribe pattern are :
- It decouples the components and reduces the complexity of the system.
- It improves the scalability and performance of the system by allowing parallel and asynchronous processing of messages.
- It supports dynamic and flexible system configuration by allowing components to join or leave the system at any time.
- It enables event-driven and reactive programming models that can handle complex and unpredictable scenarios.
- Some of the challenges of using a publish-subscribe pattern are :
- It may introduce latency and unreliability in the message delivery due to network failures or broker congestion.
- It may cause message duplication or loss if the broker does not provide guaranteed delivery or ordering of messages.
- It may require additional security and privacy mechanisms to protect the messages from unauthorized access or modification.
- It may increase the testing and debugging difficulty due to the lack of visibility and control over the message flow.
2017
- (Wikipedia, 2017) ⇒ https://en.wikipedia.org/wiki/Publish–subscribe_pattern Retrieved:2017-6-9.
- In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead characterize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.
Publish–subscribe is a sibling of the message queue paradigm, and is typically one part of a larger message-oriented middleware system. Most messaging systems support both the pub/sub and message queue models in their API, e.g. Java Message Service (JMS).
This pattern provides greater network scalability and a more dynamic network topology, with a resulting decreased flexibility to modify the publisher and the structure of the published data.
- In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead characterize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.
2003
- (Eugsterh et al., 2003) ⇒ Patrick T. Eugsterh, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. (2003). “The Many Faces of Publish / subscribe.” ACM computing surveys (CSUR), 35(2). https://doi.org/10.1145/857076.857078
- ABSTRACT: Well adapted to the loosely coupled nature of distributed interaction in large-scale applications, the publish/subscribe communication paradigm has recently received increasing attention. With systems based on the publish/subscribe interaction scheme, subscribers register their interest in an event, or a pattern of events, and are subsequently asynchronously notified of events generated by publishers. Many variants of the paradigm have recently been proposed, each variant being specifically adapted to some given application or network model. This paper factors out the common denominator underlying these variants: full decoupling of the communicating entities in time, space, and synchronization. We use these three decoupling dimensions to better identify commonalities and divergences with traditional interaction paradigms. The many variations on the theme of publish/subscribe are classified and synthesized. In particular, their respective benefits and shortcomings are discussed both in terms of interfaces and implementations.
