Broker

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.

Broker

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:

BrokerStructure

BrokerCRC

Client

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

Client-side Proxy

 

Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.

     

    • 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.

     

     

     

     

    Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, and Philipp Lenk.

    Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

    My special thanks to Embarcadero
    My special thanks to PVS-Studio
    My special thanks to Tipi.build 
    My special thanks to Take Up Code
    My special thanks to SHAVEDYAKS

    Seminars

    I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

    Standard Seminars (English/German)

    Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

    • C++ – The Core Language
    • C++ – The Standard Library
    • C++ – Compact
    • C++11 and C++14
    • Concurrency with Modern C++
    • Design Pattern and Architectural Pattern with C++
    • Embedded Programming with Modern C++
    • Generic Programming (Templates) with C++
    • Clean Code with Modern C++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,

     

     

    0 replies

    Leave a Reply

    Want to join the discussion?
    Feel free to contribute!

    Leave a Reply

    Your email address will not be published. Required fields are marked *