セールス: 1-800-867-1380

Service Bus のトピックとサブスクリプションを使用するアプリケーションの作成

更新日: 2015年2月

Microsoft Azure Service Bus は、信頼性の高いメッセージ キュー機能や永続的なパブリッシュ/サブスクライブ メッセージング機能など、クラウド ベースで運用するメッセージ指向ミドルウェアの一連のテクノロジをサポートしています。この記事では、「Service Bus キューを使用するアプリケーションの作成」で説明している情報に基づき、Service Bus のトピックで提供されるパブリッシュ/サブスクライブ機能を紹介します。この記事は、Service Bus のすべての機能を網羅することを目的としていません。ただし、この機能の使用を開始するために最低限の情報は提供します。

この記事では、「Service Bus キューを使用するアプリケーションの作成」で使用されている小売りシナリオを引き続き使用します。個別の Point of Sale (POS) 端末からの営業データは、そのデータを使用して在庫を補充するタイミングを決定する在庫管理システムにルーティングされる必要があります。各 POS ターミナルは、次に示すようにメッセージを DataCollectionQueue キューに送信することで営業データを報告し、在庫管理システムによって受信されるまでキューに残ります。

Service-Bus1

このシナリオを進化させるため、新しい要件がシステムに追加されました。店舗のオーナーが、店舗の売上をリアルタイムで監視したいとします。

この要件に対応するには、システムが営業データ ストリームを "タップ" する必要があります。POS ターミナルによって送信された各メッセージが前と同じように在庫管理システムに送信されるようにする必要がありますが、ダッシュボード ビューを店舗のオーナーに提供できるようにするため、各メッセージの別のコピーが必要です。

各メッセージを複数の当事者が使用する必要があるこのような状況では、Service Bus のトピック機能を使用できます。トピックは、パブリッシュされたメッセージがトピックに登録された 1 つ以上のサブスクリプションに対して利用できるようにするパブリッシュ/サブスクライブ パターンを提供します。一方、キューにより、各メッセージは 1 つのコンシューマーによって受信されます。

メッセージは、キューに送信されるのと同じ方法でトピックに送信されます。ただし、メッセージはトピックから直接受信されません。サブスクリプションから受信されます。トピックのサブスクリプションは、トピックに送信したメッセージのコピーを受信する仮想キューと考えることができます。メッセージは、キューから受信するのと同じ方法でサブスクリプションから受信されます。

シナリオに戻ると、最初にトピックのキューを切り替え、在庫管理システム コンポーネントで使用されるサブスクリプションを追加します。これにより、システムは次のように表示されます。

Service-Bus2

ここでの構成は、前のキュー ベースの設計と同じように動作します。つまり、トピックに送信されたメッセージは Inventory サブスクリプションにルーティングされ、在庫管理システムがそこからメッセージを消費します。

管理ダッシュボードをサポートするために、次に示すように 2 番目のサブスクリプションをトピックで作成する必要があります。

Service-Bus3

この構成では、POS ターミナルからの各メッセージは Dashboard および Inventory サブスクリプションの両方で使用できるようになります。

Service Bus キューを使用するアプリケーションの作成」では、Service Bus アカウントにサインアップし、サービスの名前空間を作成する方法を説明しています。Service Bus サービスの名前空間 を使用するには、アプリケーションが Service Bus アセンブリ (つまり、Microsoft.ServiceBus.dll) を参照する必要があります。Service Bus 依存関係を参照する最も簡単な方法は、Service Bus NuGet パッケージをインストールすることです。.NET 用の Azure クライアント ライブラリで、Azure SDK の一部としてアセンブリを見つけることもできます。このダウンロードは Azure SDK ダウンロード ページで入手できます。

Service Bus メッセージング エンティティ (キューおよび、トピックのパブリッシュ/サブスクライブ) の管理操作は、NamespaceManager クラスを通じて実行されます。Service Bus は Microsoft Azure Active Directory アクセス制御 (アクセス制御サービスまたは ACS) を使用して実装されるクレーム ベースのセキュリティ モデルを使用します。特定のサービスの名前空間の NamespaceManager インスタンスを作成するには、適切な資格情報が必要です。TokenProvider クラスは、既知のトークン プロバイダーを返す組み込みのファクトリ メソッドを持つセキュリティ トークン プロバイダーを表します。ここでは、CreateSharedAccessSignatureTokenProvider メソッドを使用して、共有アクセス署名 (SAS) の資格情報を保持します。その後、NamespaceManager インスタンスが Service Bus サービスの名前空間のベース アドレスおよびトークン プロバイダーで作成されます。

NamespaceManager クラスはメッセージング エンティティを作成、列挙、および削除するメソッドを提供します。次に示すスニペットは、NamespaceManager インスタンスの作成方法と、このインスタンスを使用して DataCollectionTopic トピックを作成する方法を示しています。

Uri uri = ServiceBusEnvironment.CreateServiceUri("sb", "ingham-blog", string.Empty);
    string name = "RootManageSharedAccessKey";
    string key = "abcdefghijklmopqrstuvwxyz";
     
    TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(name, key);
    NamespaceManager namespaceManager = new NamespaceManager(uri, tokenProvider);
 
    namespaceManager.CreateTopic("DataCollectionTopic");

トピックのプロパティを設定できるようにする CreateTopic メソッドのオーバーロードがあることに注意してください。たとえば、トピックに送信するメッセージに既定の有効期限 (TTL) 値を設定できます。次に、Inventory および Dashboard サブスクリプションを追加します。

namespaceManager.CreateSubscription("DataCollectionTopic", "Inventory");
    namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard");

