Transcript Architectural Pattern: Broker

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
Software Architecture
1
Problem characteristics
• Building a system as a set of decoupled
interacting components gains in:
–
–
–
–
–
flexibility
mantainability
changeability
distributability
scalability
Software Architecture
2
Problem characteristics
• Distributed components need inter-process
communication
• A communication solution:
– Components handle communication :
• Positive points:
– Easier to build
– Can use same programming language
Software Architecture
3
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
Software Architecture
4
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
Software Architecture
5
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
Software Architecture
6
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
Software Architecture
7
Broker Pattern Solution
• Broker’s tasks
– locating appropriate server
– forwarding requests to server
– transmitting results and exceptions to client
Software Architecture
8
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 interprocess communication protocol
• Broker architecture flexibility: dynamic
change, addition, deletion, relocation of
objects
Software Architecture
9
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
Software Architecture
10
Broker Architectural Structure
• Six types of participating components:
–
–
–
–
–
–
Clients
Servers
Brokers
Bridges
Client-side proxies
Server-side proxies
Software Architecture
11
Broker Architectural Structure
• 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*
Software Architecture
12
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
Software Architecture
13
Broker Architectural Structure
• 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)
Software Architecture
14
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
– client’s broker finds route to remote broker
– forwards request on this route
• Conclusion: brokers need to interoperate
Software Architecture
15
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
Software Architecture
16
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
Software Architecture
17
Broker Architectural Structure
• Server-side proxies
– responsible for receiving requests:
•
•
•
•
unpacking messages
unmarshalling parameters
calling appropriate service
marshalling results and exceptions to client
Software Architecture
18
Two definitions
• Marshalling
– The semantic invariant conversion of data into
a machine independent format (ASN or XDR)
• Unmarshalling
– performs reverse transformation
Software Architecture
19
Another definition
• Name service:
– provides association between names and
objects
– A name service determines which server is
associated with a given name.
Software Architecture
20
Broker Architecture: Static Diagram
Broker
Client-side Proxy
Pack_data
unpack_data
send request
return
Main_event_loop
update_repository
register-service
acknoledgment
find_server
find_client
forward_request
forward_response
Client
Call_server
start_task
use_broker_API
Bridge
Pack_data
unpack_data
forward_message
transmit_message
Software Architecture
Server-side Proxy
Pack_data
unpack_data
call_service
send_response
Server
Initialize
register_service
enter_main_loop
run_service
use_broker_API
21
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
Software Architecture
22
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.
Software Architecture
23
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.
Software Architecture
24
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)
Software Architecture
25
Implementation Issues
• 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
Server-side Proxy
Software Architecture
Broker
Server
26
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.
Software Architecture
27
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
Software Architecture
28
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
Software Architecture
29
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
Software Architecture
30
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
Software Architecture
31
Broker Benefits
•
•
•
•
•
Location transparency
components changeability and extensibility
Broker system portability
Broker systems interoperability
Reusability
Software Architecture
32
Broker Liabilities
• Restricted efficiency
– due to indirection
• Lower fault tolerance
– may need object replication for higher fault
tolerance
Software Architecture
33