برمجيات وسيطة موجهة نحو الرسائل

الموسوعة الحرة

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

تتيح تقنية MOM توزيع وحدات التطبيق على منصات متنوعة، مما يقلل من تعقيد تطوير التطبيقات التي تعمل عبر أنظمة تشغيل وبروتوكولات شبكية متعددة. وتُنشئ هذه التقنية طبقة اتصالات موزعة تعزل مطور التطبيق عن تفاصيل أنظمة التشغيل وواجهات الشبكة المختلفة. وعادةً ما توفر MOM واجهات برمجة التطبيقات ( APIs ) التي تمتد عبر منصات وشبكات متنوعة. [ 1 ]

تتيح طبقة البرمجيات الوسيطة هذه لمكونات البرمجيات (التطبيقات، والبرامج الصغيرة، والمكونات الأخرى) التي طُوّرت بشكل مستقل والتي قد تعمل على منصات شبكية مختلفة، التفاعل فيما بينها. وتستخدم التطبيقات الموزعة على عُقد شبكية مختلفة واجهة التطبيق للتواصل. إضافةً إلى ذلك، ومن خلال توفير واجهة إدارية، يُمكن جعل هذا النظام الافتراضي الجديد للتطبيقات المترابطة مقاومًا للأعطال وآمنًا. [ 2 ]

توفر MOM عناصر برمجية موجودة في جميع مكونات الاتصال في بنية العميل/الخادم، وتدعم عادةً المكالمات غير المتزامنة بين تطبيقات العميل والخادم. تقلل MOM من تدخل مطوري التطبيقات في تعقيد طبيعة آلية العميل/الخادم الرئيسية والتابعة.

فئات البرامج الوسيطة

تُمكّن جميع هذه النماذج أحد مكونات البرمجيات من التأثير على سلوك مكون آخر عبر الشبكة. وتختلف هذه النماذج في أن البرمجيات الوسيطة القائمة على RPC وORB تُنشئ أنظمة ذات مكونات مترابطة بإحكام، بينما تسمح الأنظمة القائمة على MOM بترابط أقل إحكامًا بين المكونات. في نظام قائم على RPC أو ORB، عندما يستدعي إجراءٌ ما إجراءً آخر، يجب عليه انتظار انتهاء الإجراء المُستدعى قبل أن يتمكن من القيام بأي شيء آخر. في نماذج المراسلة المتزامنة هذه في الغالب ، تعمل البرمجيات الوسيطة جزئيًا كرابط فائق، حيث تحدد موقع الإجراء المُستدعى على الشبكة وتستخدم خدمات الشبكة لتمرير معلمات الدالة أو الطريقة إلى الإجراء، ثم تُعيد النتائج. [ 2 ] تجدر الإشارة إلى أن وسطاء طلبات الكائنات يدعمون أيضًا المراسلة غير المتزامنة بالكامل عبر الاستدعاءات أحادية الاتجاه. [ 3 ]

المزايا

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

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

عدم التزامن

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

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

التوجيه

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

تحويل

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

العيوب

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

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

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

المعايير

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

يُعدّ معيار XATMI (معالجة المعاملات الموزعة: معيار XATMI) الصادر عن مجموعة X/Open أحد المعايير الراسخة لبرمجيات الوسيطة الموجهة نحو الرسائل، حيث يُوحّد واجهة برمجة التطبيقات (API) للاتصالات بين العمليات . ومن التطبيقات المعروفة لهذه الواجهة برنامج Enduro/X الوسيط من ATR Baltic وبرنامج Tuxedo من Oracle .

بروتوكول AMQP ( بروتوكول تبادل الرسائل المتقدم ) هو معيار معتمد من OASIS [ 5 ] وISO [ 6 ] ، يُحدد البروتوكول والتنسيقات المستخدمة بين مكونات التطبيقات المشاركة، مما يضمن توافق التطبيقات المختلفة. يمكن استخدام AMQP مع أنظمة توجيه مرنة، بما في ذلك نماذج المراسلة الشائعة مثل التوجيه من نقطة إلى نقطة ، والتوزيع ، والنشر/الاشتراك ، وطلب-استجابة (تم حذف هذه النماذج عمدًا من الإصدار 1.0 من معيار البروتوكول نفسه، ولكنها تعتمد على التطبيق المحدد و/أو بروتوكول الشبكة الأساسي للتوجيه). كما يدعم إدارة المعاملات، والترتيب في قوائم الانتظار، والتوزيع، والأمان، والإدارة، والتجميع، والاتحاد، ودعم منصات متعددة غير متجانسة. عادةً ما تُكتب تطبيقات Java التي تستخدم AMQP بلغة Java JMS. توفر تطبيقات أخرى واجهات برمجة تطبيقات (APIs) للغات C# و C++ و PHP و Python و Ruby وغيرها من لغات البرمجة .