たとえばメッセージの送信や受信などの Service Bus エンティティのランタイム操作では、アプリケーションはまず MessagingFactory オブジェクトを作成する必要があります。NamespaceManager クラスと同様、MessagingFactory インスタンスは、サービスの名前空間 のベース アドレスとトークン プロバイダーから作成されます。

MessagingFactory factory = MessagingFactory.Create(uri, tokenProvider);

Service Bus トピックから送受信されるメッセージは、BrokeredMessage クラスのインスタンスです。このクラスは、標準のプロパティ (LabelTimeToLive など)、アプリケーション プロパティを保持するために使用する辞書、および任意のアプリケーション データの本文のセットで構成されています。アプリケーションは、シリアル化が可能な任意のオブジェクトを渡すことで本文を設定できますが (次の例では、営業データを表す SalesData オブジェクトが POS 端末から渡されます)、これによって、DataContractSerializer を使用してオブジェクトがシリアル化されます。または、Stream を使用することもできます。

BrokeredMessage bm = new BrokeredMessage(salesData);
    bm.Label = "SalesReport";
    bm.Properties["StoreName"] = "Redmond";
    bm.Properties["MachineID"] = "POS_1";

トピックにメッセージを送信する最も簡単な方法は、CreateMessageSender を使用して、MessagingFactory インスタンスから直接 MessageSender オブジェクトを作成することです。

MessageSender sender = factory.CreateMessageSender("DataCollectionQueue");
    sender.Send(bm);

キューの使用と同じように、サブスクリプションからメッセージを受信する最も簡単な方法は、CreateMessageReceiver を使用して MessagingFactory から直接作成できる MessageReceiver オブジェクトを使用する方法です。「Service Bus キューを使用するアプリケーションの作成」で説明しているように、2 つの異なる受信モード (ReceiveAndDelete および PeekLock) のいずれかを使用できます。

サブスクリプション用に MessageReceiver を作成すると、entityPath パラメーターは topicPath/subscriptions/subscriptionName の形式になります。したがって、DataCollectionTopic トピックの Inventory サブスクリプションの MessageReceiver を作成するには、entityPathDataCollectionTopic/subscriptions/Inventory である必要があります。コードは次のように表示されます。

MessageReceiver receiver = factory.CreateMessageReceiver("DataCollectionTopic/subscriptions/Inventory");
    BrokeredMessage receivedMessage = receiver.Receive();
    try
    {
        ProcessMessage(receivedMessage);
        receivedMessage.Complete();
    }
    catch (Exception e)
    {
        receivedMessage.Abandon();
    }

これまでに、この記事ではトピックに送信されたすべてのメッセージが、登録されたすべてのサブスクリプションで使用できるようになりました。重要なのは、"使用できるようになった" ということです。Service Bus のサブスクリプションでは、トピックに送信されたすべてのメッセージが表示されますが、これらのメッセージのサブセットを仮想サブスクリプション キューにコピーできるのみです。これはサブスクリプション フィルターを使用して実行されます。サブスクリプションを作成するときは、メッセージのプロパティに対して動作する SQL92 スタイルの述語の形式でフィルター式を指定できます。これらのプロパティは、システム プロパティ (Label など) および前の例のアプリケーション プロパティ (StoreName) の両方です。

これを示すシナリオを進化させて、2 番目の店舗を小売りシナリオに追加します。両方の店舗からのすべての POS ターミナルからの営業データは、引き続き集中管理されている在庫管理システムにルーティングする必要がありますが、ダッシュボード ツールを使用している店舗マネージャーは、その店の売上のみに関心を持っています。サブスクリプション フィルター処理を使用して、これを達成できます。POS ターミナルがメッセージをパブリッシュするときは、メッセージで StoreName アプリケーション プロパティを設定します。2 つの店舗 (たとえば RedmondSeattle) があるとすると、Redmond の店舗の POS ターミナルは StoreNameRedmond のスタンプを営業データ メッセージに付け、Seattle の店舗は Seattle という StoreName を使用します。Redmond の店の店舗マネージャーは、POS ターミナルからのデータのみに関心があります。システムは次のように表示されます。

Service-Bus4

このルーティングを設定するには、次のように Dashboard サブスクリプションを作成します。

SqlFilter dashboardFilter = new SqlFilter("StoreName = ‘Redmond’");
  namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard", dashboardFilter);

このサブスクリプション フィルターでは、StoreName プロパティを Redmond に設定したメッセージのみが、Dashboard サブスクリプションの仮想キューにコピーされます。サブスクリプションのフィルター処理に関して、より重要な説明があります。アプリケーションは、サブスクリプションの仮想キューに渡すときにメッセージのプロパティを変更する機能に加えて、サブスクリプションごとに複数のフィルター ルールを持つことができます。

この記事では、Service Bus で導入されたトピック ベースのパブリッシュ/サブスクライブ機能の使用を開始する方法を説明しました。

Service Bus キューを使用するアプリケーションの作成」で説明したキューを使用するすべての理由は、特に次の点に関してトピックにも当てはまります。

  • 一時的な分離 - メッセージのプロデューサーとコンシューマーは、同時にオンラインである必要がありません。

  • 負荷分散 - 負荷のピークはトピックによって取り除かれ、処理を行うアプリケーションが、ピーク負荷ではなく平均的な負荷に対してプロビジョニングされるようにできます。

  • 負荷分散 - キューと同じように、複数の競合するコンシューマーが 1 つのサブスクリプションでリッスンし、各メッセージが 1 つのコンシューマーのみに渡され、負荷を分散します。

  • 疎結合 - たとえば、トピックにサブスクリプションを追加したり、フィルターを変更したりして新しい顧客を許可するなど、既存のエンドポイントに影響を与えることなく、メッセージング ネットワークを進化させることができます。

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2015 Microsoft