Panduan protokol AMQP 1.0 di Azure Service Bus dan Azure Event Hubs

Advanced Message Queueing Protocol (AMQA) 1.0 adalah protokol pembingkaian dan transfer standar untuk mentransfer pesan secara asinkron, aman, dan andal antara dua pihak. Ini adalah protokol utama Olahpesan Azure Service Bus dan Azure Event Hubs.

AMQP 1.0 adalah hasil kolaborasi industri luas yang menggabungkan vendor middleware, seperti Microsoft dan Red Hat, dengan banyak pengguna middleware oleh pesan seperti JP Morgan Chase yang mewakili industri jasa keuangan. Forum standardisasi teknis untuk protokol AMQP dan spesifikasi ekstensi adalah OASIS, dan telah memperoleh persetujuan formal sebagai standar internasional sebagai ISO/IEC 19494:2014.

Sasaran

Artikel ini merangkum konsep inti spesifikasi olah pesan AMQP 1.0 beserta spesifikasi ekstensi yang dikembangkan oleh Komite Teknis AMQP OASIS dan menjelaskan bagaimana Azure Service Bus menerapkan dan menyusun spesifikasi ini.

Tujuannya adalah agar setiap pengembang yang menggunakan tumpukan klien AMQP 1.0 yang ada di platform apa pun dapat berinteraksi dengan Azure Service Bus melalui AMQP 1.0.

Tumpukan AMQP 1.0 serbaguna umum, seperti Apache Qpid Proton atau AMQP.NET Lite, mengimplementasikan semua elemen protokol AMQP 1.0 inti seperti sesi atau tautan. Elemen dasar tersebut terkadang dibalut dengan API tingkat yang lebih tinggi; Apache Proton bahkan menawarkan dua API, API Messenger imperatif dan Reactor API reaktif.

Dalam diskusi berikut, kami berasumsi bahwa manajemen koneksi, sesi, dan tautan AMQP serta penanganan transfer bingkai dan kontrol aliran ditangani oleh masing-masing tumpukan (seperti Apache Proton-C) dan tidak memerlukan banyak jika ada perhatian khusus dari pengembang aplikasi. Kami secara abstrak mengasumsikan keberadaan beberapa fungsi API seperti kemampuan untuk terhubung, dan membuat beberapa bentuk objek abstraksi pengirim dan penerima, yang kemudian memiliki beberapa bentuk operasi send() dan receive() masing-masing.

Saat membahas kemampuan lanjutan Azure Service Bus, seperti penelusuran pesan atau pengelolaan sesi, fitur tersebut dijelaskan dalam istilah AMQP, tetapi juga sebagai implementasi semu berlapis selain asumsi abstraksi API.

Apa itu AMQP?

AMQP adalah protokol pembingkaian dan transfer. Pembingkaian berarti bahwa AMQP menyediakan struktur untuk aliran data biner yang mengalir di salah satu arah koneksi jaringan. Struktur ini menyediakan delineasi untuk blok data yang berbeda, yang disebut bingkai, untuk dipertukarkan antara pihak-pihak yang terhubung. Kemampuan transfer memastikan bahwa kedua pihak yang berkomunikasi dapat membangun pemahaman bersama tentang kapan bingkai harus ditransfer, dan kapan transfer harus dianggap selesai.

Tidak seperti versi draf yang kedaluwarsa sebelumnya dari grup kerja AMQP yang masih digunakan oleh beberapa broker pesan, protokol AMQP 1.0 akhir grup kerja, dan standar tidak meresepkan keberadaan broker pesan atau topologi tertentu untuk entitas di dalam broker pesan.

Protokol ini dapat digunakan untuk komunikasi peer-to-peer simetris, untuk interaksi dengan broker pesan yang mendukung antrean dan memublikasikan/berlangganan entitas, seperti yang dilakukan Azure Service Bus. Protokol Ini juga dapat digunakan untuk interaksi dengan infrastruktur olah pesan tempat pola interaksi berbeda dengan antrean reguler, seperti halnya dengan Azure Event Hubs. Sebuah hub peristiwa bertindak seperti antrean saat peristiwa dikirim ke sana, tetapi bertindak lebih seperti layanan penyimpanan serial saat peristiwa dibaca darinya; agak menyerupai drive tape. Klien memilih offset ke aliran data yang tersedia dan kemudian dilayani semua peristiwa dari offset tersebut hingga yang terbaru tersedia.

Protokol AMQP 1.0 dirancang agar dapat diperluas, sehingga spesifikasi lebih lanjut dapat ditingkatkan kemampuannya. Tiga spesifikasi ekstensi yang dibahas dalam dokumen ini menggambarkan hal ini. Untuk komunikasi melalui infrastruktur HTTPS/WebSockets yang ada, mengonfigurasi port TCP AMQP asli mungkin sulit. Spesifikasi terikat menentukan cara melapisi AMQP melalui WebSocket. Untuk berinteraksi dengan infrastruktur olah pesan dalam mode permintaan/respons untuk tujuan pengelolaan atau untuk menyediakan fungsi lanjutan, spesifikasi pengelolaan AMQP menentukan fungsi interaksi dasar yang diperlukan. Untuk integrasi model otorisasi federasi, spesifikasi keamanan berbasis klaim AMQP menentukan cara mengaitkan dan memperbarui token otorisasi yang terkait dengan tautan.

Skenario AMQP dasar

Bagian ini menjelaskan penggunaan dasar AMQP 1.0 dengan Azure Service Bus, yang mencakup pembuatan koneksi, sesi, dan tautan, serta mentransfer pesan ke dan dari entitas Azure Service Bus seperti antrean, topik, dan langganan.

