AMQP 1.0 عند ناقل خدمة Azure وإرشاد بروتوكول مراكز الأحداث

بروتوكول وضع قوائم انتظار الرسائل المتقدمة 1.0 عبارة عن بروتوكول تأطير ونقل قياسي لنقل الرسائل بين طرفين بشكل غير متزامن وآمن وموثوق به. وهو البروتوكول الأساسي من مراسلة ناقل خدمة Azure ومراكز أحداث Azure.

AMQP 1.0 هو نتيجة لتعاون الصناعة الواسعة التي جمعت بين البائعين الوسطاء، مثل Microsoft وRed Hat، مع مستخدمي رسائل الوسطاء مثل JP Morgan Chase الذي يمثل صناعة الخدمات المالية. منتدى التوحيد التقني لبروتوكول AMQP ومواصفات الملحق هو OASIS، وقد حقق موافقة رسمية كمعيار دولي مثل ISO / IEC 19494:2014.

الأهداف

تلخص هذه المقالة المفاهيم الأساسية لمواصفات المراسلة AMQP 1.0 عبر ملحق المواصفات الذي طورته اللجنة التقنية OASIS AMQP وتفسر كيف ينفذ ناقل خدمة Azure هذه المواصفات ويبني عليها.

إنّ هدف أي مطور يستخدم أي مكدس ذاكرة مؤقتة موجود AMQP 1.0 على أي نظام أساسي يتمثل في تمكين التفاعل مع ناقل خدمة Azure عبر AMQP 1.0.

تنفّذ مكدسات الذاكرة المؤقتة AMQP 1.0 ذات الهدف العام المشترك، مثل Apache Qpid ProtonأوAMQP.NETLiteتنفيذ جميع العناصر الأساسية لبروتوكول AMQP 1.0 مثل الجلسات أو الارتباطات. وتلتف هذه العناصر الأساسية أحيانًا بواجهة برمجة تطبيقات ذات مستوى أعلى، وتقدم Apache Proton حتى اثنين، ألا وهما مراسل برمجة التطبيقات الحتمي ومفاعل واجهة برمجة التطبيقات التفاعلي.

في المناقشة التالية، نفترض أن مكدس الذاكرة المؤقت المعني (مثل Apache Proton-C) يعالج إدارة اتصالات AMQP وجلساته، وارتباطاته ومعالجة عمليات نقل مع نقل الإطار والتحكم في التدفق ولا تتطلب الكثير من الاهتمام من مطوري التطبيقات. نحن نفترض بصورة مجردة وجود عدد قليل من بدائيات واجهة برمجة التطبيقات مثل القدرة على الاتصال، وتكوين شكل من أشكال عناصر تجريد المرسلوالمتلقي،التي تأخذ بعد ذلك بعض شكل send()receive() والعمليات، على التوالي.

عند مناقشة القدرات المتقدمة لناقل خدمة Azure مثل استعراض الرسائل أو إدارة الجلسات، يتم شرح هذه الميزات في بنود AMQP، لكن أيضًا كطبقات تطبيق زائف فوق هذا التجريد المفترض لواجهة برمجة التطبيقات.

ما هو AMQP؟

AMQP عبارة عن بروتوكول تأطير ونقل. يعني التأطير أنه يوفر بنية لتدفقات البيانات الثنائية التي تتدفق في أي اتجاه من شبكة الاتصال. يوفر الهيكل ترسيمًا لكتل البيانات المتميزة، التي تُسمى الإطارات، ليتم تبادلها بين الأطراف المتصلة. وتحرص قدرات النقل على أن يتمكن الطرفان المتواصلان من تكوين فهم مشترك بشأن وقت تنقل الأطر، ومتى تعتبر عمليات النقل كاملة.

على عكس إصدارات المسودة منتهية الصلاحية السابقة من مجموعة عمل AMQP التي لا تزال قيد الاستخدام من قبل عدد قليل من وسطاء الرسائل، لا يصف بروتوكول AMQP 1.0 النهائي والموحد لمجموعة العمل وجود وسيط رسائل أو أي طبولوجيا معينة للكيانات داخل وسيط الرسائل.

ويمكن استخدام البروتوكول للاتصال من نظير إلى نظير متماثل، وللتفاعل مع وسطاء الرسائل التي تدعم قوائم الانتظار ونشر/اشتراك الكيانات، كما يفعل ناقل خدمة Azure. كما يمكن استخدامه للتفاعل مع البنية التحتية للمراسلة بحيث تختلف أنماط التفاعل عن قوائم الانتظار العادية، كما هو الحال مع مراكز الأحداث Azure. يعمل مركز الأحداث بصفته قائمة انتظار عند إرسال الأحداث إليها، لكنه يعمل بشكل أشبه بخدمة تخزين تسلسلي عند قراءة الأحداث منه، ويشبه إلى حد ما محرك الأشرطة. ويختار العميل إزاحة في دفق البيانات المتوفرة ثم يتم تقديم كافة الأحداث من هذه الإزاحة إلى الإزاحة الأحدث المتوفرة.

تم تصميم بروتوكول AMQP 1.0 ليكون قابلاً للتوسيع، ما يتيح المزيد من المواصفات لتعزيز قدراته. توضح مواصفات الملحق الثلاث التي تمت مناقشتها في هذه الوثيقة. للاتصال عبر البنية الأساسية HTTPS/WebSockets الموجودة، قد يكون تكوين منافذ AMQP TCP الأصلية أمرا صعبا. تحدد مواصفات الربط كيفية تطبيق AMQP عبر WebSockets. للتفاعل مع البنية التحتية للمراسلة بطريقة الطلب/الاستجابة لأغراض الإدارة أو لتوفير وظائف متقدمة، تحدد مواصفات إدارة AMQP أساسيات التفاعل الأساسية المطلوبة. لتكامل نموذج التخويل المتحد، تعرف مواصفات الأمان المستندة إلى مطالبات AMQP كيفية إقران رموز التخويل المتميزة المقترنة بالارتباطات وتجديدها.

سيناريوهات AMQP الأساسية

يشرح هذا القسم الاستخدام الأساسي لـ AMQP 1.0 مع ناقل خدمة Azure، الذي يتضمن إنشاء اتصالات وجلسات وارتباطات، ونقل الرسائل من كيانات ناقل الخدمة وإليها، مثل قوائم الانتظار والمواضيع، والاشتراكات.

