web-dev-qa-db-ja.com

Azure ServiceBusシリアル化タイプ

サービス指向アーキテクチャーに移行するにつれ、現在のキューの代わりとしてWindowsAzureサービスバスの使用について調査を開始しました。

ほとんどのドキュメントは明確です。ただし、本体が提供されている場合、BrokeredMessageがどのタイプのシリアル化を使用するかを確認するのに苦労しています。

たとえば、次のようにBrokeredMessageオブジェクトをインスタンス化するとします。

ICommand sendMessageCommand = new SendMessageCommand
{
    Title = "A new message title",
    Body = "A new message body"
};

BrokeredMessage brokeredMessage = new BrokeredMessage(sendMessageCommand);

queueClient.Send(brokeredMessage);

SendMessageCommandは、[Serializable]属性でマークされた単純なDTOです。以前のキューでは、これはバイナリシリアル化されていたため、より高速に保存でき、メタデータを保持できました。キューを使用して ここで概説されているパターン を使用してコマンドを送信し、受信側のワーカーロールがジェネリックスと動的型付けを組み合わせてコマンドを逆シリアル化するため、これは私たちにとって重要です。

ただし、 [〜＃〜] this [〜＃〜] の記事によると、BrokeredMessageのコンストラクターに渡される本文は「BinaryXMLSerialized」です。私の仮定では、これは標準のXMLシリアル化であり、バイナリフォーマッタを通過しますが、それは正しいですか？

これに加えて;これは、デフォルトのBrokeredMessageメッセージ本文機能を使用する場合を意味します。提示されるすべての問題を含め、すべてのオブジェクトがXMLシリアル化可能であることを確認する必要がありますか？ （プライベートフィールドが失われ、ジェネリックを使用して逆シリアル化するためのメタデータがなく、xmlシリアル化属性）

最後に;このような場合は;これを回避する簡単な方法はありますか？独自のバイナリシリアル化を行ってから、byte[]をBrokeredMessageのプロパティに格納することを検討していました。

c#serializationazureazureservicebus
16
Luke Merrett

ドキュメント によると：

アプリケーションは、シリアル化可能なオブジェクトをBrokeredMessageのコンストラクターに渡すことでメッセージの本文を設定でき、適切なDataContractSerializerを使用してオブジェクトをシリアル化します。または、System.IO.Streamを提供することもできます。

使用しているコンストラクターには このドキュメント ：があります。

バイナリXmlDictionaryWriterでDataContractSerializerを使用して、指定されたオブジェクトからBrokeredMessageクラスの新しいインスタンスを初期化します。

これは、説明されているように、DataContractsとして定義されたメッセージによく適合します この記事で 。

または、 この回答 で説明されているようにサロゲートを使用することもできます。

独自のシリアライザー または ストリーム を提供することもできます。

別の方法は、独自のシリアル化を行い、（メッセージプロパティではなく）コンストラクターに提供されるシリアル化可能なオブジェクトとしてバイト配列または文字列を使用することです。 JSONや protobuf などのシリアル化形式を使用できるため、これは相互運用性に適したアプローチです。 Microsoft独自の WindowsAzureアプリケーションのパフォーマンスのベストプラクティス パフォーマンスに影響する場合は、カスタムまたはサードパーティのシリアル化を使用することをお勧めします。

JSONシリアル化と動的オブジェクトを使用して良い結果が得られました。

21
Fernando Correia