Sumber yang paling otoritatif untuk mempelajari cara kerja AMQP adalah spesifikasi AMQP 1.0, tetapi spesifikasinya ditulis untuk secara tepat memandu implementasi dan tidak mengajarkan protokol. Bagian ini berfokus pada pengantar terminologi yang diperlukan untuk menggambarkan cara Service Bus menggunakan AMQP 1.0. Untuk pengantar AMQP yang lebih komprehensif, serta diskusi AMQP 1.0 yang lebih luas, Anda dapat meninjau kursus video ini.

Koneksi dan sesi

AMQP memanggil kontainer program komunikasi kontainer; yang berisi simpul, yang merupakan entitas komunikasi di dalam kontainer tersebut. Antrean bisa berupa simpul seperti itu. AMQP memungkinkan multipleksi, sehingga koneksi tunggal dapat digunakan untuk berbagai jalur komunikasi antar simpul; misalnya, klien aplikasi dapat menerima secara bersamaan dari satu antrean dan mengirim ke antrean lain melalui koneksi jaringan yang sama.

Koneksi jaringan dengan demikian berlabuh pada kontainer. Hal ini diinisiasi oleh kontainer dalam peran klien dalam membuat koneksi soket TCP keluar ke kontainer dalam peran penerima, yang mendengarkan dan menerima koneksi TCP masuk. Jabat tangan koneksi termasuk menegosiasikan versi protokol, menyatakan atau menegosiasikan penggunaan Transport Level Security (TLS/SSL), dan jabat tangan otentikasi/otorisasi pada lingkup koneksi yang didasarkan pada SASL.

Azure Service Bus dan Azure Event Hubs memerlukan penggunaan TLS setiap saat. Ini mendukung koneksi melalui TCP port 5671, di mana koneksi TCP pertama kali dilapisi dengan TLS sebelum memasuki jabat tangan protokol AMQP, dan juga mendukung koneksi melalui TCP port 5672 di mana server segera menawarkan peningkatan koneksi wajib ke TLS menggunakan model yang ditentukan AMQP. Pengikatan AMQP WebSockets membuat terowongan melalui TCP port 443 yang kemudian setara dengan koneksi AMQP 5671.

Setelah menyiapkan koneksi dan TLS, Azure Service Bus menawarkan dua opsi mekanisme SASL:

• SASL PLAIN umumnya digunakan untuk meneruskan info masuk nama pengguna dan kata sandi ke server. Azure Service Bus tidak memiliki akun, tetapi bernama aturan Keamanan Akses Bersama, yang memberikan hak dan dikaitkan dengan kunci. Nama aturan digunakan sebagai nama pengguna dan kunci (sebagai teks berkode base64) digunakan sebagai kata sandi. Hak yang terkait dengan aturan yang dipilih mengatur operasi yang diizinkan pada koneksi.
• SASL ANONYMOUS digunakan untuk melewati otorisasi SASL saat klien ingin menggunakan model keamanan berbasis klaim (CBS) yang akan dijelaskan nanti. Dengan opsi ini, koneksi klien dapat dibuat secara anonim untuk waktu yang singkat yang pada periode tersebut hanya dapat berinteraksi dengan titik akhir CBS dan jabat tangan CBS harus selesai.

Setelah koneksi transmisi dibuat, masing-masing kontainer menyatakan ukuran bingkai maksimum yang akan mereka handel, dan setelah waktu idle habis, mereka akan diputus secara sepihak jika tidak ada aktivitas pada koneksi.

Kontainer tersebut juga menyatakan banyaknya saluran serempak yang didukung. Saluran adalah jalur transfer virtual, keluar, dan satu arah selain koneksi. Sesi mengambil saluran dari masing-masing kontainer yang saling terhubung untuk membentuk jalur komunikasi dua arah.

Sesi memiliki model kontrol aliran berbasis jendela; saat sesi dibuat, tiap pihak menyatakan banyaknya bingkai yang bersedia diterima ke dalam jendela penerimanya. Saat para pihak bertukar bingkai, bingkai yang ditransfer akan mengisi jendela tersebut dan transfer dihentikan saat jendela penuh dan hingga jendela diatur ulang atau diperluas menggunakan performatif alur (performatif adalah istilah AMQP untuk gerakan tingkat protokol yang dipertukarkan antara kedua belah pihak).

Model berbasis jendela ini kira-kira dianalogikan dengan konsep TCP kontrol alur berbasis jendela, tetapi pada tingkat sesi di dalam soket. Konsep protokol yang memungkinkan keberadaan sesi secara bersamaan sehingga lalu lintas prioritas tinggi dapat dilarikan melewati lalu lintas normal yang dicekik, seperti di jalur ekspres jalan bebas hambatan.

Azure Service Bus saat ini menggunakan tepat satu sesi untuk setiap koneksi. Ukuran bingkai maksimum Azure Bus Servis 262.144 byte (256-K byte) untuk Azure Service Bus Standard. 1048576 (100 MB) untuk Azure Service Bus Premium dan Azure Event Hubs. Azure Service Bus tidak menerapkan jendela pembatasan tingkat sesi tertentu, tetapi mengatur ulang jendela secara reguler sebagai bagian dari kontrol alur tingkat tautan (lihat bagian berikutnya).

Koneksi, saluran, dan sesi bersifat sementara. Jika koneksi yang mendasarinya putus, sesi, konteks otorisasi SASL, terowongan TLS, dan koneksi harus dibangun kembali.

Persyaratan port keluar AMQP

Klien yang menggunakan koneksi AMQP melalui TCP mengharuskan port 5671 dan 5672 dibuka di firewall lokal. Selain port ini, port tambahan mungkin perlu dibuka jika fitur EnableLinkRedirect diaktifkan. EnableLinkRedirect adalah fitur olah pesan baru yang membantu melewati satu hop saat menerima pesan, sehingga membantu meningkatkan throughput. Klien dapat mulai berkomunikasi langsung dengan layanan back-end melalui rentang port 104XX seperti yang ditunjukkan pada gambar berikut.