المصدر الأكثر موثوقية لمعرفة كيفية عمل AMQP هو مواصفات AMQP 1.0، ولكن تمت كتابة المواصفات لإرشاد التنفيذ بدقة وليس لتعليم البروتوكول. ويركز هذا القسم على إدخال المصطلحات بقدر ما يلزم لوصف كيفية استخدام ناقل الخدمة AMQP 1.0. وللحصول على مقدمة أكثر شمولاً عن AMQP، بالإضافة إلى مناقشة أوسع عن AMQP 1.0، يمكنك مراجعة دورة الفيديو التدريبية هذه.

الاتصالات والجلسات

يدعو AMQP حاوياتبرامج الاتصال تلك تحويالعقد، وهي عبارة عن كيانات التواصل داخل تلك الحاويات. ويمكن أن تكون قائمة الانتظار مثل عقدة. يسمح AMQP بالتعدد، بحيث يمكن استخدام اتصال واحد لمسارات اتصال عدة بين العقد، على سبيل المثال، يمكن أن يتلقى عميل تطبيقاً بشكل متزامن من قائمة انتظار واحدة وإرسالها إلى قائمة انتظار أخرى عبر شبكة الاتصال نفسها.

وبالتالي يتم إرساء شبكة الاتصال على الحاوية. يتم بدء التشغيل بواسطة الحاوية في دور العميل بإجراء اتصال مأخذ توصيل TCP يصدر إلى حاوية في دور المتلقي الذي يستمع إليها واتصالات TCP الواردة يقبلها. وتتضمن عملية مصافحة الاتصال التفاوض حول إصدار البروتوكول، والإعلان عن استخدام أمان مستوى النقل (TLS/SSL) أو التفاوض بشأنه، ومصافحة مصادقة/تخويل في نطاق الاتصال الذي يستند إلى SASL.

ويتطلب ناقل خدمة Azure أو مراكز أحداث Azure استخدام TLS في كافة الأوقات. وهو يدعم الاتصالات عبر منفذ TCP 5671، بحيث يتم أولاً تراكب اتصال TCP مع TLS قبل إدخال مصافحة بروتوكول AMQP، ويدعم أيضًا الاتصالات عبر منفذ TCP 5672 بحيث يقدم الملقم على الفور ترقية إلزامية للاتصال بـTLS باستخدام النموذج المحدد AMQP. وينشئ الربط WebSocket AMQP نفقًا عبر منفذ TCP 443 الذي يعادل بعد ذلك اتصالات AMQP 5671.

وبعد إعداد الاتصال وTLS، يوفر ناقل الخدمة خيارين لآلية SASL:

• يستخدم SASL PLAIN بشكل شائع لتمرير بيانات اعتماد اسم المستخدم وكلمة المرور إلى ملقم. لا يحوي ناقل الخدمة حسابات، ولكن يُسمى قواعد أمان الوصول المشترك، التي تمنح الحقوق وترتبط بمفتاح. ويتم استخدام اسم قاعدة كاسم المستخدم ويتم استخدام المفتاح (كنص ترميز base64) ككلمة المرور. تحكم الحقوق المقترنة بالقاعدة مختارة العمليات المسموح بها على الاتصال.
• يستخدم SASL ANONYMOUS لتجاوز التخويل SASL عندما يريد العميل استخدام نموذج الأمان المستند إلى المطالبات (CBS) الموضحة لاحقًا. مع هذا الخيار، يمكن تأسيس اتصال عميل مجهول لفترة قصيرة يمكن أن يتفاعل من خلالها العميل فحسب مع نقطة النهاية CBS وينبغي إكمال المصافحة CBS.

وبعد تأسيس اتصال النقل، تعلن الحاويات الحجم الأقصى للإطار الذي ترغب في معالجته، وبعد مهلة معطلة، تنفصل من طرف واحد إذا لم يكن هناك نشاط على الاتصال.

كما أنها تعلن عن عدد القنوات المتنافسة المدعومة. القناة عبارة عن مسار نقل ظاهري صادر أحادي الاتجاه، أعلى الاتصال. تأخذ جلسة قناة من كل من الحاويات المترابطة لتشكيل مسار اتصال ثنائي الاتجاه.

تحوي الجلسات نموذج تحكم تدفق يستند إلى الإطار، عند إنشاء جلسة، يعلن كل طرف عدد الإطارات التي يرغب في قبولها في إطار التلقي الخاص به. كما تتبادل الأطراف الأطر، وتملأ الإطارات المنقولة تلك النافذة وتتوقف التحويلات عندما تصبح النافذة ممتلئة وحتى يحصل على إعادة تعيين النافذة أو توسيعها باستخدام تدفق الأداء(الأداءهو مصطلح AMQP للإيماءات على مستوى البروتوكول المتبادلة بين الطرفين).

هذا النموذج المستند إلى الإطار مشابه تقريبًا لمفهوم TCP للتحكم في التدفق المستند إلى النافذة، لكن على مستوى الجلسة داخل مأخذ التوصيل. ويتوفر مفهوم بروتوكول السماح لجلسات متنافسة عدة لتتمكن نسبة استخدام الشبكة ذات الأولوية العليا من تقييد نسبة استخدام الشبكة العادية كالممر السريع على الطريق السريع.

ويستخدم ناقل خدمة Azure حاليًا جلسة واحدة لكل اتصال. خدمة ناقل الحد الأقصى لحجم الإطار هو 262.144 بايت (256 كيلو بايت) لناقل الخدمة القياسي. فيبلغ 1048576(100 ميجابايت) لخدمة ناقل الخدمة الممتازة ومراكز الأحداث. لا يفرض ناقل الخدمة أي نوافذ تقييد معينة على مستوى الجلسة، ولكنه يعيد تعيين النافذة بانتظام كجزء من التحكم في التدفق على مستوى الارتباط (راجع القسم التالي).

الاتصالات والقنوات والجلسات سريعة الزوال. إذا انطوى الاتصال الأساسي، ينبغي أن تتم إعادة تأسيس اتصالات ونفق TLS وسياق تخويل SASL وجلسات.

متطلبات المنفذ الصادر AMQP

يتطلب العملاء الذين يستخدمون اتصالات AMQP فتح منفذي TCP 5671 و5672 جدار الحماية المحلي. بالإضافة إلى هذه المنافذ، قد يكون من الضروري فتح منافذ إضافية إذا تم تمكين ميزةEnableLinkRedirect. EnableLinkRedirect هي ميزة مراسلة جديدة تساعد على تخطي وثبة واحدة أثناء تلقي الرسائل، ما يساعد على زيادة معدل النقل. وسيبدأ العميل بالاتصال مباشرة مع الخدمة الخلفية عبر نطاق المنفذ 104XX على النحو الظاهر في الصورة التالية.

