Scribd
Upload
12 views

The Broker Pattern

The Broker pattern serves as a structural framework for distributed software systems where a broker facilitates communication between independent components like clients and services. The broker receives requests from clients and redirects them to the appropriate server while also returning responses. This allows components to interact without direct knowledge of each other and supports seamless expansion of the system.

Uploaded by

ims
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
12 views

The Broker Pattern

The Broker pattern serves as a structural framework for distributed software systems where a broker facilitates communication between independent components like clients and services. The broker receives requests from clients and redirects them to the appropriate server while also returning responses. This allows components to interact without direct knowledge of each other and supports seamless expansion of the system.

Uploaded by

ims
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

The Broker Pattern

The Broker pattern serves as a structural framework for distributed


software systems housing independent components. Within this, a broker
assumes the crucial role of facilitating communication among these system
elements.
Upon receiving a request from a client, the broker redirects it to the
appropriate server and channels back the ensuing response to the client.
Importantly, this interaction remains exclusive to the broker's domain, shielding
the client and server components from direct acquaintance.
Given potential disparities in data formats between clients and servers,
both ends engage in serialization and deserialization to ensure seamless
communication. This entails the placement of a proxy between the broker and
the server/client, preserving the sanctity of the open-closed principle.
Recommended for scenarios where software systems are poised for
expansion, the Broker pattern advocates for the design of a constellation of
independent yet interconnected subsystems.

These subsystems should:


- Foster seamless communication among themselves.
- Offer runtime configurability.
- Embrace user-friendliness.
The components of this architecture are:
The Broker: Positioned at the nexus, the broker acts as a conduit between
disparate components, facilitating their collaboration via intermediary
mechanisms.
The Services: These modules or objects deliver specialized functionalities and
seek interaction with peer modules. They rely on the broker for accessing
services or extending their offerings to other modules.
The Clients: Representing the seekers of services, clients interface with the
system to avail themselves of functionalities offered by other modules. They
rely on the broker to navigate the system landscape and access desired
services.

Benefits the Broker pattern include:


- Components remain isolated, enhancing system flexibility and simplifying
maintenance.
- Centralized access to components via the broker enables seamless
integration across modules or applications, minimizing code
modifications.
- The broker facilitates easy addition or removal of services, enhancing
system scalability without disruption.
Cons of the Broker pattern:
- Brokers add a layer of indirection and hence latency, between clients
and servers, and that layer may be a communication bottleneck.
- The broker can be a single point of failure.
- A broker adds up-front complexity.
- A broker may be a target for security attacks.
- A broker may be difficult to test.

You might also like