Klien .NET akan gagal dengan SocketException ("Upaya dilakukan untuk mengakses soket dengan cara yang dilarang oleh izin aksesnya") jika port ini diblokir oleh firewall. Fitur ini dapat dinonaktifkan dengan mengatur EnableAmqpLinkRedirect=false di string koneksi, yang memaksa klien untuk berkomunikasi dengan layanan jarak jauh melalui port 5671.

Pengikatan AMQP WebSocket menyediakan mekanisme untuk terowongan koneksi AMQP melalui transportasi WebSocket. Pengikatan ini membuat terowongan melalui port TCP 443, yang setara dengan koneksi AMQP 5671. Gunakan AMQP WebSockets jika Anda berada di belakang firewall yang memblokir koneksi TCP melalui port 5671, 5672 tetapi memungkinkan koneksi TCP melalui port 443 (https).

Tautan

AMQP mentransfer pesan melalui tautan. Tautan adalah jalur komunikasi yang dibuat selama sesi yang memungkinkan transfer pesan dalam satu arah; negosiasi status transfer dilakukan melalui tautan dan dua arah antara pihak-pihak yang terhubung.

Tautan dapat dibuat oleh kontainer kapan saja dan selama sesi yang ada, yang membuat AMQP berbeda dengan kebanyakan protokol lain, termasuk HTTP dan MQTT, di mana inisiasi transfer dan jalur transfer adalah hak istimewa eksklusif pihak yang membuat koneksi soket.

Kontainer yang memulai tautan meminta kontainer yang berlawanan untuk menerima tautan dan kontainer ini memilih peran pengirim atau penerima. Oleh karena itu, salah satu kontainer dapat memulai pembuatan jalur komunikasi satu arah atau dua arah, dengan yang terakhir yang dimodelkan sebagai pasangan tautan.

Tautan diberi nama dan dikaitkan dengan simpul. Seperti yang dinyatakan di awal, simpul adalah entitas komunikasi di dalam kontainer.

Di Azure Service Bus, simpul secara langsung setara dengan antrean, topik, langganan, atau sub-antrean surat mati dari antrean atau langganan. Oleh karena itu, nama simpul yang digunakan dalam AMQP adalah nama relatif entitas di dalam namespace Azure Service Bus. Jika antrean diberi nama myqueue, ini menjadi nama simpul AMQP-nya. Langganan topik mengikuti konvensi HTTP API dengan diurutkan ke dalam koleksi sumber daya "langganan," sehingga langganan sub pada topik mytopic memiliki nama simpul AMQP mytopic/subscriptions/sub.

Klien penghubung juga diharuskan menggunakan nama node lokal untuk membuat tautan; Azure Service Bus tidak reseptif tentang nama node tersebut dan tidak menafsirkannya. Tumpukan klien AMQP 1.0 umumnya menggunakan skema untuk memastikan bahwa nama simpul sementara ini unik dalam lingkup klien.

Transfer

Setelah tautan dibuat, pesan dapat ditransfer melalui tautan tersebut. Di AMQP, transfer dijalankan dengan gerakan protokol eksplisit (performatif transfer) yang memindahkan pesan dari pengirim ke penerima melalui tautan. Transfer selesai ketika "diselesaikan", yang berarti bahwa kedua belah pihak telah saling memahami tentang hasil transfer itu.

Dalam kasus yang paling sederhana, pengirim dapat memilih untuk mengirim pesan "diselesaikan sebelumnya," yang berarti bahwa klien tidak tertarik pada hasilnya dan penerima tidak memberikan umpan balik tentang hasil operasi. Mode ini didukung oleh Azure Service Bus di tingkat protokol AMQP, tetapi tidak terekspos dalam API klien mana pun.

Kasus umumnya adalah bahwa pesan dikirim dalam kondisi tidak diselesaikan, dan penerima kemudian menunjukkan penerimaan atau penolakan menggunakan disposisi performatif. Penolakan terjadi jika penerima tidak dapat menerima pesan karena alasan apa pun, dan pesan penolakan berisi informasi tentang alasannya, yang merupakan struktur kesalahan yang ditentukan oleh AMQP. Jika pesan ditolak karena kesalahan internal di dalam Azure Service Bus, layanan akan menampilkan informasi tambahan di dalam struktur yang dapat digunakan untuk memberikan petunjuk diagnostik untuk mendukung personil jika Anda mengajukan permintaan dukungan. Anda akan mempelajari detail selengkapnya tentang kesalahan nanti.

Bentuk penolakan khusus adalah keadaan yang dirilis, yang menunjukkan bahwa penerima tidak memiliki keberatan teknis terhadap transfer, tetapi juga tidak tertarik untuk menyelesaikan transfer. Kasus tersebut terjadi, misalnya, jika pesan dikirimkan ke klien Azure Service Bus, dan klien memilih untuk "meninggalkan" pesan karena tidak dapat melakukan pekerjaan yang dihasilkan dari pemrosesan pesan; pengiriman pesan itu sendiri bukanlah kesalahan. Variasi status tersebut adalah status modifikasi, yang memungkinkan perubahan pada pesan saat dirilis. Status tersebut saat ini tidak digunakan oleh Azure Service Bus.

Spesifikasi AMQP 1.0 menentukan status disposisi lebih lanjut yang disebut diterima, yang secara khusus membantu menangani pemulihan tautan. Pemulihan tautan memungkinkan rekonstitusi status tautan dan semua pengiriman yang tertunda selain koneksi dan sesi baru, ketika koneksi dan sesi sebelumnya hilang.

Bus Layanan tidak mendukung pemulihan tautan; jika klien kehilangan koneksi ke Bus Layanan dengan transfer pesan yang tidak dibatasi tertunda, transfer pesan tersebut hilang, dan klien harus terhubung kembali, membangun kembali tautan, dan mencoba kembali transfer.

