CometD：外部サーバーから公開

Question

CometDの一般的なユーザーの使用例/アーキテクチャを理解して、適切なトラックにいるかどうかを確認しようとしています。ここに、私たちの意図する用途を説明する図があります。

我々はCometDサーバーは、当社のWebサービスのためのイベントのパブリッシュ/サブスクライブのより多くのことがしたい

、NO CONTENTはCometD、イベントデータのみを通過しません。 Webサービスは、処理するアクションに基づいてクライアントにイベントをパブリッシュできます。また、長期実行プロセス/スケジュールされたプロセスから発生することもあります。

• これはCometD Javaクライアントの適切な使用である：

  私の質問は、Javaクライアントに基づいていますか？ Javaクライアントのような のようなドキュメントは、 デスクトップアプリケーションのような短期間のライフアプリケーションに使用されています。

• CometD用のJavaクライアントがある場合、WebサービスインスタンスからCometDにイベントを送信する処理を行う単一のインスタンスまたはクライアントのプールが必要ですか？ことが正しい、
• クライアントコードは、それを呼び出すバッチメッセージと複数のスレッドを処理するのに十分な手の込んだようで、一つのメッセージを公開する必要がある場合には、それはその場でやるだけのために、クライアントが高価である確立するように思えますか？

ありがとうございました！

Answer 1

はい、これはCometD Javaクライアントの適切な使用方法です。

CometD Javaクライアントのインスタンスを1つ持つことも、マルチスレッドの使用にも安全なこと、またはWebサービスごとに1つのCometD Javaクライアントを持つことができます。これはおそらく推奨される方法です（CometD Webサービスが送信したサーバー）。

CometD Javaクライアントは非同期であることに注意してください。

あなたが送信したメッセージがCometDサーバーによって処理されたという返信や確認が必要な場合は、Webサービスリクエストを（HttpServletRequest.startAsync()などで）中断し、CometD Javaクライアントを呼び出す必要がありますクライアントへのWebサービスの応答を完了するための確認メッセージが返されます。

あなたはCometD Java client API documentationを参照して、CometDのJavaクライアントAPIでコールバックを使用して確認を得ることができます。 Webサービスからのメッセージを公開するために放送チャネルを使用する場合

は完全を期すため、メッセージはすぐにCometDサーバーでリモートクライアントに再放送されます。

一方、Webサービスからメッセージを公開するためにサービスチャネルを使用する場合、メッセージをCometDサーバーで処理してから（一部のビジネスロジックに応じてそれを充実させるか、またはドロップすることは可能です）それを再放送する機会や特定のクライアントに送る機会があります。