Menjelajahi serialisasi dan payload pesan Azure Service Bus

  • 3 menit

Pesan membawa muatan dan metadata. Metadata dalam bentuk properti pasangan kunci-nilai, dan menjelaskan muatan, dan memberikan instruksi penanganan ke Service Bus dan aplikasi. Kadang-kadang, metadata itu saja cukup untuk membawa informasi yang ingin disampaikan pengirim kepada penerima, dan muatan tetap kosong.

Model objek klien Bus Layanan resmi untuk peta .NET dan Java ke dan dari protokol kawat Bus Layanan mendukung.

Pesan Service Bus terdiri dari bagian muatan biner yang tidak pernah ditangani Bus Layanan dalam bentuk apa pun di sisi layanan, dan dua set properti. Properti broker didefinisikan sistem. Properti yang telah ditentukan sebelumnya ini mengontrol fungsionalitas tingkat pesan di dalam broker, atau mereka memetakan ke item metadata umum dan terstandardisasi. Properti pengguna adalah kumpulan pasangan kunci-nilai yang ditentukan dan ditetapkan oleh aplikasi.

Perutean dan korelasi pesan

Subset properti broker, khususnya To, , ReplyTo, ReplyToSessionIdMessageId, CorrelationId, dan SessionId, membantu aplikasi merutekan pesan ke tujuan tertentu. Pola berikut menjelaskan perutean:

  • Permintaan/balasan sederhana: Penerbit mengirim pesan ke dalam antrean dan mengharapkan balasan dari konsumen pesan. Penerbit memiliki antrean untuk menerima balasan. Alamat antrean tersebut terkandung dalam ReplyTo properti pesan keluar. Saat konsumen merespons, MessageId pesan yang ditangani disalin ke properti CorrelationId pesan balasan dan mengirimkan pesan ke tujuan yang ditunjukkan oleh properti ReplyTo. Satu pesan dapat menghasilkan beberapa balasan, tergantung konteks aplikasi.

  • Permintaan/balasan multi-siaran: Sebagai variasi pola sebelumnya, penerbit mengirim pesan ke topik dan beberapa pelanggan menjadi layak menggunakan pesan. Masing-masing pelanggan mungkin merespons dengan cara yang dijelaskan sebelumnya. Jika ReplyTo mengarah ke topik, serangkaian respons penemuan tersebut dapat didistribusikan ke audiens.

  • Multipleks: Fitur sesi ini memungkinkan multipleks aliran pesan terkait melalui antrean atau langganan sedemikian rupa sehingga setiap sesi (atau grup) pesan terkait yang diidentifikasi oleh nilai SessionId yang cocok dirutekan ke penerima tertentu saat menerima mempertahankan sesi di bawah kunci. Pelajari selengkapnya tentang detail sesi di sini .

  • Permintaan/balasan multipleks: Fitur sesi ini memungkinkan balasan multipleks, yang memungkinkan beberapa penerbit berbagi antrean balasan. Dengan mengatur ReplyToSessionId, penerbit dapat meminta konsumen menyalin nilai ke dalam properti SessionId pesan balasan. Antrean atau topik penerbitan tidak perlu mengetahui sesi. Ketika pesan dikirim, penerbit dapat menunggu sesi dengan yang diberikan SessionId untuk terwujud pada antrean dengan menerima penerima sesi secara kondisional.

Perutean di dalam namespace Bus Layanan menggunakan aturan langganan penautan dan topik otomatis. Perutean di seluruh namespace dapat dilakukan menggunakan Azure LogicApps. Properti To dicadangkan untuk digunakan di masa mendatang. Aplikasi yang menerapkan perutean harus melakukannya berdasarkan properti pengguna dan tidak condong pada To properti; namun, melakukannya sekarang tidak akan menyebabkan masalah kompatibilitas.

Serialisasi muatan

Saat transit atau disimpan di dalam Service Bus, muatan selalu berupa blok biner yang buram. Properti ContentType memungkinkan aplikasi menjelaskan muatan, dengan format yang disarankan untuk nilai properti menjadi deskripsi jenis-konten MIME sesuai IETF RFC2045; misalnya, application/json;charset=utf-8.

Tidak seperti varian Java atau .NET Standard, versi .NET Framework dari Azure Service Bus API mendukung pembuatan instans BrokeredMessage dengan meneruskan objek .NET secara sembarang ke dalam konstruktor.

Protokol SBMP warisan menserialisasikan objek dengan serializer biner default, atau dengan serializer yang disediakan secara eksternal. Protokol AMQP menserialisasikan objek ke dalam objek AMQP. Penerima dapat mengambil objek tersebut dengan metode GetBody<T>(), yang memasok jenis yang diharapkan. Dengan AMQP, objek diserialisasikan ke dalam grafik AMQP ArrayList dan objek IDictionary<string,object>, dan setiap klien AMQP dapat mendekodekannya.

Meskipun sihir serialisasi tersembunyi ini nyaman, jika aplikasi harus mengambil kontrol eksplisit dari serialisasi objek dan mengubah grafik objek mereka menjadi aliran sebelum memasukkannya ke dalam pesan, mereka harus melakukan operasi terbalik di sisi penerima. Meskipun AMQP memiliki model pengodean biner yang kuat, AMQP terkait dengan ekosistem olahpesan AMQP dan klien HTTP mengalami kesulitan mendekode payload tersebut.