Dengan demikian, Azure Service Bus dan Azure Event Hubs mendukung transfer "setidaknya sekali" saat pengirim dapat diyakinkan bahwa pesan telah disimpan dan diterima, tetapi tidak mendukung transfer "tepat sekali" di tingkat AMQP, saat sistem akan berusaha memulihkan tautan dan terus menegosiasikan status pengiriman untuk menghindari duplikasi transfer pesan.

Untuk mengimbangi kemungkinan pengiriman duplikat, Azure Service Bus mendukung deteksi duplikat sebagai fitur opsional pada antrean dan topik. Deteksi duplikat mencatat ID pesan semua pesan masuk selama periode waktu yang ditentukan pengguna, lalu secara diam-diam menghilangkan semua pesan yang dikirim dengan ID pesan yang sama selama periode yang sama.

Kontrol alur

Selain model kontrol aliran tingkat sesi yang sebelumnya dibahas, setiap tautan memiliki model kontrol alirannya sendiri. Kontrol aliran tingkat sesi mencegah kontainer menangani terlalu banyak bingkai sekaligus, kontrol aliran tingkat tautan menempatkan aplikasi untuk menangani banyaknya pesan yang ingin ditangani dari tautan dan kapan.

Pada tautan, transfer hanya dapat dilakukan jika pengirim memiliki kredit tautan yang cukup. Kredit tautan adalah penghitung yang ditetapkan oleh penerima menggunakan performatif aliran, yang dicakup ke tautan. Saat pengirim diberi kredit tautan, pengirim mencoba menghabiskan kredit tersebut dengan mengirimkan pesan. Setiap pengiriman pesan akan mengurangi sisa kredit tautan sebesar 1. Saat kredit tautan habis, pengiriman berhenti.

Jika Azure Service Bus berada dalam peran penerima, kredit tautan yang cukup akan langsung diberikan kepada pengirim, sehingga pesan dapat segera dikirim. Saat kredit tautan digunakan, Azure Service Bus sesekali mengirimkan performatif aliran kepada pengirim untuk memperbarui saldo kredit tautan.

Dalam peran pengirim, Azure Service Bus mengirim pesan untuk menghabiskan kredit tautan yang tersisa.

Panggilan "terima" di tingkat API diterjemahkan menjadi performatif aliran yang dikirim ke Azure Service Bus oleh klien, dan Azure Service Bus menggunakan kredit tersebut dengan mengambil pesan pertama yang tersedia dan tidak terkunci dari antrian, menguncinya, lalu mentransfernya. Jika tidak ada pesan yang tersedia untuk dikirim, semua kredit yang tersisa oleh tautan apa pun yang dibuat dengan entitas tertentu tetap dicatat dalam urutan kedatangan, dan pesan dikunci dan ditransfer saat tersedia, untuk menggunakan kredit yang tersisa.

Kunci pada pesan dilepaskan saat transfer diselesaikan ke salah satu status terminal diterima, ditolak, atau dirilis. Pesan dihapus dari Azure Service Bus ketika status terminal diterima. Ini tetap berada di Azure Service Bus dan dikirim ke penerima berikutnya saat transfer mencapai salah satu status lainnya. Azure Service Bus otomatis memindahkan pesan ke dalam antrean surat mati entitas saat mencapai jumlah pengiriman maksimum yang diizinkan untuk entitas karena penolakan atau pelepasan ulang.

Meski Azure Service Bus API tidak langsung mengekspos opsi seperti itu hari ini, klien protokol AMQP tingkat bawah dapat menggunakan model kredit tautan untuk mengubah interaksi "gaya tarik" dalam mengeluarkan satu unit kredit untuk setiap permintaan penerimaan menjadi model "gaya dorong" dengan mengeluarkan sejumlah besar kredit tautan dan kemudian menerima pesan saat tersedia tanpa interaksi lebih lanjut. Pendorongan didukung melalui pengaturan properti ServiceBusProcessor.PrefetchCount atau ServiceBusReceiver.PrefetchCount . Ketika pengaturan tersebut non-nol, klien AMQP menggunakannya sebagai kredit tautan.

Dalam konteks ini, perlu dipahami bahwa jam kedaluwarsa untuk kunci pada pesan di dalam entitas akan dimulai saat pesan diambil dari entitas, bukan saat pesan dimasukkan di kabel. Setiap kali klien menunjukkan kesiapan untuk menerima pesan dengan mengeluarkan kredit tautan, klien diharapkan secara aktif menarik pesan di seluruh jaringan dan siap menanganinya. Jika tidak, kunci pesan mungkin telah kedaluwarsa sebelum pesan bahkan dikirimkan. Penggunaan kontrol aliran kredit tautan harus langsung mencerminkan kesiapan langsung untuk menangani pesan yang tersedia yang dikirim ke penerima.

Singkatnya, bagian berikut ini memberikan ringkasan skematik tentang aliran performatif selama interaksi API yang berbeda. Setiap bagian menjelaskan operasi logika yang berbeda. Beberapa interaksi tersebut mungkin "malas", yang berarti mereka mungkin hanya dilakukan jika diperlukan. Membuat pengirim pesan mungkin tidak menyebabkan interaksi jaringan hingga pesan pertama dikirim atau diminta.

Tanda panah dalam tabel berikut memperlihatkan arah aliran performatif.

Membuat penerima pesan

Klien	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={entity name},<br/>target={client link ID}<br/>)	Klien melampirkan ke entitas sebagai penerima
Balasan Azure Service Bus melampirkan akhiran tautannya	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={entity name},<br/>target={client link ID}<br/>)

Membuat pengirim pesan

