ترغب بنشر مسار تعليمي؟ اضغط هنا

يتطلّب الاعتماد المتزايد على الأنظمة الشبكية في النشاطات اليومية تزويدها لخدمات متوفّرة و موثوقة. تزوّد 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 الفترة الزمنية نفسها التي يتطلّبها الحل السابق لاكتشاف تعطّل المجموعة بكاملها.
mircosoft-partner

هل ترغب بارسال اشعارات عن اخر التحديثات في شمرا-اكاديميا