قد يفشل عميل .NET مع SocketException ("تم إجراء محاولة للوصول إلى مأخذ توصيل بطريقة محظورة بواسطة أذونات الوصول الخاصة به") إذا تم حظر هذه المنافذ بواسطة جدار الحماية. ويمكن تعطيل الميزة عن طريق الإعداد EnableAmqpLinkRedirect=false في سلسلة الاتصال، ما يفرض على العملاء الاتصال بالخدمة البعيدة عبر المنفذ 5671.

يوفر ربط AMQP WebSocket آلية للاتصال النفقي باتصال AMQP عبر نقل WebSocket. ينشئ هذا الربط نفقا عبر منفذ TCP 443، وهو ما يعادل اتصالات AMQP 5671. استخدم AMQP WebSockets إذا كنت خلف جدار حماية يحظر اتصالات TCP عبر المنافذ 5671، 5672 ولكنه يسمح باتصالات TCP عبر المنفذ 443 (https).

الارتباطات

ينقل AMQP الرسائل عبر الارتباطات. الارتباط هو مسار اتصال تم إنشاؤه عبر جلسة تمكن من نقل الرسائل في اتجاه واحد؛ التفاوض على حالة النقل هو عبر الارتباط وثنائي الاتجاه بين الأطراف المتصلة.

ويمكن إنشاء الارتباطات بواسطة أي حاوية في أي وقت وعلى جلسة موجودة، ما يجعل AMQP مختلفًا عن بروتوكولات أخرى عدة، بما في ذلك HTTP وMQTT، بحيث يكون بدء النقل ومسار النقل امتيازًا حصريًا للطرف الذي ينشئ اتصال مأخذ التوصيل.

وتطلب الحاوية التي تبدأ بالارتباط من الحاوية المقابلة قبول ارتباط وتختار دورًا للمرسل أو المتلقي. لذلك، يمكن أن تبدأ الحاوية بإنشاء مسارات اتصال أحادية الاتجاه أو ثنائية الاتجاه، ويأتي هذا الأخير على شكل نموذج أزواج من الارتباطات.

يتم تسمية الارتباطات وإقرانها بالعقد. كما هو مذكور في البداية، العقد هي الكيانات المتصلة داخل حاوية.

وفي ناقل الخدمة، تكون عقدة مكافئ مباشرة إلى قائمة انتظار أو موضوع أو اشتراك أو قائمة انتظار فرعية ميتة لقائمة انتظار أو اشتراك. ولذلك، يكون اسم العقدة المستخدمة في AMQP الاسم النسبي للكيان داخل مساحة اسم ناقل الخدمة. إذا سميت قائمة انتظارmyqueue، ذلك الاسم هو أيضًا اسم عقدة AMQP. يتبع اشتراك موضوع اتفاقية واجهة برمجة التطبيقات HTTP من خلال فرزه إلى مجموعة موارد "الاشتراكات" وبالتالي، لدى فرع اشتراك حول موضوع mytopic اسم عقدة AMQP mytopic/الاشتراكات/الفرعية.

ويطلب أيضًا من عميل الاتصال استخدام اسم عقدة محلية لإنشاء ارتباطات؛ ناقل الخدمة غير إلزامي حول أسماء العقد هذه ولا يفسرها. وتستخدم مكدسات الذاكرة المؤقتة للعميل AMQP 1.0 بشكل عام نظامًا للتأكد من أن أسماء العقد المؤقتة هذه فريدة في نطاق العميل.

عمليات النقل

بمجرد إنشاء ارتباط، يمكن نقل الرسائل عبر هذا الارتباط. في AMQP، يتم تنفيذ عملية نقل مع إيماءة بروتوكول صريحة (نقل الأداء) الذي ينقل رسالة من المرسل إلى المتلقي عبر ارتباط. يكون نقل ما كاملًا عندما يكون ”مستقرًا“، ما يعني أن الطرفين أنشآ فهمًا مشتركًا لنتيجة هذا النقل.

في أسهل الحالات، يمكن للمرسل أن يرسل رسالة "مستقرة مسبقًا"، ما يعني أن العميل ليس مهتمًا بالنتيجة والمتلقي لا يوفر أي تعليقات بشأن نتيجة العملية. ويدعم ناقل الخدمة هذا الوضع على مستوى بروتوكول AMQP، لكن لا يتعرض لأي من واجهات برمجة تطبيقات العميل.

تتمثل الحالة العادية في إرسال رسائل غير مستقرة، ثم يشير المتلقي إلى القبول أو الرفض باستخدام أداء التصرف. ويحدث الرفض عندما لا يمكن قبول المتلقي للرسالة لأي سبب من الأسباب، وتحوي رسالة الرفض معلومات حول السبب، وهو البنية الخطأ التي يعرفها AMQP. إذا تم رفض الرسائل بسبب أخطاء داخلية داخل ناقل الخدمة، تُرجع الخدمة معلومات إضافية داخل تلك البنية يمكن استخدامها لتوفير تلميحات التشخيص لدعم الموظفين إذا كنت تملأ طلبات الدعم. يمكنك معرفة المزيد من التفاصيل حول الأخطاء لاحقًا.

يتمثل شكل خاص من أشكال الرفض في الحالةالتي تم إصدارها، ما يشير إلى أن المتلقي ليس لديه اعتراض تقني على النقل، لكن لديه أيضًا مصلحة في تسوية النقل. هذه الحالة موجودة، على سبيل المثال، عند تسليم رسالة إلى عميل ناقل خدمة، ويختار العميل "التخلي" عن الرسالة لأنه لا يمكن تنفيذ العمل الناتج عن معالجة الرسالة؛ تسليم الرسالة بحد ذاتها ليس خطأ. الاختلاف في تلك الحالة هو الحالة المعدلة، التي تسمح بإجراء تغييرات على الرسالة في أثناء إصدارها. ولا يستخدم ناقل الخدمة هذه الحالة في الوقت الحاضر.

تحدد مواصفات AMQP 1.0 حالة تصرف أخرى تُسمى تم تلقيها، تساعد على وجه التحديد على معالجة استرداد الارتباط. ويسمح استرداد الارتباط بإعادة تشكيل حالة الارتباط وأي عمليات تسليم معلقة أعلى اتصال جديد وجلسة جديدة، عندما يتم فقدان الاتصال وجلسة السابقين.

