Azure Service Bus ve Event Hubs protokol kılavuzunda AMQP 1.0

Gelişmiş İleti Kuyruğa Alma Protokolü 1.0, iletileri iki taraf arasında zaman uyumsuz, güvenli ve güvenilir bir şekilde aktarmak için standartlaştırılmış bir çerçeveleme ve aktarım protokolüdür. Azure Service Bus Mesajlaşma ve Azure Event Hubs'ın birincil protokolü budur.

AMQP 1.0, Microsoft ve Red Hat gibi ara yazılım satıcılarını JP Morgan Chase gibi finansal hizmetler sektörünü temsil eden birçok mesajlaşma ara yazılım kullanıcısı ile bir araya getiren geniş bir endüstri işbirliğinin sonucudur. AMQP protokolü ve uzantı belirtimleri için teknik standardizasyon forumu OASIS'dir ve ISO/IEC 19494:2014 olarak uluslararası bir standart olarak resmi onay almıştır.

Hedefler

Bu makalede, OASIS AMQP Teknik Komitesi tarafından geliştirilen uzantı belirtimleri ile birlikte AMQP 1.0 mesajlaşma belirtiminin temel kavramları özetlenmiş ve Azure Service Bus'ın bu belirtimleri nasıl uyguladığı ve oluşturduğu açıklanmaktadır.

Amaç, herhangi bir platformdaki mevcut AMQP 1.0 istemci yığınını kullanan tüm geliştiricilerin AMQP 1.0 aracılığıyla Azure Service Bus ile etkileşim kurabilmesidir.

Apache Qpid Proton veya AMQP.NET Lite gibi genel amaçlı AMQP 1.0 yığınları, oturumlar veya bağlantılar gibi tüm temel AMQP 1.0 protokol öğelerini uygular. Bu temel öğeler bazen daha üst düzey bir API ile sarmalanmıştır; Apache Proton, kesinlik temelli Messenger API'sini ve reaktif Reactor API'sini bile sunar.

Aşağıdaki tartışmada AMQP bağlantılarının, oturumlarının ve bağlantılarının yönetiminin ve çerçeve aktarımlarının ve akış denetiminin işlenmesinin ilgili yığın (Apache Proton-C gibi) tarafından işlendiğini ve uygulama geliştiricilerinin belirli bir dikkati olması durumunda çok fazla işlem gerektirmediğini varsayıyoruz. Bağlantı kurma ve bir tür gönderen ve alıcı soyutlama nesnesi oluşturma gibi birkaç API temel öğesinin var olduğunu ve ardından sırasıyla bazı şekil send() ve receive() işlemlere sahip olduğunu varsayıyoruz.

Azure Service Bus'ın iletiye göz atma veya oturumların yönetimi gibi gelişmiş özellikleri tartışılırken, bu özellikler AMQP terimleriyle açıklansa da, bu varsayılan API soyutlaması üzerine katmanlı bir sahte uygulama olarak da açıklanır.

AMQP nedir?

AMQP bir çerçeveleme ve aktarım protokolüdür. Çerçeveleme, ağ bağlantısının her iki yönünde de akan ikili veri akışları için yapı sağladığı anlamına gelir. Yapı, bağlı taraflar arasında değiş tokuş için çerçeve adı verilen ayrı veri blokları için çizgileme sağlar. Aktarım özellikleri, her iki iletişimci tarafın çerçevelerin ne zaman aktarılacağı ve aktarımların ne zaman tamamlandığının ortak bir anlayışa sahip olmasını sağlar.

AmQP çalışma grubunun hala birkaç ileti aracısı tarafından kullanılmakta olan daha önceki taslak sürümlerinin aksine, çalışma grubunun son ve standart AMQP 1.0 protokolü, ileti aracısı veya ileti aracısı içindeki varlıklar için belirli bir topolojinin varlığını yazmaz.

Protokol, Azure Service Bus'ın yaptığı gibi kuyrukları destekleyen ve varlıkları yayımlayan/abone olan ileti aracılarıyla etkileşim için simetrik eşler arası iletişim için kullanılabilir. Azure Event Hubs'ta olduğu gibi, etkileşim desenlerinin normal kuyruklardan farklı olduğu mesajlaşma altyapısıyla etkileşim için de kullanılabilir. Olay hub'ı, olaylar ona gönderildiğinde kuyruk gibi davranır, ancak olaylar okunduğunda daha çok seri depolama hizmeti gibi davranır; bir bant sürücüsüne benzer. İstemci, kullanılabilir veri akışına bir uzaklık seçer ve ardından bu uzaklıktan en son kullanılabilir duruma kadar tüm olaylara sunulur.

AMQP 1.0 protokolü, özelliklerini geliştirmek için daha fazla belirtim sağlayarak genişletilebilir olacak şekilde tasarlanmıştır. Bu belgede açıklanan üç uzantı belirtimi bunu göstermektedir. Mevcut HTTPS/WebSockets altyapısı üzerinden iletişim için yerel AMQP TCP bağlantı noktalarını yapılandırmak zor olabilir. Bağlama belirtimi, AMQP'nin WebSockets üzerinden nasıl katman yapılacağını tanımlar. Yönetim amacıyla veya gelişmiş işlevsellik sağlamak amacıyla mesajlaşma altyapısıyla istek/yanıt biçiminde etkileşime geçmek için AMQP yönetim belirtimi gerekli temel etkileşim temel öğelerini tanımlar. Federasyon yetkilendirme modeli tümleştirmesi için AMQP talep tabanlı güvenlik belirtimi, bağlantılarla ilişkili yetkilendirme belirteçlerinin nasıl ilişkilendirilip yenilendiğini tanımlar.

Temel AMQP senaryoları

Bu bölümde bağlantılar, oturumlar ve bağlantılar oluşturma ve kuyruklar, konular ve abonelikler gibi Service Bus varlıklarına ileti aktarma dahil olmak üzere Azure Service Bus ile AMQP 1.0'ın temel kullanımı açıklanmaktadır.

