• [アーティクル]

October 2011

Volume 26 Number 10

この記事は機械翻訳されたものです。

予測: 曇り - Windows Azure の AppFabric サービス バス: トピック

Joseph Fultz | October 2011

この記事は、Windows Azure AppFabric CTP 6 月アップデートに基づいています。ｪｳｪｳｪﾋﾑﾀ銧ｪｵｪ・ﾆｪ､ｪ・ｹｪﾙｪﾆｪﾎ・ﾜﾃｪﾏ｡｢変ﾌﾚｪｵｪ・・ﾞｪｬｪ｢ｪ・ﾞｪｹ｡｣

Joseph FultzWindows Azure サービス バスの機能は、実際に多くのサポートからご希望こと私の同僚の間では明らかです。ただし、Windows Azure AppFabric CTP 6 月アップデートで、マイクロソフト最後にどのような私は本当に有用な技術へのプレース ホルダーよりもはるかはありませんから、サービス バスを移動するための十分な機能追加しました。記事の目的はここで、重要なメッセージング ・ テクノロジーを今すぐ AppFabric サービス バスを提供していますのです "項目"、豊富なパブリッシュ サブスクライブ機能します。私は、技術 inter-store の在庫チェックを容易にする使用方法を参照する [小売業界での経験のために apt は私についてのトピックのこの資料と、図形の調整でを詳しく説明します。

今まで、何かを購入し、最後の 1 つだけ販売または使用アイテムが何らかの方法である messed 参照するには、移動されましたか。このような場合は、販売の事務員は POS システムにされ、近くの店で在庫確認されます。多くの場合は、そのチェックを中央のデータベースや計画 (ERP) システムのいくつかの種類のエンタープライズ リソースに保持される在庫数をあり事務員は通常、組織固有の知識の近くにあるストアを使用して番号を保存する] をチェックします。多くの場合、データは少しだけ、終わりの時の処理日の一部として、トランザクション ログ ファイルとその他のデータ更新がありますので、古いをアップロードされ、企業システムでの処理です。

理想的なストア要求に関する製品の販売開始、ときにいつでもスローし、近くにあるストア応答、それらがあるかどうかを示すがあります。私の図のように、Windows Azure AppFabric サービス バスを使用してを設定するつもりです図 1。

は、インベントリのチェックのメッセージ
図 1 は、インベントリのチェックのメッセージ

トピックは、私は最大 2,000 ユーザー トピックごとにコンテンツをプッシュすることができます、耐久性に優れたメカニズムを提供します。サブスクライバーの制限可能性のある仕様としては望ましくないことは、ソリューションのアーキテクチャのようなことを説明するもの) を強制的に、セグメントのトピックを何らかの方法で作成することによって動作します。たとえば、米国の代わりにSouthCentral 米国を作成する必要があります在庫確認、地域別のサブスクライバーのフィルター、トピックインベントリのトピックを確認し、さらに、特定のローカル ブランチにフィルターを適用します。私私私 wonderland でフランチャイズの場所のいくつかのより多くの必要はありませんを約束することができます、その点では、私 1 つ在庫確認トピックと共に実行します。

 

 

メッセージの取得

Windows Azure AppFabric CTP 6 月からの更新をダウンロードすることができます bit.ly/p3DhAU、管理ポータルでの検索と portal.appfabriclabs.com。いくつかの私を使用する必要がありますコードの情報を取得する管理ポータルをアクセスできます (を参照してください図 2)。

の Windows Azure の AppFabric 管理ポータルから情報を取得します。
図 2 の Windows Azure の AppFabric 管理ポータルから情報を取得します。

私は、サービス ゲートウェイ、デフォルトの発行者 (常に「所有者」CTP で) および既定のキーを取得する必要があります。これらのサンプルで必要なので、私オブジェクト スコープで作成します。

private string sbNamespace = "jofultz";
private string issuerName = "owner";
private string issuerKey = "25vtsCkUPBtB39RdiBbUtCQglYRPOdHHC4MvX5fvxxxx";

私これらの変数を関数のトピックでは、作成に使用するトピックにメッセージを投稿します。他のインターフェイスを使用する場合、または、クライアント ライブラリを使用することは、プラットフォーム上で展開されていないです。Windows クライアントを構築するために、私は、ライブラリを使用します。これを行うには、Microsoft.ServiceBus、Microsoft.ServiceBus.Message、System.ServiceModel への参照を追加するのにはのようにほしい図 3。

参照を追加する図
参照を追加する図 3

その後、簡単な数行のコードだけで、トピックの設定に必要なです。

SharedSecretCredential credential =
  TransportClientCredentialBase.CreateSharedSecretCredential(
  issuerName, issuerKey);
 
Uri sbUri = ServiceBusEnvironment.CreateServiceUri(
  "sb", sbNamespace, String.Empty);
ServiceBusNamespaceClient sbNSClient =
  new ServiceBusNamespaceClient(sbUri, credential);
Topic newTopic = sbNSClient.CreateTopic(topicName);

