Architectural Patterns: Broker

Intention

Support for distributed systems

Advantages of distributed systems: Economics, Performance and Scaleability, Reliability

Disadvantages: You really need a different set of software than do centrilized systems

Do consider computer systems with multiple CPU and LAN with hundreds of heterogeneous computers

Brokers will be interested to people who are

Working with existing broker system and interested in understanding the architecture of such system

Willing to learn a lean versions of a Broker system without all the details

Planning to implement a fully-fledged broker system, and therefore need an in-depth description of the Broker architecture

Compared with Design Pattern with Proxy, this AP looks somewhat similar but in more detail. But, it is due to the fact that AP tell you how to build a system of applications, where DP tells you how to solve a problem

For people who know RPC, this AP is somewhat similar to RPC but presented in a system-wide scale

Introduction

The Broker architectural pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations

The Broker component is responsible for coordinating communication, such as forwarding requests, as well as transmitting results and exceptions

Example

Build a City Information System (CIS) designed to run on a wide area network.

Wide area network in this case can be viewed as a set of networks that are not directly connected at all time

There are different kinds of computers in the network.

Users can access the information from the WWW which is the front end software supported for on-line retrieval of information.

The backend are data distributed out across the network

The system will glow continuously, so individual services should be decoupled from each other

One solution is to rebuild a new network that connect everyone at all time - Intranet (does not work in general case like this)

So, we will have to go with Internet approach

Context

Your environment is a distributed and possibly heterogeneous system with independent cooperating components

Problem

Need great flexibility, maintainability and changeability

Need to partition functionality into independent components

Need to be distributed and scalable

When distributed componets communicate with each other, some means of inter-process communication is required

(If component handles communication, dependencies surface such as clients need to know the location of servers)

Services for adding, removing, exchanging, activating and locating components are also needed

From developer points of view, there should not be any different in doing centralized software or distributed software

We need to balance the following forces:

Components should be able to access services provided by others through remote, location-transparent service invocations

Need to exchange, add or remove components at run-time

The architecture should hide system- and implementation-specific details from the users of components and services

Solution

Introduce a broker component to achieve better decoupling of clients and servers

Servers register themselves with the broker, and make their services available to clients through method interfaces

Clients access the functionality of servers by sending requests via the broker

The broker will locate the appropriate server, forward the request to the server and transmit results and exceptions back to the client

Using the Broker pattern, an application can access distributed services simply by sending message calls to the appropriate object, instead of focusing on low-level inter-process communication

This AP allows dynamic change, addition, deletion, and relocation of objects

From a developer point of view, distribution is transparent. You talk to a Broker one way or the other and it introduces an object model in which distributed services are encapsulated within objects

Broker thus suports integration of distribution as well as object technology

(Or you could say it extends the tranditional object model from single application to distributed applications)

Structure

There are six types of components in Broker architectural pattern:

Clients, Servers, Brokers, Bridges, Client-side proxies and Server-side proxies

A server implements objects that expose their functionality through interfaces that consist of operations and attributes

These interfaces are either through Interface Definition Language (IDL), through a binary standard, or some kind of APIs.

Interfaces are grouped by semantically-related functionality. So, we could have

Servers offering common services to many application domains

Servers implementing specific functionality for a single application domain or task

Clients are applications that access the servicess of at least one server

To call remote services, clients forword requests to the broker

Clients then will receive responses or exceptions from the broker

Remember clients and servers are logically terms. So, a client can be a server and vice versa

Clients are the requesters and do not need to know about the location of the servers

As a developer, you can consider clients are application and servers are libraries

A broker is a messager that is responsible for the transmission of requests from clients to servers

It also takes care the transmission of responses and exceptions back to the client

A broker will store control information for locating the receivers (servers) of the requests (it is normally down with some unique system identifier, IP address might not be enough)

Broker also offer interface for clients and servers

They are usually in the form of APIs with control operations such as registering servers and invoking server methods

Broker keeps track of all the servers information it maintains locally. If a request comes in and it is for a server that is on the tracking list. It passs the request along directly

If the server is currently inactive, the broker activates it (spawn a job, folk a process, create a thread, use a prestart job, etc)

Then response are passed back to the client through the broker

If the request is for a server hosted by another broker, the local broker finds a route to the remote broker and forwards the request using this route (So, a common way of communcation among brokers is needed)

Sometimes, name services (DNS, LDAP, NT directory ?, RMI ?, etc) or marshaling support will be integrated into the broker

Client-side proxies represent a layer between clients and the broker

This additional layer provides transparency, which a remote object appears to the client as a local one

It hides the implementation detail such as:

• Inter-process communication mechanism used for message transfer between clients and brokers
• The creation and deletion of memory blocks (remember, we are dealing with multiple different languages to build a system, not just Java)
• The marshaling of parameters and results

In most cases, client-side proxies translate the object model specified as part of the Broker architectural pattern to the object model of the programming language used to implement the client

Server-side proxies are generally analogous to Client-side proxies

