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
Software Architecture 2
Problem characteristics
• Building a system as a set of decoupled interacting components gains in:– flexibility– mantainability– changeability– distributability– scalability
Software Architecture 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
Software Architecture 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
Software Architecture 5
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 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
Software Architecture 7
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 8
Broker Pattern Solution
• Broker’s tasks– locating appropriate server– forwarding requests to server– transmitting results and exceptions to client
Software Architecture 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
Software Architecture 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
Software Architecture 11
Broker Architectural Structure
• Six types of participating components:– Clients– Servers– Brokers– Bridges– Client-side proxies– Server-side proxies
Software Architecture 12
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 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
Software Architecture 14
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 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
– client’s broker finds route to remote broker– forwards request on this route
• Conclusion: brokers need to interoperate
Software Architecture 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
Software Architecture 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
Software Architecture 18
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 19
Two definitions
• Marshalling– The semantic invariant conversion of data into
a machine independent format (ASN or XDR)• Unmarshalling
– performs reverse transformation
Software Architecture 20
Another definition
• Name service:– provides association between names and
objects– A name service determines which server is
associated with a given name.
Software Architecture 21
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
Software Architecture 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
Software Architecture 23
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 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.
Software Architecture 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 ( IBM’s SOM)
Software Architecture 26
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 Broker
Server-side Proxy Server
Software Architecture 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.
Software Architecture 28
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 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
Software Architecture 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 CORBA’s
Software Architecture 31
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 32
Broker Benefits
• Location transparency• components changeability and extensibility• Broker system portability• Broker systems interoperability• Reusability
Top Related