Brokerは，分散ソフトウェアシステムを構築するために利用できるアーキテクチャパターンである．互いに依存性をもたないコンポーネント群が，リモートサービスを起動することによって相互作用するという構造をもっている．このパターンの中心となるブローカコンポーネントは，リクエストの転送，レスポンスや例外の送信などの通信上の強調を行う責務を負っている
前提
対象となる環境が分散システムであり，強調し合う独立コンポーネントから構成されるヘテロジニアスシステムとなる可能性を持つ．
課題
ソフトウェアシステムを独立しているが，相互運用可能なコンポーネントの集合として構築すると，高い柔軟性・保守性・変更容易性を備えたものとして作れる． ところで，このような分散コンポーネント同士が通信を行う際に，何らかのプロセス間通信が必要となる． 自身で通信を行うとすると，システムが依存性を持ち制約を受けてしまう．
以下のフォースのバランスを取る必要がある
- リモートコンポーネントが提供するサービスへのアクセスは，コンポーネントから透過的に行える
- コンポーネントの交換，追加，削除が実行時においても可能である
- コンポーネントやサービスのユーザから，システムや実装に依存する部分を隠蔽する
解決策
クライントとサーバをぶんりするために，「ブローカ」の役割を演じるBrokerコンポーネントを導入する. * サーバはこのブローカに自分自身を登録し，メソッドインターフェースを介して自らのサービスをクライントに提供する * クライントはブローカを経由してリクエストを送ってサーバの機能にアクセスする
Brokerパターンによって，アプリは適切なオブジェクトに単にメッセージ呼び出しを行うだけで，下位レベルのプロセス間通信を考慮しなくても分散サービスにアクセスできる． またBrokerパターンによるアーキテクチャは柔軟なので，オブジェクトの動的な変更，追加，削除，再配置が可能となる．
静的側面
Brokerアーキテクチャパターンは，以下の6種類のコンポーネントから構成される．
- Client
- Server
- Broker
- Bridge
- Client-side Proxy
- Server-side Proxy
Server（サーバコンポーネント）
操作・属性からなるインターフェースによって機能を公開するオブジェクト群を実装したもの．
Client（クライアントコンポーネント）
サーバーにアクセスするアプリケーション． リモートのサービスを呼び出すために，クライアントはブローカにリクエストを送る． それに応じてある操作が実行され，クライアントはブローカからレスポンスや例外を受けとる．
Broker（ブローカコンポーネント）
クライアントからサーバへリクエストの送信，および，サーバからのクライアントへのレスポンスや例外の送信を行う責務を追うメッセージ仲介者． ブローカはリクエストの受信者の位置を特定する機能を持つ． さらに，サーバの登録やサーバメソッドの起動を行うための操作を含むAPIをクライアントやサーバに提供する．
Client-side Proxy（クライアントサイドプロキシコンポーネント）
クライアントとブローカの間に挿入される1つのレイヤを形成するコンポーネント． このレイヤが透過性を提供する． これによりクライントによってはリモートに存在するオブジェクトがローカルオブジェクトと同一のものとして見えるようになる．
Server-side Proxy（サーバサイドプロキシコンポーネント）
クライアントサイドプロキシと類似している． 異なる点は，サーバサイドプロキシが，リクエストの受信，受信メッセージのあんパッキング，パラメータのアンマーシャリングを行って，適切なサービスを呼び出す責務を追う点．
Bridge（ブリッジコンポーネント）
２つのブローカが相互運用する際の，実装詳細を隠蔽するのに利用できるコンポーネント
動的側面
シナリオ1
- システムの初期化が行われ，イベントループ状態になりメッセージの到着を待つ．
- ユーザやその他の実体により，サーバアプリが起動されると，サーバは自らの初期化コードを実行する．
そして自分自身をブローカに登録する - ブローカはサーバからの登録要求を受取り，リポジトリに格納する．このリポジトリはサーバの特定や活性化に用いられる．
サーバには承認を返す． - ブローカから承認が返されると，サーバはメインループに入り，クライアントからのリクエストを待つ．
シナリオ2
このシナリオは，クライアントがローカルに位置するサーバにリクエストを送る場合である．
- クライアントは，リモートサーバオブジェクトのメソッドを起動する
- クライアントサイドプロ棋士は，パラメータ等をメッセージにパッケージングして，ブローカに転送する
- ブローカは，要求されたサーバ位置をリポジトリから検索し，サーバサイドプロキシにメッセージを転送する
- サーバサイドプロキシは，メッセージをあんパッキングし，適切なサービスを起動する
- サービスの実行が完了するとサーバはサーバサイドプロキシに結果を返す． ...
- 最終的にクライアントがレスポンスを受け取る．
シナリオ3
ブリッジを介する場合のブローカ間の相互作用を示す．
- ブローカAがリクエストを受取，リポジトリを検索して，指定されたサービスを実行できるサーバを特定する.
そのサーバが別のネットワークノードにあるので，ブローカAはリモートブローカにリクエストを転送する． - メッセージがブローカAからブリッジAに渡される．
- ブリッジAはメッセージ変換し，ブリッジBへメッセージを送信する.
- ブリッジBは受け取ったリクエストを，ネットワーク依存のフォーマットからブローカBが解釈できるフォーマットへ変換する
- ブローカBはリクエストを受け取ると，そのリクエストで必要とされるすべての処理を実行する
実装
- オブジェクトモデルを定義する，あるいは既存のオブジェクトモデルを利用する.
- システムがどのようなコンポーネント相互運用性を提供するかを決定する
- クライアントとサーバを強調させるために，ブローカコンポーネントが提供するAPIを規定する
- クライアントやサーバからのプロセス間通信の実装を隠蔽するために，Proxyオブジェクトを利用する
- ステップ3,4と同時に，ブローカを設計する
- IDLコンパイラを開発する
バリエーション
直接通信ブローカシステム
効率化という観点で，ブローカ経由の通信を避けたいときがある． クライアントとサーバの直接通信が行われる．
メッセージ通信ブローカシステム
RPCシステムを実装するためのものではなく，データ送信に商店を合わせたシステムに適したもの．
トレーダシステム
アダプタブローカシステム
柔軟性を向上させるために，アダプタレイヤを追加してサーバに対するブローカコンポーネントのインターフェースを隠蔽できる．
コールバックブローカシステム
このモデルはイベント駆動型であり，クライアントとサーバの区別を規定しない．
適用例
CORBA
SOM/DSOM
OLE
WWW
ATM-P
結論
Brokerパターンの利点
- 位置透過性
- コンポーネントの変更容易性と拡張性
- ブローカシステムの移植性
- 他のブローカシステムとの相互運用性
- 再利用性
Brokerパターンの欠点
- 効率の制限
- フォールトトレランスの低下
