architectural pattern broker l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Architectural Pattern: Broker PowerPoint Presentation
Download Presentation
Architectural Pattern: Broker

Loading in 2 Seconds...

play fullscreen
1 / 33

Architectural Pattern: Broker - PowerPoint PPT Presentation


  • 361 Views
  • 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

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

PowerPoint Slideshow about 'Architectural Pattern: Broker' - JasminFlorian


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 characteristics3
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 characteristics4
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 solution8
Broker Pattern Solution
  • Broker’s tasks
    • locating appropriate server
    • forwarding requests to server
    • transmitting results and exceptions to client

Software Architecture

broker pattern solution9
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 structure12
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 structure13
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 structure14
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 structure15
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 structure16
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 structure17
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 structure18
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

slide21

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

dynamics23
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

dynamics24
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 issues26
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 issues27
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 corba29
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