非同期メッセージングベースのサービスでのメッセージ検証
非同期メッセージングベースのサービス（つまり、HTTPベースのAPIまたは同様のリクエスト/レスポンス指向の何かを提供するのではなく、何らかのメッセージキューまたはブローカーからメッセージをプルするサービス）でのメッセージ検証への最良のアプローチに関する情報を探しています）。
HTTP APIでは、メッセージが無効（フィールドが間違っている、JSON/XML /何でも無効）の場合、400エラーを返すことがあります。受信サービスは以前と同様に続行でき、送信者はエラーに対処する必要があります。 （多くのHTTPライブラリは200以外の応答が返されると例外を発生させ、問題の原因を非常に明確にします。）
非同期メッセージングプロセスでは、いくつかのアプローチを考えることができます。
- 受信プロセスは何らかの方法でエラーを処理します。
- 受信側のサービスは、無効なメッセージを無視するだけです。
- 受信サービスは無効なメッセージをログに記録してから、次のメッセージに進みます。正常に動作していないようであれば、うまくいけば、ログで問題を特定できます。
- 受信サービスは、ある種の応答チャネルでエラー通知を送り返します。
これらのオプションのどれも、特に良いようには見えません。
オプション（1）は、実際にはまだ知られていないソリューションの方向への単なる「ハンドウェーブ」です。
オプション（2）〜（3）は、送信者のコードがマスキングされて特定が困難になるリスクを冒しているようです（「場所」で発生する400応答をすぐに特定できる要求と応答の状況と比較して） "エラーの原因に非常に密接に関連しています）。
オプション（4）は、要求/応答システムを再作成しようとしているようで、非同期メッセージングベースのシステムを選択する理由を否定しています。リクエスト/レスポンスを行う場合、そもそもなぜメッセージブローカーベースのシステムを使用するのでしょうか。
ベストプラクティス、および上記の緊張がどのように解決されるかについての情報をいただければ幸いです。
最も*メッセージ指向ミドルウェア プラットフォームは、schematic検証（ieスキーマに対するメカニズム）エンキューされた着信メッセージ。これは、欠落/ nullフィールド、特定の範囲外の値、不正なフォーマットなどをチェックするロジックです。ただし、これらのチェックは、エンドシステムではなくメッセージブローカーによって実行されるため、チェックできませんreferences（顧客IDが存在する、注文が存在するなど）.
*ダム文字列をキューに入れるシステムだけでなく、強く型付けされたメッセージブローカーの「ほとんど」。
たとえば、JMSでは 'Validator'メソッドを割り当てることができます： https://docs.spring.io/spring/docs/4.1.1.RELEASE/spring-framework-reference/html/jms.html# jms-annotated-method-signature
WCFには似たようなものがあり、私が見つけた最も近いものは この記事 であると思います。
あなたのオプションについては、おそらく4が最も一般的だと思います。 （スケーラビリティーに関して）この応答チャネルが要求/応答型のシステムよりも好ましい理由があります（メッセージを検証し、いつでも例外を送信できます。その間、両端でソケット+プロセス/スレッドを拘束するのではなく、ライブなどを待つ。
メッセージを Dead Letter Queue に送信することもできます
メッセージキューイングでは、デッドレターキューは、次の基準の1つ以上を満たすメッセージを格納するためのサービス実装です。
存在しないキューに送信されるメッセージ。
キューの長さの制限を超えました。
メッセージの長さの制限を超えました。
メッセージは別のキュー交換によって拒否されました。
メッセージは消費されないため、しきい値の読み取りカウンター数に達しました。
これは「バックアウトキュー」と呼ばれることもあります。これらのメッセージをデッドレターキューに保存することで、開発者は一般的なパターンと潜在的なソフトウェアの問題を探すことができます。
現在のプロジェクトで確認した限り、＃4が使用されています。検証チェックが失敗した場合は、ソースチャネルに通知を送信します。
私はここ数年、キューベースのAPIを使用しており、実装されたソリューションは正常に機能していることがわかりました。彼らがこのAPIで行ったことは次のとおりです。
- クライアントは、処理するメッセージをRESTエンドポイントに送信します
- メッセージの正当性が検証されます。有効でない場合、応答はHTTPエラーです。それ以外の場合は200が返され、キュー内のメッセージを識別するIDが含まれます
- メッセージの処理中にエラーが発生した場合は、別のログファイルに記録されます
- クライアントは常に、別のエンドポイントを介してキューにクエリを実行し、キューに入れられたメッセージの現在のステータスを確認できます（たとえば、すべてのエラーをクエリできます）。
HTH。
送信者は要求を検証するためのすべての情報を持ち、キューにはこれらの無効化を含むデータがないため、要求に対して実行できる回路図およびその他の検証は送信者側で実行できます。これは、新しいサービスがキュー内のデータをリッスンして処理したい場合にも将来的に役立ちます。
送信者が受信者サービスの範囲に含まれないエラーに対して有用なことを何でも実行できる場合、送信者が検証/防止できないエラーについては、応答キュー/エラーを通じて受信者に送り返すことができますキュー、それ以外の場合は、受信者側でログに記録したり警告したりできます。これにより、後者の場合の応答キューの不要な作成が削減されます。前者の場合、送信者がそのスコープ内にある何かで応答を送信できる場合、応答を送信することは問題ないようです。どちらの場合も、検証エラーはすぐに特定され、その生成元に近くなります。