メッセージをフィルタ リングし、領域に基づく受信場所に関連するもののみを取得するには、ストアの機能はどのような私がメッセージをスローすることを開始するとことが重要になりますです。 相関関連づけおよびサブスクリプション Id として捉える、API をサポートしますが、フィルタ リングのデータの要求の内容に基づいてフィルターに関する自分の知識を使用します。 したがって、地理的に閉じるストアを検索し、お互いの領域に基づく在庫の要求に対応する必要な。 同時に、私は元のストアを要求されないことを確認する必要があります。 元のストアに関する要求をフィルター処理できます要求、SKU は、照会が作成され、地域問題のアイテムが、RequesterID が含まれます。

[Serializable]
class InventoryQueryData
{
  public string Region;
  public string ResponderID;
  public string RequesterID;
  public string Sku;
  public int Count;
}

私がクラスに追加した [Serializable] 属性に注意してください。DataContract を使用します DataMembers としてプロパティをマークすることができませんでしたが、私のトピックに送信する型がシリアル化可能で必要があることです。

SKU の場合は、任意の文字列を入力および転記のストアの一覧から選択することができる簡単なフォームを作成しました。[照会] ボタンのコードがコードに接続し、トピックを作成するにはのように表示され、検索メッセージの Api の使用時に示すように、標準的な構成要素のような図 4。

図 4 のデータ値を取得します。

// Assign data values.
InventoryQueryData data = new InventoryQueryData();
data.Sku = txtSKU.Text;
data.StoreID = cboStore.SelectedText;
data.Region = cboStore.SelectedValue.ToString();
 
Uri sbUri = ServiceBusEnvironment.CreateServiceUri("sb", sbNamespace, string.Empty);
SharedSecretCredential credential = TransportClientCredentialBase.CreateSharedSecretCredential(issuerName, issuerKey);
 
MessagingFactory msgFactory = MessagingFactory.Create(sbUri, credential);
TopicClient topicClient = msgFactory.CreateTopicClient(topicName);
MessageSender MsgSender = topicClient.CreateSender();
 
BrokeredMessage msg = BrokeredMessage.CreateMessage(data);
// Add props to message for filtering.
msg.Properties["Region"] = data.Region;
msg.Properties["RequesterID"] = data.RequesterID;
 
msg.TimeToLive = TimeSpan.FromSeconds(60);
 
MsgSender.Send(data);

ここで注意するのには、次の 2 つです。 まず、BrokeredMessage.Properties コレクションにフィルタ リングに必要な名前/値ペアを追加しました。 サブスクリプション トピックを保つ必要がありますもバックアップの取得から 60 秒 TimeToLive (TTL) を設定した 2 番目に、ランタイムの保守の問題をします。 もちろん、一般的より細かなアプローチは、ttl の期限を選択するため必要がありますが私要求、サブスクライバーのいずれかの時間の中に到達しない場合、その可能性がありますが長すぎるされているためお客様に図が待っているに立って。 それに、これは例だけです。

バスに送信されるすべてのメッセージ、CreateMessage ファクトリ メソッドが、BrokeredMessage の形式でです。 すべての完全に機能のメッセージング システムに必要な構造が含まれている BrokeredMessage 型のインスタンスにこれだけで、データをラップします。

この私が在庫確認トピックのサブスクライバーに提供する必要のあるすべてがあることをここではサブスクリプション メッセージを取得し、対応するクライアントのセットアップに開始します。

