Architectural Pattern: Broker

Software Architecture 1

Architectural Pattern: Broker

• Used to structure distributed systems– decouple components that interact by remote

service invocations– Responsible for coordinating communication:

• forwarding of requests from client to server• transmission of results and exceptions

• Context: distributed, heterogeneous, with independent components environment


Problem characteristics

• Building a system as a set of decoupled interacting components gains in:– flexibility– mantainability– changeability– distributability– scalability



• Distributed components need inter-process communication

• A communication solution: – Components handle communication :

• Positive points:– Easier to build– Can use same programming language



• Negative points– system is dependent on communication method used– clients need to know location of servers– new components have to be written using same language– components need to know such communication protocol

• Furthermore, need component services for adding, removing, exchanging, activating, locating services

– these services cannot depend on detail specifics to guarantee: portability and interoperability


Developer’s Hint

• There should be no essential difference between developing software for centralized systems and for distributed systems

• OO applications should :– use only interface offered by objects

• OO applications should not need to know:– implementation details– object’s physical location


Forces to balance

• Components should be able to access services provided through remote, location transparent service invocations

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

• architecture should hide system and implementation specific details from users of components and services


Broker Pattern solution

• Design broker component to decouple clients from servers

• Servers:– Register with broker– present method interfaces to clients

• Clients– access server’s methods via broker– uses same form to call server’s methods


Broker Pattern Solution

• Broker’s tasks– locating appropriate server– forwarding requests to server– transmitting results and exceptions to client


Broker Pattern Solution

• Applications access distributed services:– sending message calls to appropriate object

as if in same memory space– no need to focus on low-level inter-process

communication protocol• Broker architecture flexibility: dynamic

change, addition, deletion, relocation of objects


Broker characteristics

• Makes distribution transparent to developer• How: Introduces distributed OO model

encapsulated within the objects• Integrates two core technologies:

– distributed systems– Object technology

• An added plus: components can be written in different programming languages


Broker Architectural Structure

• Six types of participating components:– Clients– Servers– Brokers– Bridges– Client-side proxies– Server-side proxies



• Servers kinds– library-type: offer services to many applications– application specific servers

• Server’s Objects interface:– written using an IDL or– through a binary standard*



• Clients: are applications that access servers• To call remote service:

– client forward requests to broker– broker forwards response or exception to client

• client and server model of interaction: – Dynamic: servers may also act as clients

• Contrast traditional client-server model: Static



• Broker’s role: messenger– transmits requests from clients to servers– transmits response and exceptions to client

• Broker must have means to locate server of a request based on server’s unique ID

• Brokers presents API to client and servers– to registering services (of server)– invoking servers methods (by client)



• Each client and server is hosted by a broker• if a client makes request to local server:

– broker forwards request directly to server• if client makes request to remote server

– client’s broker finds route to remote broker– forwards request on this route

• Conclusion: brokers need to interoperate



• Bridges: layer between two brokers, used to hide each side implementation details

• In particular when a Broker system is run on a heterogeneous network– two brokers have to communicate

independently of network and OS in use– Bridges encapsulate these system-specific

details



• Client-side proxies– represent layer between client and broker– layer provides transparency:

• remote objects appear local to client• there is no dependence between a client and broker

• proxies allow implementation hiding:– inter-process communication between clients and brokers– creation and deletion of memory blocks– marshalling of parameters to broker– receives message, unmarshals results and exceptions from broker and

forwards to client



• Server-side proxies– responsible for receiving requests:

• unpacking messages• unmarshalling parameters• calling appropriate service• marshalling results and exceptions to client


Two definitions

• Marshalling– The semantic invariant conversion of data into

a machine independent format (ASN or XDR)• Unmarshalling

– performs reverse transformation


Another definition

• Name service:– provides association between names and

objects– A name service determines which server is

associated with a given name.


Broker Architecture: Static Diagram

Client-side Proxy

Broker

Server-side Proxy

ServerBridge