Klien	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	Tidak ada tindakan
Tidak ada tindakan	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={client link ID},<br/>target={entity name}<br/>)

Membuat pengirim pesan (kesalahan)

Klien	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	Tidak ada tindakan
Tidak ada tindakan	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source=null,<br/>target=null<br/>)<br/><br/><-- detach(<br/>handle={numeric handle},<br/>closed=**true**,<br/>error={error info}<br/>)

Menutup penerima/pengirim pesan

Klien	Service Bus
--> detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)	Tidak ada tindakan
Tidak ada tindakan	<-- detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)

Kirim (berhasil)

Klien	Service Bus
--> transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,,more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)	Tidak ada tindakan
Tidak ada tindakan	<-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**accepted**<br/>)

Kirim (kesalahan)

Klien	Service Bus
--> transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,,more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)	Tidak ada tindakan
Tidak ada tindakan	<-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**rejected**(<br/>error={error info}<br/>)<br/>)

Terima

Klien	Service Bus
--> flow(<br/>link-credit=1<br/>)	Tidak ada tindakan
Tidak ada tindakan	< transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
--> disposition(<br/>role=**receiver**,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**accepted**<br/>)	Tidak ada tindakan

Penerimaan multi-pesan

Klien	Service Bus
--> flow(<br/>link-credit=3<br/>)	Tidak ada tindakan
Tidak ada tindakan	< transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
Tidak ada tindakan	< transfer(<br/>delivery-id={numeric handle+1},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
Tidak ada tindakan	< transfer(<br/>delivery-id={numeric handle+2},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
--> disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID+2},<br/>settled=**true**,<br/>state=**accepted**<br/>)	Tidak ada tindakan

Pesan

Bagian berikut menjelaskan properti dari bagian pesan AMQP standar yang digunakan oleh Azure Service Bus dan bagaimana properti tersebut dipetakan ke rangkaian Azure Service Bus API.

Properti apa pun yang perlu didefinisikan aplikasi harus dipetakan ke peta application-properties AMQP.

