Architectural pattern broker
This presentation is the property of its rightful owner.
Sponsored Links
1 / 33

Architectural Pattern: Broker PowerPoint PPT Presentation


  • 104 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Architectural Pattern: Broker

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


Architectural pattern broker

Broker Architecture: Static Diagram

Broker

Main_event_loop

update_repository

register-service

acknoledgment

find_server

find_client

forward_request

forward_response

Client-side Proxy

Server-side Proxy

Pack_data

unpack_data

send request

return

Pack_data

unpack_data

call_service

send_response

Client

Server

Bridge

Initialize

register_service

enter_main_loop

run_service

use_broker_API

Call_server

start_task

use_broker_API

Pack_data

unpack_data

forward_message

transmit_message

Software Architecture


Dynamics

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


Dynamics1

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


Dynamics2

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


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

Client-side proxy

Broker

Server-side Proxy

Server

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

  • 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


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


  • Login