AMQP'nin nasıl çalıştığı hakkında bilgi edinmek için en yetkili kaynak AMQP 1.0 belirtimidir, ancak belirtim, protokolü öğretmek için değil tam olarak uygulamaya kılavuzluk etmek için yazılmıştır. Bu bölüm, Service Bus'ın AMQP 1.0'ı nasıl kullandığını açıklamaya yönelik olarak gerektiği kadar terminolojinin tanıtılması üzerinde durmaktadır. AMQP'ye daha kapsamlı bir giriş yapmak ve AMQP 1.0 hakkında daha geniş bir tartışma için bu video kursunu gözden geçirin.

Bağlantılar ve oturumlar

AMQP, iletişim programları kapsayıcılarını çağırır; bunlar, bu kapsayıcıların içindeki iletişim varlıkları olan düğümleri içerir. Kuyruk böyle bir düğüm olabilir. AMQP çoğullama sağlar, bu nedenle düğümler arasındaki birçok iletişim yolu için tek bir bağlantı kullanılabilir; örneğin, bir uygulama istemcisi eşzamanlı olarak bir kuyruktan alabilir ve aynı ağ bağlantısı üzerinden başka bir kuyruğa gönderebilir.

Bu nedenle ağ bağlantısı kapsayıcıya sabitlenmiştir. İstemci rolündeki kapsayıcı tarafından başlatılır ve gelen TCP bağlantılarını dinleyen ve kabul eden alıcı rolündeki bir kapsayıcıya giden TCP yuva bağlantısı kurar. Bağlantı el sıkışması, protokol sürümünü belirlemeyi, Aktarım Düzeyi Güvenliği (TLS)/Güvenli Yuva Katmanı (SSL) kullanımını bildirmeyi veya görüşmeyi ve SASL'yi temel alan bağlantı kapsamında kimlik doğrulama/yetkilendirme el sıkışmasını içerir.

Azure Service Bus veya Azure Event Hubs, TLS'nin her zaman kullanılmasını gerektirir. 5671 numaralı TCP bağlantı noktası üzerinden bağlantıları destekler; bunun sonucunda TCP bağlantısı, AMQP protokolü el sıkışmasına girmeden önce TLS ile ilk kez ele geçirilir ve ayrıca sunucunun AMQP tarafından belirtilen modeli kullanarak TLS'ye hemen zorunlu bir bağlantı yükseltmesi sunduğu TCP bağlantı noktası 5672 üzerinden bağlantıları destekler. AMQP WebSockets bağlaması, 443 numaralı TCP bağlantı noktası üzerinden AMQP 5671 bağlantılarına eşdeğer bir tünel oluşturur.

Service Bus, bağlantıyı ve TLS'yi ayarladıktan sonra iki SASL mekanizması seçeneği sunar:

• SASL PLAIN, kullanıcı adı ve parola kimlik bilgilerini bir sunucuya geçirmek için yaygın olarak kullanılır. Service Bus'ın hesapları yoktur, ancak paylaşılan erişim güvenliği kuralları olarak adlandırılır . Bu kurallar, hakları bir anahtarla ilişkilendirilir. Bir kuralın adı kullanıcı adı olarak kullanılır ve anahtar (base64 kodlanmış metin olarak) parola olarak kullanılır. Seçilen kuralla ilişkili haklar, bağlantıda izin verilen işlemleri yönetir.
• SASL ANONIM, istemci daha sonra açıklanan talep tabanlı güvenlik (CBS) modelini kullanmak istediğinde SASL yetkilendirmesini atlamak için kullanılır. Bu seçenekle, istemcinin yalnızca CBS uç noktasıyla etkileşim kurabildiği ve CBS el sıkışmasının tamamlanması gereken kısa bir süre için anonim olarak bir istemci bağlantısı kurulabilir.

Aktarım bağlantısı kurulduktan sonra kapsayıcıların her biri işlemek istedikleri maksimum çerçeve boyutunu bildirir ve boşta kalma zaman aşımından sonra bağlantıda etkinlik yoksa tek taraflı olarak bağlantıyı keserler.

Ayrıca kaç eşzamanlı kanalın desteklendiği bildirilir. Kanal, bağlantının üzerindeki tek yönlü, giden, sanal aktarım yoludur. Oturum, birbirine bağlı kapsayıcıların her birinden bir kanal alarak çift yönlü bir iletişim yolu oluşturur.

Oturumların pencere tabanlı akış denetim modeli vardır; bir oturum oluşturulduğunda, her taraf alma penceresine kabul etmek istediği çerçeve sayısını bildirir. Taraflar çerçeveleri değiştirirken, aktarılan çerçeveler bu pencereyi doldurur ve aktarımlar, pencere dolduğunda ve akış performansı kullanılarak pencere sıfırlanana veya genişletilene kadar durur (performans, iki taraf arasında değiştirilen protokol düzeyi hareketlerin AMQP terimidir).

Bu pencere tabanlı model, pencere tabanlı akış denetiminin TCP kavramına yaklaşık olarak benzerdir, ancak yuvanın içindeki oturum düzeyindedir. Protokolün birden çok eşzamanlı oturuma izin verme kavramı, yüksek öncelikli trafiğin otoyol express lane'de olduğu gibi kısıtlanmış normal trafikten sonra aceleye getirilebilmesi için mevcuttur.

Azure Service Bus şu anda her bağlantı için tam olarak bir oturum kullanıyor. Service Bus standart için en büyük çerçeve boyutu 262.144 bayttır (256-K bayt). Service Bus Premium ve Event Hubs için 1048576 (100 MB). Service Bus, belirli bir oturum düzeyinde azaltma penceresi uygulamaz, ancak bağlantı düzeyi akış denetiminin bir parçası olarak pencereyi düzenli olarak sıfırlar (sonraki bölüme bakın).

Bağlantılar, kanallar ve oturumlar kısa ömürlü olur. Temel alınan bağlantı daraltılırsa bağlantılar, TLS tüneli, SASL yetkilendirme bağlamı ve oturumların yeniden kurulması gerekir.

