22

私はWebサービス、JAX-WSなどにまったく慣れていないので、おそらく初心者の質問です...

そこで、2つのシステムを通信させるためのWebサービスを実装したいと思います。「クライアント」システムは、「サーバー」システムで生成されるイベントに関心があります。ただし、「クライアントシステム」は、それ自体が別のアプリのサーバーです。サーバーはJava（tomcatではWAR）です。クライアントは.Netです。

クライアントシステムは1つだけである必要がありますが、クライアントシステム内には複数のクライアントプロセスがあり、それぞれが異なるカテゴリのイベントに関心を持っています。

サーバー側とテストクライアントを実装します。他の誰かが.Netコードを実装します。

実行シーケンスはこの線に沿っている必要があります：

  1. サーバーが実行されています...
  2. クライアントは会話を開始し、サーバーに「登録」して、いくつかの初期データを要求します。
  3. サーバーは、登録されたクライアントのエンドポイントのリストを保持します
  4. サーバーには、特定のイベントが発生したときに通知されるリスナーがあります。次に、登録済みクライアントのリストを調べて、イベントを各クライアントに転送します
  5. ある時点で、クライアントは「登録解除」できず、イベントを受信したくないことをサーバーに通知できません。

まず、それは合理的に実行可能な何かのように聞こえますか？

また、SOAP（サーバー上のJAX-WS、クライアントの.Netで利用可能なもの）を使用する標準の組み込みメカニズムがありますか？サーバーは、クライアントからコールバックエンドポイントを取得するために使用できますか？

たとえば、RMIを使用して非常によく似た処理を行いました。この場合、クライアントはリモート参照を自分自身に送信するだけで、サーバーは後でant参照を保存できます。

最後に、エンドポイント参照を保存し、（集合的な）コールバックを作成し、リストを最新の状態に保ち、応答しないクライアントを削除して「ping」呼び出しを行うための標準ライブラリはありますか？

明確にするための注意：コールバックを使用した非同期メソッド以上のものが必要です。クライアントからの1つのメッセージは、サーバーからクライアントへの多くのコールバックメッセージを生成します。

4

4 に答える 4

16

任意の匿名クライアントに通知する通知機能を実装したいようです。

まず、SOAPメッセージを使用して情報を渡す方法を検討することをお勧めします。次に、java-JAX-WSまたは追加の非標準ライブラリを使用してこれを実現する方法を検討できます。重要なのは、SOAPメッセージを転送するために必要な重大な制限または仮定があるかもしれないということです。たとえば、ファイアウォールがHTTPメッセージをブロックする場合や、クライアントが「クライアントのみ」であり、サーバーの役割を果たしてSOAP通知要求を受信することができない場合があります。

注：非同期コールバックメカニズムはJAX-WS 2.0で定義されており、サービスはクライアントのエンドポイント参照を取得します。これは、DeepakBalaによって説明されているWebLogic/Fusion独自のソリューションによって提供されるのと同じ種類の機能です。Websphereには、同様の独自の非同期ソリューションがあります。これらはいずれも要件を満たしていません。これは、リクエストごとに1つの応答しか許可されていないためです。

SOAPオプション：

  1. 独自の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インターフェイスを宣言する必要があります。

  2. 上記と同じですが、SOAPヘッダーにWS-addressingデータを含めて、相手のエンドポイントアドレスのいずれかの側に通知します。

    基本的に最初のオプションと同じ問題/仮定。WS-addressingアドレスは、SOAPメッセージを正しいURLアドレスにインテリジェントにルーティングするのに役立ちますが、それ以上は役立ちません。

  3. WS通知を使用する

    この仕様は、シナリオに合わせて設計されています。
    WS-BaseNotificationサブスタンダードはあなたのニーズを満たします。通知プロデューサーとコンシューマーにWSDLポート定義を提供します。これは、コンシューマーからプロデューサーへのサブスクリプション、およびプロデューサーからコンシューマーへの通知のためのWS標準準拠のソリューションを提供します。

    問題/制限：（1）通知ペイロードの形式を定義していません。通知ペイロードは、アプリケーションドメイン固有です（独自の設計）。この標準では、「標準」または「組み込み」の通知状況またはメッセージは定義されていません。（2）上記と同じようにファイアウォールを通過するHTTP通知にも問題があります。（3）WS-Notificationは、Java EE / JAX-WSでサポートされている標準ではありません（ただし、拡張機能としてサポートしているオープンソースおよび商用のアプリサーバーはたくさんあります）。

  4. トラフィックがHTTPにカプセル化されたメッセージキューソリューション（JMSなど）を使用するこれには、クライアントとサーバー間を行き来するペイロードの独自の設計が必要です。つまり、両者の間で契約を形成します。利点は、クライアントが純粋なクライアントであり、メッセージが受信されたときにスレッドでメッセージリスナーが呼び出されることです。

    問題/制限：（1）上記と同じようにファイアウォールを通過するHTTP通知にも問題があります。（2）日曜大工の実装です。（3）現在使用しているよりも多くのテクノロジーを使用しています。

