Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal
"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, such as forwarding requests, as well as for transmitting results and exceptions." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996
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 brokers tasks include locating the appropriate server, forwarding the request to the server and transmitting results and exceptions back to the client. By using the Broker pattern, an application can access distributed services simply by sending message calls to the appropriate object, instead of focusing on low-level inter-process communication. In addition, the Broker architecture is flexible, in that it allows dynamic change, addition, deletion, and relocation of objects. The Broker pattern reduces the complexity involved in developing distributes 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. For a more detailed Motivation description for this pattern see: Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996.
This pattern has been used on the following systems: CORBA. Common Object Request Broker Architecture (CORBA) is an object-oriented technology for distributing objects on heterogeneous systems. The CORBA defined by the Object Management Group used the Broker architectural pattern. The support of interoperability of client and server objects is made available through an interface definition language. (Object Management Group, The Common Object Request Broker: Architecture and Specification, OMG Document Number 91.12.1, Revision 1.1, 1992.) IBM SOM/DSOM. This is a CORBA-compliant Broker system that combines the CORBA interface definition language with a binary protocol. (Campagnoni, F.R., IBMs System Object Model, Dr. Dobbs Journal, Special Report, #225 Winter 1994/95, pp. 24-28.) Microsofts OLE 2.x uses the Broker pattern and defines a binary standard for exposing and accessing server interfaces. (Brockschmidt, K., Inside OLE 2, Microsoft Press, 1994.) In the World Wide Web the Broker system is used as the hypertext browsers (i.e. HotJava, Mosaic, Netscape, etc.) act as the brokers and the WWW servers have the role of the service providers. ATM-P. This Siemens in-house project to build a telecommunication switching system based on ATM implemented the Message Passing Broker System variant. (Siemens AG, ATM-P: Komplexspezifikation, internal document, 1993.)
Forwarder-Receiver, Proxy, Client-Dispatcher-Server, and Mediator patterns
Proxy pattern, Mediator pattern, Broker pattern, Forwarder-Receiver pattern, Client-Dispatcher-Server pattern, Buschmann patterns, architectural patterns, forward requests, structure distributed software systems, communication (coordination)
any system that is distributed and possibly heterogeneous with independent cooperating componentsinformation system
components may be distributed across networkscomponents need to be exchanged, added, or removed at run-timecomponents need to communicatecomponents should be able to access services provided by others through remote, location-transparent service invocationscomponents should be independent of communication mechanismneed a structure for distributed, de-coupled components
changeability and extensibility of componentsinteroperability between different Broker systemslocation transparencyportability of a broker systemreusability
error handlinglower fault tolerancerestricted efficiencytesting and debugging
Simple implementation of the pattern - ServerProxy. ServerProxy.javaSimple implementation of the pattern - Server. Server.javaSimple implementation of the pattern - ClientProxy. ClientProxy.javaSimple implementation of the pattern - Client. Client.javaSimple implementation of the pattern - Broker. Broker.javaSimple implementation of the pattern - Bridge. Bridge.javaSimple implementation of the pattern. broker.h