AMQP giden bağlantı noktası gereksinimleri

TCP üzerinden AMQP bağlantıları kullanan istemciler, yerel güvenlik duvarında 5671 ve 5672 numaralı bağlantı noktalarının açılmasını gerektirir. Bu bağlantı noktalarıyla birlikte, EnableLinkRedirect özelliği etkinse ek bağlantı noktalarının açılması gerekebilir. EnableLinkRedirect , iletileri alırken tek atlama atlamayı ve dolayısıyla aktarım hızını artırmaya yardımcı olan yeni bir mesajlaşma özelliğidir. İstemci, aşağıdaki görüntüde gösterildiği gibi 104XX bağlantı noktası aralığı üzerinden arka uç hizmetiyle doğrudan iletişim kurmaya başlar.

Bu bağlantı noktaları güvenlik duvarı tarafından engellenirse bir .NET istemcisi SocketException ("Erişim izinleri tarafından yasak bir şekilde bir yuvaya erişim girişiminde bulunuldu") başarısız olabilir. Özellik, istemcileri 5671 numaralı bağlantı noktası üzerinden uzak hizmetle iletişim kurmaya zorlayan bağlantı dizesi ayarıyla EnableAmqpLinkRedirect=false devre dışı bırakılabilir.

AMQP WebSocket bağlaması , WEBSocket aktarımı üzerinden AMQP bağlantısına tünel oluşturmak için bir mekanizma sağlar. Bu bağlama, 443 numaralı TCP bağlantı noktası üzerinden AMQP 5671 bağlantılarına eşdeğer bir tünel oluşturur. 5671, 5672 numaralı bağlantı noktaları üzerinden TCP bağlantılarını engelleyen ancak bağlantı noktası 443 (https) üzerinden TCP bağlantılarına izin veren bir güvenlik duvarının arkasındaysanız AMQP WebSockets kullanın.

Bağlantılar

AMQP, iletileri bağlantılar üzerinden aktarır. Bağlantı, bir oturum üzerinden oluşturulan ve iletilerin tek yönde aktarılmasını sağlayan bir iletişim yoludur; transfer durumu anlaşması, bağlı taraflar arasındaki bağlantı ve çift yönlü üzerinden yapılır.

Bağlantılar herhangi bir zamanda ve mevcut bir oturum üzerinden kapsayıcı tarafından oluşturulabilir ve bu da AMQP'nin HTTP ve MQTT gibi diğer birçok protokolden farklı olmasını sağlar. Burada aktarımların ve aktarım yolunun başlatılması, yuva bağlantısını oluşturan tarafın özel bir ayrıcalığıdır.

Bağlantı başlatan kapsayıcı, karşı kapsayıcıdan bir bağlantıyı kabul etmelerini ister ve gönderen veya alıcı rolü seçer. Bu nedenle, kapsayıcılardan biri tek yönlü veya çift yönlü iletişim yolları oluşturmaya başlayabilir ve ikincisi bağlantı çiftleri olarak modellenmiştir.

Bağlantılar adlandırılır ve düğümlerle ilişkilendirilir. Başlangıçta belirtildiği gibi, düğümler kapsayıcı içindeki iletişim varlıklarıdır.

Service Bus'ta düğüm, bir kuyruk, konu, abonelik veya bir kuyruk veya aboneliğin yeniden yazma alt sırasına doğrudan eşdeğerdir. Bu nedenle AMQP'de kullanılan düğüm adı, Service Bus ad alanının içindeki varlığın göreli adıdır. Bir kuyruk olarak adlandırılırsa myqueue, bu aynı zamanda AMQP düğüm adıdır. Konu aboneliği, "abonelikler" kaynak koleksiyonuna sıralanarak HTTP API kuralını izler ve bu nedenle, mytopic konusunda bir abonelik alt öğesinin AMQP düğüm adı mytopic/subscriptions/sub olur.

Bağlantı oluşturmak için yerel düğüm adı kullanmak için de bağlanan istemci gereklidir; Service Bus bu düğüm adları hakkında açıklayıcı değildir ve bunları yorumlamaz. AMQP 1.0 istemci yığınları genellikle bu kısa ömürlü düğüm adlarının istemci kapsamında benzersiz olmasını sağlamak için bir düzen kullanır.

Transferler

Bağlantı kurulduktan sonra iletiler bu bağlantı üzerinden aktarılabilir. AMQP'de, bir iletinin gönderenden alıcıya bir bağlantı üzerinden taşınmasına neden olan açık bir protokol hareketi ( aktarım performansı) ile aktarım yürütülür. Aktarım "kararlaştırılmış" olduğunda tamamlanır, yani her iki taraf da bu aktarımın sonucunu ortak bir şekilde anlamış olur.

En basit durumda, gönderen "önceden hazır" iletiler göndermeyi seçebilir, yani istemci sonuçla ilgilenmez ve alıcı işlemin sonucu hakkında herhangi bir geri bildirim sağlamaz. Bu mod, Service Bus tarafından AMQP protokol düzeyinde desteklenir, ancak istemci API'lerinin hiçbirinde gösterilmez.

Normal durum, iletilerin gönderilmemiş olarak gönderilmesidir ve alıcı daha sonra edat performansını kullanarak kabul veya reddetmeyi gösterir. Reddetme, alıcı herhangi bir nedenle iletiyi kabul edemediğinde ve reddetme iletisi neden hakkında bilgi içerdiğinde oluşur ve amqp tarafından tanımlanan bir hata yapısıdır. Service Bus içindeki iç hatalar nedeniyle iletiler reddedilirse, hizmet bu yapı içinde destek isteklerinde bulunuyorsanız destek personeline tanılama ipuçları sağlamak için kullanılabilecek ek bilgiler döndürür. Hatalar hakkında daha fazla ayrıntıyı daha sonra öğreneceksiniz.