لا يدعم ناقل خدمة Microsoft Azure استرداد الارتباط؛ إذا فقد العميل الاتصال بناقل خدمة Microsoft Azure مع تعليق نقل الرسائل غير المستقرة، يتم فقدان نقل الرسالة هذا، ويجب على العميل إعادة الاتصال وإعادة إنشاء الارتباط وإعادة محاولة النقل.

على هذا النحو، يدعم ناقل الخدمة ومراكز الأحداث نقل "مرة واحدة على الأقل" بحيث يمكن أن يكون المرسل مطمئنًا من تخزين الرسالة، ولكن لا يدعم "مرة واحدة بالضبط" عمليات النقل على مستوى AMQP، حيث سيحاول النظام استرداد الارتباط والاستمرار في التفاوض على حالة التسليم لتجنب الازدواجية في نقل الرسالة.

للتعويض عن إرسال التكرارات المحتملة، يدعم ناقل الخدمة الكشف عن التكرارات كميزة اختيارية في قوائم الانتظار والمواضيع. الكشف عن التكرارات بتسجيل معرفات الرسالة لكافة الرسائل الواردة أثناء إطار زمني يعرفه المستخدم، ثم يسقط بصمت كافة الرسائل المرسلة مع معرفات الرسالة نفسها في أثناء الإطار نفسه.

التحكم بالتدفق

بالإضافة إلى نموذج التحكم في التدفق على مستوى الجلسة التي تمت مناقشتها مسبقًا، كل ارتباط له نموذج التحكم بالتدفق الخاص به. إنّ التحكم بالتدفق على مستوى الجلسة يحمي الحاوية من الاضطرار إلى معالجة إطارات كثيرة جدًا في وقت واحد، ويضع التحكم بالتدفق على مستوى الارتباط التطبيق مسؤولًا عن عدد الرسائل التي تريد التعامل معها من ارتباط الوقت.

على الارتباط، لا يمكن أن تحدث عمليات النقل إلا عندما يكون لدى المرسل رصيد ارتباطكافٍ. رصيد الارتباط هو عداد تم تعيينه بواسطة المتلقي باستخدام تدفق الأداء، يتم تحديد نطاقه إلى ارتباط. وعندما يتم تعيين رصيد ارتباط للمرسل، يحاول استخدام هذا الائتمان عن طريق تسليم الرسائل. كل تسليم رسالة يتناقص مع رصيد الارتباط المتبقي بمقدار 1. عند استخدام رصيد الارتباط، تتوقف عمليات التسليم.

وعندما يكون ناقل الخدمة في دور المتلقي، يزوّد المرسل على الفور برصيد ارتباط وافر، بحيث يمكن إرسال الرسائل فورًا. عندما يتم استخدام رصيد الارتباط، يرسل ناقل خدمة أحيانًا تدفق الأداء إلى المرسل لتحديث رصيد ائتمان الارتباط.

في دور المرسل، يرسل ناقل الخدمة رسائل لاستخدام أي رصيد ارتباط معلق.

ويترجم استدعاء "تلقي" على مستوى واجهة برمجة التطبيقات إلى تدفقالأداء الذي يرسله العميل إلى ناقل الخدمة ويستهلك ناقل خدمة هذا الائتمان عن طريق أخذ الرسالة المتوفرة الأولى غير المقفلة من قائمة الانتظار، وقفلها ونقلها. إذا لم تكن هناك رسالة متاحة بسهولة للتسليم، يظل أي رصيد من أي ارتباط تم إنشاؤه مع هذا الكيان المحدد مسجلاً حسب ترتيب الوصول، ويتم قفل الرسائل وتحويلها عند توفرها، لاستخدام أي رصيد معلق.

ويتم إصدار القفل عن رسالة عند تسوية النقل إلى إحدى الحالات الطرفية المقبولةأو المرفوضةأو الصادرة. تتم إزالة الرسالة من ناقل الخدمة عند قبول الحالة الطرفية. ويبقى في ناقل الخدمة ويتم تسليمها إلى المتلقي التالي عندما يصل النقل إلى أي من الحالات الأخرى. وينقل ناقل خدمة الرسالة تلقائيًا إلى قائمة انتظار الرسائل الميتة للكيان عندما يصل إلى الحد الأقصى لعدد التسليم المسموح به للكيان بسبب الرفض المتكرر أو الإصدارات.

على الرغم من أن واجهات برمجة تطبيقات ناقل الخدمة لا تعرض مثل هذا الخيار مباشرة اليوم، يمكن لعميل بروتوكول AMQP ذي المستوى الأدنى استخدام نموذج الارتباط والائتمان لتحويل التفاعل "أسلوب السحب" لإصدار وحدة ائتمان واحدة لكل طلب تلقي إلى نموذج "أسلوب الدفع" عن طريق إصدار عدد كبير من اعتمادات الارتباط، ثم تلقي الرسائل عند توفرها من دون أي تفاعل آخر. يتم دعم الدفع من خلال إعدادات خاصية ServiceBusProcessor.PrefetchCount أو ServiceBusReceiver.PrefetchCount . عندما لا تكون صفرًا، يستخدمها عميل AMQP كرصيد الارتباط.

في هذا السياق، من المهم أن نفهم أن الساعة لانتهاء صلاحية قفل الرسالة داخل الكيان تبدأ عند أخذ الرسالة من الكيان، وليس عند وضع الرسالة على السلك. وكلما يشير العميل إلى الاستعداد لتلقي الرسائل عن طريق إصدار رصيد ارتباط، من المتوقع إذًا أن يتم سحب الرسائل عبر الشبكة بشكل نشط وأن يكون مستعدًا للتعامل معها. وإلا فقد يكون تأمين الرسالة قد انتهت صلاحيته قبل تسليم الرسالة. وينبغي أن يعكس استخدام التحكم بالتدفق ارتباط الائتمان بشكل مباشر الاستعداد الفوري للتعامل مع الرسائل المتاحة المرسلة إلى المتلقي.

باختصار، توفر الأقسام التالية نظرة عامة تخطيطية لتدفق الأداء في أثناء تفاعلات واجهة برمجة التطبيقات المختلفة. ويصف كل قسم عملية منطقية مختلفة. قد تكون بعض هذه التفاعلات "كسولة"، مما يعني أنه قد يتم إجراؤها فقط عند الحاجة. قد لا يتسبب إنشاء مرسل رسالة في تفاعل الشبكة حتى يتم إرسال الرسالة الأولى أو طلبها.

