Architectural pattern broker
1 / 33

Architectural Pattern: Broker - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Architectural Pattern: Broker' - ishi

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Architectural pattern broker
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

Problem characteristics
Problem characteristics

  • Building a system as a set of decoupled interacting components gains in:

    • flexibility

    • mantainability

    • changeability

    • distributability

    • scalability

Software Architecture

Problem characteristics1
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

Problem characteristics2
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

Developer s hint
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

Forces to balance
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

Broker pattern solution
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

Broker pattern solution1
Broker Pattern Solution

  • Broker’s tasks

    • locating appropriate server

    • forwarding requests to server

    • transmitting results and exceptions to client

Software Architecture

Broker pattern solution2
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

Broker characteristics
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

Broker architectural structure
Broker Architectural Structure

  • Six types of participating components:

    • Clients

    • Servers

    • Brokers

    • Bridges

    • Client-side proxies

    • Server-side proxies

Software Architecture

Broker architectural structure1
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

Broker architectural structure2
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

Broker architectural structure3
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

Broker architectural structure4
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

Broker architectural structure5
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

Broker architectural structure6
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

Broker architectural structure7
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

Two definitions
Two definitions

  • Marshalling

    • The semantic invariant conversion of data into a machine independent format (ASN or XDR)

  • Unmarshalling

    • performs reverse transformation

Software Architecture

Another definition
Another definition

  • Name service:

    • provides association between names and objects

    • A name service determines which server is associated with a given name.

Software Architecture

Broker Architecture: Static Diagram










Client-side Proxy

Server-side Proxy



send request





















Software Architecture


  • 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


  • 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


  • 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

Implementation issues
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

Implementation issues1
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

Implementation issues2
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

Implementations available corba
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

Implementations available corba1
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

Implementations available rmi iiop
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

Implementations available
Implementations Available


    • 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

Broker benefits
Broker Benefits

  • Location transparency

  • components changeability and extensibility

  • Broker system portability

  • Broker systems interoperability

  • Reusability

Software Architecture

Broker liabilities
Broker Liabilities

  • Restricted efficiency

    • due to indirection

  • Lower fault tolerance

    • may need object replication for higher fault tolerance

Software Architecture