They receive requests, unpack messages, unmarshaling parameters and call the appropriate service (in a server)

(Most web server has "built-in" client and server proxy to communicate with client and internet router, so there is nothing to implement in that case)

(In RPC, client-side and server-side proxies are kind of parallel to stubs)

Bridges are used to bridge communication among brokers

They are optional to hide the implementation detail

They are most useful when the system run across heterogeneous network (so bridge will take care of, say IPX network talks to IP network as well as SNA network)

There are two general types of Brokers: Direct communication and Indirect communication

Direct communication:

Assume client and server understand the same protocol

Broker will assist in the inital hand share of the client and server

Then all the messages, exceptions and responses are tranferred between client-side proxies and server-side proxies without using the broker as an intermediate layer

(Usually a mix approach is used, Java applet can use socket directly but not all the other components)

Brief Object Model:

Client-side Proxy .--- transfer msg ---- Broker ---- transfer msg ---. Server-side Proxy
        .                                  |                                    .
        |                                  |                                    |
       calls                               |                                  calls
        |                             -------------                             |
        |                             |     |     |                             |
        | . uses API ------------------     |     |------------- uses API --. Server
      Client                                o
                                         Bridge 

Dynamics

Scenario I (A server registers itself with the local broker component)

The broker is started in the initialization phase of the system

The broker enters its event loop and waits for incoming messages

The user, or other components, starts a server application

First the server executes its initialization code and then it registers itself with the broker

The broker receives the incoming registration request from the server

It extracts all necessary information from the message and stores it into one or more repositories (The repositories are used to local and activate servers)

An ack is sent back

After getting the ack from the broker, the server enters its main loop waiting for incoming client request

Scenario II (A client sends a request to a local server, local means locally maintain by the broker)

(We assume the client will block until a response is back - thus, we are doing synchronous)

The client application starts and in the middle, it invokes a method of a remote server object

The client-side proxy packages all parms and other control information into a message and forwards it to the local broker

The broker looks up the location of the server requested in the repositories (sometimes called directory).

Since the server is available locally, the broker forwards the message to the corresponding server-side proxy

The server-side proxy unpacks all the parameters and other control information (such as method to call, etc)

It then invokes the appropriate service in a server

The service execution is complete, the server returns the result to the server-side proxy, which packages it into a message with other relevant information and passes it to the broker

The broker forwards the response to the client-side proxy

The client-side proxy receives the response, unpacks the result and returns to the client application

The client process continues with its computation ... and go on to other application logic

Scenario III (Interaction of different brokers via bridge components)

[There are two Brokers (A & B) and two Bridges (A& B) in this scenario]

Broker A receives an incoming request

It locates the server responsible for the request by searching in its respositories

The corresponding server is available but at another network node

The broker forwards the request to a remote broker

The message is passed from Broker A to Bridge A (This bridge will convert the message from the protocol defined by Broker A to a network-specific but common protocol understood by the two participating bridges

After message conversion, Bridge A transmits the message to Bridge B

Bridge B maps the incoming request from the network-specific format to a Broker B-specific format

Broker B perfroms all the actions necessary when a request arrives as described in the first step of this scenario

Implementation

Define an object model, or use an existing model

(The object model you pick should specify entities such as object names, objects, request, values, exceptions, supported types, type extensions, interfaces and operations

Need to describe definitions of the state of server objects, definition of methods, how methods are selected for execution and how server objects are generated and destroyed

The state of server objects and their method implementations should not be directly accessible to clients)

Decide which kind of component-interoperability the system should offer

(What kind of IDL you should use, do a generator exists, etc

If not using IDL, you can use the binary approach which needs support from your programming language

Binary method tables are available in MS OLE/DCOM/COM/Active X. These tables consist of pointers to method implementations, and enable clients to call methods indirectly using pointers. Access to OLE objects (for example) is only supported by compilers (MS VC++) or interpreters that know the physical structure of these tables

Mix approach such as IBM's SOM is available <- but it is phasing out now

When using binary standard and every semantic concept of the object model must be associated with a binary representation ... so if you use OLE/DCOM/COM, you are bounded to use a lot of microsoft products)

Specify the APIs the broker component provides for collaborating with clients and servers

Use proxy objects to hide implementation details from clients and servers

Design the broker component

Specify a detailed on-the-wire protocol for interacting with client-side proxies and server-side proxies

Develop IDL compilers

Variants

Direct Communication Broker System - Broker manages the channels for communication, but the actual communcation

Callback Broker System - There is not clear client or server differences. A event pops up and broker picks the right service(s) to react (ala reative model)

Known Uses

CORBA - Common Object Request Broker Architecture

IBM SOM/DSOM

OLE/COM/DCOM/Active X

World Wide Web (WWW)

Consequences

Advantages

Location Transparency

Changeability and extensibility of components

Portability of a Broker system

Interoperability between different Broker systems

Reusability

Testing and Dubugging

Disadvantages

Restricted efficiency

Lower fault tolerance

Testing and Dubugging