Özel bir reddedilme biçimi, alıcının aktarıma teknik bir itirazı olmadığını, aynı zamanda aktarımı düzenlemekle de ilgilenmediğini gösteren serbest bırakılan durumdur. Bu durum, örneğin bir ileti Service Bus istemcisine teslim edildiğinde ve istemci iletinin işlenmesinden kaynaklanan işi gerçekleştiremediğinden iletiyi "bırakmayı" seçtiğinde vardır; ileti tesliminin kendisi hatalı değildir. Bu durumun bir varyasyonu, ileti yayımlandıkçe iletide değişiklik yapılmasını sağlayan değiştirilmiş durumdur. Bu durum şu anda Service Bus tarafından kullanılmaz.

AMQP 1.0 belirtimi, özellikle bağlantı kurtarmayı işlemeye yardımcı olan alınan adlı başka bir değerlendirme durumu tanımlar. Bağlantı kurtarma, önceki bağlantı ve oturum kaybolduğunda yeni bir bağlantı ve oturumun üzerinde bağlantının durumunu ve bekleyen teslimleri yeniden oluşturmayı sağlar.

Service Bus bağlantı kurtarmayı desteklemez; İstemci, service Bus bağlantısını beklemede olan bir ileti aktarımı beklemedeyken kaybederse, bu ileti aktarımı kaybolur ve istemcinin yeniden bağlanması, bağlantıyı yeniden kurması ve aktarımı yeniden denemesi gerekir.

Bu nedenle Service Bus ve Event Hubs, gönderenin iletinin depolandığından ve kabul ettiğinden emin olabileceği ancak amqp düzeyinde "tam olarak bir kez" aktarımları destekleyebileceği ve sistemin bağlantıyı kurtarmaya çalışacağı ve ileti aktarımının yinelenmemesi için teslim durumu konusunda anlaşmaya devam ettiği "en az bir kez" aktarımı destekler.

Olası yinelenen göndermeleri telafi etmek için Service Bus, kuyruklarda ve konu başlıklarında isteğe bağlı bir özellik olarak yinelenenleri algılamayı destekler. Yinelenen algılama, kullanıcı tanımlı bir zaman penceresi sırasında tüm gelen iletilerin ileti kimliklerini kaydeder, ardından aynı pencere sırasında aynı ileti kimlikleriyle gönderilen tüm iletileri sessizce bırakır.

Akış denetimi

Daha önce açıklanan oturum düzeyinde akış denetimi modeline ek olarak, her bağlantının kendi akış denetim modeli vardır. Oturum düzeyinde akış denetimi kapsayıcıyı aynı anda çok fazla kareyi işlemek zorunda kalmadan korur. Bağlantı düzeyinde akış denetimi, uygulamayı bir bağlantıdan ve ne zaman işlemek istediği iletilerden sorumlu duruma getirir.

Bir bağlantıda aktarımlar yalnızca gönderenin yeterli bağlantı kredisi olduğunda gerçekleşebilir. Bağlantı kredisi, alıcı tarafından akış performansı kullanılarak ayarlanan ve kapsamı bir bağlantı olarak belirlenmiş bir sayaçtır. Gönderene bağlantı kredisi atandığında, iletileri teslim ederek bu krediyi kullanmaya çalışır. Her ileti teslimi, kalan bağlantı kredisini 1'e kadar geriler. Bağlantı kredisi kullanıldığında teslimatlar durur.

Service Bus alıcı rolüne geldiğinde, iletilerin hemen gönderilebilmesi için gönderene anında bol bağlantı kredisi sağlar. Bağlantı kredisi kullanıldığında, Service Bus bazen bağlantı kredisi bakiyesini güncelleştirmek için gönderene performans gösteren bir akış gönderir.

Gönderen rolünde Service Bus, kalan tüm bağlantı kredilerini kullanmak için iletiler gönderir.

API düzeyinde bir "alma" çağrısı, istemci tarafından Service Bus'a gönderilen bir akış performansına dönüşür ve Service Bus bu krediyi kuyruktan ilk kullanılabilir, kilidi açılmış iletiyi alarak, kilitleyerek ve aktararak kullanır. Teslim için hazır bir ileti yoksa, söz konusu varlıkla kurulan herhangi bir bağlantının bekleyen kredisi, varma sırasında kaydedilir ve iletiler kullanılabilir duruma geldikçe kilitlenir ve aktarılır.

İletideki kilit, aktarım kabul edilen, reddedilen veya serbest bırakılan terminal durumlarından birine yerleştiği zaman serbest bırakılır. Terminal durumu kabul edildiğinde ileti Service Bus'tan kaldırılır. Service Bus'ta kalır ve aktarım diğer eyaletlerden herhangi birine ulaştığında sonraki alıcıya teslim edilir. Service Bus, yinelenen reddetmeler veya sürümler nedeniyle varlık için izin verilen teslim sayısı üst sınırına ulaştığında iletiyi otomatik olarak varlığın yeniden kullanım kuyruğuna taşır.

Service Bus API'leri bugün böyle bir seçeneği doğrudan kullanıma sunmasa da, alt düzey bir AMQP protokol istemcisi, çok sayıda bağlantı kredisi vererek her alma isteği için bir birim kredi vermenin "çekme stili" etkileşimini "çekme stilinde" bir modele dönüştürmek için bağlantı kredisi modelini kullanabilir ve daha fazla etkileşim olmadan kullanılabilir hale geldikçe iletileri alabilir. Gönderme, ServiceBusProcessor.PrefetchCount veya ServiceBusReceiver.PrefetchCount özellik ayarları aracılığıyla desteklenir. Sıfır olmayan AMQP istemcisi bunu bağlantı kredisi olarak kullanır.

Bu bağlamda, varlığın içindeki iletideki kilidin süre sonu saatinin ileti ileti kabloya yerleştirildiğinde değil, varlıktan alındığında başladığını anlamak önemlidir. İstemci, bağlantı kredisi vererek ileti almaya hazır olduğunu gösterdiğinde, bu nedenle iletileri ağ üzerinden etkin bir şekilde çekmesi ve bunları işlemeye hazır olması beklenir. Aksi takdirde ileti teslim edilene kadar ileti kilidinin süresi dolmuş olabilir. Bağlantı kredisi akış denetiminin kullanımı doğrudan alıcıya gönderilen kullanılabilir iletilerle ilgilenmeye hazır olma durumunu yansıtmalıdır.

