私はSOAPWebサービスを始めたばかりで、WS-Addressingに出くわしました。
ウィキペディアのページを読みましたが、WS-Addressingのポイントが何であるかを理解するのに苦労しています。
ウィキペディアおよびWeb上のさまざまなソースによると、WS-Addressingを使用すると、「アドレス指定情報」または「ルーティング情報」をSOAP要求のヘッダーに入れることができます。
なぜこれが便利なのですか？HTTP経由（またはSMTPやUDP経由）でリクエストを送信する場合、送信先のアドレスはリクエストを処理するサーバーのアドレスであり、サーバーは同じチャネルで簡単に応答できます。では、なぜアドレス指定/ルーティング情報が必要なのですか？
WS-Addressingが役立つ実際の（多かれ少なかれ）例に特に興味があります。
WS-Addressingは、SOAP応答をすぐに提供できない状況で特に役立つことがわかりました。応答を形成するためのリソースがすぐに利用できないか、結果自体が生成されるまでに長い時間がかかります。
これは、たとえば、ビジネスプロセスに「人間的なタッチ」が含まれる場合に発生する可能性があります（WS-HumanTaskが対象としているプロセスのようなプロセス）。あなたはあなたのビジネスの前にウェブサービスを固執することができます、しかし時々ビジネスは時間がかかります。手動で検証する必要のあるサブスクリプション、承認されるものなどがありますが、それを行うには数日かかります。その間ずっと接続を開いたままにしますか？応答を待つ以外に何もしませんか？いいえ！それは非効率的です。
必要なのは通知プロセスです。クライアントは要求を行いますが、応答を待ちません。代わりに、「返信先」アドレスを使用して、応答の送信先をサーバーに指示します。応答が利用可能になると、サーバーはそのアドレスに接続して応答を送信します。
そして出来上がり... Webサービス間の非同期相互作用、通信プロセスの存続期間をHTTP接続の存続期間から切り離します。非常に便利...
しかし待ってください...HTTP接続？なぜ私はそれを気にする必要がありますか？別のタイプのプロトコルで応答を送り返したい場合はどうすればよいですか？（SOAPはどのプロトコルにも関連付けられていないため、親切に提供します）。
通常の要求/応答フローでは、応答は要求と同じチャネルで送信されます。これは、既知の接続である場合に使用します。たとえば、HTTP接続があります。これはHTTP入力とHTTP出力を意味します。
しかし、WS-Addressingを使用すると、それに縛られることはありません。別のタイプのチャネルで応答を要求できます。たとえば、リクエストはHTTPで送信されますが、たとえばSMTP経由でレスポンスを返送するようにサーバーに指示できます。
このように、WS-Addressingは、複数のトランスポートを介してメッセージをルーティングする標準的な方法を定義します。ウィキページが言っているように：
ルーティング情報を伝達するためにネットワークレベルのトランスポートに依存する代わりに、WS-Addressingを利用するメッセージには、標準化されたSOAPヘッダーに独自のディスパッチメタデータが含まれる場合があります。
そしてあなたの観察に関して：
サーバーは同じチャネルで簡単に応答できます
...ある人にとってはうまくいくもの、他の人にとってはうまくいかないかもしれないもの、そして他の人にとってはWS-Addressing：Dがあります。