Client

Call_serverstart_taskuse_broker_API

Pack_dataunpack_datasend requestreturn

Main_event_loopupdate_repositoryregister-serviceacknoledgmentfind_serverfind_clientforward_requestforward_response

Pack_dataunpack_datacall_servicesend_response

Initializeregister_serviceenter_main_looprun_serviceuse_broker_API

Pack_dataunpack_dataforward_messagetransmit_message


Dynamics

• Scenario I: server registers with local Broker system– broker is started in inialization phase of system. Broker

enters event loop and waits for messages– user, or some other entity, starts server application.

Server executes initialization code. Server registers with broker

– Broker receives registration request. Extracts information from message and stores in repository. Acknoledgment is sent

– Server enters main loop waiting for client requests


Dynamics

• Scenario II: client sends synchronous request to local server.– Client app started. Client invokes remote server’s method.– Client-side proxy packs parameters and other information in message to

forward to local broker– broker looks up location of server in repository. Server local, broker forwards

message to server-side proxy.– Server-side proxy unpacks parameters and other information. Server-side

proxy invokes appropriate message on server– after completion, server returns results to server-side proxy which packages it

to broker– broker forwards message to client-side proxy– client-side proxy unpacks result and returns to client.


Dynamics

• Scenario III: interaction of different brokers via bridge.– Broker receives request. Locates server in remote node. Broker

forwards request to remote broker.– Message is passed from Broker A to Bridge A. Bridge A converts

message to common protocol understood by both bridges. Bridge A transmit message to bridge B.

– Bridge B maps common protocol to Broker B format.– Broker B performs all actions necessary when request arrives, as

in scenario I.


Implementation Issues

• Object model– existing one– define one

• Characteristics of object model– object names, objects, requests, values, exceptions,

supported types, type exceptions, interfaces, operations• Component interoperability to offer

– binary standard (OLE)– IDL (CORBA)– Combination ( IBM’s SOM)



• Specify Broker’s API for clients and servers• Use proxy objects to hide implementation

details from clients and servers– Client-side proxy: represents server object – Server-side proxy: represents client

Client Client-side proxy Broker

Server-side Proxy Server



• Simultaneously design Broker– Design it into layers– Lots of more issues to consider here

• Design IDL compilers one per PL language to support.


Implementations Available: CORBA

• CORBA defined by OMG– OO technology for distribution on heterogeneous systems– It’s an abstract specification , not constraining underlying

implementations

• CORBA basic components– Interface definition language

• Language independent• Has a rich set of data types, and ways to define value objects

– A wire protocol: IIOP (internet interoperability object protocol) based on TCP/IP, and based on RPC

– Set of language mappings


Implementations Available: CORBA

• CORBA components (cont.)– Portable object adapter:

• pulls request of wire, demarshalls data, forwards to proxy• More flexible than RMI run-time and more programmer

process control

– Services:• Naming • Event service• Transaction service


Implementations Available: RMI/IIOP

• Uses much of RMI• Replaces RMI native protocol with IIOP protocol• Interfaces are define as in RMI:

– They use serializable objects– Extend remote interface– Throw remote exceptions

• Server is implemented differently– Does not extend UnicastRemoteObject, or Activatable, it extends

PortableRemoteObject • Proxies are generated with rmic

– with th –iiop flag to use IIOP as communication protocol• Naming service is CORBA’s


Implementations Available

• IBM SOM/DSOM – iteroperability: IDL and binary– subclassing from binary patern allows to do mix-language

inheritance

• Microsoft’s – OLE– DCOM

• The Web– Browsers act as brokers, and a client uses a web-browser– WWW servers act as service providers


Broker Benefits

• Location transparency• components changeability and extensibility• Broker system portability• Broker systems interoperability• Reusability


Broker Liabilities

• Restricted efficiency– due to indirection

• Lower fault tolerance– may need object replication for higher fault

tolerance

Documents

Architectural Pattern: Broker