Özetle, aşağıdaki bölümler farklı API etkileşimleri sırasında gerçekleştirdiği akışa şematik bir genel bakış sağlar. Her bölümde farklı bir mantıksal işlem açıklanır. Bu etkileşimlerden bazıları "gecikmeli" olabilir, yani bunlar yalnızca gerektiğinde gerçekleştirilebilir. İleti göndereni oluşturmak, ilk ileti gönderilene veya istenene kadar ağ etkileşimlerine neden olmayabilir.

Aşağıdaki tablodaki oklar, performans akış yönünü gösterir.

İleti alıcısı oluşturma

İstemci	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={entity name},<br/>target={client link ID}<br/>)	İstemci, varlığa alıcı olarak ekler
Service Bus, bağlantının sonunu ekliyor	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={entity name},<br/>target={client link ID}<br/>)

İleti göndereni oluşturma

İstemci	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	Eylem yok
Eylem yok	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={client link ID},<br/>target={entity name}<br/>)

İleti göndereni oluşturma (hata)

İstemci	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	Eylem yok
Eylem yok	<-- 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/>)

İleti alıcısı/göndereni kapatma

İstemci	Service Bus
--> detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)	Eylem yok
Eylem yok	<-- detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)

Gönder (başarılı)

İstemci	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/>)	Eylem yok
Eylem yok	<-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**accepted**<br/>)

Gönder (hata)

İstemci	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/>)	Eylem yok
Eylem yok	<-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**rejected**(<br/>error={error info}<br/>)<br/>)

Al

İstemci	Service Bus
--> flow(<br/>link-credit=1<br/>)	Eylem yok
Eylem yok	< 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/>)	Eylem yok

Çok iletili alma

İstemci	Service Bus
--> flow(<br/>link-credit=3<br/>)	Eylem yok
Eylem yok	< transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
Eylem yok	< 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/>)
Eylem yok	< 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/>)	Eylem yok

İletiler

Aşağıdaki bölümlerde, standart AMQP ileti bölümlerinden hangi özelliklerin Service Bus tarafından kullanıldığı ve Service Bus API kümesiyle nasıl eşlendiği açıklanmaktadır.

Uygulamanın tanımlaması gereken tüm özellikler AMQP application-properties eşlemesine eşlenmelidir.

Üst bilgi

Alan Adı	Kullanım	API adı
dayanıklı	-	-
öncelik	-	-
ttl	Bu ileti için yaşam süresi	TimeToLive
ilk edinici	-	-
teslim sayısı	-	DeliveryCount

Properties

Alan Adı	Kullanım	API adı
message-id	Bu ileti için uygulama tanımlı, serbest biçimli tanımlayıcı. Yinelenen algılama için kullanılır.	MessageId
user-id	Uygulama tanımlı kullanıcı tanımlayıcısı, Service Bus tarafından yorumlanmaz.	Service Bus API'sine erişilemez.
to	Uygulama tanımlı hedef tanımlayıcısı, Service Bus tarafından yorumlanmaz.	İşlem
subject	Uygulama tanımlı ileti amacı tanımlayıcısı, Service Bus tarafından yorumlanmaz.	Konu
reply-to	Uygulama tanımlı yanıt yolu göstergesi, Service Bus tarafından yorumlanmaz.	Yanıtla
correlation-id	Uygulama tanımlı bağıntı tanımlayıcısı, Service Bus tarafından yorumlanmaz.	CorrelationId
content-type	Gövde için uygulama tanımlı içerik türü göstergesi, Service Bus tarafından yorumlanmaz.	ContentType
content-encoding	Gövde için uygulama tanımlı içerik kodlama göstergesi, Service Bus tarafından yorumlanmaz.	Service Bus API'sine erişilemez.
absolute-expiry-time	İletinin süresinin dolmasına ilişkin mutlak anında bildirir. Girişte yoksayılır (üst bilgi TTL gözlemlenir), çıkışta yetkilidir.	Service Bus API'sine erişilemez.
creation-time	İletinin oluşturulduğu zamanı bildirir. Service Bus tarafından kullanılmaz	Service Bus API'sine erişilemez.
group-id	İlgili bir ileti kümesi için uygulama tanımlı tanımlayıcı. Service Bus oturumları için kullanılır.	SessionId
group-sequence	Oturumun içindeki iletinin göreli sıra numarasını tanımlayan sayaç. Service Bus tarafından yoksayıldı.	Service Bus API'sine erişilemez.
reply-to-group-id	-	ReplyToSessionId

İleti ek açıklamaları

AMQP ileti özelliklerinin parçası olmayan ve iletide olduğu gibi MessageAnnotations geçirilen birkaç service bus ileti özelliği daha vardır.

Ek Açıklama Eşleme Anahtarı	Kullanım	API adı
x-opt-scheduled-enqueue-time	İletinin varlıkta ne zaman görüneceğini bildirir	ScheduledEnqueueTime
x-opt-partition-key	İletinin hangi bölüme inmesi gerektiğini belirten uygulama tanımlı anahtar.	PartitionKey
x-opt-via-partition-key	Bir işlem aktarım kuyruğu üzerinden ileti göndermek için kullanılacaksa uygulama tanımlı bölüm anahtarı değeri.	TransactionPartitionKey
x-opt-enqueued-time	İletinin gerçek sıralandığı saati temsil eden hizmet tanımlı UTC saati. Girişte yoksayıldı.	EnqueuedTime
x-opt-sequence-number	bir iletiye atanan hizmet tanımlı benzersiz numara.	SequenceNumber
x-opt-offset	İletinin hizmet tanımlı sıralı sıra numarası.	EnqueuedSequenceNumber
x-opt-locked-until	Hizmet tanımlı. İletinin kuyrukta/abonelikte kilitlendiği tarih ve saat.	LockedUntil
x-opt-deadletter-source	Hizmet Tanımlı. İleti teslim edilemeyen ileti kuyruğundan alınırsa, özgün iletinin kaynağını temsil eder.	DeadLetterSource

