Patterns are an important abstraction in modern software development and software architecture. They offer well-defined terminology, clean documentation, and learning from the best. The Broker Pattern structures distributed software systems that interact with remote service calls. It is responsible for coordinating communications, their outcomes and exceptions.
Rainer Grimm has been working as a software architect, team leader and training manager for many years. He likes to write articles on the programming languages C++, Python and Haskell, but also likes to speak frequently at specialist conferences. On his blog Modernes C++ he deals intensively with his passion for C++.
The Broker Pattern from the book “Pattern-Oriented Software Architecture, Volume 1” helps to solve many challenges of distributed systems. This can be, for example, finding the right service provider, communicating with them securely, using the right programming language or dealing with errors. I will not go into detail in this article. It is only intended to give a rough overview of the broker pattern. More information can be found in the book “Pattern-Oriented Software Architecture, Volume 1”.
Broker
Purpose
- A complex software system should be designed as a series of decoupled and interacting subsystems.
- The service used should be transparent to the client.
- This has the following consequences:
- All subsystems must communicate with each other via an interprocess communication protocol (IPC).
- A subsystem has to find its suitable service.
- The services need to be managed.
Solution
- You introduce a broker that brings together the service provider and the service user.
- The service provider registers with the broker.
- The client makes a request to the broker, which then connects it to the service provider.
- The broker provides the infrastructure for communicating, finding and configuring the subsystems via a simple API.
Structure
The broker consists of five components:
Client
- Implements the application functionality and
- sends requests to the server via the
clientseitig Proxy.
clientseitig Proxy
- Encapsulates system-specific functions,
- speaks the language of the client and
- mediates between the client and the broker.
Server
- Implements services and
- registers with the broker.
serverseitig Proxy
- Calls server services,
- speaks the language of the server
- encapsulates system-specific functions and
- mediates between the server and the broker.
Broker
- Registers servers and deregisters them,
- transmits messages and errors and
- finds servers.
There are other interesting aspects of the broker architecture.
Interface Definition Language
Typically, the services offered by the server are defined in an Interface Definition Language (IDL). It is the basis for the client-side proxy and the server-side proxy. Here are the two typical steps:
- Using the programming language-independent IDL to create the stub and skeleton for a specific programming language. This is often possible for different programming languages.
- Implementing the client-side proxy and server-side proxy based on the stub and skeleton.
The IDL can also be registered within the broker so that the broker can find the appropriate server-side proxy when asked by the client-side.
The advantage of the broker architecture is that clients and servers can communicate with each other even though they speak different programming languages, for example.
So far I have described the static structure of the Broker pattern. Now I will look at the interaction between the client and the server.
The client has a request
If a client wants to use a service, he asks the broker for it. The latter returns the client-side proxy that implements the service’s interface. The client-side proxy manages data caching, interprocess communication, or data preparation (marshaling/serialization). It connects to the server-side proxy, which invokes the server. The server-side proxy has a similar task to the client-side proxy: it prepares the data and speaks the language of the server. When the server returns the result of the function call, it invokes its server-side proxy, which communicates with the client-side.
The server logs in
During system initialization, the broker starts itself and enters its event loop. The server initializes and registers 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. A broker can therefore delegate the service request to another broker. In this advanced architecture, each broker must support two protocols. An internal protocol for its client-side proxy and server-side proxy, and an external protocol for the other broker.
There are many examples of broker architectures.
examples
SunRPC:
The program rpcgen generates stubs, skeletons and an XDR file for data conversion from an interface description. rpcgen offers 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. Unlike the function references in SunRPC, these are object references. Since Java 5, the stubs and skeletons are implicitly generated 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 uses objects similar to RMI. Standardized implementations of IDL2Language Compilers are available for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I and Python.
Simple Object Access Protocol (SOAP):
Web Service Definition Language (WSDL) is used as the interface description language. WSDL is a text-based protocol (XML). This protocol is not only declarative, but also specifies the type of data transmission and a service.
There is a wsdl2Compiler code generator in Java, C++, Python, Perl, …
- C++ implementation: gSOAP
Advantages and disadvantages
Advantages
- Location independence of client and server through the intermediary.
- The client is independent of server implementation changes.
- Changes to the IDL can be easily implemented, so only minor adjustments are required on the client and server.
- It’s easy to port the broker to another system because the client and server don’t use native features.
- Adding clients or servers that speak other programming languages is fairly easy if an IDL is available for the programming language compiler.
- New services can be added easily as they can leverage the existing broker architecture.
- SOAP is a text-based protocol; this makes it fairly easy to parse communications with UNIX-based command-line tools or to implement a simple program that sends text.
Disadvantages
- Due to the many indirections (client -> client-side representative -> broker -> server-side representative -> server), the provision of data and the communication between the processes, the performance is often insufficient; after the initial communication between the client-side proxy and the server-side proxy, both components often talk to each other directly, without the intermediary broker.
- The communication of the parties depends on many components and is therefore difficult to debug in the event of an error; unlike 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 the individual components model, view and controller. The model manages the data and rules of the application. The view renders the data and the controller interacts with the user. I will introduce MVC in my next article.
(rme)