Broker Pattern Pattern-Oriented Software Architecture (POSA 1) F. Buschmann, Regine Meunier, H....

Broker Pattern

Pattern-Oriented Software Architecture(POSA 1)

F. Buschmann, Regine Meunier, H. Rohnert, P. Sommerlad, M. Stal

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

2

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

3

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

4

Summary Description of Broker Pattern

• Structure distributed sw systems

– with decoupled components– that interact by remote service

invocations• Responsible for

– coordinating communication– transmitting results– transmitting exceptions

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

5

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

6

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

7

Broker Pattern:Problem - 2

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

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

8

Broker Pattern:Problem - 3

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.

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

9

Broker Pattern:Solution

• 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

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

10

Broker Pattern:Solution -- 2

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

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

11

Broker Pattern:Structure

• Participating components

– Clients– Servers– Brokers– Bridges– Client-side proxies– Server-side proxies

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

12

Server-side interaction

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

13

Client-Server interaction via Broker

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

14

Object relationships

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

15

Broker pattern:Implementation

1. Define an object model or use an existing one2. Decide which kind of component-

interoperability the system should offer3. Specify the APIs the broker component

provides for collaborating with clients and servers

4. Use proxy objects to hide implementation details from clients and servers

5. Design the broker component in parallel with steps 3 and 4

• broken down into nine steps6. Develop IDL compilers

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

16

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

17

Broker Pattern:Consequences

• 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