Architectural Pattern Broker Used to structure distributed systems

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 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-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 Unicast. Remote. Object, or Activatable, it extends Portable. Remote. Object • 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