وتظهر الأسهم في الجدول التالي اتجاه تدفق الأداء.

إنشاء متلقي الرسائل

العميل	ناقل الخدمة
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={entity name},<br/>target={client link ID}<br/>)	يعلق العميل على الكيان كمتلقٍّ
ردود ناقل الخدمة مرفقة بنهايتها من الارتباط	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={entity name},<br/>target={client link ID}<br/>)

إنشاء مرسل رسالة

العميل	ناقل الخدمة
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	عدم القيام بإجراء
عدم القيام بإجراء	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={client link ID},<br/>target={entity name}<br/>)

إنشاء مرسل رسالة (خطأ)

العميل	ناقل الخدمة
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	عدم القيام بإجراء
عدم القيام بإجراء	<-- 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/>)

إغلاق متلقي / مرسل الرسالة

العميل	ناقل الخدمة
--> detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)	عدم القيام بإجراء
عدم القيام بإجراء	<-- detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)

إرسال (نجاح)

العميل	ناقل الخدمة
--> transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,,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/>)

إرسال (خطأ)

العميل	ناقل الخدمة
--> transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,,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=**rejected**(<br/>error={error info}<br/>)<br/>)

استلام

العميل	ناقل الخدمة
--> flow(<br/>link-credit=1<br/>)	عدم القيام بإجراء
عدم القيام بإجراء	< 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/>)	عدم القيام بإجراء

تلقي رسائل متعددة

العميل	ناقل الخدمة
--> flow(<br/>link-credit=3<br/>)	عدم القيام بإجراء
عدم القيام بإجراء	< transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
عدم القيام بإجراء	< 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/>)
عدم القيام بإجراء	< 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/>)	عدم القيام بإجراء

الرسائل

وتشرح الأقسام التالية الخصائص من أقسام رسالة AMQP القياسية المستخدمة بواسطة ناقل الخدمة وكيفية تعيينها إلى مجموعة واجهة برمجة تطبيقات ناقل الخدمة.

وينبغي تعيين أي خاصية يحتاج التطبيق لتعريفها إلى الرسم application-properties على خريطة AMQP.

العنوان

اسم الحقل	الاستخدام	اسم واجهة برمجة التطبيقات
معمر	-	-
أولوية	-	-
ttl	حان الوقت للعيش من أجل هذه الرسالة	timeToLive
الحصول أولاً	-	-
التسليم -العد	-	عدد التسليم

الخصائص

اسم الحقل	الاستخدام	اسم واجهة برمجة التطبيقات
message-id	معرف تطبيق النموذج الحر لهذه الرسالة. مستخدم للكشف عن التكرارات.	MessageId
user-id	معرف المستخدم المعرّف للتطبيق، لا يتم تفسيره بواسطة ناقل الخدمة.	لا يمكن الوصول إليها من خلال واجهة برمجة تطبيقات ناقل الخدمة.
to	معرف المستخدم المعرّف للتطبيق، لا يتم تفسيره بواسطة ناقل الخدمة.	إلى
الموضوع	معرف المستخدم المعرّف للتطبيق، لا يتم تفسيره بواسطة ناقل الخدمة.	الموضوع
reply-to	معرف المستخدم المعرّف للتطبيق، لا يتم تفسيره بواسطة ناقل الخدمة.	الرد
correlation-id	معرف المستخدم المعرّف للتطبيق، لا يتم تفسيره بواسطة ناقل الخدمة.	معرف الارتباط
content-type	مؤشر نوع المحتوى المعرّف للتطبيق، لا يتم تفسيره بواسطة ناقل الخدمة.	نوع المحتوى
ترميز المحتوى	مؤشر نوع المحتوى المعرّف للتطبيق، لا يتم تفسيره بواسطة ناقل الخدمة.	لا يمكن الوصول إليها من خلال واجهة برمجة تطبيقات ناقل الخدمة.
absolute-expiry-time	يعلن عند أي لحظة مطلقة تنتهي صلاحية الرسالة. تم تجاهله على الإدخال (تتم ملاحظة عنوان TTL)، موثوقة على الإخراج.	لا يمكن الوصول إليها من خلال واجهة برمجة تطبيقات ناقل الخدمة.
وقت الإنشاء	يعرف الوقت الذي تم فيه إنشاء الرسالة. لا يستخدمه ناقل الخدمة	لا يمكن الوصول إليها من خلال واجهة برمجة تطبيقات ناقل الخدمة.
معرف المجموعة	معرف المستخدم المعرّف للتطبيق لمجموعة من الرسائل ذات الصلة. يستخدم لجلسات ناقل الخدمة.	معرف الجلسة
تسلسل المجموعة	العداد الذي يحدد رقم التسلسل النسبي للرسالة داخل جلسة. يتجاهله ناقل الخدمة.	لا يمكن الوصول إليها من خلال واجهة برمجة تطبيقات ناقل الخدمة.
معرف الرد على المجموعة	-	معرف الرد على المجموعة

التعليقات التوضيحية

هناك عدد قليل من الخصائص الأخرى لرسالة ناقل الخدمة التي ليست جزءًا من خصائص رسالة AMQP ويتم تمريرها عبر MessageAnnotations في الرسالة.

مفتاح خريطة التعليق التوضيحي	الاستخدام	اسم واجهة برمجة التطبيقات
x-opt-scheduled-enqueue-time	يعلن في أي وقت تنبغي أن تظهر الرسالة على الكيان	ScheduledEnqueueTime
x-opt-partition-key	مفتاح معرف التطبيق الذي يحدد القسم الذي ينبغي أن تهبط فيه الرسالة.	PartitionKey
x-opt-via-partition-key	قيمة مفتاح القسم المعرفة للتطبيق عند استخدام معاملة لإرسال رسائل عبر قائمة انتظار نقل.	TransactionPartitionKey
x-opt-enqueued-time	وقت UTC المعرف للخدمة الذي يمثل الوقت الفعلي للرسالة المدرجة. تم تجاهله في الإدخال.	وقت الانتظار
رقم التسلسل x-opt	الرقم الفريد المعين لرسالة بواسطة ناقل الخدمة.	رقم تسلسل
إزاحة x-opt	رقم تسلسل الخدمة المعرف للرسالة.	EnqueuedSequenceNumber
x-opt مقفل حتى	الخدمة محددة. التاريخ والوقت الذي سيتم فيه قفل الرسالة في قائمة الانتظار/الاشتراك.	LockedUntil
x-opt-deadletter-source	الخدمة محددة. إذا تم تلقي الرسالة من قائمة انتظار الأحرف غير المستخدمة، سيقدم مصدر الرسالة الأصلية.	DeadLetterSource

