Broker

The Broker Pattern structures distributed software systems that interact with remote service invocations. It is responsible for coordinating the communication, its results, and exceptions.

The Broker Pattern from the book  “Pattern-Oriented Software Architecture, Volume 1” helps solve many challenges of distributed systems, such as finding the appropriate service provider, communicating with them securely, using the right programming language, or dealing with errors. This will not go into the details. It should only provide you with a rough idea of the Broker Pattern. For further information, study the pattern in the book “Pattern-Oriented Software Architecture, Volume 1“.

Broker

Purpose

• A complex software system should be designed as a set of decoupled and interacting subsystems.
• This has the following consequences:
  • All subsystems must communicate with each other using an inter-process communication protocol (IPC)
  • A subsystem must find its appropriate service
  • The services must be managed
• The used service should be transparent for the client

Solution

• Introduce a broker that brings the service provider and the service user together.
• The service providers register with the broker. The client requests the broker, which connects it to the service provider.
• The broker provided the infrastructure for communicating, finding, and configuring the subsystems through a simple API.

Structure

The Broker consists of five components:

Client

• Implements the application functionality
• Sends requests to the server via the Client-Side Proxy

Client-side Proxy

• Encapsulates system-specific functionality
• Speaks the language of the Client
• Mediates between the client and the broker

Server

• Implements services
• Registers itself with the Broker


Server-side Proxy

• Calls server services
• Speaks the language of the Server
• Encapsulates system-specific functionality
• Mediates between the Server and the Broker

Broker

• (Un-)registers servers
• Transfers messages and errors
• Locates servers

There are more interesting aspects of the Broker Architecture.

Interface Definition Language

Typically, the server’s services are specified in an interface definition language (IDL).  The IDL is the base  Client-Side Proxy, and the Server-Side Proxy. Here are the two typical steps:

1. Use the programming language agnostic IDL to generate the stub and skeleton for a specific programming language. This can often be done for various programming languages.
2. Implement the Client-Side Proxy and the Server-Side Proxy based on the stub and skeleton.

The IDL may also be registered within the Broker.This helps the broker to find the appropriate Server-Side Proxy, when asked by the Client-Side Proxy.

The benefit of the Broker architecture is that clients and servers can communicate with each other, although they speak different programming languages.

So far, I have described the static structure of the Broker Pattern. Let’s consider the interplay between the client and the server.

The Client has a Request

When a client wants to use a remote service, it asks the Broker for it. The Broker returns the Client-Side Proxy that implements the remote service’s interface. The Client-Side Proxy manages the caching of data, the inter-process communication, or the marshaling/serialization of data. It connects with the Server-Side Proxy that calls the server. The Server-Side Proxy has a similar job, such as the Client-Side Proxy. It essentially unmarshals the data and speaks the language of the server. When the server sends back the function call result, it calls its Server-Side Proxy, which communicates with the client-side proxy. 

 

The Server registers itself

During the initialization of the system, the Broker starts itself and enters its event loop. The server initializes and registers itself with the Broker. The server receives the registration confirmation from the Broker and enters its event loop.

Additional Brokers

Sometimes there is more than one Broker. One Broker can, therefore, delegate the services request to another Broker. In this advanced architecture, each Broker must support two protocols. One internal protocol for its Client-Side Proxy and Server-Side Proxy and one external protocol for the other Broker.

 

There are many examples of Broker architectures.

Examples

SunRPC

The program rpcgen generates from an interface description stubs, skeletons, and an XDR file for data conversion

rpcgen provides an API for remote function calls in C

Remote Method Invocation (RMI):

The rmic compiler generates the stubs and skeletons from a server interface in Java

In contrast to the function references in SunRPC, these are object references

Since Java 5, the stubs and skeletons are implicitly created by the Java Virtual Machine

Common Object Request Broker Architecture (CORBA):

CORBA uses the IDL for the interface description

The syntax of the IDL is C++ oriented

CORBA refers to objects such as RMI

Standardized implementation of the IDL2Language compiler exists for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I, and Python

C++ Implementation: The ADAPTIVE Communication Environment (ACE)

Simple Object Access Protocol (SOAP):

The interface description language is called Web Service Definition Language (WSDL)

WSDL is a text-based protocol (XML)

The WSDL is not only declarative but specifies the type of data transfer and the service points

Implementations of a wsdl2Compiler code generator exist in Java, C++, Python, Perl, …

C++ Implementation: gSOAP

Pros and Cons

Pros

• Location independence of the client and server through the intermediary
• The client is independent of implementation changes of the server
• Modifications of the IDL can be implemented easily so that only slight adaptations on the client and server are necessary
• It is easy to port the Broker to a different system because the client and server don’t use system-specific functionality
• Clients or servers speaking other programming languages are pretty easy to add if an IDL to the programming language compiler is available
• New services are straightforward to add because they can use the existing Broker architecture
• SOAP is a text-based protocol; This makes it pretty easy to analyze the communication with UNIX-based command line tools or implement a simple program sending text.

Cons

• Due to the many indirections (Client -> Client-Side Proxy -> Broker -> Server-Side Proxy -> Server), data marshaling, and inter-process communication, the performance is not good enough; after the first communication of the Client-Side Proxy and the Server-Side Proxy is performed, both components often talk directly with each other without the intermediate Broker
• The communication of the parties depends on many components and is, therefore, difficult to debug in the error case; besides SOAP, the other protocols are binary

What’s Next?

The Model-View-Controller (MVC) is one of the classic architectural patterns. It divides the program logic of a user interface into separate components model, view, and controller. The model manages the data and rules of the application. The view represents the data, and the controller interacts with the user. Let me present the MVC in my next post.