導入 †
- これまで見てきたパターンはどうやって組み合わせるのか?これらのパターンを使ってアプリケーション同士をどうインテグレーションするのか?コードはどうなって、どう動くのか?
リクエスト・リプライの例 †
- 主なクラスは二つ
- Requestor : リクエストメッセージを送信して、リプライメッセ―ジを待つ
- Relier : リクエストメッセージを受け取って、リプライメッセージを返す
- 扱うパターン
- メッセージ・チャネル(60)とポイント・ツー・ポイントチャネル - リクエストとリプライに対してチャネルを一つずつ割り当てる
- ドキュメント・メッセージ(147) - リクエストとリプライの両方で使うメッセージのタイプ
- リクエスト・リプライ(154) - アプリケーションが双方向のコミュニケーションのコミュニケーションをできるようになる。
- リターンアドレス(159) - レスポンスを返すチャネル
- 相関識別子(163) - このレスポンスを引き起こすリクエストのID
- データ型チャネル(111) - 各チャネルのメッセージがすべて同じ型でなければならない
- 不正メッセージのチャネル(115) - 正しくない型
- 第10章の「メッセージング・エンドポイント」のパターンも使っている
- ポーリング・カスタマー - リクエスターがリプライメッセージをどう受け取るか
- イベント駆動。コンシューマー - リプライアがリクエストメッセージをどう受け取るか
- この本は、技術や製品、言語に中立だが、コードはそうはいかない。メッセージングプラットフォームとして、以下の二つを選んだ。
パブリッシュ・サブスクライブの例 †
- パブリッシュ・サブスクライブチャネル(106)を使って、どうやってオブザーバーパターンを実装するかを考える。分散やスレッドの問題を扱い、メッセージングによって問題が単純になるところを見る。プッシュモデルとプルモデルを両方実装し、それぞれどうなるかを比較する。さらに、複雑なエンタープライズでチャネル過不足なく設計するにはどうすればよいかも考える。
- 扱うパターン
- パブリッシュ・サブスクライブチャネル(106) - パブリッシュ・サブスクライブ型の通知をできるようにするチャネル
- イベントメッセージ(151) - 通知を送るのに使われるメッセージ
- リクエスト・リプライ(154) - プルモデルの一部として使われるテクニックで、オブザーバーがサブジェクトの状態を問い合わせる
- コマンドメッセージ(145) - サブジェクトの状態を問い合わせるのにつかうメッセージのタイプ
- ドキュメント・メッセージ (147) - サブジェクトがオブザーバーに対して自分の状態を送信するのに使うメッセージのタイプ
- リターン・アドレス (159) - サブジェクトが状態をオブザーバーに返すのに使う方法を伝える
- データ型・チャネル (111)- 関連しないサブジェクト二つが同じチャネルを使って同じオブザーバーを更新できるかどうか
- また、第10章「メッセージングエンドポイント」からもいくつかパターンを引っ張っている。
- メッセージングゲートウェイ(468) - サブジェクトとオブザーバがメッセージングコードをカプセル化する方法
- イベント駆動コンシューマー(498) - オブザーバが通知メッセージを受け取る方法
- 持続可能なサブスクライバ (522) - 通知が送られたときに落ちていたとしても、通知を受け取り損ねたくないオブザーバー。
- こちらはJMSを使ってJavaでだけ実装する。JMSのTopicインターフェイスがいい具合にパブリッシュ・サブスクライバをサポートしているからで、MSMQだといまいち。MSMQが対応すれば、JMSのテクニックが仕えるようになる。