Architectural Pattern: Broker

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

2
Problem characteristics

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

3
Problem characteristics

• Distributed components need inter-process
  communication
• A communication solution
• Components handle communication
• Positive points
• Easier to build
• Can use same programming language

4
Problem characteristics

• 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

5
Developers 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
• objects physical location

6
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

7
Broker Pattern solution

• Design broker component to decouple clients from
  servers
• Servers
• Register with broker
• present method interfaces to clients
• Clients
• access servers methods via broker
• uses same form to call servers methods

8
Broker Pattern Solution

• Brokers tasks
• locating appropriate server
• forwarding requests to server
• transmitting results and exceptions to client

9
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

10
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

11
Broker Architectural Structure

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

12
Broker Architectural Structure

• Servers kinds
• library-type offer services to many applications
• application specific servers
• Servers Objects interface
• written using an IDL or
• through a binary standard

13
Broker Architectural Structure

• 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

14
Broker Architectural Structure

• Brokers 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 servers unique ID
• Brokers presents API to client and servers
• to registering services (of server)
• invoking servers methods (by client)

15
Broker Architectural Structure

• 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
• clients broker finds route to remote broker
• forwards request on this route
• Conclusion brokers need to interoperate

16
Broker Architectural Structure

• 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

17
Broker Architectural Structure

• 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

18
Broker Architectural Structure

• Server-side proxies
• responsible for receiving requests
• unpacking messages
• unmarshalling parameters
• calling appropriate service
• marshalling results and exceptions to client

19
Two definitions

• Marshalling
• The semantic invariant conversion of data into a
  machine independent format (ASN or XDR)
• Unmarshalling
• performs reverse transformation

20
Another definition

• Name service
• provides association between names and objects
• A name service determines which server is
  associated with a given name.

21
Broker Architecture Static Diagram
Broker
Main_event_loop update_repository register-service
acknoledgment find_server find_client forward_req
uest forward_response
Client-side Proxy
Server-side Proxy
Pack_data unpack_data send request return
Pack_data unpack_data call_service send_response
Client
Server
Bridge
Initialize register_service enter_main_loop run_se
rvice use_broker_API
Call_server start_task use_broker_API
Pack_data unpack_data forward_message transmit_mes
sage
22
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

23
Dynamics

• Scenario II client sends synchronous request to
  local server.
• Client app started. Client invokes remote
  servers 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.

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

25
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 ( IBMs SOM)

26
Implementation Issues

• Specify Brokers 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
27
Implementation Issues

• Simultaneously design Broker
• Design it into layers
• Lots of more issues to consider here
• Design IDL compilers one per PL language to
  support.

28
Implementations Available CORBA

• CORBA defined by OMG
• OO technology for distribution on heterogeneous
  systems
• Its 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

29
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

30
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 CORBAs

31
Implementations Available

• IBM SOM/DSOM
• iteroperability IDL and binary
• subclassing from binary patern allows to do
  mix-language inheritance
• Microsofts
• OLE
• DCOM
• The Web
• Browsers act as brokers, and a client uses a
  web-browser
• WWW servers act as service providers

32
Broker Benefits

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

33
Broker Liabilities

• Restricted efficiency
• due to indirection
• Lower fault tolerance
• may need object replication for higher fault
  tolerance