{i>header

Nama Bidang	Penggunaan	Nama API
tahan Lama	-	-
prioritas	-	-
ttl	Time to live untuk pesan ini	TimeToLive
first-acquirer	-	-
delivery-count	-	DeliveryCount

properti

Nama Bidang	Penggunaan	Nama API
message-id	Pengidentifikasi bentuk bebas yang ditentukan aplikasi untuk pesan ini. Digunakan untuk deteksi duplikat.	MessageId
user_id	Pengidentifikasi pengguna yang ditentukan aplikasi, tidak ditafsirkan oleh Service Bus.	Tidak dapat diakses melalui Azure Service Bus API.
ke	Pengidentifikasi tujuan yang ditentukan aplikasi, tidak ditafsirkan oleh Service Bus.	Untuk
subjek	Pengidentifikasi tujuan pesan yang ditentukan aplikasi, tidak ditafsirkan oleh Service Bus.	Subjek
reply-to	Pengidentifikasi jalur balasan yang ditentukan aplikasi, tidak ditafsirkan oleh Service Bus.	ReplyTo
correlation-id	Pengidentifikasi koralasi yang ditentukan aplikasi, tidak ditafsirkan oleh Service Bus.	CorrelationId
tipekonten	Indikator jenis konten yang ditentukan aplikasi, tidak ditafsirkan oleh Service Bus.	ContentType
content-encoding	Indikator pengkodean konten yang ditentukan aplikasi, tidak ditafsirkan oleh Azure Service Bus.	Tidak dapat diakses melalui Azure Service Bus API.
absolute-expiry-time	Menyatakan instan absolut mana saat pesan kedaluwarsa. Diabaikan di input (TTL header diamati), wajib di output.	Tidak dapat diakses melalui Azure Service Bus API.
creation-time	Menyatakan waktu saat pesan dibuat. Tidak digunakan oleh Azure Service Bus	Tidak dapat diakses melalui Azure Service Bus API.
group-id	Pengidentifikasi yang ditentukan aplikasi untuk sekumpulan pesan terkait. Digunakan untuk sesi Azure Service Bus.	SessionId
group-sequence	Penghitung yang mengidentifikasi nomor urut relatif pesan di dalam sesi. Diabaikan oleh Azure Service Bus.	Tidak dapat diakses melalui Azure Service Bus API.
reply-to-group-id	-	ReplyToSessionId

Anotasi pesan

Ada beberapa properti pesan bus layanan lainnya, yang bukan bagian dari properti pesan AMQP, dan diteruskan sebagai MessageAnnotations pada pesan.

Kunci Peta Anotasi	Penggunaan	Nama API
x-opt-scheduled-enqueue-time	Menyatakan waktu saat pesan akan muncul pada entitas	ScheduledEnqueueTime
x-opt-partition-key	Kunci yang ditentukan aplikasi yang menentukan partisi tempat pesan akan ditempatkan.	PartitionKey
x-opt-via-partition-key	Nilai kunci partisi yang ditentukan aplikasi saat transaksi harus digunakan untuk mengirim pesan melalui antrean transfer.	TransactionPartitionKey
x-opt-enqueued-time	Waktu UTC yang ditentukan layanan menunjukkan waktu aktual saat memasukkan pesan dalam antrean. Diabaikan pada input.	EnqueuedTime
x-opt-sequence-number	Nomor unik yang ditentukan layanan yang ditetapkan ke pesan.	SequenceNumber
x-opt-offset	Nomor urutan antrean pesan yang ditentukan layanan.	EnqueuedSequenceNumber
x-opt-locked-until	Ditentukan layanan. Tanggal dan waktu hingga pesan akan dikunci dalam antrean/langganan.	LockedUntil
x-opt-deadletter-source	Ditentukan Layanan. Jika pesan diterima dari antrean surat mati, ia mewakili sumber dari pesan asli.	DeadLetterSource

Kemampuan transaksi

Transaksi mengelompokkan dua operasi atau lebih menjadi satu cakupan eksekusi. Secara alami, transaksi semacam itu harus memastikan bahwa semua operasi milik kelompok operasi tertentu berhasil atau gagal bersama. Operasi dikelompokkan menurut pengidentifikasi txn-id.

Untuk interaksi transaksional, klien bertindak sebagai transaction controller, yang mengontrol operasi yang harus dikelompokkan bersama. Layanan Azure Service Bus bertindak sebagai transactional resource dan melakukan pekerjaan seperti yang diminta oleh transaction controller.

Klien dan layanan berkomunikasi melalui control link, yang ditetapkan oleh klien. Pesan declare dan discharge dikirim oleh pengontrol melalui tautan kontrol untuk mengalokasikan dan menyelesaikan transaksi masing-masing (pesan ini tidak mewakili pembatasan pekerjaan transaksional). Kirim/terima aktual tidak dilakukan pada tautan ini. Setiap operasi transaksional yang diminta secara eksplisit diidentifikasi dengan yang diinginkan txn-id dan oleh karena itu mungkin terjadi pada tautan apa pun pada Koneksi. Jika tautan kontrol ditutup, sementara ada transaksi yang belum dihentikan yang dibuatnya, semua transaksi tersebut segera digulirkan kembali, dan upaya untuk melakukan pekerjaan transaksional lebih lanjut terhadapnya akan menyebabkan kegagalan. Pesan pada tautan kontrol tidak boleh diselesaikan sebelumnya.

Setiap koneksi harus memulai tautan kontrolnya sendiri untuk dapat memulai dan mengakhiri transaksi. Layanan menentukan target khusus yang berfungsi sebagai coordinator. Klien/controller membuat tautan kontrol ke target ini. Tautan kontrol berada di luar batas entitas, yaitu, tautan kontrol yang sama dapat digunakan untuk memulai dan menghentikan transaksi untuk beberapa entitas.

Memulai transaksi

Untuk memulai pekerjaan transaksional. pengontrol harus mendapatkan txn-id dari koordinator. Tindakan ini dilakukan dengan mengirim pesan jenis declare. Jika pernyataan berhasil, koordinator akan merespons dengan hasil disposisi, yang membawa txn-id yang ditetapkan.

Klien (Pengontrol)	Arah	Azure Service Bus (Koordinator)
lampirkan( name={nama tautan}, ... , role=pengirim, target=Koordinator )	------>
	<------	lampirkan( name={nama tautan}, ... , target=Koordinator() )
transfer( delivery-id=0, ...) { AmqpValue (Menyatakan())}	------>
	<------	disposisi( first=0, last=0, state=Dinyatakan( txn-id={ID transaksi} ))

Mengeluarkan biaya transaksi

Pengontrol menyimpulkan pekerjaan transaksional dengan mengirim pesan discharge ke koordinator. Pengontrol menunjukkan keinginannya untuk melakukan atau mengembalikan pekerjaan transaksional dengan mengatur bendera fail pada isi penghentian. Jika koordinator tidak dapat menyelesaikan penghentian, pesan akan ditolak dengan hasil ini yang membawa transaction-error.

Catatan: fail=true adalah Mengembalikan transaksi, dan fail=false Adalah Melakukan.

Klien (Pengontrol)	Arah	Azure Service Bus (Koordinator)
transfer( delivery-id=0, ...) { AmqpValue (Menyatakan())}	------>
	<------	disposisi( first=0, last=0, state=Dinyatakan( txn-id={ID transaksi} ))
	. . . Pekerjaan transaksional di tautan lainnya . . .
transfer( delivery-id=57, ...) { AmqpValue ( Discharge(txn-id=0, fail=false))}	------>
	<------	disposisi( first=57, last=57, state=Diterima())

Mengirim pesan dalam transaksi

Semua pekerjaan transaksi dilakukan dengan status transactional-state pengiriman transaksi yang membawa txn-id. Saat mengirim pesan, status transaksi diangkut oleh bingkai transfer pesan.

Klien (Pengontrol)	Arah	Azure Service Bus (Koordinator)
transfer( delivery-id=0, ...) { AmqpValue (Menyatakan())}	------>
	<------	disposisi( first=0, last=0, state=Dinyatakan( txn-id={ID transaksi} ))
transfer( handle=1, delivery-id=1, status= TransactionalState( txn-id=0)) { payload }	------>
	<------	disposisi( first=1, last=1, state=TransactionalState( txn-id=0, outcome=Accepted()))

Membuang pesan dalam transaksi

Disposisi pesan mencakup operasi seperti Complete / Abandon / DeadLetter / Defer. Untuk melakukan operasi ini dalam transaksi, lewati transactional-state dengan disposisi.

Klien (Pengontrol)	Arah	Azure Service Bus (Koordinator)
transfer( delivery-id=0, ...) { AmqpValue (Menyatakan())}	------>
	<------	disposisi( first=0, last=0, state=Dinyatakan( txn-id={ID transaksi} ))
	<------	transfer( handle=2, delivery-id=11, state=null) { payload }
disposisi( first=11, last=11, state=TransactionalState( txn-id=0, outcome=Accepted()))	------>

Kapabilitas Lanjutan Azure Service Bus

Bagian ini mencakup kapabilitas lanjutan Azure Service Bus yang didasarkan pada ekstensi draf ke AMQP, yang saat ini sedang dikembangkan di Komite Teknis OASIS untuk AMQP. Azure Service Bus menerapkan versi draf terbaru dan mengadopsi perubahan yang digunakan saat draf mencapai status standar.

Catatan

Operasi lanjutan Azure Service Bus Messaging didukung melalui pola permintaan/respons. Detail operasi ini dijelaskan dalam artikel AMQP 1.0 di Azure Service Bus: operasi berbasis respons permintaan.

Pengelolaan AMQP

Spesifikasi pengelolaan AMQP adalah yang pertama dari draf ekstensi yang dibahas dalam artikel ini. Spesifikasi ini menentukan serangkaian protokol berlapis selain protokol AMQP yang memungkinkan interaksi pengelolaan dengan infrastruktur olahpesan melalui AMQP. Spesifikasi menentukan operasi generik seperti membuat, membaca, memperbarui, dan menghapus untuk mengelola entitas di dalam infrastruktur olah pesan dan serangkaian operasi kueri.

Semua gerakan tersebut memerlukan interaksi permintaan/respons antara klien dan infrastruktur olah pesan, dan oleh karena itu, spesifikasi menentukan cara memodelkan pola interaksi tersebut selain AMQP: klien terhubung ke infrastruktur olah pesan, memulai sesi, dan kemudian membuat sepasang tautan. Pada satu tautan, klien bertindak sebagai pengirim dan di sisi lain bertindak sebagai penerima, sehingga membuat sepasang tautan yang dapat bertindak sebagai saluran dua arah.

Operator Logika	Klien	Service Bus
Membuat Jalur Respons Permintaan	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=**null**,<br/>target=”myentity/$management”<br/>)	Tidak ada tindakan
Membuat Jalur Respons Permintaan	Tidak ada tindakan	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=null,<br/>target=”myentity”<br/>)
Membuat Jalur Respons Permintaan	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=”myentity/$management”,<br/>target=”myclient$id”<br/>)
Membuat Jalur Respons Permintaan	Tidak ada tindakan	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=”myentity”,<br/>target=”myclient$id”<br/>)

