ブローカーパターン
ブローカーパターンは、リモートプロシージャコール（RPC）によって相互作用する分離されたコンポーネントを持つ分散ソフトウェアシステムを構築するために使用できるアーキテクチャパターンです。ブローカーコンポーネントは、リクエストの転送、結果や例外の送信など、通信の調整を担います。[ 1 ]
意味
ブローカーパターンは、「ブローカー」と呼ばれる仲介ソフトウェアエンティティを用いて、2つ以上のソフトウェアコンポーネント間の通信を容易にするアーキテクチャパターンです。ブローカーはコンポーネント間の「仲介者」として機能し、コンポーネントが互いの存在を意識することなく通信できるようにします。
ブローカーパターンでは、ブローカーは1つのコンポーネントからメッセージを受信し、適切な受信者に転送する役割を担います。ブローカーを介して通信するコンポーネントは、サーバーまたはクライアントと呼ばれます。ブローカーは、フィルタリング、メッセージの変更、サービス品質（QoS）の確保（例：0は「最大1回」）、セキュリティ、ソフトウェアコンポーネントへの追加サービスの提供といった追加タスクを実行することもあります。
ブローカーパターンを使用すると、コンポーネントは分離され、それぞれの責務に集中しながらも、システム内の他のコンポーネントとの通信や連携が可能になります。また、コンポーネント間の依存関係を削減することで、システムの柔軟性と保守性を高めることもできます。
用語
ブローカ
- 登録されたソフトウェア コンポーネントのルーティング テーブルを維持します。
- 通過するメッセージを適切なソフトウェア コンポーネントに再ルーティングするためのフィルター テーブルを維持します。
- 情報セキュリティやサービス品質などの追加機能も保証できます。
サーバ
- メッセージを送信する役割を担うソフトウェア コンポーネント。
- 出版社とも呼ばれます。
クライアント
- 特定のメッセージをサブスクライブして待機するソフトウェア コンポーネント。
- 消費者または加入者と呼ばれることもあります。
利点
出典: [ 2 ]
- コンポーネントの動的な変更、追加、削除、再配置が可能です。
- ブローカーとの通信の 1 つのソース。インターフェースを定義します。
- コンポーネントは互いを認識する必要はありません。
デメリット
- 堅牢かつ効率的に記述する必要がある 1 つの中心コンポーネント。
- 送信されたメッセージのデータの一貫性がありません。
パターンの実際の実装
パターンに関する混乱
ブローカーパターンとパブリッシュ・サブスクライブパターンにはいくつかの類似点があり、混同されることもあります。[ 3 ]しかし、表現に関しては、いくつかの重要な違いがあります。
- ブローカーアーキテクチャ パターンは、多対1対多の図で表されます。
- パブリッシュ・サブスクライブ・アーキテクチャパターンは、多対多の図で表現されます。ここでは、メッセージング機能は横断的関心事として隠されています。
参考文献
- ^ 「解決策：ブローカーを使用する - パターン指向ソフトウェアアーキテクチャFor Dummies [書籍]」 www.oreilly.com . 2023年3月26日閲覧。
- ^ Stal, Michael (1995年1月1日). 「ブローカーのアーキテクチャフレームワーク」 . 2023年3月26日閲覧– www.academia.eduより。
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です - ^チーム、The HiveMQ。「MQTTクライアント、ブローカー、MQTTサーバーの接続確立の説明 - MQTTの基本：パート3」。www.hivemq.com。2023年3月26日閲覧。
 | このコンピュータプログラミング関連の記事はスタブです。不足している情報を追加してWikipediaに貢献してください。 |
