Broker

Broker

This post is a cross-post from Brok.

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:

No alt text provided for this image
No alt text provided for this image

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.

{loadmoduleid 157}

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 data caching, 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 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.

No alt text provided for this image

Modernes C++ Mentoring

Stay informed: Subscribe.

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, Animus24, 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, Dominik Vo??ek, and Rob North.

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

My special thanks to Embarcadero , PVS-Studio , and Tipi.build .

Seminars

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

Bookable (Online)

German

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++

New

  • Clean Code with Modern C++
  • C++20

Contact Me

Modernes C++,

No alt text provided for this image

要查看或添加评论,请登录

社区洞察

其他会员也浏览了