القدرة على إجراء المعاملة

تجمع المعاملة بين عمليتين أو أكثر معًا في نطاق تنفيذ. وينبغي أن تضمن هذه العملية بطبيعتها نجاح جميع العمليات التي تنتمي إلى مجموعة معينة من العمليات أو فشلها بصورة مشتركة. ويتم تجميع العمليات بواسطة معرف txn-id.

بالنسبة إلى التفاعل بين المعاملات، يعمل العميل كـtransaction controller، الذي يتحكم بالعمليات التي ينبغي تجميعها معًا. وتعمل خدمة ناقل الخدمة بمثابة transactional resource وتؤدي العمل كما يطلبهtransaction controller.

ويتصل العميل والخدمة عبر control link التي ينشئها العميل. ترسل وحدة التحكم الرسالتين declare وdischarge عبر ارتباط التحكم لتخصيص المعاملات وإتمامها على التوالي (لا تمثل ترسيم عمل المعاملات). لا يتم تنفيذ الإرسال/التلقي الفعلي على هذا الارتباط. يتم تعريف كل عملية معاملات مطلوبة بشكل صريح مع المطلوبtxn-id، وبالتالي قد تحدث على أي ارتباط على الاتصال. وإذا تم إغلاق ارتباط التحكم في أثناء وجود معاملات غير مفرغة أنشأها تعود كافة هذه المعاملات فورًا إلى الحالة السابقة، وستؤدي محاولات تنفيذ مزيد من عمل المعاملات عليها إلى الفشل. وينبغي عدم تسوية الرسائل الموجودة على ارتباط التحكم مسبقًا.

وينبغي أن يبدأ كل اتصال بارتباط التحكم الخاص به ليكون قادرًا على بدء المعاملات وإنهائها. وتعرف الخدمة هدفًا خاصًا يعمل كـcoordinator. وينشئ العميل/وحدة التحكم ارتباط تحكم لهذا الهدف. ويقع ارتباط التحكم خارج حدود كيان، أي يمكن استخدام ارتباط التحكم نفسه لبدء المعاملات وتفريغها لكيانات متعددة.

بدء معاملة

لبدء العمل على المعاملات. وينبغي أن تحصل وحدة التحكم على txn-id من المنسق. وهو يقوم بذلك عن طريق إرسالdeclareرسالة نوع. وإذا نجح الإعلان، يستجيب المنسق بنتيجة التصرف التي تحمل المعينtxn-id.

العميل (وحدة التحكم)	الاتجاه	ناقل الخدمة (منسق)
إرفاق( اسم = {اسم الارتباط}، ... , دور =المرسل، الهدف =المنسق )	------>
	<------	إرفاق( اسم = {اسم الارتباط}، ... , target=Coordinator() )
النقل( معرف التسليم = 0، ...) {قيمة Amqp _(إعلان ())}	------>
	<------	التصرف( first=0, last=0, state=Declared( txn-id={transaction ID} ))

تفريغ معاملة

تختتم وحدة تحكم العمل على المعاملات عن طريق إرسال discharge رسالة إلى المنسق. ويشير جهاز التحكم إلى أنه يرغب في الالتزام بالعمل على المعاملات أو إعادته إلى الحالة السابقة عن طريق وضع fail العلم على جسم التفريغ. وإذا كان المنسق غير قادر على إكمال التفريغ، يتم رفض الرسالة مع هذه النتيجة التي تحمل transaction-error .

ملاحظة: يشير فشل = صحيح إلى إعادة المعاملة إلى الحالة السابقة ويشير فشل = خطأ إلى الالتزام.

العميل (وحدة التحكم)	الاتجاه	ناقل الخدمة (منسق)
النقل( معرف التسليم = 0، ...) {قيمة Amqp (إعلان ())}	------>
	<------	التصرف( first=0, last=0, state=Declared( txn-id={transaction ID} ))
	. . . بدء العمل على المعاملات على ارتباطات أخرى . . .
النقل( معرف التسليم = 57، ...) {قيمة amqp ( تفريغ(txn-id=0, فشل=خطأ))}	------>
	<------	التصرف( first=57, last=57, state=Accepted())

إرسال رسالة في معاملة

يتم تنفيذ جميع أعمال المعاملات مع حالة transactional-state تسليم المعاملات التي تحمل txn-id. عند إرسال الرسائل، يتم نقل حالة المعاملات بواسطة إطار نقل الرسالة.

العميل (وحدة التحكم)	الاتجاه	ناقل الخدمة (منسق)
النقل( معرف التسليم = 0، ...) {قيمة Amqp (إعلان ())}	------>
	<------	التصرف( first=0, last=0, state=Declared( txn-id={transaction ID} ))
النقل( معالجة = 1، معرف التسليم =1، حالة= TransactionalState( txn-id=0)) {الحمولة}	------>
	<------	التصرف( الأول=1، الأخير=1، state=TransactionalState( txn-id=0, النتيجة = مقبولة()))

إرسال رسالة في معاملة

يتضمن ترتيب الرسائل عمليات مثل Complete / Abandon / DeadLetter / Defer. لتنفيذ هذه العمليات داخل المعاملةtransactional-stateمع الترتيب.

العميل (وحدة التحكم)	الاتجاه	ناقل الخدمة (منسق)
النقل( معرف التسليم = 0، ...) {قيمة Amqp (إعلان ())}	------>
	<------	التصرف( first=0, last=0, state=Declared( txn-id={transaction ID} ))
	<------	النقل( معالجة = 2، معرف التسليم =11، state=null) {الحمولة}
التصرف( الأول=11، الأخير=11، state=TransactionalState( txn-id=0, النتيجة = مقبولة()))	------>

قدرات ناقل الخدمة المتقدمة

يغطي هذا القسم القدرات المتقدمة لناقل الخدمة Azure الذي يستند إلى مسودة ملحقات AMQP، والذي يتم تطويره حاليًا في اللجنة التقنية OASIS لـAMQP. وينفذ ناقل الخدمة أحدث إصدارات هذه المسودات ويعتمد التغييرات التي أدخلت، بما أن تلك المسودات تصل إلى الوضع القياسي.

إشعار

