Broker Pattern Pattern-Oriented Software Architecture (POSA 1) F. Buschmann, Regine Meunier, H. Rohnert, P. Sommerlad, M. Stal

ECEN 5053 SW Eng of Dist Sys, Univ of Colorado Basic Pattern Format Name and summary description Example Context Problem Solution Structure CRC cards Scenarios and Sequence diagrams Implementation Example Resolved Variants Known Uses Consequences Related Patterns and Credits 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado

ECEN 5053 SW Eng of Dist Sys, Univ of Colorado Basic Pattern Format Name and summary description Example Context Problem, including forces Solution Structure CRC cards Scenarios and Sequence diagrams Implementation Example Resolved Variants Known Uses Consequences: benefits and liabilities Related Patterns and Credits 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado

Summary Description of Broker Pattern ECEN 5053 SW Eng of Distributed Systems Summary Description of Broker Pattern 9/19/2006 Structure distributed sw systems with decoupled components that interact by remote service invocations Responsible for coordinating communication transmitting results transmitting exceptions Suppose you have a City Information System for a WAN Some computers host: 1 or more services to maintain information about events, restaurants, hotels, historical monuments, public transportation Computer terminals connected to the network Tourists can retrieve information using a browser. Front-end sw supports online retrieval of info from appropriate servers and its display on the screen Data is distributed across the network; not all maintained in the terminals. Expectations: The system changes and grows continuously so individual services are decoupled from each other Terminal sw should be able to access services without having to know their location Allows us to move, replicate, or migrate services One (not good enough) solution: Install a separate network to connect all terminals and servers – an intranet system. Disadvantages: Not every information provider wants to connect to a closed intranet. Available services should also be accessible from all over the world. 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder

Broker Pattern: Context “Your environment is a distributed and possibly heterogeneous system with independent cooperating components.” 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado

Broker Pattern: Problem Build a complex sw system as a set of decoupled, interoperating components rather than a monolith. Greater flexibility, maintainability, changeability Partitioning into independent components makes system distributable and scalable. Require a means of inter-process communication If components themselves handle communication, result has several dependencies and limitations System depends on which comm mechanism used Clients need to know location of servers 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado

Broker Pattern: Problem - 2 ECEN 5053 SW Eng of Distributed Systems Broker Pattern: Problem - 2 9/19/2006 Need services for adding, removing, exchanging, activating, and locating components Must not depend on system-specific details to guarantee portability and interoperability An object that uses an object should only see the interface offered by the object – know nothing about implementation. Previous slide is about inter-process communication. The above are additional services needed. 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder

Broker Pattern: Problem - 3 ECEN 5053 SW Eng of Distributed Systems Broker Pattern: Problem - 3 9/19/2006 Broker pattern balances the following forces Components access others’ services via remote, location-transparent service invocations. Need to exchange, add, or remove components at run-time Architecture should hide system-specific and implementation-specific details from users of components and services. Previous slide is about inter-process communication. The above are additional services needed. 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder

Broker Pattern: Solution ECEN 5053 SW Eng of Distributed Systems Broker Pattern: Solution 9/19/2006 Introduce a broker component to achieve better decoupling of clients and servers Servers: register themselves with the broker and make their services available to clients through method interfaces. Clients: access the functionality of servers by sending requests via the broker A broker’s tasks: Locating the appropriate server and forwarding a request to that server Transmitting results and exceptions back to the client Application accesses distributed services by sending message calls to the appropriate object. Does not need to focus on low-level inter-process communication. Broker architecture is flexible Allows dynamic change, addition, deletion, and relocation 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder

Broker Pattern: Solution -- 2 ECEN 5053 SW Eng of Distributed Systems Broker Pattern: Solution -- 2 9/19/2006 Reduces the complexity involved in developing distributed applications. Introduces object model where distributed services are encapsulated within objects. Broker systems offer a path to the integration of two core technologies: Distribution Object technology Extend object models from single applications to dist’d applications made of decoupled components that can run on heterogeneous machines and written in different programming languages. Application accesses distributed services by sending message calls to the appropriate object. Does not need to focus on low-level inter-process communication. Broker architecture is flexible Allows dynamic change, addition, deletion, and relocation 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder

Broker Pattern: Structure ECEN 5053 SW Eng of Distributed Systems Broker Pattern: Structure 9/19/2006 Participating components Clients Servers Brokers Bridges Client-side proxies Server-side proxies 6 pages on “structure” 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder

Server-side interaction ECEN 5053 SW Eng of Distributed Systems 9/19/2006 9 pages spelling out structure for 3 scenarios 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder

ECEN 5053 SW Eng of Dist Sys, Univ of Colorado Client-Server interaction via Broker 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado

ECEN 5053 SW Eng of Dist Sys, Univ of Colorado Object relationships 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado

Broker pattern: Implementation ECEN 5053 SW Eng of Distributed Systems Broker pattern: Implementation 9/19/2006 Define an object model or use an existing one Decide which kind of component-interoperability the system should offer Specify the APIs the broker component provides for collaborating with clients and servers Use proxy objects to hide implementation details from clients and servers Design the broker component in parallel with steps 3 and 4 broken down into nine steps Develop IDL compilers 4. On client side, a local proxy represents the remote server object called by the client. On the server side, a proxy is used for playing the role of the client. Proxy objects: package procedure calls into messages and forward the messages to the local broker component they receive responses and exceptions from the local broker and pass them to the calling client Whenever you implement interoperability by providing an IDL, you need to build an IDL compiler for every programming language you support. The IDL compiler translate the server interface definitions to programming language code. When many programming languages are in use, it is best to develop the compiler as a framework that allows the developer to add his own code generators. 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder

Broker pattern: Known Uses CORBA Microsoft’s OLE WWW – Hypertext browsers such as Mosaic and Netscape act as brokers and WWW servers play the role of service providers 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado

Broker Pattern: Consequences ECEN 5053 SW Eng of Distributed Systems Broker Pattern: Consequences 9/19/2006 Benefits Location transparency Changeability and extensibility of components Portability of a Broker system Interoperability between different Broker systems Reusability Liabilities Restricted efficiency Lower fault tolerance (server fails, broker fails, ...) Testing and debugging Liabilities – testing and debugging – A client app developed from tested services is more robust and easier itself to test Debugging and testing a broker system is a tedious job because of the many components involved 9/19/2006 ECEN 5053 SW Eng of Dist Sys, Univ of Colorado University of Colorado, Boulder