İşlem özelliği

Bir hareket, iki veya daha fazla işlemi tek bir yürütme kapsamında bir araya toplar. Doğası gereği, böyle bir işlem belirli bir işlem grubuna ait tüm işlemlerin birlikte başarılı veya başarısız olmasını sağlamalıdır. İşlemler bir tanımlayıcıya txn-idgöre gruplandırılır.

İşlem etkileşimi için istemci, birlikte gruplanması gereken işlemleri denetleyen bir transaction controller işlevi görür. Service Bus Hizmeti bir transactional resource işlevi görür ve tarafından transaction controlleristenen şekilde iş gerçekleştirir.

İstemci ve hizmet, istemcisi tarafından oluşturulan bir control link üzerinden iletişim kurar. declare ve discharge iletileri, denetim bağlantısı üzerinden denetleyici tarafından işlemleri sırasıyla ayırmak ve tamamlamak için gönderilir (bunlar işlemsel çalışmanın özetini temsil etmemektedir). Asıl gönderme/alma işlemi bu bağlantıda gerçekleştirilmiyor. İstenen her işlem işlemi açıkça istenen txn-id ile tanımlanır ve bu nedenle Bağlantı üzerindeki herhangi bir bağlantıda oluşabilir. Denetim bağlantısı, oluşturduğu boşaltılmamış işlemler varken kapatılırsa, bu tür tüm işlemler hemen geri alınır ve bunlar üzerinde daha fazla işlem çalışması gerçekleştirme girişimleri hataya neden olur. Denetim bağlantısındaki iletiler önceden kapatılmamalıdır.

İşlemleri başlatabilmek ve sonlandırabilmek için her bağlantının kendi denetim bağlantısını başlatması gerekir. Hizmet, olarak işlev gösteren özel bir coordinatorhedef tanımlar. İstemci/denetleyici bu hedefe bir denetim bağlantısı kurar. Denetim bağlantısı bir varlığın sınırının dışındadır, yani birden çok varlık için işlemleri başlatmak ve boşaltmak için aynı denetim bağlantısı kullanılabilir.

İşlem başlatma

İşlemsel çalışmaya başlamak için denetleyicinin koordinatörden bir txn-id alması gerekir. Bunu bir declare tür iletisi göndererek yapar. Bildirim başarılı olursa, koordinatör atanan txn-idöğesini taşıyan bir değerlendirme sonucuyla yanıt verir.

İstemci (Denetleyici)	Yön	Service Bus (Koordinatör)
attach( name={link name}, ... , role=sender, target=Koordinatör )	------>
	<------	attach( name={link name}, ... , target=Coordinator() )
transfer( delivery-id=0, ...) { AmqpValue (Declare())}	------>
	<------	disposition( first=0, last=0, state=Declared( txn-id={transaction ID} ))

İşlem boşaltma

Denetleyici, koordinatöre bir discharge ileti göndererek işlemsel çalışmayı sonlandırıyor. Denetleyici, boşaltma gövdesinde bayrağını ayarlayarak işlemsel çalışmayı işlemeyi fail veya geri almayı arzu ettiğini belirtir. Koordinatör boşaltmayı tamamlayamazsa, ileti bu sonuçla transaction-errorbirlikte reddedilir.

Not: fail=true bir işlemin geri alınmasına, fail=false ise İşleme'ye başvurur.

İstemci (Denetleyici)	Yön	Service Bus (Koordinatör)
transfer( delivery-id=0, ...) { AmqpValue (Declare())}	------>
	<------	disposition( first=0, last=0, state=Declared( txn-id={transaction ID} ))
	. . . İşlemsel çalışma diğer bağlantılarda . . .
transfer( delivery-id=57, ...) { AmqpValue ( Deşarj(txn-id=0, fail=false))}	------>
	<------	disposition( first=57, last=57, state=Accepted())

bir işlemde ileti gönderme

Tüm işlemsel işler, txn-id değerini taşıyan işlemsel teslim durumuyla transactional-state gerçekleştirilir. İletiler gönderilirken, işlem durumu iletinin aktarım çerçevesi tarafından taşınır.

İstemci (Denetleyici)	Yön	Service Bus (Koordinatör)
transfer( delivery-id=0, ...) { AmqpValue (Declare())}	------>
	<------	disposition( first=0, last=0, state=Declared( txn-id={transaction ID} ))
transfer( handle=1, delivery-id=1, state= TransactionalState( txn-id=0)) { payload }	------>
	<------	disposition( first=1, last=1, state=TransactionalState( txn-id=0, outcome=Accepted()))

İletiyi bir işlemde yok etme

İleti bırakma işlemi gibi CompleteDeadLetterDefer / Abandon / / işlemleri içerir. Bu işlemleri bir işlem içinde gerçekleştirmek için, öğesini edat ile geçirin transactional-state .

İstemci (Denetleyici)	Yön	Service Bus (Koordinatör)
transfer( delivery-id=0, ...) { AmqpValue (Declare())}	------>
	<------	disposition( first=0, last=0, state=Declared( txn-id={transaction ID} ))
	<------	transfer( handle=2, delivery-id=11, state=null) { payload }
disposition( first=11, last=11, state=TransactionalState( txn-id=0, outcome=Accepted()))	------>

Gelişmiş Service Bus özellikleri

Bu bölüm, Azure Service Bus'ın şu anda AMQP için OASIS Teknik Komitesi'nde geliştirilmekte olan AMQP'ye yönelik taslak uzantıları temel alan gelişmiş özelliklerini kapsar. Service Bus, bu taslakların en son sürümlerini uygular ve bu taslaklar standart duruma ulaştığında ortaya çıkan değişiklikleri benimser.

Not