تُعدّ بنية المستوى العالي (HLA IEEE 1516) معيارًا مشتركًا بين معهد مهندسي الكهرباء والإلكترونيات (IEEE) ومنظمة معايير قابلية التشغيل البيني للمحاكاة (SISO) لضمان قابلية التشغيل البيني لأنظمة المحاكاة. يُعرّف هذا المعيار مجموعة من الخدمات المُقدّمة عبر واجهة برمجة تطبيقات (API) بلغة C++ أو Java. تُتيح هذه الخدمات تبادل المعلومات القائم على نموذج النشر/الاشتراك، استنادًا إلى نموذج كائنات الاتحاد المعياري. كما تتضمن خدمات لتبادل البيانات المنسق والتقدم الزمني، استنادًا إلى وقت المحاكاة المنطقي، بالإضافة إلى نقاط التزامن. وتُوفّر خدمات إضافية نقل الملكية، وتحسين توزيع البيانات، ومراقبة وإدارة الأنظمة (الوحدات) المُشاركة في الاتحاد.

بروتوكول نقل بيانات القياس عن بُعد MQTT هو معيار ISO (ISO/IEC PRF 20922) تدعمه منظمة OASIS. يوفر هذا البروتوكول بروتوكول نقل رسائل موثوقًا وخفيف الوزن يعتمد على النشر والاشتراك، ويستند إلى بروتوكول TCP/IP، وهو مناسب للاتصال في سياقات M2M/IoT حيث يكون حجم الكود صغيرًا و/أو عرض النطاق الترددي للشبكة محدودًا.

توفر خدمة توزيع البيانات (DDS) التابعة لمجموعة إدارة الكائنات معيارًا برمجيًا وسيطًا للنشر/الاشتراك (P/S) قائمًا على الرسائل، ويهدف إلى تمكين تبادل بيانات قابل للتوسع، وفي الوقت الفعلي، وموثوق، وعالي الأداء، وقابل للتشغيل البيني بين الناشرين والمشتركين. [ 7 ] يوفر هذا المعيار واجهات للغات C++ وC++11 وC و Ada وJava وRuby.

XMPP

بروتوكول المراسلة والحضور القابل للتوسيع ( XMPP ) هو بروتوكول اتصالات للبرمجيات الوسيطة الموجهة نحو الرسائل، ويعتمد على لغة الترميز القابلة للتوسيع ( XML ). صُمم هذا البروتوكول ليكون قابلاً للتوسيع، وقد استُخدم أيضًا في أنظمة النشر والاشتراك، والإشارة في بروتوكول نقل الصوت عبر الإنترنت (VoIP)، والفيديو، ونقل الملفات، والألعاب، وتطبيقات إنترنت الأشياء مثل الشبكة الذكية، وخدمات التواصل الاجتماعي. على عكس معظم بروتوكولات المراسلة الفورية، يُعرَّف XMPP بمعيار مفتوح، ويستخدم نهج الأنظمة المفتوحة في التطوير والتطبيق، مما يسمح لأي شخص بتنفيذ خدمة XMPP والتوافق مع تطبيقات المنظمات الأخرى. ولأن XMPP بروتوكول مفتوح، يمكن تطوير تطبيقاته باستخدام أي ترخيص برمجي؛ فعلى الرغم من أن العديد من تطبيقات الخادم والعميل والمكتبات تُوزَّع كبرامج مجانية ومفتوحة المصدر ، إلا أن هناك أيضًا العديد من تطبيقات البرامج المجانية والاحتكارية. وقد شكّلت فرقة عمل هندسة الإنترنت (IETF) فريق عمل خاصًا بـ XMPP في عام 2002 لإضفاء الطابع الرسمي على البروتوكولات الأساسية كتقنية مراسلة وحضور فورية تابعة لـ IETF. أصدر فريق عمل XMPP أربع مواصفات (RFC 3920، RFC 3921، RFC 3922، RFC 3923)، والتي اعتُمدت كمعايير مقترحة في عام 2004. وفي عام 2011، استُبدلت المواصفتان RFC 3920 وRFC 3921 بالمواصفتين RFC 6120 وRFC 6121 على التوالي، حيث حددت RFC 6122 تنسيق عنوان XMPP. بالإضافة إلى هذه البروتوكولات الأساسية الموحدة في IETF، تعمل مؤسسة معايير XMPP (المعروفة سابقًا باسم مؤسسة برمجيات Jabber) بنشاط على تطوير امتدادات XMPP مفتوحة المصدر. ووفقًا لمؤسسة معايير XMPP، تُستخدم البرامج القائمة على XMPP على نطاق واسع عبر الإنترنت، وتشكل أساس إطار القدرات الموحدة لوزارة الدفاع الأمريكية. [ 8 ]

