استكشاف البيانات الأساسية لرسائل ناقل خدمة Azure وتسلسلها
تحمل الرسائل حمولة وبيانات تعريف. بيانات التعريف في شكل خصائص زوج قيمة المفتاح، وتصف الحمولة، وتعطي تعليمات المعالجة إلى خدمة الناقل والتطبيقات. أحيانا، تكون بيانات التعريف هذه وحدها كافية لنقل المعلومات التي يريد المرسل توصيلها إلى المستقبلات، وتظل الحمولة فارغة.
نموذج الكائن لعملاء ناقل خدمة Microsoft Azure الرسميين ل .NET وJava يعين من وإلى بروتوكولات الأسلاك التي يدعمها ناقل خدمة Microsoft Azure.
تتكون رسالة ناقل خدمة Azure من مقطع حِمل ثنائي لا يعالجه ناقل خدمة Azure في أي نموذج على جانب الخدمة، ومجموعتين من الخصائص. خصائص الوسيط محددة من قبل النظام. تتحكم هذه الخصائص المعرفة مسبقا في وظائف مستوى الرسالة داخل الوسيط، أو أنها تعين عناصر بيانات التعريف الشائعة والموحدة. خصائص المستخدم هي مجموعة من أزواج قيم المفاتيح المعرفة والمحددة من قبل التطبيق.
توجيه الرسائل والارتباط
مجموعة فرعية من خصائص الوسيط، على وجه التحديدTo، ReplyToReplyToSessionIdو، MessageIdو، CorrelationIdو، وSessionId، ومساعدة التطبيقات على توجيه الرسائل إلى وجهات معينة. تصف الأنماط التالية التوجيه:
طلب/رد بسيط: يرسل الناشر رسالة إلى قائمة انتظار ويتوقع ردا من مستهلك الرسالة. يمتلك الناشر قائمة انتظار لتلقي الردود. يتم تضمين عنوان قائمة الانتظار هذه في
ReplyToخاصية الرسالة الصادرة. عندما يستجيب المستهلك، فإنه ينسخMessageIdمن الرسالة التي تمت معالجتها في خاصيةCorrelationIdلرسالة الرد ويسلم الرسالة إلى الوجهة المشار إليها من قبل خاصيةReplyTo. يمكن أن تسفر رسالة واحدة عن ردود متعددة، اعتمادا على سياق التطبيق.طلب/رد الإرسال المتعدد: كتنوع للنمط السابق، يرسل الناشر الرسالة إلى موضوع ويصبح العديد من المشتركين مؤهلين لاستهلاك الرسالة. قد يستجيب كل مشترك هكذا بالصورة الموضحة سابقا. إذا أشار
ReplyToإلى موضوع ما، يمكن توزيع مجموعة من استجابات الاكتشاف هذه على جمهور.الارسال المتعدد: تتيح ميزة جلسة العمل هذه تعدد تدفقات الرسائل ذات الصلة من خلال قائمة انتظار واحدة أو اشتراك واحد بحيث يتم توجيه كل جلسة عمل (أو مجموعة) من الرسائل ذات الصلة، التي تم تحديدها من خلال
SessionIdالقيم المتطابقة، إلى جهاز استقبال معين بينما يحتفظ المتلقي بجلسة العمل أثناء القفل. تعرف على المزيد حول تفاصيل الجلسات هنا.طلب/رد متعدد الرسائل/الرد: تتيح ميزة جلسة العمل هذه ردودا متعددة، مما يسمح للعديد من الناشرين بمشاركة قائمة انتظار الرد. بواسطة تعيين
ReplyToSessionId، يمكن للناشر إرشاد المستهلك (المستهلكين) لنسخ هذه القيمة في خاصيةSessionIdلرسالة الرد. لا يلزم أن تكون قائمة انتظار النشر أو الموضوع مدركة للجلسة. عند إرسال الرسالة، يمكن للناشر انتظار جلسة عمل مع المعطاةSessionIdلتجسيدها في قائمة الانتظار عن طريق قبول مستقبل جلسة عمل بشكل مشروط.
يستخدم التوجيه داخل مساحة اسم ناقل خدمة Microsoft Azure قواعد التسلسل التلقائي والاشتراك في الموضوع. يمكن تنفيذ التوجيه عبر مساحات الأسماء باستخدام Azure LogicApps. To الخاصية محجوزة للاستخدام في المستقبل. يجب أن تقوم التطبيقات التي تنفذ التوجيه بذلك استنادا إلى خصائص المستخدم ولا تعتمد على To الخاصية؛ ومع ذلك، فإن القيام بذلك الآن لن يسبب مشكلات في التوافق.
تسلسل الحمولة
عند النقل أو التخزين داخل ناقل خدمة Azure، الحمولة تكون دائمًا كتلة ثنائية مبهمة. خاصية ContentType تمكن التطبيقات لوصف الحمولة، مع تنسيق المقترح لقيم الخاصية هو وصف نوع محتوى MIME وفقا ل IETF RFC2045؛ على سبيل المثال، application/json;charset=utf-8.
بعكس المتغيرات Java أو .NET Standard، يعتمد إصدار .NET Framework API ناقل الخدمة إنشاء مثيلات BrokeredMessage بتمرير كائنات .NET إجبارية إلى المنشئ.
يقوم بروتوكول SBMP القديم بتسلسل الكائنات باستخدام التسلسل الثنائي الافتراضي، أو مع مسلسل يتم توفيره خارجيا. يقوم بروتوكول AMQP بتسلسل العناصر في كائن AMQP. يمكن استرداد المتلقي هذه الكائنات باستخدام طريقة GetBody<T>() توفير النوع المتوقع. مع AMQP، يتم تسلسل الكائنات في رسم بياني AMQP ArrayListIDictionary<string,object> والكائنات، وأي عميل AMQP يمكن فك ترميزها.
في حين أن سحر التسلسل المخفي هذا مناسب، إذا كان يجب على التطبيقات التحكم الصريح في تسلسل الكائنات وتحويل الرسوم البيانية للكائنات الخاصة بها إلى تدفقات قبل تضمينها في رسالة، يجب أن تقوم بالعملية العكسية على جانب المتلقي. في حين أن AMQP لديه نموذج ترميز ثنائي قوي، فإنه مرتبط بالنظام البنائي لمراسلة AMQP ويواجه عملاء HTTP صعوبة في فك تشفير مثل هذه الحمولات.