Dengan menerapkan sepasang tautan, implementasi permintaan/respons sangat mudah: permintaan adalah pesan yang dikirim ke entitas di dalam infrastruktur olah pesan yang memahami pola ini. Dalam pesan permintaan tersebut, bidang reply-to d bagian properti diatur ke pengidentifikasi target untuk link tempat respons akan dikirim. Entitas penanganan memproses permintaan, kemudian mengirimkan balasan melalui tautan yang pengidentifikasi targetnya cocok dengan pengidentifikasi reply-to yang ditunjukkan.

Pola ini jelas mengharuskan bahwa kontainer klien dan pengidentifikasi yang dibuat klien untuk tujuan balasan unik di seluruh klien dan, untuk alasan keamanan, juga sulit diprediksi.

Pertukaran pesan yang digunakan untuk protokol manajemen dan untuk semua protokol lain yang menggunakan pola yang sama terjadi di tingkat aplikasi; mereka tidak menentukan gerakan tingkat protokol AMQP baru. Hal ini disengaja, sehingga aplikasi dapat mengambil manfaat langsung dari ekstensi ini dengan tumpukan AMQP 1.0 yang sesuai.

Bus Layanan saat ini tidak menerapkan salah satu fitur inti dari spesifikasi manajemen, tetapi pola permintaan/respons yang ditentukan oleh spesifikasi manajemen bersifat dasar untuk fitur keamanan berbasis klaim dan untuk hampir semua kemampuan tingkat lanjut yang dibahas di bagian berikut:

Otorisasi berbasis klaim

Draf spesifikasi Otorisasi Berbasis Klaim (CBS) AMQP dibuat berdasarkan pola permintaan/respons spesifikasi pengelolaan, dan menjelaskan model umum tentang cara menggunakan token keamanan gabungan dengan AMQP.

Model keamanan default AMQP yang dibahas dalam bagian pengantar didasarkan pada SASL dan terintegrasi dengan jabat tangan koneksi AMQP. Menggunakan SASL memiliki keuntungan bahwa SASL menyediakan model yang dapat diperluas di mana serangkaian mekanisme telah ditentukan yang manfaatnya dapat diambil dari protokol apa pun yang secara formal bersandar pada SASL. Di antara mekanisme tersebut adalah "PLAIN" untuk transfer nama pengguna dan kata sandi, "EXTERNAL" untuk dikaitkan ke keamanan tingkat TLS, "ANONYMOUS" untuk mengekspresikan tidak adanya autentikasi/otorisasi eksplisit, dan berbagai mekanisme lain yang memungkinkan lolosnya info masuk atau token autentikasi dan/atau otorisasi.

Integrasi SASL AMQP memiliki dua kelemahan:

• Semua info masuk dan token tercakup dalam koneksi. Infrastruktur olahpesan mungkin ingin menyediakan kontrol akses yang berbeda berdasarkan per entitas; misalnya, mengizinkan pembawa token untuk mengirim ke antrean A tetapi tidak untuk mengantrekan B. Dengan konteks otorisasi yang berlabuh pada koneksi, tidak dimungkinkan untuk menggunakan satu koneksi dan namun menggunakan token akses yang berbeda untuk antrean A dan antrean B.
• Token akses biasanya hanya berlaku selama waktu terbatas. Validitas ini mengharuskan pengguna untuk secara berkala mengambil kembali token dan memberikan kesempatan bagi penerbit token untuk menolak mengeluarkan token baru jika izin akses pengguna telah berubah. Koneksi AMQP mungkin berlangsung untuk jangka waktu yang lama. Model SASL hanya memberikan kesempatan untuk mengatur token pada waktu koneksi, yang berarti bahwa infrastruktur olahpesan harus memutuskan sambungan klien ketika token kedaluwarsa atau perlu menerima risiko memungkinkan komunikasi berkelanjutan dengan klien yang hak aksesnya mungkin telah dicabut sementara.

