SOAP Webサービスコールバックアーキテクチャ？
私はWebサービスやJAX-WSなどに非常に慣れていないので、多分noobの質問です...
そこで、2つのシステムが通信できるようにWebサービスを実装したいと思います。 「クライアント」システムは、「サーバー」システムで生成されるイベントに関心があります。ただし、「クライアントシステム」自体は別のアプリのサーバーです。サーバーはJava（TomcatのWAR）です。クライアントは.Netです。
クライアントシステムは1つだけですが、クライアントシステム内には複数のクライアントプロセスがあり、それぞれが異なるカテゴリのイベントに関心を持っています。
サーバー・サイドとテスト・クライアントを実装します。他の誰かが.Netコードを実装します。
実行シーケンスはこの行に沿っている必要があります：
- サーバーが実行中...
- クライアントは会話を開始し、サーバーに「登録」して、いくつかの初期データを要求します。
- サーバーは登録済みクライアントのエンドポイントのリストを保持します
- サーバーには、特定のイベントが発生したときに通知されるリスナーがあります。次に、登録済みクライアントのリストを調べて、各クライアントにイベントを転送します
- ある時点で、クライアントは「登録を解除」して、サーバーにイベントの受信を望まないことを通知することはできません。
最初に、それは合理的に実行可能な何かのように聞こえますか？
SOAP（サーバー上のJAX-WS、.Net nクライアントで利用可能なものなら何でも）を使用した標準の組み込みメカニズムがあります-サーバーはコールバックエンドポイントを取得するために使用できますクライアントから？
たとえば、RMIを使用して非常によく似た方法を実行しました。この場合、クライアントはリモート参照を自分自身に送信でき、サーバーは後で参照するantを格納できます。
最後に、エンドポイント参照を保存し、（集合的）コールバックを作成し、リストを最新に保ち、応答しないクライアントを削除して「ping」呼び出しを行う標準ライブラリはありますか？
明確にするために注意してください。コールバックを使用する非同期メソッドだけでなく、クライアントからの1つのメッセージでサーバーからクライアントに多数のコールバックメッセージが生成されます。
任意の匿名クライアントに通知する通知機能を実装したいようです。
まず、SOAPメッセージを使用して情報を渡す方法を検討することをお勧めします。次に、Java-JAX-WSまたは追加の非標準ライブラリを使用してこれを実現する方法を検討できます。重要なのは、SOAPメッセージを転送するために必要な重要な制限または前提条件がある可能性があることです。例えば。ファイアウォールがHTTPメッセージをブロックする可能性があり、クライアントがSOAP通知リクエストを受信するためにサーバーの役割で機能することができない「クライアントのみ」である可能性があります
注：非同期コールバックメカニズムはJAX-WS 2.0で定義されており、サービスはクライアントのエンドポイント参照を取得します。これは、Deepak Balaが記述したWebLogic/Fusion独自のソリューションが提供する機能と同じです。 Websphereにも同様の独自の非同期ソリューションがあります。リクエストごとに1つの応答しか許可されないため、これらはいずれも要件を満たしません。
SOAPオプション：
独自のSOAPメッセージ-「100％日曜大工オプション」
完全なSOAPペイロードスキーマとメッセージ交換パターンを設計します。
クライアントのSOAPエンドポイントアドレスがわかっている場合は、サーバーからクライアントに通知をプッシュできます。クライアントは、そのSOAPエンドポイントアドレスを元のSOAPリクエストペイロード内で転送できます。その後、サーバーはSOAP要求をクライアントに送信できます。
問題/仮定：（1）サーバーからクライアントへのリクエストにはSOAP/HTTP通信パスが必要-ファイアウォールが存在する場合は保証されません。 （2）クライアントは通知スキーマを認識する必要があります-実際、クライアントはSOAP通知リクエストを受信するためのサービスエンドポイントとして機能する必要があります。これは、任意の匿名クライアントをサポートしようとしている場合の2つの大きな前提です。これは何かではありませんSOAP "サポートするだけ"両端で詳細に設計する必要があります。実際、これをサービスのタイプセーフな方法で行うには、クライアントが独自のサービスWSDLインターフェースを宣言して、呼び出しできるようにする必要があります。 （3）前述のように、多くのクライアントは「単なるクライアント」であり、SOAP要求を受け入れるHTTPサーバーがない場合があります。
したがって、独自の「プッシュ」通知が機能するためには、両側がサーバーに、両方がSOAインターフェースを公開する必要があります。
または、通知をクライアントにプルすることもできます。クライアントは、ブロックまたはポーリングしているサーバーへの通知要求を使用できます。サーバーは通知または何もないかエラーで応答できます。
問題/仮定：（1）HTTPサーバー（つまり、SOAPサーバー）は、原則としてブロッキング要求をサポートしません。つまり、ポーリングする必要があります。 （2）クライアントは通知スキーマを認識する必要があります-実際、クライアントはSOAP通知リクエストを受信するためのサービスエンドポイントとして機能する必要があります。これは、任意の匿名クライアントの2つの非常に大きな前提です。これはSOAPではなく、両端を詳細に設計する必要があります。実際、これをサービスのタイプセーフな方法で行うには、クライアントが独自のサービスWSDLインターフェースを宣言して、呼び出しできるようにする必要があります。
上記と同じですが、SOAPヘッダーにWS-addressingデータを含めて、相手のエンドポイントアドレスのどちらかの側に通知します。
基本的に、最初のオプションと同じ問題/仮定。 WS-addressingアドレスは、SOAPメッセージを正しいURLアドレスにインテリジェントにルーティングするのに役立ちますが、それ以上はルーティングできません。
WS-notificationを使用する
この仕様は、シナリオに合わせて設計されました。
WS-BaseNotificationサブスタンダードはあなたのニーズを満たします。通知プロデューサーとコンシューマーにWSDLポート定義を提供します。これは、コンシューマからプロデューサへのサブスクリプション、およびプロデューサからコンシューマへの通知のためのWS標準準拠のソリューションを提供します。問題/制限：（1）通知ペイロードの形式を定義していません。通知ペイロードは、アプリケーションドメイン固有です（独自の設計）。標準は、「標準」または「組み込み」の通知状況またはメッセージを定義していません。 （2）ファイアウォールを通過するHTTP通知についても、上記と同じ問題があります。 （3）WS-NotificationはJava EE/JAX-WSのサポートされている標準ではありません（ただし、拡張機能としてそれをサポートする多くのアプリサーバー、オープンソース、商用があります）。
HTTPでカプセル化されたトラフィックでメッセージキューソリューション（JMSなど）を使用するこれには、クライアントとサーバーの間でやり取りされるペイロードの独自の設計が必要です。利点は、クライアントが純粋なクライアントであり、メッセージが受信されたときにスレッドでメッセージリスナーが呼び出されることです。
問題/制限：（1）上記のファイアウォールを通過するHTTP通知と同じ問題があります。 （2）日曜大工の実装です。 （3）現在使用しているよりも多くのテクノロジーを使用します。
最終結果：
ソリューションの少なくとも一部を独自の設計にする必要があります。SOAP/ WS標準は完全な要件を満たしていません。理論的には、この独自の設計は製品を活用して多くのレッグワークを提供できますが、通知スキーマ設計を作成して統合する必要があります。
通知をプッシュしたい場合は、クライアントに渡す通知のsomeコントラクトの種類が必要です。クライアントはSOAサーバーとして機能する必要があり、ファイアウォールを開く必要がありますあなたのトラフィック。ほとんどの企業は、サーバーを離れてクライアントに渡されるHTTPリクエストを許可していません。通常、ファイアウォールポートを開くには非常に十分な理由が必要ですが、それでも多くの企業はそれを拒否します...
クライアントに通知をポーリングしてもらいたい場合は、クライアントから頻繁に呼び出せるサーバー側の基本的なWSDLインターフェースが必要です。
今後のオプション：HTML5 Webソケット
クライアントがHTML5アプリである場合、Webソケット対応サーバーはトラフィックをブラウザーにプッシュできます。企業がファイアウォールを開く可能性があります。 SOAPメッセージはHTTP Webソケットを介して送信されるため、通知をプッシュできます。
ポーリングとコールバック の使用により、WSDLベースのサービスで非同期クライアントがサポートされます。あなたの場合、要件は比較的複雑だと思います。
Oracle Fusionミドルウェア ドキュメントページ には、役立つシナリオの概要が記載されています。これは、クライアントがHTTP 202（受け入れ済み）を生成する要求を送信し、クライアントがメッセージキューで応答を待機できるようにする方法を詳しく説明しています。あなたの場合、シナリオは以下に示すものから微調整することができます。
コールバックのカテゴリごとにいくつかの応答キューを開始します。クライアントは、キューのクライアントとカテゴリIDを提供することで、それらをフィルタリングできます。これは、各クライアントまたは各クライアントの下で管理されるプロセスのコールバックメカニズムとして機能します。 MDBは、信頼性と1回限りの配信を保証するために、ファイルストアまたはDBストアによってサポートされます。
もちろん、これを実装するためにOracle Fusionwareは必要ありません。 RabbitMQまたはRedis（トランザクションあり）を使用して、クライアントでのメッセージの受信を確認できます。クライアントが登録を解除したい場合は、呼び出しを行い、キューの待機を停止します。
私はあなたのシナリオに適合する業界標準を知りませんが、私はこのソリューションがあなたのためにうまくいくと信じています。
メッセージング製品を使用した「pub-sub」のより簡単なアプローチを検討しましたか？ （MQ、EMS、ActiveMQなど）
あなたが説明する要件は、「クラシックな」要求/応答の同期/非同期SOAP Webサービスのシナリオに適合しないようです。
Pub/Subソリューションでは、クライアントはトピックに1回サブスクライブし、パブリッシャー（この場合はサーバー）はすべてのサブスクライバーに任意の数の関連メッセージを投稿できます。
おまけとして、ほとんどのメッセージング製品には「恒久サブスクライバー」のサポートが含まれているため、クライアントはオフラインになり、再接続後にすべてのメッセージを受信できます。
あなたの場合、サーバーは（無料の）ActiveMQサーバーを収容できます...探しているように見える機能のほとんどを提供します。
そうした場合は、.NetをサポートするJMS準拠の製品を選択することをお勧めします。
検索エンジンからアクセスする場合：
現在、Web API for Web APIを使用できます。これは、基本的にOPの説明どおりに機能します。
RESTたとえば、クライアントには、実際のサーバーからのPOSTイベント/通知の受信専用のHTTPエンドポイントがあります。クライアントは自分のエンドポイントを登録します。彼の通知エンドポイントにURIを与えることにより、実際のサーバーで。その時点から、実際のサーバーはクライアントの通知エンドポイントにPOSTすることができます。非同期の用語を使用します。
たぶんJavaまたは.NetにはWebHooks用のライブラリがあります。
つまり、SSEおよびWebsockets標準は、HTTPおよびほとんどのブラウザーと互換性がある一方で、実際のプッシュおよびリアルタイムメッセージを提供します。
長いポーリングのバリエーションも過去に使用され、現在は彗星と呼ばれることもあります。