EIP / New Catalog

New Catalog †

一言要約 †

カタログを更新するのだ。

要約 †

WGRUSのカタログには、ウィジェットとガジェットそれぞれの製品が並べられている。
一度の注文でそれぞれの製品を注文可能なサービスも。

• 複数の供給源からの情報をひとつに統合するという情報ポータルの例。

サプライヤーによるカタログ更新の頻度は3ヶ月。
そこでFile Transferですよ。

• FTPなどのプロトコルで簡単且つ効率的にインターネットでやり取り可能。
• 非同期メッセージングはインターネットとは相性が悪い。

内部のカタログフォーマットを合わせるのに、トランスレーターとアダプターを使用することも可能。

• ただし、トランスレーターは、レコード単位ではなくカタログのすべてを一度に処理。
  • 同じフォーマットで大量のデータを扱うのであれば、非常に効率的。

Announcements †

一言要約 †

聞いてもらいたい人にだけ伝えておきたいのだが。

要約 †

特価品をアナウンスしたい。
特定の顧客には特定のメッセージを送りたい。

• 優先顧客に特別な取引の案内とか。

複数に発信するのに、Publish-Subscribe Channelを使えそう。

が、若干不利なことが。

1. サブスクライバーがパブリッシャーを知らなくてもメッセージを取得できちゃう。
   • 大口顧客向けのメッセージは小口顧客に受け取ってほしくない。
2. 効率的に働くのはローカルのネットワーク内のみ。
   • WANを通して送る場合は、サブスクライバーそれぞれにメッセージのコピーを送りつける必要ががが。

ということで、顧客が購読希望を出し、それぞれの顧客へ個々のメッセージを送るソリューションが必要。
そこでDynamic Recipient Listですよ。

• Message Routingの二つのパターンを組み合わせたもの。
• Recipient Listは一組のレシピエントにひとつのメッセージを伝搬させるルーター。
  • Publish-Subscribe Channelとの主な違いは、レシピエントの宛先を知っていて、誰がメッセージを受信するかをきっちり制御しているところ。
• Dynamic Routerは、ルーティングアルゴリズムを制御メッセージに基づいて変えることができるルーター。

実装例。

• メールの場合。
  • 一般的なメールシステムの提供するメーリングリスト機能を利用可能。
  • それぞれのレシピエントチャネルはメールアドレスで特定。
• Webサービスのインターフェイスの場合。
  • それぞれのレシピエントチャネルはSOAPのリクエストとして実装。
  • チャネルのアドレスはWebサービスのURIとなる。

ソリューションのデザインに使うパターンは、特定のトランスポート技術に依存しない。

Testing and Monitoring †

一言要約 †

メッセージが正しく実行されたかをモニタリングするのは超重要。

要約 †

Message Storeは、注文にかかる平均時間など重要なビジネスメトリクスを提供。

でも、インテグレーションソリューションのうまくいったオペレーションの詳細なんかも知りたくなるかも。

顧客の信用調査で外部の信用調査機関にアクセスするソリューションを強化することを考えてみる。

• 支払い状況が悪く見えなくても、信用度が低い顧客なら注文数を減らしたいよね。
• 特に支払い履歴のない、新しい顧客なら尚更のこと。

外部のサービスなので使用料を払わなくちゃいけない。

• プロバイダの請求書について、実際の使用量を追跡してそれと突き合わせたい。
• お得意さんの外部信用調査は行わないとしたら、単純に注文数に従うことはできない。
• 外部プロバイダのQoS合意書なんかも。
  • 応答時間がしきい値を超えると、そのリクエスト分の支払いは発生しないなど。

といったところで正しく請求されているかを確認するのに、リクエストの数と応答時間を追跡したい。

2つの状況に対応できるべき。

1. 外部のサービスは一度にひとつ以上のリクエストを処理できるので、リクエストとリプライのメッセージをマッチできるか。
2. 外部のサービスを内部の共有サービスとして扱うので、サービス利用者にReturn Address（サービスがリプライメッセージを返すチャネル）の指定を許可できるか。

リプライがどのチャネルに送られているか不明なら、リクエストとリプライのマッチは難しい。

ここで再びSmart Proxyですよ。

• サービス利用者と外部サービスの間に挿入。
  • サービスのリクエストをインターセプトし、利用者ごとのSmart Proxyで固定の応答チャネルを置換。
• 外部サービスのリクエストとリプライのメッセージ間の経過時間も測定。
  • 計測結果はControl Busに通知。
    • Control Busは多くの異なるコンポーネントからのメトリクスを収集する管理コンソールとつながってる。

外部の信用サービスの使用量を追跡する以外にも、正しく動いているかを確認したい。
Smart Proxyは、タイムアウトしきい値内にリプライメッセージを受け取れなかったケースを管理コンソールに通知。

外部サービスが誤った結果をリプライとして送ってくるケースは、発見が非常に難しい。

• 外部サービスが故障してすべての顧客の信用度を0でリターンすると、すべての注文を拒否することになる。
• 保護メカニズムは2つ。
  1. 定期的にTest Messageをリクエストメッセージに差し込んでおく。
     • 信頼度を知っている特定の人の信頼度を取得。
     • リプライ受信チェックとメッセージ内容のチェックも可能。
     • Smart ProxyはReturn Addressをサポートするので、テストデータジェネレーターは通常のリプライとは分離されたテスト用のリプライチャネルを使用できる。
  2. 統計サンプルを取る。
     • 顧客の信用度が低いことがあることもふまえ、平均で10中1未満の注文を拒否すると期待しているとき。
     • 続けて5以上の注文を拒否した場合、外部サービスかビジネスロジックが故障している兆候と見なせる。
     • 管理コンソールは拒否が正当かどうかを管理者に、この5つの注文のメールを送信する。

担当者のつぶやき †

これまでの本に比べたら大分読みやすいと思います。

みんなの突っ込み †