Service Bus Mesajlaşması gelişmiş işlemleri bir istek/yanıt düzeni aracılığıyla desteklenir. Bu işlemlerin ayrıntıları Service Bus: istek-yanıt tabanlı işlemler'de AMQP 1.0 makalesinde açıklanmıştır.

AMQP yönetimi

AMQP yönetim belirtimi, bu makalede ele alınan taslak uzantıların ilkidir. Bu belirtim, AMQP üzerinden mesajlaşma altyapısıyla yönetim etkileşimlerine izin veren AMQP protokolünün üzerine katmanlı bir protokol kümesi tanımlar. Belirtim, bir mesajlaşma altyapısı ve bir dizi sorgu işlemi içindeki varlıkları yönetmek için oluşturma, okuma, güncelleştirme ve silme gibi genel işlemleri tanımlar.

Tüm bu hareketler, istemci ile mesajlaşma altyapısı arasında istek/yanıt etkileşimi gerektirir ve bu nedenle belirtim, AMQP'nin üzerinde bu etkileşim deseninin nasıl modellendiğini tanımlar: istemci mesajlaşma altyapısına bağlanır, bir oturum başlatır ve ardından bir bağlantı çifti oluşturur. Bir bağlantıda, istemci gönderen ve diğerinde alıcı gibi davranarak çift yönlü kanal işlevi görebilen bir bağlantı çifti oluşturur.

Mantıksal İşlem	İstemci	Service Bus
İstek Yanıt Yolu Oluştur	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=**null**,<br/>target=”myentity/$management”<br/>)	Eylem yok
İstek Yanıt Yolu Oluştur	Eylem yok	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=null,<br/>target=”myentity”<br/>)
İstek Yanıt Yolu Oluştur	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=”myentity/$management”,<br/>target=”myclient$id”<br/>)
İstek Yanıt Yolu Oluştur	Eylem yok	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=”myentity”,<br/>target=”myclient$id”<br/>)

Bu bağlantı çiftinin yerinde olması, istek/yanıt uygulaması basittir: İstek, mesajlaşma altyapısı içindeki bir varlığa gönderilen ve bu düzeni anlayan bir iletidir. Bu istek iletisinde, özellikler bölümündeki yanıtla alanı, yanıtın gönderildiği bağlantının hedef tanımlayıcısına ayarlanır. İşleme varlığı isteği işler ve ardından hedef tanımlayıcısı belirtilen yanıt tanımlayıcısı ile eşleşen bağlantı üzerinden yanıtı teslim eder.

Desen, yanıt hedefi için istemci kapsayıcısının ve istemci tarafından oluşturulan tanımlayıcının tüm istemciler arasında benzersiz olmasını ve güvenlik nedenleriyle tahminde de zor olmasını gerektirir.

Yönetim protokolü ve aynı deseni kullanan diğer tüm protokoller için kullanılan ileti değişimleri uygulama düzeyinde gerçekleşir; yeni AMQP protokol düzeyi hareketleri tanımlamaz. Bu, uygulamaların uyumlu AMQP 1.0 yığınlarıyla bu uzantılardan hemen yararlanabilmesi için kasıtlı olarak kullanılır.

Service Bus şu anda yönetim belirtiminin temel özelliklerinden hiçbirini uygulamaz, ancak yönetim belirtimi tarafından tanımlanan istek/yanıt deseni, talep tabanlı güvenlik özelliği ve aşağıdaki bölümlerde açıklanan gelişmiş özelliklerin neredeyse tümü için temeldir:

Talep tabanlı yetkilendirme

AMQP Talep Tabanlı Yetkilendirme (CBS) belirtimi taslağı, yönetim belirtimi isteği/yanıt deseni üzerinde oluşturulur ve AMQP ile federasyon güvenlik belirteçlerinin nasıl kullanılacağına yönelik genelleştirilmiş bir modeli açıklar.

Girişte ele alınan AMQP'nin varsayılan güvenlik modeli SASL'yi temel alır ve AMQP bağlantısı el sıkışmasıyla tümleştirilir. SASL'yi kullanmanın avantajı, SASL'yi resmi olarak kullanan herhangi bir protokolün yararlanabileceği bir dizi mekanizmanın tanımlandığı genişletilebilir bir model sağlamasıdır. Bu mekanizmalar arasında kullanıcı adlarının ve parolaların aktarımı için "PLAIN", TLS düzeyi güvenliğe bağlanmak için "EXTERNAL", açık kimlik doğrulaması/yetkilendirmenin yokluğunu ifade etmek için "ANONIM" ve kimlik doğrulaması ve/veya yetkilendirme kimlik bilgileri veya belirteçlerinin geçirilmesine izin veren çok çeşitli ek mekanizmalar bulunur.

AMQP'nin SASL tümleştirmesi iki dezavantaja sahiptir:

• Tüm kimlik bilgileri ve belirteçlerin kapsamı bağlantı kapsamındadır. Mesajlaşma altyapısı varlık bazında farklı erişim denetimi sağlamak isteyebilir; örneğin, bir belirtecin taşıyıcısının A kuyruğuna göndermesine izin verme ancak B kuyruğuna göndermemesi. Yetkilendirme bağlamı bağlantıda sabitlenmişken, tek bir bağlantı kullanmak ve yine de A kuyruğu ve B kuyruğu için farklı erişim belirteçleri kullanmak mümkün değildir.
• Erişim belirteçleri genellikle yalnızca sınırlı bir süre için geçerlidir. Bu geçerlilik, kullanıcının belirteçleri düzenli aralıklarla yeniden satın almasını gerektirir ve kullanıcının erişim izinleri değiştiyse belirteç verene yeni bir belirteç vermeyi reddetme fırsatı sağlar. AMQP bağlantıları uzun süre sürebilir. SASL modeli yalnızca bağlantı zamanında belirteç ayarlama şansı sağlar. Bu, mesajlaşma altyapısının belirtecin süresi dolduğunda istemcinin bağlantısını kesmesi veya arada erişim hakları iptal edilmiş olabilecek bir istemciyle sürekli iletişime izin verme riskini kabul etmesi gerektiği anlamına gelir.

