管理コンソールの最初のバージョン は、コードが表示する煩わしさがなくとても簡単だった。 メッセージを受け取ると、あとで分析のために1つのファイルにメッセージの内容を書く。
今、いくつかのより賢さを、管理コンソールに取り入れる。 1つめは、第1のクレジットの案内係の監視が、失敗を示す。 管理コンソールは、コンテキストベースのMessage Routerでメッセージを第2のサービスプロバイダーに経路決めするために、指示をかける。 管理コンソールの中にこの機能を実装することを選択するので、 監視と、コンテキストベースのMessage Routerを分離することができる。 効率的に、管理コンソールはMediator[GOF]として動く。
2つめに、システムの現在の状態を表示する管理コンソールのために簡単なユーザインターフェイスを組み立てていく。 特に、メッセージのパスが動的に変わるのであれば、メッセージングシステムの全体像を取得することはかなり難しい。 コンポーネントの小さい数は、メッセージが流れる場所を調整することを難しくさせる。 ユーザインターフェイスは、単純だが、それでもやはり、かなり役に立つ。 コンポーネント間の相互作用を表現するためにこの本の中で定義されたアイコンの言語を使用している。 今や、ユーザインターフェイスは、システムのクレジット窓口案内係フェイルオーバー部分だけを表示しており、2つのサービスとコンテキストベースのMessage Routerで構成されている。
The Management Console Indicates That Both Credit Bureau Services Are Active
The Management Console Indicates That the Primary Credit Bureau Failed and Traffic Is Being Rerouted
クラス図
Propagation of Events Inside the Management Console.
1つのチャプターのスコープにこの例を合わせるために、いくつかの単純化した想定で作らなければならない。 例えば、フェイルオーバーのメカニズムは、第1のクレジット案内所サービスが失敗したときにすでにキューに積み上がったメッセージを扱えない。 これらのメッセージは、サービスが復旧されるまで積み上ったままにする。
ローンブローカーは、機能し続けることができる。なぜなら入ってくる応答メッセージを、返信メッセージに関連づけるため。 しかし、"stuck"メッセージに関連づいたローン相場要求は、第1のクレジット案内係のサービスがオンラインに戻るまで処理しないであろう。 フェイルオーバーシナリオで応答時間を改善するために、ローンブローカーに失敗したサービスの前で無期限に積み上がったこれらのメッセージのために、要求メッセージを再発行する再送信機能を実装すべきである。 代わりに、フェイルオーバールーターは、サービスの正しい機能が最後に確認されてから到着した全ての要求メッセージを保存することができる。 もしサービスの失敗が検出されたら、ルーターはこれらのメッセージを再送信することができる。なぜならこれらのいくつかは、正しく処理されてこないかもしれないからだ。 このアプローチは、重複した要求メッセージを導くことができる。 しかし、クレジット案内所とローンブローカーの両方のサービスが、いくつかの問題を起こさないIdempotent Recivers である。- 重複した返答メッセージは、単純に無視される。
この例は、前回のチャプターにおいてそのパターンで実装したシステム管理機能の小さな部分集合だけをお見せした。 例えば、全てのコンポーネントを通るメッセージトラフィックを監視することができたり、パーフォーマンス限界点を設定したり、それぞれのコンポーネントにハートビートのメッセージを送ったり、などができる。 実際のところ、メッセージソリューションを配布するための頑丈なシステム管理を追加していくことは、より多い設計とオリジナルのソリューションとして実装努力を要求する。