OwinスタートアップクラスのOnMessageを使用してAzureサービスバスを購読する

Question

私の同僚は、既存のAsp.Net WebApiアプリケーションの1つを使用し、ASBにOWINを申し込むAzure Service Busからのメッセージを処理するソリューションに取り組んでいます。スタートアップ例えば

public class Startup 
{ 
    public void Configuration(IAppBuilder app) 
    { 
     // ... registering WebApi etc 

     var queueClient = SubscriptionClient.CreateFromConnectionString("connection string", "sometopic", "somesubscription"); 

     queueClient.OnMessage(m => 
     { 
      //do something with message 

      m.Complete(); 
     }, new OnMessageOptions 
     { 
      AutoComplete = false, 
      AutoRenewTimeout = TimeSpan.FromSeconds(30), 
      MaxConcurrentCalls = 30 
     }); 
    } 
} 

は、私は個人的に、これはそれを行うには正しい方法ではありません、代わりに私たちはWebJobsまたはWorkerRoles、私は彼を説得するために、任意の引数を考えることができないhovewerを使用すべきだと思います私の考え。

だから質問がある：右である

1. は、私や私の同僚、または多分両方のソリューションはOKですか？
2. 私の同僚が正しくない場合、彼の解決策に対する議論は何ですか？

Answer 1

そのWeb APIプロジェクトは、ちょうどこのキューを聴くことは、これらのウェブジョブやWorkerロールのアプローチを使用することの利点を検討以上にない場合：

• Workerロールは、Webアプリケーション
• とは独立して拡張することができますがWebアプリケーション/ワーカーロールは、Webアプリケーションとは独立して更新することができます。
• プロセス分離：いずれかが失敗した場合、他のプロセスがまだ実行されている可能性があります。

Azure関数（https://azure.microsoft.com/en-us/services/functions/）を使用すると、サーバーレスコンピューティングを適用することもできます。あなたは使用量（機能のホスティングではない）のみを支払うだけでなく、独自にスケールアップして更新することもできます。

技術的には両方の方法が有効です。メッセージの処理がWebアプリケーションと直接対話している場合（メッセージで何をしているのか分からなかった場合）、作業に応じてWebアプリケーションでメッセージを実行する方が適切な場合があります。

Webサイトは、連続プロセスを実行する代わりに、要求を処理する方が優れています。 Webジョブ/作業者の役割は、この種の状況のた​​めのより良い環境のように感じるだけでなく、本当にAzure関数を見てください。

Answer 2

サービスバスが存在する理由の1つは、この特定のプロセスが大きなエンタープライズシステムのサブシステムまたはサブドメインであると識別されたため、このメッセージ/キューを単独で処理することです。したがって、（ウェブワーカーロール/ウェブジョブ/アズール関数の形式の）アプリ/サービスは、サブシステムのフォーカスドメイン知識を持つ同じチームまたは異なるチームによって開発することができます。それは独立したプロセスであるため、必要に応じて独立してスケーリングすることができます。

メッセージの処理がWebアプリケーションビジネスロジック/サービスに依存する場合、それがWeb APIプロセスに必要な理由についての赤い旗になる可能性があります。