Broker Design Pattern

Decentralized Network

A system with multiple (may or may not be remote) objects that interact remote objects that interact synchronously or asynchronously. The main concern is, communication concern due to isolating communication system.

What problem it is resolving?

The main challenges in an isolating commination are:

  • We don’t want application developers to go through different accidental and inherited complexities (like: low level message passing, different language issues and all the nitty-gritty details). Hence this pattern to reduce complexity and help developers to concentrate on development. This can be reduced by proxy design pattern though.
  • Having said that there are other things that might cause issue, which can be reduced using this design pattern. As an example, if the language of client side and server side are different, then this can play a vital role to resolve the issues. Not only that if the operating systems are different, or the network protocols or the hardware is different then also this can be pretty much useful.
  • Other than this, partial failure, security mechanism, latency, network outage etc. also can be improved.
  • Distributed structure scalability. Moreover, components should be added, removed in runtime.
  • Achieve maximum decoupling for a highly distributed system.

A brief discussion on the existing architectures in the application you have observed/studied/worked on.
Let’s take an enterprise application in cloud, which is involved in different kinds of transactions, providing cloud platforms, interacting with IOT devices etc. Interacting with different systems eventually means there are different hardware and software systems (that has to be taken as a consideration while designing the whole system).

 

A justification for use of the variant of the architectural pattern.

Let’s take an example of the same. In the example stated above, there are separate system communication functioning amongst themselves. Now, look at the practical scenario, for all the different systems different kind of code and interfaces needs to be written, which is a time-consuming process and takes huge effort. Here broker system can be introduced which can isolate communication related concerns and provide better output.

e.g.: One way to implement the same in Android:

A service implements binder object, which is not accessible to client directly and that is kind of abstract for all the services. So, the client knows there is a process, but what that exactly is that is hidden from client.

Client calls a method on proxy and then it uses Android Binder IPC mechanism or broker to communicate to the object across process boundaries.

Docs_Broker

 

The binder IPC mechanism uses a stub to upcall a method to the object.

This can be somewhat compared with skeleton-stub architecture in some way.

A justification for use of the variant of the architectural pattern.
Broker architecture pattern connect clients with remote objects by mediating invocations from client to remote objects, while encapsulating the details of local/remote IPC. This pattern can be implemented if any system wants to support local communication system in a consistent way!

But the key thing is, the app needs to have capability for:

  • Remote communication
  • Provide location transparency
  • Handle faults
  • Manage end to end QoS
  • Encapsulate low level system details

 

Brief Object Model:

Broker_pattern

There are six types of components in Broker architectural pattern:

  • Servers [Implements services, registers itself with the local broker, Sends responses and exceptions back to the client through a server-side proxy]
  • Clients [Implements user functionality, Sends requests to servers through a client-side proxy]
  • Brokers [Register and deregister servers, Offers APIs, Transfer message, error recovery, locate server, interoperate with brokers with bridges]
  • Bridges [Encapsulates network-specific functionality, Mediates between the local broker and the bridge of a remote broker]
  • Server -side proxies [Calls services within the server, Encapsulates system-specific functionality, Mediates between the server and the broker]
  • Client-side proxies [Implements system specific functionality, mediates between client and broker]

How it works (in simple 3 steps):

  1. A server registers itself with the local broker component
  2. A client sends a request to a local server, local means locally maintain by the broker
  3. Interaction of different brokers via bridge components

 

Known Uses

  • CORBA – Common Object Request Broker Architecture
  • IBM SOM/DSOM
  • OLE/COM/DCOM/Active X
  • World Wide Web (WWW)
Digiprove sealCopyright secured by Digiprove © 2019 Geeks 18

Be the first to comment

Leave a Reply

Your email address will not be published.


*