非同期（キューに登録された）メッセージと関連付けられたセッションデータ

Question

私はキューに入れられたメッセージングシステムのセッションコンテキストデータを実装しようとしています。

セッションの処理は次のようになります。 フロントエンドアプリケーションは自身を認証し、セッションIDを受け取ります。 その後、セッションIDがメッセージヘッダに含まれるので、メッセージハンドラには、例えば、セキュリティチェック、監査ロギング。クライアントがクラッシュして作業を続けると、クライアントがセッションを取得することがあります。

ここで、キーと値のペアをセッションIDに関連付ける必要があります。しかし、これは、メッセージ・ハンドラーが使用するセッション・データがメッセージの送信時に使用されていなければならないため、セッション・データが変更された場合に多くの並行性の問題を引き起こします。

Iは、2つの可能な解決策を参照：

1. を
2. すべてのメッセージヘッダに関連付けられたセッションデータを入れて保存セッションデータがデータベースにバージョンとメッセージヘッダにバージョン番号を使用します。

最初のメッセージはメッセージを大きくし、2番目のメッセージはセッションDBを大きくし、多くのインフラストラクチャコードを作成します。私は両方のDBに最新の値を保存しなければならないので、クラッシュまたは接続が失われた場合でもクライアントは作業を続けることができます。

他に解決策はありますか？私は最初の解決策を使う傾向がありますが、最初にいくつかのフィードバックを得たいと思います。

（JMS/NServiceBus/Masstransitなど）他の人がこれをどのように処理しますか？回答に基づいて

更新：のみフロントエンドでセッションデータを使用するために私のチームメンバーを説得し、それがメッセージハンドラのために必要とされる場合、メッセージにそれを置くのルートを取るために選ばれた I've。

Answer 1

セッションコンセプトにキーと値のペアを関連付ける理由について詳しくは触れていません。

SOAとサービスの境界に関するNServiceBusとUdi Dahanの助言から来るこのタイプのセッションコンセプトは、間違った方法で私をこする傾向があります。私の気持ちは、メッセージハンドラは、ほとんどの場合、時間に関してかなり決定的でなければならないということです。つまり、すぐに実行するか、しばらく待ってから、いつか同じ方法で実行してください。

私の助言は、セキュリティ上の理由から、必要に応じてメッセージヘッダーを使用することです。 NServiceBusでは、ハンドラチェーン内で最初に実行されるように設定されたIT/Opsサービスからのメッセージハンドラを導入し、実際のビジネスロジックとは独立したセキュリティやそのようなものを検証できます。この場合、ヘッダー情報はメッセージが処理されるか拒否されるかに影響します。

セッションタイプの情報が得られたら、それらの要件を慎重に分析し、関連する部分をメッセージスキーマ自体に入れたいと思います。

この場合も、最初にセッションデータの背後にある動機づけを知ることは役に立ちます。質問を編集した場合、おそらくそれらの要件を再編成する方法を特定することができます。