18

RESTful Web サービス経由で利用できるようにする Java アプリケーションがあります。クライアントがイベントの通知に登録できるメカニズムを作成したいと考えています。問題は、クライアント プログラムが Java プログラムであるという保証がないため、これに JMS を使用できないことです (つまり、すべてのクライアントが Java アプリである場合、クライアントが JMS トピックにサブスクライブできるようにすることができます)。そこで通知メッセージをリッスンします)。

ユースケースはおおよそ次のとおりです。

  1. クライアントは、特定のオブジェクトが更新されるたびに通知メッセージを取得することに関心があることを示す、RESTful Web サービス呼び出しを介してサーバー アプリケーションに自身を登録します。
  2. 対象のオブジェクトが更新されると、サーバー アプリケーションは、このイベントの通知を希望するすべてのクライアントに通知を送信する必要があります。

上で述べたように、すべてのクライアントが Java アプリである場合にこれを行う方法はわかっています。つまり、クライアントが通知メッセージをリッスンできるトピックを設定します。ただし、多くのクライアントが JMS トピックの通知メッセージをリッスンできない可能性が高いため、このアプローチは使用できません。

この問題が通常どのように解決されるかについて、誰かが私に教えてもらえますか? RESTful API を使用してどのようなメカニズムを提供できますか?

4

4 に答える 4

9

次の 4 つのアプローチが考えられます。

  1. Twitter のアプローチ: クライアントを登録すると、GET を使用して定期的にコールバックし、通知を取得します。

  2. クライアントは、登録要求を行うときに通知を受け取る方法を記述します。そうすれば、JMS を処理できる人には JMS を許可し、できない人には電子メールなどにフォールバックできます。

  3. 登録リクエスト中に URL を取得し、通知があるときに各クライアントに個別に POST します。Pub/Sub はほとんどありませんが、効果は似ています。もちろん、クライアントはこれらの通知をリッスンしており、仕様に従ってクライアントを実装していると想定しています。

  4. IBM WebSphere MQ (MQSeries) を購入します。史上最高の IBM 製品。REST ではありませんが、このようなマルチプラットフォーム統合には優れています。

于 2009-07-07T18:28:47.940 に答える
4

私たちはこの問題を抱えており、比較的少数のリスナーに対して低遅延の非同期更新を必要としています。私たちの2つの代替ソリューションは次のとおりです。

  1. ポーリング:必要なリソースのリストを GET リクエストで叩く
  2. イベント更新のストリーミング:モニター リソースを提供します。サーバーは接続を開いたままにします。イベントが発生すると、サーバーは、マルチパート コンテンツ タイプまたはチャンク転送エンコーディングを使用して、イベントの説明のストリームを送信します。
于 2009-10-13T21:20:58.520 に答える
3

RESTful 要求への応答で、クライアントが更新を監視できる個別の RESTful URL を指定できます。

つまり、1 つの URL (/Signup.htm など) があり、クライアントの情報 (適切な場合は ID、監視するオブジェクトの ID) を受け取り、カスタマイズされた URL (/Monitor/XYZPDQ) を返します。ここで、XYZPDQ は作成された UUID です。その特定のクライアントのために。クライアントは、そのカスタマイズされた URL を一定の間隔でポーリングでき、更新が発生した場合に通知を受け取ります。

クライアントが誰であるかを気にしない場合 (そして、それほど多くの UUID を作成したくない場合) は、監視する必要があるオブジェクトごとに個別の RESTful URL を用意するだけで、「サインアップ」URL は単に正しいもの。

John Saunders が言うように、HTTP 経由でより簡単なパブリッシュ/サブスクライブを実際に行うことはできません。

于 2009-07-07T18:29:25.927 に答える