Azure Service Busメッセージポンプは実際にイベント駆動ですか？

Question

最近、我々はAzureサービスバスを調べてきました。キュー/サブスクリプションをポーリングするために無限ループを使うべきか、OnMessageコールバック/メッセージポンプ機能を使うべきかどうかについて、ちょっと混乱しています。何がより少ない操作を実行し、コストを下げるのでしょうか？

理想的には、イベント駆動型システムが欲しいので、私たちは操作を浪費していないので、一般的にもっと良いアプローチです。

私の質問は、「イベントドリブンメッセージポンプでメッセージを処理する」というイベントが実際に駆動するOnMessageを使用していますか？

このページ（QueueClient.OnMessage）：https://msdn.microsoft.com/library/azure/microsoft.servicebus.messaging.queueclient.onmessage.aspxを見ると、基本的にはReceive（）メソッドを呼び出す無限ループのラッパーであるという発言の下部に表示されています。それは私にとってはイベント駆動型ではないようです。

今このページ（SubscriptionClient.OnMessage）： https://msdn.microsoft.com/en-us/library/azure/dn130336.aspxを見ると、その発言は存在しません。トピック/サブスクリプションとキューでは同じですか、サブスクリプションではイベント駆動型ですか、キューではありませんか？

明らかにそうでない場合、なぜイベント駆動型であると言っているのですか？ QueueClient.OnMessageページの発言に「無限ループ」と「すべての受信操作が請求可能なイベント」と表示されているという事実は、やや怖いです。

また、どれくらいのコストがかかりますか、私はできるだけ効率的にすることにもっと関心があります。

Answer 1

私はOnMessageを使用しませんでしたが、質問は私に興味があったので、いくつかの掘り下げを行いました。

私の理解では、OnMessageのアプローチは、待ち行列からのメッセージを処理するための通常の懸念の一部をカプセル化して、気にすることなくよりクリーンで簡単な方法を提供することです。そのため、ポーリングの周りにすべての足場を書くのではなく、プッシュ型/イベント駆動型の実装（メッセージポンプモデル）にもっと集中することができます。

これは、基本的には依然としてReceive（）を呼び出しているループであるという点で正しいので、デフォルトのタイムアウトでは、ポーリングの数は同じで、同じコストになります。

私は、これらの文献に出くわした：

http://fabriccontroller.net/introducing-the-event-driven-message-programming-model-for-the-windows-azure-service-bus/

http://www.flyersoft.net/?p=971 - これはあなたと同じ質問をカバーして、あまりにもコメントをご確認ください。

トピック/サブスクリプションとキューでは同じですか、サブスクリプションでは実際にはイベント駆動型ですか、キューではありませんか？

私は100％ではありませんが、私の研究に基づいた私の仮定は、それは同じであり、ドキュメンテーションが明確でない場合です。