تطـــويـر الـتطــبيـقـات المــوزّعــة المــوثـوقـة والقــابــلـة للتـجــزئــة بـاســتـخـدام Jgroup/ARM

يتطلّب الاعتماد المتزايد على الانظمة الشبكية في النشاطات اليومية تزويدها لخدمات متوفّرة وموثوقة. تزوّد Jgroup خدمة متوفّرة من خلال انشائها نسخ (Replicas) متعددة من الخدمة نفسها وتوزيعها على اجهزة متعددة, بينما تحقّق الموثوقية من خلال سماحها لنسخ الخدمة بالحفاظ على الحالة المشتركة فيما بينها وتنسيق نشاطاتها باستخدام تقنية استدعاء الطريقة البعيدة (Remote Method Invocation). خلافاً لـJgroup, تستخدم JavaGroups تقنية تمرير الرسائل (Message Passing) لتحقيق التنسيق بين النسخ. تقارن هذه المقالة بين اداءي استدعاء طريقة المجموعة في Jgroup بنوعيه الوحيد (anycast) والمتعدّد (multicast) واستدعاء الطريقة في JavaGroups بنوعيه طريقة الحصول على اول اجابة (GET_FIRST) وطريقة الحصول على جميع الاجابات (GET_ALL). تحسّن هذه المقالة ايضاً من اداء منصّة العمل ARM (Autonomous Replication Management) المدمجة مع Jgroup (Jgroup/ARM) لزيادة دعمها مع التسامح مع الخطا؛ من خلال ايجاد حل افضل لمعالجة مشكلة تعطّل كامل اعضاء نسخ الخدمة في تعاقب سريع. تتميز الآلية الجديدة بقيام نسخة واحدة فقط (النسخة القائدة) بارسال حدث التجديد بدلاً من قيام كل نسخ الخدمة بارسال هذا الحدث؛ مع محافظتها على الزمن اللازم لاكتشاف حالة التعطّل من قبل مدير النسخ (Replication Manager). تُظهر نتائج المقارنة بين Jgroup وJavaGroups تفوّق الثانية عند وجود نسخة خدمة واحدة, بينما يتفوّق اداء الاستدعاء في Jgroup على JavaGroups مع تزايد عدد نسخ الخدمة. تظهر النتائج ايضاً تزايد ملحوظ في زمن الاستدعاء في JavaGroups مع تزايد حجم المصفوفة الممررة الى الطريقة المستدعاة. الامر الذي يجعل JavaGroups غير مناسبة للتطبيقات التي تتطلب نقلاً لحجوم كبيرة من البيانات وعدداً كبيراً من المخدمات, بينما تعتبر Jgroup مناسبة لذلك. تبين نتائج تقييم اداء الحل المقترح بانّه يخفّض عدد احداث التجديد المرسلة مقارنةً مع حل ميلينغ تصل في حدّها الاعظمي الى 37.5%, وتستغرق Jgroup/ARM الفترة الزمنية نفسها التي يتطلّبها الحل السابق لاكتشاف تعطّل المجموعة بكاملها.