最終結果：
ソリューションの少なくとも一部を独自の設計にする必要があります。SOAP/WS標準は完全な要件を満たしていません。理論的には、この独自の設計は製品を活用して多くのレッグワークを提供できますが、通知スキーマ設計はユーザーが作成して統合する必要があります。

通知をプッシュする場合は、クライアントに通知を渡すための何らかの契約が必要であり、クライアントはSOAサーバーとして機能する必要があり、トラフィック用にファイアウォールを開く必要があります。ほとんどの企業は、サーバーを出てクライアントに渡すHTTPリクエストを許可していません。通常、ファイアウォールポートを開くには非常に正当な理由が必要ですが、それでも多くの企業は許可しません...

クライアントに通知をポーリングさせたい場合は、クライアントが頻繁に呼び出すことができるサーバー側の基本的なWSDLインターフェースが必要です。

将来のオプション：HTML5 Webソケット
クライアントがHTML5アプリの場合、Webソケット対応のサーバーはトラフィックをブラウザーにプッシュできます。企業がファイアウォールを開く可能性があります。SOAPメッセージはHTTPWebソケットを介して送信される可能性があり、通知をプッシュできるようになります。

于 2013-03-13T05:52:48.710 に答える
7

非同期クライアントは、ポーリングとコールバックを使用して、WSDLベースのサービスでサポートされます。あなたの場合、要件は比較的複雑だと思います。

Oracle Fusionミドルウェアのドキュメントページには、役立つシナリオの概要が記載されています。クライアントがHTTP202（受け入れ済み）を生成する要求を送信し、クライアントがメッセージキューで応答を待機できるようにする方法について詳しく説明します。あなたの場合、シナリオは以下に示すものから微調整することができます。

クライアントのコールバック

コールバックのカテゴリごとにいくつかの応答キューを開始します。クライアントは、キューのクライアントとカテゴリIDを指定することにより、それらをフィルタリングできます。これは、各クライアントまたは各クライアントの下で管理されるプロセスのコールバックメカニズムとして機能します。MDBは、信頼性と1回限りの配信を保証するために、ファイルストアまたはDBストアによってサポートされます。

もちろん、これを実装するためにOracleFusionwareは必要ありません。RabbitMQまたはRedis（トランザクションあり）を使用して、クライアントでのメッセージの受信を確認できます。クライアントが登録を解除したい場合は、電話をかけてキューのリッスンを停止します。

私はあなたのシナリオに合う業界標準を知りませんが、このソリューションはあなたにとってうまくいくはずだと思います。

于 2013-03-11T09:34:47.840 に答える
5

メッセージング製品を使用した「pub-sub」のより単純なアプローチを検討しましたか？（MQ、EMS、ActiveMQなど）

説明する要件は、「従来の」要求/応答同期/非同期SOAPWebサービスのシナリオに適合していないようです。

Pub / Subソリューションでは、クライアントはトピックを1回サブスクライブし、パブリッシャー（この場合はサーバー）はすべてのサブスクライバーに関連するメッセージをいくつでも投稿できます。

ボーナスとして、ほとんどのメッセージング製品には「耐久性のあるサブスクライバー」のサポートが含まれているため、クライアントは時々オフラインになり、再接続後にすべてのメッセージを受信できます。

あなたの場合、サーバーは（無料の）ActiveMQサーバーを収容することができます...あなたが求めているように見える機能のほとんどを提供します。

そのようにする場合は、.NetをサポートするJMS準拠の製品を選択することをお勧めします。

于 2013-03-13T17:36:15.653 に答える
0

検索エンジンからここに来る人のために：

最近では、Web Hook for Web APIを使用できます。これは、基本的にOPで説明されているとおりに機能します。

たとえば、RESTでは、クライアントには、実際のサーバーからPOSTイベント/通知を受信するための専用のHTTPエンドポイントがあります。クライアントは、通知エンドポイントでURIを指定することにより、エンドポイントを実際のサーバーに登録します。その時点から、実際のサーバーはクライアントの通知エンドポイントにPOSTできます。非同期の用語に精通している場合、これは本質的に複雑なコールバックです。

たぶん、Javaまたは.NetにはWebHooks用のライブラリがあります。

とは言うものの、SSEとWebsocketの標準は、HTTPおよびほとんどのブラウザーと互換性がありながら、実際のプッシュメッセージとリアルタイムメッセージを提供します。

過去には長いポーリングのバリエーションも使用されていましたが、現在は集合体としてコメットと呼ばれることもあります。

于 2017-03-21T06:20:16.930 に答える