Broker Pattern

The Broker architectural pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, forwarding requests, transmitting results and exceptions, message translations, etc.

Use the Broker architecture to balance the following forces:

  • Components should be able to access services provided by others through remote, location-transparent service invocations.
  • You need to exchange, add, or remove components at run-time.
  • The architecture should hide system- and implementation-specific details from the users of components and services


  • Message brokers can become a performance bottleneck.
  • Brokers can be replicated or clustered.
  • Business Process Orchestration (BPO) platforms are commonly built as a layer on top of a message broker. They extend message broker by adding: state management, deployment and development tools.
  • Message Broker can take care of a spaghetti architecture and fix it.

Introduce a broker component to achieve better decoupling of clients and servers. Servers register themselves with the broker, and make their services available to clients through method interfaces. Clients access the functionality of servers by sending requests via the broker. A broker's tasks include locating the appropriate server, forwarding the request to the server and transmitting results and exceptions back to the client.

The Broker pattern reduces the complexity involved in developing distributed applications, because it makes distribution transparent to the developer. It achieves this goal by introducing an object model in which distributed services are encapsulated within objects. Broker systems therefore offer a path to the integration of two core technologies: distribution and object technology. They also extend object models from single applications to distributed applications consisting of decoupled components that can run on heterogeneous machines and that can be written in different programming languages.

Participating Parts:

Client, server, broker, bridge, client-side proxy and server-side proxy

Client-side proxies represent a layer between clients and the broker. This additional layer provides transparency, in that a remote object appears to the client as a local one.

Server-side proxies are generally analogous to Client-side proxies. The difference is that they are responsible for receiving requests, unpacking incoming messages, unmarshaling the parameters, and calling the appropriate service. They are used in addition for marshaling results and exceptions before sending them to the client.

Bridges are optional components used for hiding implementation details when two brokers interoperate. Suppose a Broker system runs on a heterogeneous network.

The server implementations use API functions primarily for registering with the broker. Brokers use repositories to maintain the information. These repositories may be available as external files, so that servers can register themselves before system start-up. Another approach is to implement the repository as an internal part of the broker component.


Callback Broker System:
Instead of implementing an active communication model in which clients produce requests and servers consume them, you can also use a reactive model. The reactive model is event-driven, and makes no distinction between clients and servers. Whenever an event arrives, the broker invokes the callback method of the component that is registered to react to the event. The execution of the method may generate new events that in turn cause the broker to trigger new callback method invocations.

Direct Communication:
When a client invokes a method of a server, the Broker system is responsible for returning all results and exceptions back to the original
client. In other words, the system must remember which client has sent the request. In the Direct Communication variant there is no need to remember the originator of an invocation, because the client and the server are directly connected through a communication channel.

Related patterns:

Forwarder-Receiver pattern:
Encapsulates inter-process communication between two components. On the client side a forwarder receives a request and addressee from the client and handles the mapping to the IPC (inter-process communication) facility used. The receiver on the server side unpacks and delivers the message to the server. There is no broker component in this pattern.

Remote Proxy pattern:
Is often used in conjunction with a forwarder. The proxy encapsulates the interface and remote address of the server. The forwarder takes the message and transforms it into IPC-level code.

Client-DispatcherServer pattern:
Is a lightweight version of the Direct Communication Broker variant. A dispatcher allocates, opens and maintains a direct channel between client and server.

Mediator design pattern:
Replaces a web of inter-object connections by a star configuration in which the central mediator component encapsulates collective behavior by defining a common interface for communicating with objects. As with the Broker pattern, the Mediator pattern uses a hub of communication, but it also has several major differences. The Broker pattern is a large-scale infrastructure paradigm-it is not used for building single applications, but rather serves as a platform for whole families of applications.

See message broker example in Essential Software Architecture book by Ian Gordon and Microsoft BizTalk.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License