توفر بيئة برمجة Java EE واجهة برمجة تطبيقات قياسية تسمى خدمة رسائل Java (JMS)، والتي يتم تنفيذها بواسطة معظم موردي MOM وتهدف إلى إخفاء تطبيقات MOM API المحددة؛ ومع ذلك، فإن JMS لا تحدد تنسيق الرسائل التي يتم تبادلها، لذلك فإن أنظمة JMS غير قابلة للتشغيل البيني.

يُبذل جهد مماثل في مشروع OpenMAMA الذي يشهد تطوراً مستمراً ، والذي يهدف إلى توفير واجهة برمجة تطبيقات (API) مشتركة، خاصةً لعملاء لغة C. اعتباراً من أغسطس 2012، يُعد هذا المشروع مناسباً بشكل أساسي لتوزيع البيانات المتعلقة بالسوق (مثل أسعار الأسهم) عبر برمجيات وسيطة للنشر والاشتراك.

ترتيب الرسائل في قائمة الانتظار

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

انظر أيضاً

مراجع

  1. ↑ كاري، إدوارد (2004). البرمجيات الوسيطة الموجهة نحو الرسائل .في كتاب "البرمجيات الوسيطة للاتصالات"، تحرير قصي ح. محمود، الصفحات 1-28. تشيتشستر، إنجلترا: جون وايلي وأولاده. doi : 10.1002/0470862084.ch1 . ISBN 978-0-470-86206-3
  2. 1 2 البرمجيات الوسيطة الموجهة نحو الرسائل .
  3. 1 2 بنية وسيط طلب الكائنات المشتركة .
  4. ↑ «إي. كاري، دي. تشامبرز، وجي. ليونز، "توسيع نطاق البرمجيات الوسيطة الموجهة نحو الرسائل باستخدام الاعتراض"، عُرض في ورشة العمل الدولية الثالثة حول الأنظمة الموزعة القائمة على الأحداث (DEBS '04)، ICSE '04، إدنبرة، اسكتلندا، المملكة المتحدة، 2004» (ملف PDF) . مؤرشف من النسخة الأصلية (PDF) بتاريخ 26 يوليو 2011. تم الاطلاع عليه بتاريخ 9 أغسطس 2011 .
  5. ↑ أصبح الإصدار 1.0 معيارًا لمنظمة OASIS . AMQP (31-10-2012). تم الاطلاع عليه بتاريخ 23-05-2014.
  6. ^ "آيزو/آي إي سي 19464:2014" . ايزو .
  7. ↑ خدمة توزيع البيانات للأنظمة في الوقت الحقيقي (DDS)، مجموعة إدارة الكائنات، الإصدار 1.2، يناير 2007
  8. ↑أُرشف بتاريخ 23 مايو 2013 في أرشيف الإنترنت (Wayback Machine) .
  9. ↑ "MQ - مقدمة إلى البرمجيات الوسيطة الموجهة نحو الرسائل وIBM MQ" . itgix.com . 30-08-2018.
  10. ↑ بروتوكول OASIS AMQP الإصدار 1.0، القسمان 2.6.7-2.6.8. اللجنة الفنية لبروتوكول OASIS AMQP. تم الاطلاع عليه بتاريخ 18 يونيو 2012.
  11. ↑ يوهانسون، ليف (18 أبريل 2005). "XMPP كـ MOM". ندوة البرمجيات الوسيطة لدول الشمال الكبرى (GNOMIS). أوسلو: جامعة ستوكهولم
  12. ↑ "مواصفات بروتوكول STOMP، الإصدار 1.2" . stomp.github.io . 22 أكتوبر 2012.
  13. ↑ هل أنت ضعيف في المنتصف؟ مستقبل تكنولوجيا المعلومات المؤسسية يكمن في تطبيقات الأجهزة. مؤرشف بتاريخ 9 فبراير 2009 في أرشيف الإنترنت.
  14. ↑ ORB express for Field Programmable on Gate Arrays ( FPGA )