私の問題の解決策は実際よりも簡単なはずのように思えます。リモート クライアント マシンが Azure Service Bus キューからメッセージを送受信できることをテストして確認しようとしています。

Microsoft がhttps://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-amqp/で提供しているサンプル アプリケーションを使用しています。

すべてのポートが開いている限り、サンプル アプリケーションは問題なく動作します。ただし、ポート 80/443 のみが使用可能な場合に機能するソリューションが必要です。80/443 でのインバウンド/アウトバウンド トラフィックのみを許可するように Windows ファイアウォールを構成すると、機能しません。「アクセス許可で禁止されている方法でソケットにアクセスしようとしました」というエラーが表示されます。

サンプル アプリケーションの問題のある行は次のとおりです。

私は非常に多くのサイトを見てきましたが、見つけた提案の 1 つは、次のように接続モードを Http に設定することでした。

それもうまくいきません。

リモート クライアントまたは Azure がホストするロールでカスタム サービスをセットアップしようとはしていません。Azure の Service Bus キューとトピックを介してメッセージを送受信できるようにする必要があります。

誰かが私の欠陥を指摘できますか?

Azure Service Bus Queuesを使用して、メッセージを保存し、クライアントアプリケーションのリモートインストールに転送しています。

私のアプローチは、リモートサイトごとにキューを設定し、アプリケーションの各インスタンスを独自のキュー名で構成することです。

クライアントアプリケーションでキューとクレデンシャルを保護する方法についてアドバイスを求めています。私が理解しているように、名前空間ごとに1セットのクレデンシャルがあるため、クライアントアプリケーションの各インスタンスは同じキュー接続文字列を持ちます。また、復号化された接続文字列を使用すると、呼び出しにはメッセージをデキューするだけでなく、キューを作成/削除する権限があるようです-これに対して保護できますか？

オースティンサンプルをベースにしたサンプルアプリケーションを作成しようとしています。最初にサンプルで404を入手し、App.ConfigでconnectionStringを調整して修正しました（これを忘れてしまいました。悪いです）。これで、AzureテーブルではなくServiceBusキューにメッセージを送信する2番目のシンクを作成しました。SampleApplicationとEventSourceSimulatorを起動すると、最初の2つのメッセージは正しく通過したように見えますが、3番目のメッセージは404エラーを示しています。以下は、エラーと私のシンクのクラスのスクリーンショットです。私を助けるためにもっと情報が必要な場合は、教えてください。前もって感謝します、

更新：管理ポータルのService Busキューに何も表示されないため、何も表示されないと思います。

バックグラウンド

いくつかの操作を提供するRESTfulAPIがあります。このRESTfulAPIは、APIの操作にアクセスするために、プラットフォームで認証および承認される必要があるサードパーティによって使用されます。

サードパーティは信頼性の高いデータ消費を必要とし、APIは一部のデータを消費するためのパブリッシャー/コンシューマーパターンベースのソリューションを提供する必要があります。

いわゆるAPIは車輪の再発明を行わないため、Windows AzureServiceBusを使用しようとしています。

問題

RESTful APIは、実際のサービスバスサービスを抽象化する必要があります。一方、Service Busは、独自のプラットフォームで信頼性の高いメッセージングを提供するソリューションです。

実際、Service Busはスタンドアロンのサービスではありませんが、一部のワークフローの一部です。サードパーティは、WindowsAzureの資格情報を持っているとは想定されていません。

サードパーティは、Service Busのトピック（つまり、メッセージキュー）へのアクセスを許可するAPI固有の資格情報を使用してWindows AzureServiceBusに接続する必要があります。

可能な解決策

a。WindowsAzureサービスバスへの直接アクセスを承認する

それは最も簡単な解決策のようです。フローを見てみましょう：

1. サードパーティは、Windows Azure Service Bus接続文字列（資格情報）を取得するために、RESTfulAPIにリクエストを送信します。
2. 接続文字列を取得すると、サードパーティはWindows Service Busに接続し、トピックサブスクリプションからのメッセージの受信を開始します。注：接続文字列はサーバー側で暗号化されており、承認されたクライアントのみが復号化できます。

長所

• 簡単。APIは、サードパーティがWindows Azure Service Busを使用することを許可し、その他の責任はありません。
• 独自のAPIは、トピックサブスクライバーの高負荷を管理しません。これは、WindowsAzureプラットフォームによって処理されます。

短所

• サードパーティは、WindowsAzureと非常に密接に関連しています。
• サードパーティは、しばらくの間、RESTfulAPIを簡単にバイパスできます。

b。WindowsAzureサービスバスへのプロキシアクセス

これは可能ですか？全体のフローは次のようになります。

1. サードパーティは、Windows Azure Service Busトピックにサブスクライブするために、RESTfulAPIと同様のTCPAPIを要求します。
2. TCP APIは接続を確立し、サービスバスI/OへのTCPAPI接続をサードパーティへのTCPAPIにミラーリングするためにプロキシを作成します。
3. これで、サードパーティがプロキシに接続され、メッセージを送受信します。

長所

