Broker pattern: Difference between revisions
Content deleted Content added
m Corrected odd phrasing |
|||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{confused|Mediator pattern}} |
{{confused|Mediator pattern}} |
||
{{Prose|date=February 2023}} |
{{Prose|date=February 2023}} |
||
The '''broker pattern''' is an [[architectural pattern]] that can be used to structure [[distributed software]] systems with decoupled components that interact by [[remote procedure call]]s. A broker component is responsible for coordinating communication, such as forwarding requests, as well as |
The '''broker pattern''' is an [[architectural pattern]] that can be used to structure [[distributed software]] systems with decoupled components that interact by [[remote procedure call]]s. A broker component is responsible for coordinating communication, such as forwarding requests, as well as transmitting results and exceptions.<ref>{{Cite web|url=https://www.oreilly.com/library/view/pattern-oriented-software-architecture/9781119963998/chap12-sec005.html|title=Solution: Use a Broker - Pattern-Oriented Software Architecture For Dummies [Book]|website=www.oreilly.com|accessdate=26 March 2023}}</ref> |
||
== Definition == |
== Definition == |
||
The broker pattern is an architecture pattern that involves the use of an intermediary software entity called "broker" to facilitate communication between two or more software components. The broker acts as a "middleman" between the components, allowing them to communicate without being |
The broker pattern is an architecture pattern that involves the use of an intermediary software entity, called a "broker", to facilitate communication between two or more software components. The broker acts as a "middleman" between the components, allowing them to communicate without being aware of each other's existence. |
||
In the broker pattern, the broker is responsible for receiving messages from one component and forwarding them to the appropriate recipient. The components that communicate through the broker are known as servers or clients. The broker may also perform additional tasks, such as filtering, modifying messages, ensuring a [[quality of service]] (QoS) e.g. 0 for "at most once", |
In the broker pattern, the broker is responsible for receiving messages from one component and forwarding them to the appropriate recipient. The components that communicate through the broker are known as servers or clients. The broker may also perform additional tasks, such as filtering, modifying messages, ensuring a [[quality of service]] (QoS) (e.g. 0 for "at most once"), security, or providing additional services to the software components. |
||
The broker pattern allows the components to remain decoupled and focused on their own responsibilities, while still being able to communicate and collaborate with other components in the system. It can also be used to reduce the number of dependencies between components, making the system more flexible and easier to maintain. |
The broker pattern allows the components to remain decoupled and focused on their own responsibilities, while still being able to communicate and collaborate with other components in the system. It can also be used to reduce the number of dependencies between components, making the system more flexible and easier to maintain. |
||
| Line 19: | Line 19: | ||
'''Server''' |
'''Server''' |
||
* Software components responsible for sending a message out. |
* Software components responsible for sending a message out. |
||
* It |
* It is also referred to as a ''publisher''. |
||
'''Client''' |
'''Client''' |
||
* Software components that subscribed and |
* Software components that subscribed and await a specific message. |
||
* It can also be |
* It can also be referred to as ''a consumer'' or ''subscriber.'' |
||
** ''Consumer'' |
|||
** ''Subscriber'' |
|||
== Advantages == |
== Advantages == |
||
Source:<ref>{{Cite journal|url=https://www.academia.edu/57594620|title=The Broker Architectural Framework|first=Michael|last=Stal|date=1 January 1995|accessdate=26 March 2023|via=www.academia.edu}}</ref> |
Source:<ref>{{Cite journal|url=https://www.academia.edu/57594620|title=The Broker Architectural Framework|first=Michael|last=Stal|date=1 January 1995|accessdate=26 March 2023|via=www.academia.edu}}</ref> |
||
* Dynamic changes, additions, deletions and relocations of components possible. |
* Dynamic changes, additions, deletions, and relocations of components possible. |
||
* One source of communication with |
* One source of communication with the broker, which defines the interface. |
||
* Components do not need to know each other. |
* Components do not need to know each other. |
||
| Line 44: | Line 42: | ||
== Confusions around the pattern == |
== Confusions around the pattern == |
||
The broker pattern and [[publish–subscribe pattern]] have some similarities and are sometimes confused.<ref>{{Cite web|url=https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment/|title=MQTT Client and Broker and MQTT Server Connection Establishment Explained - MQTT Essentials: Part 3|first=The HiveMQ|last=Team|website=www.hivemq.com|accessdate=26 March 2023}}</ref> Nevertheless, when it comes to the representation, there are some core differences: |
|||
* The ''Broker architectural pattern'' is represented by a ''Many'' to ''One'' to ''Many'' diagram. |
* The ''Broker architectural pattern'' is represented by a ''Many'' to ''One'' to ''Many'' diagram. |
||
* The ''Publish-subscribe architectural pattern'' is represented by ''Many'' to ''Many'' diagram. Here, the messaging functionalities are ''hidden'' as a [[Cross-cutting concern]]. |
* The ''Publish-subscribe architectural pattern'' is represented by a ''Many'' to ''Many'' diagram. Here, the messaging functionalities are ''hidden'' as a [[Cross-cutting concern]]. |
||
==References== |
==References== |
||
| Line 53: | Line 51: | ||
{{Design Patterns Patterns}} |
{{Design Patterns Patterns}} |
||
{{DEFAULTSORT:Design Pattern (Computer Science)}} |
|||
[[Category:Software design patterns]] |
[[Category:Software design patterns]] |
||
Latest revision as of 20:27, 4 April 2024
 |
The broker pattern is an architectural pattern that can be used to structure distributed software systems with decoupled components that interact by remote procedure calls. A broker component is responsible for coordinating communication, such as forwarding requests, as well as transmitting results and exceptions.[1]
Definition
[edit]The broker pattern is an architecture pattern that involves the use of an intermediary software entity, called a "broker", to facilitate communication between two or more software components. The broker acts as a "middleman" between the components, allowing them to communicate without being aware of each other's existence.
In the broker pattern, the broker is responsible for receiving messages from one component and forwarding them to the appropriate recipient. The components that communicate through the broker are known as servers or clients. The broker may also perform additional tasks, such as filtering, modifying messages, ensuring a quality of service (QoS) (e.g. 0 for "at most once"), security, or providing additional services to the software components.
The broker pattern allows the components to remain decoupled and focused on their own responsibilities, while still being able to communicate and collaborate with other components in the system. It can also be used to reduce the number of dependencies between components, making the system more flexible and easier to maintain.
Terminology
[edit]Broker
- Maintain a routing table of registered software components.
- Maintain a filter table to reroute the transiting messages to the right software components.
- May assure additional functionalities such as information security and quality of service.
Server
- Software components responsible for sending a message out.
- It is also referred to as a publisher.
Client
- Software components that subscribed and await a specific message.
- It can also be referred to as a consumer or subscriber.
Advantages
[edit]Source:[2]
- Dynamic changes, additions, deletions, and relocations of components possible.
- One source of communication with the broker, which defines the interface.
- Components do not need to know each other.
Disadvantages
[edit]- One central component that needs to be robust and efficiently written.
- No data consistency of transmitted messages.
Real-life implementation of the pattern
[edit]Confusions around the pattern
[edit]The broker pattern and publish–subscribe pattern have some similarities and are sometimes confused.[3] Nevertheless, when it comes to the representation, there are some core differences:
- The Broker architectural pattern is represented by a Many to One to Many diagram.
- The Publish-subscribe architectural pattern is represented by a Many to Many diagram. Here, the messaging functionalities are hidden as a Cross-cutting concern.
References
[edit]- ^ "Solution: Use a Broker - Pattern-Oriented Software Architecture For Dummies [Book]". www.oreilly.com. Retrieved 26 March 2023.
- ^ Stal, Michael (1 January 1995). "The Broker Architectural Framework". Retrieved 26 March 2023 – via www.academia.edu.
{{cite journal}}: Cite journal requires|journal=(help) - ^ Team, The HiveMQ. "MQTT Client and Broker and MQTT Server Connection Establishment Explained - MQTT Essentials: Part 3". www.hivemq.com. Retrieved 26 March 2023.
 | This computer-programming-related article is a stub. You can help Wikipedia by expanding it. |