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
33
Embed
Software Architecture1 Architectural Pattern: Broker Used to structure distributed systems –decouple components that interact by remote service invocations.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
• 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.
• 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