1 / 33

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

JasminFlorian
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Software Architecture

  2. Problem characteristics • Building a system as a set of decoupled interacting components gains in: • flexibility • mantainability • changeability • distributability • scalability Software Architecture

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. Broker Pattern Solution • Broker’s tasks • locating appropriate server • forwarding requests to server • transmitting results and exceptions to client Software Architecture

  9. 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

  10. 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

  11. Broker Architectural Structure • Six types of participating components: • Clients • Servers • Brokers • Bridges • Client-side proxies • Server-side proxies Software Architecture

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. Two definitions • Marshalling • The semantic invariant conversion of data into a machine independent format (ASN or XDR) • Unmarshalling • performs reverse transformation Software Architecture

  20. Another definition • Name service: • provides association between names and objects • A name service determines which server is associated with a given name. Software Architecture

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. Broker Benefits • Location transparency • components changeability and extensibility • Broker system portability • Broker systems interoperability • Reusability Software Architecture

  33. Broker Liabilities • Restricted efficiency • due to indirection • Lower fault tolerance • may need object replication for higher fault tolerance Software Architecture

More Related