トピックのストリームをタップし、[応答

僕のクライアントでは、要求のストリームを送信する準備ができて私しますが、右にはこれになることができますビットを単に野生のエーテルが失われます。 Windows フォーム アプリケーションを作成し、XML ストアの一覧と、最初の (送信者) アプリケーションから InventoryQueryData を再利用します。 私は、トピックにリッスンしている各クライアントの一意なサブスクリプションを作成する必要があります。 簡単にこれをリッスンするように必要な番号を保存、サブスクリプション名を組み合わせることで実現されます。 私の小さなテスト アプリケーション私だけその値ベースのサブスクリプションの名前を付加してサブスクリプションの一意の名前を作成するために番号を保存するためのコンボ ボックスから選択することができます。 すべてのクライアントが独自のサブスクリプションを持っていることを確認することが重要です。 2 つ以上を使用して同じサブスクリプションは競合状態を作成するサブスクライバーだけでなく、メッセージを受信して削除するには、最初の 1 つは競争しますが優先されます。

Topic invTopic = sbNSClient.GetTopic(topicName);
SubscriptionName = "InventoryQuerySubscription" + this.cboStore.Text;
SqlFilterExpression RegionFilter = new SqlFilterExpression("Region = '" +
  cboStore.SelectedValue + "' AND RequesterID <> '" + cboStore.Text + "'");
 
Subscription sub = invTopic.AddSubscription(SubscriptionName, RegionFilter);

私のトピックにサブスクリプションを追加すると、各店舗在庫チェック要求の独自の地域のみを受け取るように私はフィルターに渡すこともできます。 FilterExpression 型は基本型から開発できますが、特に一緒に使用する場合、API には、ほとんどのシナリオに対応する必要があります 4 つの種類が含まれます。 CorrelationFilterExpression、MatchAllFilterExpression、MatchNoneFilterExpression と SqlFilterExpression。 私を簡単に使用できる instinctively、テキサスの領域では、たとえば、メッセージを取得するには、次の式を作成して自分のストアから発信されたメッセージを除外する SqlFilterExpression を使用しました。

"Region = '[Region]' AND RequesterID <> '[StoreID]'"

私を要求にフィルターを適用するだけで済みますが、いくつかのケースでは理論的には「と言う、SqlFilterExpression、SqlFilterAction とを結合するには、RuleDescription を使用する方法で一部のデータ修正できませんでした」。 前者、後者に実行するアクションを定義しますが、対象として、メッセージを識別します。 このような機能は、受信者と、バスの両端の動作に各行にする必要がありますから入ってくるデータ処理できないエラーまたは変更しない場合役に立ちます。

サブスクリプションを設定した後でも、クライアントが後まで、維持されます。 これは、このシナリオでは完璧です。 私の監視を開始し、既存の接続を接続するたびには私だけでは、SubscriptionClient を作成します。 ただし、すべてのユーザー設定をします。 クライアントをシャット ダウンすると、サブスクリプションを削除する場合を想像することができます。

SubscriptionClient subClient = msgFactory.CreateSubscriptionClient(
  topicName, SubscriptionName);
MessageReceiver msgReceiver = subClient.CreateReceiver(ReceiveMode.ReceiveAndDelete);
msgReceiver.Open();

CreateReceiver の呼び出しで私 ReceiveMode を ReceiveAndDelete に設定されていることに注意してください。ReceiveMode の PeekLock を使用することもできます。ここでは、単にメッセージとプロセスに適切な受信を確認する必要があると私がないと、メッセージが失われた場合は、それはそれほど問題ではありませんのでを削除する前に処理を取得したいです。私より保証と信頼性の高い動作が必要な場合は、私可能性が 2 つのことです。私ねメッセージ、トピック、またはサブスクリプションの場合は、TTL を設定し、代わりにメッセージを無期限にライブすることができます。また、受信者を処理または実際に配信不能メッセージが配信不能キューになるようにすることを例外キューに移動するのに十分な時間と私は非常に高い TTL 設定した場合は。また、私 PeekLock 受信機を読み、データを処理して関連の処理の完了時にメッセージの削除のみを使用します。この分散トランザクション動作を手動で作成する簡単は、有害キューなど、その他の問題可能性がありますがその動作を説明し、問題が別の時間を設定します。

受信機が開いた後はメッセージをチェックするループを入力します。API は、BrokeredMessage が返されますを直接受信メソッドがあります。ただし、成功を示す bool 値を返しますが、TryReceive メソッドを使用します (を参照してください図 5)。私は比較的短時間のタイムアウトを確認し、メッセージを受信するには十分に長くする必要がありますその方法に通過します。メッセージを受信した場合は、操作してすぐに別のメッセージを確認します。メッセージを受信していない場合は、スレッドはスリープしてもう一度確認します。

図 5 のメッセージのチェック

while (MonitorOn)
{
  BrokeredMessage NewMsg;
  bool recvSuccess = msgReceiver.TryReceive(TimeSpan.FromSeconds(3), out NewMsg);
 
  if (recvSuccess)
  {
    this.lbMessages.Items.Add(NewMsg.MessageId);
    InventoryQueryData RequestObject =
      NewMsg.GetBody<CreateInquiry.InventoryQueryData>();
    ProcessMessage(RequestObject);
  }
  else
  {
    System.Threading.Thread.Sleep(3000);
  }
}

要求オブジェクトは、BrokeredMessage では、含まれているし、それを取得するためにはオブジェクトの種類を渡す GetBody <T>、呼んでいます。意味をここでは、バスの両側に一致するオブジェクトの種類必要があることです。プロキシ型を使用してこれを行うことができますまた、不確実性または渡された普通の古い XML の場合は、オブジェクトを文字列として渡すし、XML として処理することができます。

次回まで…

この時点では、メッセージを作成して、関心のあるノードやトピックからメッセージを取得するに導入することにすべての処理が行われます。私だけでなく、メッセージをブロードキャストが抽出することも適切に、購読している受信側にできるようにする機能を説明しました。～ 帰りキューと、シナリオを終了し、Windows Azure の AppFabric サービス バスでの新機能の基本的な理解をラウンドするには、相関関係の相補的な使用を説明するためには、次の月を操作します。私も、完全なコードは、ダウンロードするときに使用できる必要があります。

ジョセフ Fultz はソフトウェア アーキテクトはヒューレット ・ パッカード社は稼働時間の HP.com グローバル IT グループの一部として 以前は、マイクロソフトのソフトウェア アーキテクトとして、一流企業や ISV の顧客のためにアーキテクチャの定義とソリューション設計を行っていました。

この記事を確認するのには次の技術のエキスパートに感謝： ジム Keane