Spesifikasi AMQP CBS, yang diimplementasikan oleh Azure Service Bus, memungkinkan solusi elegan untuk kedua masalah tersebut: Memungkinkan klien mengaitkan token akses dengan setiap node, dan memperbarui token tersebut sebelum masa berlakunya berakhir, tanpa mengganggu aliran pesan.

CBS menentukan simpul pengelolaan virtual, yang bernama $cbs, yang akan disediakan oleh infrastruktur olah pesan. Simpul pengelolaan menerima token atas nama simpul lain dalam infrastruktur olah pesan.

Gerakan protokol adalah pertukaran permintaan/balasan yang ditentukan oleh spesifikasi pengelolaan. Hal ini berarti bahwa klien membuat sepasang tautan dengan simpul $cbs dan kemudian meneruskan permintaan pada tautan keluar, dan kemudian menunggu respons pada tautan masuk.

Pesan permintaan memiliki properti aplikasi berikut:

Tombol	Opsional	Jenis Nilai	Konten Nilai
operation	Tidak	string	put-token
type	Tidak	string	Jenis token yang ditempatkan.
name	Tidak	string	"Audiens" yang tokennya diberlakukan.
expiration	Ya	rentang waktu	Waktu kedaluwarsa token.

Properti nama menentukan entitas yang akan dikaitkan dengan token. Di Azure Service Bus, ini adalah jalur ke antrian, atau topik/langganan. Properti jenis menentukan jenis token:

Jenis Token	Deskripsi Token	Jenis Isi	Catatan
jwt	JSON Web Token (JWT)	Nilai AMQP (string)
servicebus.windows.net:sastoken	Token SAS Azure Service Bus	Nilai AMQP (string)	-

Hak pemberian token. Azure Service Bus tahu tentang tiga hak dasar: "Kirim" memungkinkan pengiriman, "Dengar" memungkinkan penerimaan, dan "Kelola" memungkinkan memanipulasi entitas. Token ASS Azure Service Bus mengacu pada aturan yang dikonfigurasi pada namespace atau entitas, dan aturan tersebut dikonfigurasi dengan hak. Penandatanganan token dengan kunci yang dikaitkan dengan aturan tersebut, sehingga membuat token mengekspresikan hak masing-masing. Token yang terkait dengan entitas yang menggunakan put-token mengizinkan klien yang terhubung untuk berinteraksi dengan entitas per hak token. Tautan tempat klien mengambil peran pengirim memerlukan hak "Kirim"; mengambil peran penerima memerlukan hak "Dengar".

Pesan balasan memiliki nilai properti aplikasi berikut

Tombol	Opsional	Jenis Nilai	Konten Nilai
status-code	Tidak	int	Kode respons HTTP [RFC2616].
status-description	Ya	string	Deskripsi status.

Klien dapat memanggil put-token berulang kali dan untuk entitas apa pun dalam infrastruktur olah pesan. Token dicakup ke klien saat ini dan didasarkan pada koneksi saat ini, yang berarti bahwa server menurunkan token yang dipertahankan saat koneksi turun.

Penerapan Azure Service Bus saat ini hanya mengizinkan CBS dalam hubungannya dengan metode SASL "ANONYMOUS." Koneksi SSL/TLS harus selalu tersedia sebelum SASL handshake.

Oleh karena itu, mekanisme ANONYMOUS harus didukung oleh klien AMQP 1.0 yang dipilih. Akses anonim berarti bahwa jabat tangan koneksi awal, termasuk pembuatan sesi awal terjadi tanpa Azure Service Bus mengetahui siapa yang membuat koneksi.

Setelah koneksi dan sesi dibuat, melampirkan tautan ke simpul $cbs dan mengirim permintaan put-token adalah satu-satunya operasi yang diizinkan. Token yang valid harus berhasil diatur menggunakan permintaan put-token untuk beberapa simpul entitas dalam waktu 20 detik setelah koneksi dibuat, jika tidak, koneksi akan diturunkan secara sepihak oleh Azure Service Bus.

Klien kemudian bertanggung jawab untuk melacak masa berakhirnya token. Ketika masa berlaku token berakhir, Azure Service Bus segera menghilangkan semua tautan pada koneksi ke entitas masing-masing. Untuk mencegah masalah terjadi, klien dapat mengganti token untuk simpul tersebut dengan yang baru kapan saja melalui simpul pengelolaan $cbs virtual dengan gerakan put-token yang sama, dan tanpa menghalangi lalu lintas playload yang mengalir pada tautan yang berbeda.

Fungsi send-via

Pengirim Send-via/Transfer adalah fungsi yang memungkinkan bus layanan meneruskan pesan tertentu ke entitas tujuan melalui entitas lainnya. Fitur ini digunakan untuk melakukan operasi di seluruh entitas dalam satu transaksi.

Dengan fungsi ini, Anda dapat membuat pengirim dan membuat tautan ke via-entity. Saat membuat tautan, informasi tambahan diteruskan untuk menetapkan tujuan yang sebenarnya dari pesan/transfer pada tautan ini. Setelah lampiran berhasil, semua pesan yang dikirim pada tautan ini otomatis diteruskan ke destination-entity melalui via-entity.

Catatan: Autentikasi harus dilakukan baik untuk via-entity dan destination-entity sebelum membuat tautan ini.

Klien	Arah	Service Bus
attach(<br/>name={link name},<br/>role=sender,<br/>source={client link ID},<br/>target=**{via-entity}**,<br/>**properties=map [(<br/>com.microsoft:transfer-destination-address=<br/>{destination-entity} )]** )	------>
	<------	attach(<br/>name={link name},<br/>role=receiver,<br/>source={client link ID},<br/>target={via-entity},<br/>properties=map [(<br/>com.microsoft:transfer-destination-address=<br/>{destination-entity} )] )

Langkah berikutnya

Untuk mempelajari selengkapnya tentang AMQP, lihat Gambaran umum Azure Service Bus AMQP.