Service Bus tarafından uygulanan AMQP CBS belirtimi, bu sorunların her ikisi için de zarif bir geçici çözüm sağlar: İstemcinin erişim belirteçlerini her düğümle ilişkilendirmesine ve ileti akışını kesintiye uğratmadan süresi dolmadan bu belirteçleri güncelleştirmesine olanak tanır.

CBS, mesajlaşma altyapısı tarafından sağlanacak $cbs adlı bir sanal yönetim düğümü tanımlar. Yönetim düğümü, mesajlaşma altyapısındaki diğer düğümler adına belirteçleri kabul eder.

Protokol hareketi, yönetim belirtimi tarafından tanımlanan bir istek/yanıt değişimidir. Bu, istemcinin $cbs düğümüyle bir bağlantı çifti oluşturup giden bağlantıda bir istek ilettiği ve ardından gelen bağlantıda yanıtı beklediği anlamına gelir.

İstek iletisi aşağıdaki uygulama özelliklerine sahiptir:

Anahtar	İsteğe bağlı	Değer Türü	Değer İçeriği
operation	Hayır	Dize	put-token
type	Hayır	Dize	Konulmakta olan belirtecin türü.
name	Hayır	Dize	Belirtecin geçerli olduğu "hedef kitle".
expiration	Yes	timestamp	Belirtecin süre sonu süresi.

name özelliği, belirtecin ilişkilendirileceği varlığı tanımlar. Service Bus'ta bu, kuyruğun veya konu başlığının/aboneliğin yoludur. type özelliği belirteç türünü tanımlar:

Belirteç Türü	Belirteç Açıklaması	Gövde Türü	Notlar
jwt	JSON Web Belirteci (JWT)	AMQP Değeri (dize)
servicebus.windows.net:sastoken	Service Bus SAS Belirteci	AMQP Değeri (dize)	-

Belirteçler konfederasyon hakları. Service Bus üç temel hak hakkında bilgi sahibidir: "Gönder", göndermeyi etkinleştirir, "Dinle" almayı etkinleştirir ve "Yönet" varlıkların manipülesini etkinleştirir. Service Bus SAS belirteçleri ad alanında veya varlıkta yapılandırılan kurallara başvurur ve bu kurallar haklarla yapılandırılır. Belirteci bu kuralla ilişkilendirilmiş anahtarla imzalamak, belirtecin ilgili hakları ifade eder. Put-token kullanan bir varlıkla ilişkilendirilmiş belirteç , bağlı istemcinin belirteç haklarına göre varlıkla etkileşim kurmasına izin verir. İstemcinin gönderen rolüne sahip olduğu bağlantı için "Gönder" hakkı gerekir; alıcı rolünü üstlenmek için "Dinleme" hakkı gerekir.

Yanıt iletisi aşağıdaki uygulama özellikleri değerlerine sahiptir

Anahtar	İsteğe bağlı	Değer Türü	Değer İçeriği
status-code	Hayır	int	HTTP yanıt kodu [RFC2616].
status-description	Yes	Dize	Durumun açıklaması.

İstemci, mesajlaşma altyapısındaki herhangi bir varlık için put-token'ı art arda çağırabilir. Belirteçlerin kapsamı geçerli istemciye göre belirlenmiştir ve geçerli bağlantıya sabitlenmiştir. Bu, bağlantı bırakıldığında sunucunun tutulan belirteçleri bırakması anlamına gelir.

Geçerli Service Bus uygulaması yalnızca "ANONIM" SASL yöntemiyle birlikte CBS'ye izin verir. SASL el sıkışmadan önce her zaman bir SSL/TLS bağlantısı bulunmalıdır.

Bu nedenle ANONIM mekanizması seçilen AMQP 1.0 istemcisi tarafından desteklenmelidir. Anonim erişim, ilk oturum oluşturma dahil olmak üzere ilk bağlantı el sıkışmasının Service Bus'ın bağlantıyı kimin oluşturduğunu bilmeden gerçekleştiği anlamına gelir.

Bağlantı ve oturum kurulduktan sonra, bağlantıları $cbs düğümüne eklemek ve put-token isteğini göndermek izin verilen tek işlemlerdir. Bağlantı kurulduktan sonra 20 saniye içinde bazı varlık düğümü için bir put-token isteği kullanılarak geçerli bir belirteç başarıyla ayarlanmalıdır, aksi takdirde bağlantı Service Bus tarafından tek taraflı olarak bırakılır.

İstemci daha sonra belirteç süre sonunu izlemekle sorumludur. Bir belirtecin süresi dolduğunda, Service Bus ilgili varlığa bağlantıdaki tüm bağlantıları derhal bırakır. Sorun oluşmasını önlemek için istemci, sanal $cbs yönetim düğümü aracılığıyla aynı put-token hareketine sahip ve farklı bağlantılarda akan yük trafiğinin önüne geçmeden düğümün belirtecini istediğiniz zaman yenisiyle değiştirebilir.

Gönderme yoluyla işlevi

Gönderme/ Göndereni aktarma, service bus'ın belirli bir iletiyi başka bir varlık üzerinden hedef varlığa iletmesine olanak tanıyan bir işlevdir. Bu özellik, varlıklar arasında tek bir işlemde işlem gerçekleştirmek için kullanılır.

Bu işlevsellikle, bir gönderen oluşturur ve bağlantısını via-entityoluşturursunuz. Bağlantı oluşturulurken, bu bağlantıdaki iletilerin/aktarımların gerçek hedefini oluşturmak için ek bilgiler geçirilir. Ekleme başarılı olduktan sonra, bu bağlantıda gönderilen tüm iletiler otomatik olarak varlık aracılığıyla hedef varlığa iletilir.

Not: Bu bağlantı oluşturulmadan önce hem via-entity hem de destination-entity için kimlik doğrulaması gerçekleştirilmelidir.

İstemci	Yön	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} )] )

Sonraki adımlar

AMQP hakkında daha fazla bilgi edinmek için bkz . Service Bus AMQP'ye genel bakış.