software architecture1 architectural pattern: broker used to structure distributed systems...
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
• 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
Software Architecture 33
Broker Liabilities
• Restricted efficiency– due to indirection
• Lower fault tolerance– may need object replication for higher fault
tolerance