WS-notification（WS Notification）を使用して通知するだけにするか、データをペイロードとともに送信して余分な呼び出し（バック）を節約する必要があります。
ユースケース：顧客の記録が変更されました。他のシステムに通知する必要があります。通知を送信します。
シナリオ1.顧客レコードの変更を含む通知を送信します。各リスニングシステムが異なるアクションを実行したり、顧客レコードを必要とする場合と必要としない場合があるため、悪い可能性があります。
シナリオ2.通知を送信するだけです。各リスニングシステムが何らかの方法で「反応」する必要があることを意味します。責任はリスニングシステムにあります。
2つの方法。
Pub /SubPushおよびPub/SubPull。
Pub / Sub Pushは、完全なデータをプッシュすることです。
Pub / Sub Pullは、ターゲットアプリがコールバックして完全なデータを要求するのに十分なデータを送信することです。これにより、pub /subpushメソッドよりも渡される情報をより適切に制御できます。
Pub / Sub Pushメソッドは、実装が最も簡単です。
Pub-subの種類は、通知の消費者がサブスクライブしているという事実により、問題のトピックにすでに関心があることを意味します。しかし、あなたが言うように、彼らは応答する必要がないかもしれません。したがって、通知を真のイベントと見なす場合、通知システムは「これが私の状態が変更されたという通知です」と言っています。通知コンシューマーが関心を持っている場合は、request-responseを使用してその新しい状態を取得できます。これは、より柔軟で軽量になります。通知は本質的にイベント指向であるため、状態をプッシュするために通知を使用することは慎重に検討する必要があります。特にpub-subの場合と同様に、実行時にサブスクライバーの数を把握することはめったにありません。その場合、容量の計画は困難になる可能性があり、ピーク負荷の急増は珍しくありません。したがって、通知を軽量に保ちます。イベントに参加するかどうかを消費者に決定させます。あなたは真のEDAへの道を進んでいます！