ويتم دعم عمليات مراسلة ناقل الخدمة المتقدمة من خلال نمط طلب/استجابة. ويتم وصف تفاصيل هذه العمليات في المقالة AMQP 1.0 في ناقل الخدمة: العمليات المستندة إلى الاستجابة للطلب.

إدارة AMQP

مواصفات إدارة AMQP هي الملحق الأول من مسودة ملحقات التي تمت مناقشتها في هذه المقالة. وتعرف هذه المواصفات مجموعة من البروتوكولات ذات الطبقات فوق بروتوكول AMQP تسمح بالتفاعلات الإدارية مع البنية التحتية للمراسلة عبر AMQP. وتحدد المواصفات العمليات العامة مثل إنشاءوقراءةوتحديثوحذف لإدارة الكيانات داخل البنية التحتية للمراسلة ومجموعة من عمليات الاستعلام.

وتتطلب كل هذه الإيماءات تفاعل طلب/استجابة بين العميل والبنية التحتية للمراسلة، وبالتالي تحدد المواصفات كيفية نمذجة نمط التفاعل هذا في أعلى AMQP: يتصل العميل بالبنية التحتية للمراسلة، ويبدأ جلسة عمل، ثم ينشئ زوجًا من الارتباطات. على ارتباط واحد، يعمل العميل كمرسل وعلى ارتباط آخر يعمل كمتلقٍّ وبالتالي ينشئ زوجًا من الارتباطات التي يمكن أن تعمل كقناة ثنائية الاتجاه.

العمليات المنطقية	العميل	ناقل الخدمة
إنشاء مسار الطلب / الاستجابة	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=**null**,<br/>target=”myentity/$management”<br/>)	عدم القيام بإجراء
إنشاء مسار الطلب / الاستجابة	عدم القيام بإجراء	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=null,<br/>target=”myentity”<br/>)
إنشاء مسار الطلب / الاستجابة	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=”myentity/$management”,<br/>target=”myclient$id”<br/>)
إنشاء مسار الطلب / الاستجابة	عدم القيام بإجراء	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=”myentity”,<br/>target=”myclient$id”<br/>)

مع وجود هذا الزوج من الارتباطات في مكانه، يطبق الطلب/الاستجابة مباشرة: الطلب هو رسالة يتم إرسالها إلى كيان داخل البنية التحتية للمراسلة تفهم هذا النمط. وفي رسالة الطلب تلك، يتم تعيين حقل الرد على في قسم الخصائص إلى معرف الهدف للارتباط الذي سيتم تسليم الاستجابة إليه. ويعالج كيان المعالجة الطلب، ثم يسلم الرد عبر الارتباط الذي يتطابق معرف الهدف الخاص به مع معرف الرد على المشار إليه.

ومن الواضح أن النمط يتطلب أن تكون حاوية العميل والمعرف الذي تم إنشاؤه بواسطة العميل لوجهة الرد فريدة عبر كافة العملاء، ولأسباب أمنية، من الصعب التنبؤ بها أيضًا.

تحدث عمليات تبادل الرسائل المستخدمة لبروتوكول الإدارة ولكافة البروتوكولات الأخرى التي تستخدم نفس النمط على مستوى التطبيق؛ لا يحددون إيماءات جديدة على مستوى بروتوكول AMQP. هذا مقصود، بحيث يمكن للتطبيقات الاستفادة الفورية من هذه الملحقات مع مكدسات الذاكرة المؤقتة AMQP 1.0 المتوافقة.

لا يقوم ناقل خدمة Microsoft Azure حاليا بتنفيذ أي من الميزات الأساسية لمواصفات الإدارة، ولكن نمط الطلب/الاستجابة المحدد بواسطة مواصفات الإدارة أساسي لميزة الأمان المستندة إلى المطالبات ولكافة الإمكانات المتقدمة تقريبا التي تمت مناقشتها في الأقسام التالية:

التخويل المستند إلى المطالبات

تستند مسودة مواصفات التخويل المستندة إلى المطالبات AMQP (CBS) إلى نموذج طلب/استجابة مواصفات الإدارة، ويصف نموذجًا معممًا لكيفية استخدام رموز الأمان المتحدة مع AMQP.

ويستند نموذج الأمان الافتراضي AMQP الذي تمت مناقشته في المقدمة إلى SASL ويتكامل مع مصافحة اتصال AMQP. واستخدام SASL له ميزة وهي أنه يوفر نموذجًا قابلًا للتوسيع حددت له مجموعة من الآليات التي يمكن أن يستفيد منها أي بروتوكول يعتمد رسميًا على SASL. ومن بين هذه الآليات، نذكر “العادية“ لنقل أسماء المستخدمين وكلمات المرور و“الخارجية“ للربط على مستوى أمان TSL و“المجهولة“ للتعبير عن غياب المصادقة/المصادقة الصريحة ومجموعة واسعة من الآليات الإضافية التي تسمح بتمرير مصادقة و/أو بيانات اعتماد المصادقة أو الرموز المتميزة.

لدى دمج SASL AMQP عيبان:

• توضع كافة بيانات الاعتماد والرموز المميزة في نطاق الاتصال. قد ترغب البنية الأساسية للمراسلة في توفير تحكم متميز في الوصول على أساس كل كيان؛ على سبيل المثال، السماح لحامل الرمز المميز بالإرسال إلى قائمة الانتظار A ولكن ليس إلى قائمة الانتظار B. مع وضع سياق التخويل على الاتصال، لا يمكن استخدام اتصال واحد، ومع ذلك استخدام رموز وصول مختلفة لقائمة الانتظار A وقوائم الانتظار B.
• وتكون رموز الوصول المتميزة عادة صالحة لوقت محدود. وتتطلب هذه الصلاحية أن يكتسب المستخدم الرموز المتميزة مجددًا بشكل دوري وتوفر فرصة إلى مصدر شهادة الرموز المتميزة برفض إصدار رمز متميز جديد إذا تغيرت أذونات وصول المستخدم. قد تستمر اتصالات AMQP لفترات طويلة من الوقت. يوفر نموذج SASL فرصة فقط لتعيين رمز مميز في وقت الاتصال، ما يعني أن البنية الأساسية للمراسلة إما أن تقوم بقطع اتصال العميل عند انتهاء صلاحية الرمز المميز أو أنها تحتاج إلى قبول مخاطر السماح بالاتصال المستمر مع عميل ربما تم إبطال حقوق الوصول الخاصة به في هذه الأثناء.