• サードパーティはプロキシを介して接続されています。つまり、サードパーティはWindows Azureクレデンシャルを所有しておらず、TCPまたはRESTfulAPIをバイパスできない可能性があります。
• メッセージングは​​、もはやWindowsAzureに完全に結び付けられているわけではありません。

短所

• Windows Azure Service Busが接続を閉じるとどうなりますか？
• プラットフォームプロキシがダウンした場合はどうなりますか？

c。Windows AzureServiceBusサーバーラッパー

これが定義とフローです。

1. RESTful APIサーバーには、Windows AzureServiceBusサブスクリプション接続のプールがあります。
2. サードパーティは、APIサーバーのTCPソケットまたはWebSocketにサブスクライブされています。
3. Windows Azure Service Busにメッセージがある場合は常に、サードパーティの接続プールにルーティングされ、サードパーティがメッセージを受信します。
4. サードパーティは、RESTfulAPIを使用してメッセージを送信します。

長所

• サードパーティは、サービスバステクノロジーに完全に依存していません。

短所

• bと同じ。アプローチ。

質問

• bです。アプローチは可能ですか？

• cについてのあなたのアドバイスは何ですか。Windows AzureServiceBusサーバーラッパー。回避可能な戦争は、稼働時間とWindows Azure Service BusからAPI、およびAPIからサードパーティへの同期の点で信頼性が低いと思いますか？

• 私は間違っていますか？これらのアプローチに代わるものがありますか？

Service Bus 経由で Wi​​ndows サービスを公開しています。構成ファイルは次のとおりです。奇妙なエラーが発生しています（コード/構成に変更はありませんが、突然エラーが発生し始めました。以前は正常に機能していました。

One23InsightService を開始できませんでした。例外メッセージ: - コレクションに同じ種類の項目が既に含まれているため、値をコレクションに追加できませんでした: 'Microsoft.ServiceBus.TransportClientEndpointBehavior'。このコレクションは、各タイプのインスタンスを 1 つだけサポートします。パラメーター名: item インターフェイスが異なる 2 つのエンドポイントがありますが、動作構成は同じです。

AzureServiceBusを介して通信するさまざまなマシンに一連のソフトウェアエージェントをインストールしています。各エージェントは、パブリッシャーとサブスクライバーの両方である可能性があります。

送信者がバスからメッセージを受信しないようにするための組み込みのメカニズム（たとえば、ある種の「エコーキャンセル」）はありますか？

例：A、B、およびCがエージェントである場合、私が達成したいのは、Aによって送信されたメッセージがAへのループバックなしでBおよびCに配信されることです。

フィルタでうまくいくと思いますが、サービスにもっとシンプルなものが組み込まれているのではないかと思います。

Windows Phone 8 でクラウド ベースの pub/sub 実装を使用したいと考えています。2 台以上の電話を接続しようとしています (友人スタイルのターン ベースの言葉を考えてください)。Azure でこれを実行できることはわかっていますが、すべての DLL がそうであるとは限りません。 Windows phone (7/8) で利用できます。Windows phone で pub/sub を実行するための適切な参考資料はありますか?

Azure Service Bus アーキテクチャを理解するのに数時間かかりました。特に、このキューイング テクノロジを使用してメッセージ ルーティングをサポートできるかどうかを考えています。これは、RabbitMQ のルーティング機能に似たものです。 http://www.rabbitmq.com/tutorials/tutorial-four-python.html

代わりに直接交換を使用します。直接交換の背後にあるルーティング アルゴリズムは単純です。メッセージは、バインディング キーがメッセージのルーティング キーと正確に一致するキューに送られます。

このセットアップでは、2 つのキューがバインドされた直接交換 X を見ることができます。最初のキューはバインディング キー オレンジでバインドされ、2 番目のキューには 2 つのバインディングがあり、1 つはバインディング キー ブラック、もう 1 つはグリーンです。

このようなセットアップでは、オレンジ色のルーティング キーで交換に公開されたメッセージはキュー Q1 にルーティングされます。黒または緑のルーティング キーを持つメッセージは Q2 に送られます。他のすべてのメッセージは破棄されます。

この種のキューを実装するための最適なベクトルを推奨するために、Service Bus アーキテクチャを深く理解している人を探しています。

既にメッセージが含まれているこの Service Bus があります。現在、私は SqlFilter を使用してサブスクリプションを作成しています - フィルターが (myProperty < x) であるとしましょう。

問題は、メッセージが既にキューに入れられるまで x が何であるかわからないことです。x に具体的な値があり、新しいサブスクリプション (myProperty < 123) を作成すると、それを使用して、既にキューにあるメッセージを受信できません。

サブスクリプションが作成される前にキューにあったメッセージを取得するためにサブスクリプションにフラグを付ける方法はありますか? バスの代わりにテーブルに切り替える必要があると思いますか?

メッセージ x を Azure サービス バスに仲介するプッシャーがあります。これは、ある注文の顧客要求です。

消費者がやって来て、「メッセージ x の状態は何か」を知りたがっていますか? メッセージ x についてできる限り知りたいのですが、少なくとも「はい/いいえ」で答える必要があります。それはまだキューに入っていますか? Azure Service Bus 内でこれに推奨されるパターンはありますか?