単純なメッセージ バスとして機能するプロジェクトを開始しようとしています。サブスクライバーを待っているだけで、メッセージまたはイベントが送信されます。メッセージを保存する必要はありません。これは、ライブ データのサブスクライバーのパススルーとしてのみ必要なためです。推奨される配信メカニズムは Web リクエスト (REST/JSON) です。
最近の Redis の作業では、これが良い候補だと思いましたが、私たちは主にMicrosoft ショップであるため、 WCF ServiceとWindows Service Busも考えています。
サブスクライバーがすべて .Net クライアントであるとは限らないため、可能な限り汎用性を維持したいと考えていますが、最初は .Net クライアント接続が優先されます。
私は可能な限り単純な実装を作成したいと考えています。そのほとんどをサブスクライバーに費やしたいので、膨大な開発時間は必要ありません。
提案を歓迎します。
Redis を使用する場合は、Redis のpublish / subscribeコマンドをご覧ください。
私は .net の人ではありませんが、次のリンクが正しい方向に導くようです: https://github.com/ServiceStack/ServiceStack.Redis/wiki/RedisPubSub
Windows Azure Service Busは、メッセージングとイベントの両方のパターンをサポートしています。ネットワークの境界を越えてサービスを接続するだけの場合は、Relayを使用できますが、場合によっては、さまざまなタイプのクライアントがさまざまなプロトコルと通信するため、メッセージングの方が適切な場合があります。任意のプロトコル/プログラミングモデル->.NETAPI、WCFバインディング、および単純なRESTクライアントを使用して、デキューメッセージをエンキューできます。パターンの観点からは、単一の要求/応答チャネルまたはブロードキャストなどが必要かどうかに応じて、キューまたはトピックとサブスクリプションを使用できます。次のコードサンプルは、WCFプログラミングモデルの使用を示しています。
http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-WCF-ed259f73
http://code.msdn.microsoft.com/windowsazure/Windows-Azure-Inter-Role-9935c439
RESTクライアントの場合、次のサンプルが役立ちます：http: //code.msdn.microsoft.com/windowsazure/Brokered-Messaging-569cff88
キュー/トピックの詳細については、 http ：//www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-queues/http://www.windowsazure.com/enを参照してください 。 -us / development / net / how-to-guides / service-bus-topics /
REST APIリファレンスはここから入手できます：http： //msdn.microsoft.com/en-us/library/windowsazure/hh780717