تمكّن مواصفات CBS AMQP، التي يتم تنفيذها بواسطة ناقل الخدمة، الحل البديل الأنيق لكلا هاتين المشكلتين: يسمح لعميل بربط رموز الوصول المميزة بكل عقدة، وتحديث تلك الرموز المميزة قبل انتهاء صلاحيتها، من دون مقاطعة تدفق الرسالة.

ويعرف CBS عقدة إدارة ظاهرية، تُسمى $cbs، يتم توفيرها بواسطة بنية المراسلة التحتية. وتقبل عقدة إدارة الرموز المميزة نيابة عن أي عقد أخرى في بنية المراسلة التحتية.

إيماءة البروتوكول هي تبادل طلب/رد على النحو الذي تحدده مواصفات الإدارة. وهذا يعني أن العميل يؤسس زوجًا من الارتباطات مع عقدة $cbs، ثم يمرر طلبًا على الارتباط الصادر، وبعدها ينتظر الاستجابة على الارتباط الوارد.

ينبغي أن تتضمن رسالة الطلب خصائص التطبيق التالية:

مفتاح	اختياري	نوع القيمة	محتويات القيمة
operation	لا	سلسلة	put-token
type	لا	سلسلة	نوع الرمز الذي تم وضعه.
name	لا	سلسلة	"الجمهور" الذي ينطبق عليه الرمز المميز.
expiration	‏‏نعم‬	الطابع الزمني	وقت انتهاء صلاحية الرمز المميز.

تعرف خاصية الاسم الكيان الذي ينبغي أن يقترن به الرمز المميز. في ناقل الخدمة، هي الطريق إلى قائمة الانتظار أو الموضوع/الاشتراك. وتعرف خاصية النوع نوع الرمز المميز:

نوع الرمز المميز	وصف الرمز المتميز	نوع الهيئة	الملاحظات
jwt	رمز ويب JSON المتميز (JWT)	قيمة AMQP (سلسلة)
servicebus.windows.net:sastoken	رمز SAS لناقل الخدمة	قيمة AMQP (سلسلة)	-

تمنح الرموز حقوقًا. ويعرف ناقل الخدمة ثلاثة حقوق أساسية تقريبًا: يمكّن "إرسال" الإرسال ويمكّن "الاستماع" التلقي ويمكّن "إدارة" معالجة الكيانات. وتشير رموز SAS المتميزة الخاصة بناقل الخدمة إلى القواعد المكونة على مساحة الاسم أو الكيان، ويتم تكوين هذه القواعد مع الحقوق. وبالتالي، يجعل توقيع الرمز المميز مع المفتاح المقترن بهذه القاعدة وبالتالي الرمز المميز يعبر عن الحقوق المعنية. ويسمح الرمز المميز المقترن بكيان يستخدم وضع رمز مميز للعميل المتصل بالتفاعل مع الكيان وفقًا لحقوق الرمز المميز. ويتطلب الارتباط الذي يأخذ العميل على دور المرسل حق "إرسال"; ويتطلب الأخذ على دور المتلقي حق "الاستماع".

وتتضمن رسالة الرد قيم خصائص التطبيق التالية

مفتاح	اختياري	نوع القيمة	محتويات القيمة
status-code	لا	العدد الصحيح	رمز الرد HTTP [RFC2616].
status-description	‏‏نعم‬	سلسلة	وصف الحالة.

يمكن للعميل استدعاء وضع الرمز المميز بشكل متكرر ولأي كيان في بنية المراسلة التحتية. يتم وضع الرموز المميزة في نطاق إلى العميل الحالي وإرساؤها على الاتصال الحالي، ما يعني أن الملقم يسقط أي رموز مميزة محتفظ بها عند انخفاض الاتصال.

يسمح تطبيق ناقل الخدمة الحالي فقط ب CBS بالاقتران مع طريقة SASL "ANONYMOUS". يجب أن يكون اتصال SSL/TLS موجودا دائما قبل مصافحة SASL.

لذلك، ينبغي أن يعتمد العميل الذي يختاره AMQP 1.0 آلية ANONYMOUS. ويعني الوصول المجهول أن الاتصال الأولي، بما في ذلك إنشاء الجلسة الأولية يحدث بدون أن يعرف ناقل خدمة من ينشئ الاتصال.

وبمجرد تأسيس الاتصال والجلسة، إرفاق الارتباطات إلى عقدة $cbs وإرسال طلب وضع الرمز المميز هي العمليات المسموح بها فحسب. وينبغي تعيين رمز مميز صالح بنجاح باستخدام طلب وضع الرمز المميز لبعض عقدة الكيان في خلال 20 ثانية بعد تأسيس الاتصال، وإلا يتم إسقاط الاتصال من طرف واحد بواسطة ناقل الخدمة.

بعد ذلك، العميل هو المسؤول في وقت لاحق عن تتبع انتهاء صلاحية الرمز المميز. وعند انتهاء صلاحية رمز مميز، يسقط ناقل الخدمة على الفور كافة الارتباطات على الاتصال بالكيان المعني. لمنع حدوث المشكلة، يمكن أن يستبدل العميل الرمز المميز للعقدة بواحد جديد في أي وقت من خلال عقدة إدارة $cbs الظاهرية معإيماءة وضع الرمز المميزنفسها ومن دون إعاقة نسبة استخدام شبكة الحمولة التي تتدفق على ارتباطات مختلفة.

وظيفة الإرسال عبر

مرسل الإرسال عبر / النقل هو وظيفة تسمح لناقل الخدمة بتوجيه رسالة معينة إلى كيان الوجهة من خلال كيان آخر. ويتم استخدام هذه الميزة لتنفيذ العمليات عبر الكيانات في معاملة واحدة.

باستخدام هذه الوظيفة، يمكنك إنشاء مرسل وإنشاء الارتباط إلى via-entity. وأثناء تأسيس الارتباط، يتم تمرير معلومات إضافية لتأسيس الوجهة الحقيقية للرسائل/عمليات النقل على هذا الارتباط. وبمجرد نجاح الإرفاق، يتم توجيه جميع الرسائل المرسلة على هذا الارتباط تلقائيًا إلىالكيان الوجهة من خلال الكيان.

ملاحظة: ينبغي إجراء المصادقة لكل من عبر الكيانوكيان الوجهةقبل إنشاء هذا الارتباط.

العميل	الاتجاه	ناقل الخدمة
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} )] )

الخطوات التالية

لمعرفة المزيد حول AMQP، راجع نظرة عامة على ناقل خدمة AMQP.