Software Architecture1 Architectural Pattern: Broker Used to structure distributed systems...

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


Problem characteristics

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



• Distributed components need inter-process communication

• A communication solution: – Components handle communication :

• Positive points:– Easier to build

– Can use same programming language



• 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


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


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


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


Broker Pattern Solution

• Broker’s tasks– locating appropriate server– forwarding requests to server– transmitting results and exceptions to client


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


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


Broker Architectural Structure

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



• 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*



• 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



• 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)



• 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



• 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



• 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



• Server-side proxies– responsible for receiving requests:

• unpacking messages

• unmarshalling parameters

• calling appropriate service

• marshalling results and exceptions to client


Two definitions

• Marshalling– The semantic invariant conversion of data into

a machine independent format (ASN or XDR)

• Unmarshalling– performs reverse transformation


Another definition

• Name service:– provides association between names and

objects– A name service determines which server is

associated with a given name.


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


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


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.


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.


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)



• 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



• Simultaneously design Broker– Design it into layers– Lots of more issues to consider here

• Design IDL compilers one per PL language to support.


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


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


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


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


Broker Benefits

• Location transparency

• components changeability and extensibility

• Broker system portability

• Broker systems interoperability

• Reusability


Broker Liabilities

• Restricted efficiency– due to indirection

• Lower fault tolerance– may need object replication for higher fault

tolerance

Software Architecture1 Architectural Pattern: Broker Used to structure distributed systems...

Documents

Transcript of Software Architecture1 Architectural Pattern: Broker Used to structure distributed systems...