Brokers

Messages are carried across networks using prescribed formatting and addressing protocols. The Socket API partially hides these details from programmers. We can complete the cover up by abstracting the network into an object called a message broker. A message broker is like a virtual network. It provides a name resolution service to hide network-dependent addresses, and it provides functions for sending and receiving messages.

There are many kinds of brokers that allow us to create interesting types of network services. A call back broker is similar to a publisher. It allows subscribers to register functions that should be called when a certain type of message for the subscriber is received by the broker. This is similar to the event manager discussed in the problem section of Chapter 2. Recall that an event manager is a notification mechanism that calls a registered subscriber function when a certain type of event occurs.

Technically, a dispatcher isn't really a broker, it is simply a name server similar to the table server implemented earlier, only it stores associations between names of servers and their current locations. A location might be a pointer, OID, IP address, port number, or URL. A dispatcher is comparable to the white pages in a telephone directory— a client that knows the name of a server, but not its location, so it asks a dispatcher to look up the location. After that, it's up to the client to establish a connection to the server. Port mapper daemons and domain name servers are examples of dispatchers.

If a dispatcher is analogous to the white pages of a telephone directory, then a trader system is analogous to the yellow pages. A client knows the name of the service it wants performed, so it contacts a trader system to get the location of a convenient server that currently provides this service. "Convenient" might mean "nearby" or "not busy".

Here is the basic Broker design pattern:

Broker [POSA], [Go4]

Other names

Object request broker, ORB, ORB Architecture. Brokers are similar to mediators, dispatchers, message pumps, component containers.

Problem

A client needs to communicate with multiple servers. Server locations can change. Server implementation languages are unknown. We also want to avoid dependence on a particular IPC mechanism.

Solution

A broker is the software-equivalent of a bus or the transport layer of a network. Correspondent's (which are analogous to ICs or host nodes) can use a broker to send and receive messages. The broker provides a naming service, so correspondents can refer to each other by name rather than location. The broker hides the IPC mechanism from correspondents. We can use remote broker proxies to hide language differences.

Structure

An in-process broker is used to pass messages between local objects:

For example, every MFC program is driven by a controller called theApp:

CWinApp theApp;

This controller is essentially an active message broker (see Problem 7.11). It perpetually monitors a message queue. When a message arrives, theApp extracts it and forwards it to its target. This design is useful for communication between threads. It also promotes looser coupling between objects.

An out-of-process broker might use remote proxies to create the illusion that each correspondent has an in-process broker implemented in the correspondent's language:

ORB architectures such as CORBA and Java RMI combine brokers with remote server proxies:

Brokers may also use the Chain of Command design pattern to forward messages to other brokers. For example, each computer on a network may have a broker that knows about all servers running on its machine. Requests for other servers are forwarded to a broker running on another machine according to some routing algorithm. (See Problem 7.13.)