المحاضرة الثالثة | الكائنات الموزعة والاستدعاء البعيد

بيانات المصدر

هوية المحاضرة الشريحة 1

المصدر الأكاديمي

العنوان الأصلي: Distributed Objects and Remote Invocation.
التاريخ الظاهر: 27/4/2026.
المحاضر: Dr. Eng. Mohssen Abboud.
المحتوى مأخوذ من الفصول 4 و5 و6 و8.

الكتاب المعتمد

Distributed Systems: Concepts and Design للمؤلفين G. Coulouris وJ. Dollimore وT. Kindberg وG. Blair، منشورات Addison Wesley/Pearson Education.

الرجوع إلى الشرائح الأصلية

01

الفكرة الكبرى للمحاضرة الشرائح 2-5

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

التطبيق الموزع

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

الكائن البعيد

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

الواجهة البعيدة

عقد يحدد تواقيع الطرائق التي يمكن لكائنات في عمليات أخرى استدعاؤها على الكائن البعيد.

ثلاثة أساليب للتفاعل بين العمليات
الأسلوب	وحدة الاستدعاء	كيف يبدو للمبرمج؟	طبيعة التفاعل
RPC	إجراء في برنامج خادم	كأنه إجراء محلي	طلب ونتيجة غالبًا
RMI	طريقة في كائن بعيد	كأن الكائن محلي	مرجع وواجهة وطريقة بعيدة
Event-Based	إشعار عن حدث	اشتراك بدل الاستدعاء المباشر	غير متزامن ويفصل الناشر عن المستقبل

خريطة المحاضرة في سطر واحد بيانات البرنامج تتحول إلى بايتات، ثم تدخل رسالة طلب-رد، ثم تقدمها Middleware كـRPC أوRMI، أو تستبدل التزامن المباشر بنشر أحداث وإشعارات.

02

Middleware والشفافية الشرائح 4-9

الـMiddleware برمجيات تقدم نموذج برمجة أعلى من العمليات وتمرير الرسائل، وتستخدم بروتوكولات الرسائل لبناء تجريدات مثل الاستدعاء البعيد والأحداث.

طبقات الاستدعاء البعيد

التطبيقات والخدمات

RMI وRPC

بروتوكول الطلب-الرد

Marshalling والتمثيل الخارجي

UDP وTCP

الشكل 1: كل طبقة تخفي تفاصيل الطبقة الأدنى وتقدم عقدًا أبسط للأعلى.

خصائص الشفافية التي توفرها Middleware
نوع الشفافية	ما الذي تخفيه؟	المثال الوارد
شفافية الموقع	المكان الفعلي للإجراء أو الكائن	عميل RPC/RMI لا يعرف موقع الهدف
شفافية بروتوكول النقل	تفاصيل UDP أوTCP	يمكن تطبيق Request-Reply فوق أي منهما
شفافية العتاد	اختلاف المعمارية وتمثيل البيانات	إخفاء اختلاف ترتيب البايتات
شفافية نظام التشغيل	اختلاف النظام الأساسي	استقلال التطبيق عن نظام التشغيل
شفافية لغة البرمجة	اختلاف لغات المكونات	CORBA تستخدم IDL لتعريف واجهات مشتركة

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

03

التمثيل الخارجي للبيانات الشرائح 10-14

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

External Data Representation

معيار متفق عليه لتمثيل القيم البدائية وبنى البيانات خارج ذاكرة البرنامج.

Marshalling

جمع عناصر البيانات وتجميعها في صيغة مناسبة للإرسال داخل رسالة.

Unmarshalling

تفكيك البيانات الواصلة لبناء مجموعة مكافئة من عناصر البيانات في الوجهة.

من ينفذ التحويل؟

تنفذ طبقة الـMiddleware عمليتي Marshalling وUnmarshalling تلقائيًا عادة، بدل كتابة تحويل يدوي لكل حقل.

خيارا التمثيل على الشبكة

صيغة خارجية متفق عليها: يحول المرسل من تمثيله الداخلي إلى الصيغة الخارجية، ثم يحول المستقبل منها إلى تمثيله الداخلي؛ أي تحويلان.
صيغة المرسل: يرسل المرسل بياناته بصيغته مع مؤشر يحدد هذه الصيغة، ويتولى المستقبل التحويل عند الوصول.

رحلة بنية البيانات

يمنع المعيار اختلاف ترتيب البايتات أو تمثيل الأنواع من تغيير معنى القيمة.

مقارنة أساليب التمثيل الخارجي الثلاثة
الأسلوب	المجال	ما الذي يمثله؟	معلومات النوع	القيد
CORBA CDR	معاملات ونتائج الاستدعاء في CORBA	الأنواع البدائية والمنظمة	لا يحملها؛ يحمل القيم فقط	يفهم النوع من الواجهة المتفق عليها
Java Object Serialization	الإرسال أو التخزين	كائن واحد أو شجرة كائنات بعد تسطيحها	يحملها	خاص بجافا
XML	تبادل بيانات منظمة	تمثيل نصي موسوم	يحملها	صيغة نصية

مثال خطوة بخطوة: جهازان بترتيب بايتات مختلف

تعرف الواجهة نوعي الحقلين: عدد صحيح وقيمة منطقية.
يحول الـMarshaller القيم إلى التمثيل الخارجي المتفق عليه.
توضع البايتات الناتجة في حمولة الرسالة.
يقرأ الخادم المعيار نفسه ويعيد بناء القيم بتمثيله الداخلي.
تحصل الخدمة على المعنى نفسه رغم اختلاف العتاد.

04

بروتوكول الطلب-الرد الشرائح 15-21

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

الطلب-الرد المتزامن

يحجب العميل عمليته بعد الإرسال حتى يصل الرد. هذه هي الحالة الطبيعية في RPC وRMI.

الطلب-الرد غير المتزامن

يتابع العميل عمله ويسترجع النتيجة لاحقًا؛ يفيد عندما لا يلزم انتظار فوري.

لماذا يبنى فوق UDP كثيرًا؟

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

التبادل الطبيعي بين العميل والخادم

العميلdoOperation ثم انتظار

الخادمgetRequest · اختيار الكائن · التنفيذ · sendReply

الشكل 2: يسير Request إلى الخادم، ثم يعود Reply وتستكمل عملية العميل.

عمليات الاتصال الثلاث في الشكل 3
العملية	التوقيع	الوظيفة
`doOperation`	`public byte[] doOperation(RemoteObjectRef o, int methodId, byte[] arguments)`	يرسل الطلب إلى الكائن البعيد ويعيد الرد؛ تحدد المعاملات الهدف والطريقة ومعاملاتها.
`getRequest`	`public byte[] getRequest()`	يلتقط طلب عميل عبر منفذ الخادم.
`sendReply`	`public void sendReply(byte[] reply, InetAddress clientHost, int clientPort)`	يرسل الرد إلى عنوان الإنترنت ومنفذ العميل.

بنية الرسالة

حقول Request/Reply في الشكل 4
الحقل	النوع	الدور
`messageType`	`int`	0 تعني Request و1 تعني Reply.
`requestId`	`int`	مطابقة الرد بالطلب وكشف النسخ المكررة.
`objectReference`	`RemoteObjectRef`	الكائن البعيد المستهدف.
`methodId`	`int or Method`	الطريقة المطلوب تنفيذها.
`arguments`	مصفوفة بايتات	المعاملات بعد Marshalling، أو حمولة النتيجة في تصميم الرد.

MessageIdentifier = (senderProcessId, requestId) requestId فريد داخل المرسل، وهوية العملية - مثل عنوان IP والمنفذ - تجعل الزوج فريدًا في النظام كله.

قاعدة المطابقة الرقم 12 عند عميل A ليس هو الطلب 12 عند عميل B؛ الفريد عالميًا هو هوية المرسل مع رقم طلبه المتزايد.

05

الفشل والتكرار وأنماط التبادل الشرائح 22-27

عند تنفيذ العمليات الثلاث فوق UDP ترث فشل الحذف، وغياب ضمان ترتيب الرسائل، وإمكان فشل العمليات. لذلك نحتاج إلى مؤقتات ومعرفات وترشيح للتكرار وسجل للردود.

Omission Failure

قد يضيع الطلب قبل الخادم أو يضيع الرد بعد تنفيذ العملية.

غياب الترتيب

لا تضمن رزم UDP الوصول بترتيب إرسالها.

فشل العمليات

قد ينهار العميل أو الخادم في مرحلة تجعل نتيجة الاستدعاء غير معلومة.

ماذا يحدث عند انتهاء المهلة؟

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

Idempotent Operation

عملية يمكن تكرارها وتبقى حالتها النهائية كما لو نفذت مرة واحدة فقط.

setBalance(100) مثال تقريبي Idempotent، أما incrementBalance(100) فليست كذلك.

History

سجل يسمح بإعادة الرد من دون إعادة تنفيذ العملية. يحوي معرف الطلب والرسالة ومعرف العميل.

له كلفة ذاكرة؛ يمكن حفظ آخر رد لكل عميل وحذف الردود بعد مدة محدودة.

قرار الخادم عند وصول طلب مكرر

إذا لم يكن الرد قد أرسل: يكمل الخادم التنفيذ ويرسل الرد عند الانتهاء.
إذا كان الرد قد أرسل: يعيد التنفيذ للحصول على النتيجة، أو يعيد الرد المحفوظ في History.
إذا كانت كل العمليات Idempotent فلا يحتاج الخادم إلى إجراء خاص لمنع تكرار أثرها.
للعمليات غير Idempotent يجب ترشيح التكرار وإعادة الرد القديم بدل إعادة التنفيذ.

أنماط تبادل RPC في الشكل 5
البروتوكول	رسالة العميل الأولى	رسالة الخادم	رسالة العميل الأخيرة	الاستخدام
R	Request	لا يوجد	لا يوجد	عندما لا تعيد الطريقة قيمة.
RR	Request	Reply	لا يوجد	معظم تبادلات العميل والخادم.
RRA	Request	Reply	Acknowledge Reply	عندما يحتاج الخادم إلى تأكيد وصول الرد.

عدد الرسائل في كل نمط

R

Client -> Request -> Server

رسالة واحدة.

RR

Client -> Request -> Server
Client <- Reply <- Server

رسالتان.

RRA

Request -> Reply -> Ack

ثلاث رسائل.

الإقرار الأخير في RRA يخبر الخادم أن العميل استلم الرد.

06

RPC والبرمجة بالواجهات الشرائح 28-32

في Remote Procedure Call يستدعي برنامج العميل إجراء داخل برنامج خادم بعيد. يخفي نظام RPC ترميز المعاملات والنتائج وفكها، ويبنى عادة فوق بروتوكول الطلب-الرد.

حدود RPC RPC يتعامل مع الإجراءات فقط، ولا يعالج الكائنات أو مراجع الكائنات. الانتقال إلى هذه المفاهيم هو ما يضيفه RMI.

لماذا الواجهات مهمة؟

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

Service Interface

مواصفة الإجراءات التي يتيحها الخادم للاستدعاء البعيد من العملاء.

Interface Definition Language

لغة محايدة تسمح لإجراءات مكتوبة بلغات مختلفة باستدعاء بعضها، وتحدد نوع كل معامل وهل هو Input أوOutput.

مثال IDL المذكور

Sun XDR مثال على لغة تعريف واجهة لـRPC. يقرأ مترجم الواجهة العقد ويولد كود الربط على الطرفين، بحيث يتفقان على الأنواع واتجاه المعاملات.

07

دلالات استدعاء RPC الشرائح 33-35

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

Retry Request

هل يعاد إرسال الطلب حتى يصل الرد أو يفترض فشل الخادم؟

Duplicate Filtering

هل يكتشف الخادم الطلب المعاد ويمنع تنفيذه من جديد؟

Retransmit Result

هل يحفظ الخادم النتيجة كي يعيد الرد الضائع بلا إعادة تنفيذ؟

جدول دلالات الاستدعاء كما في الشكل 6
إعادة الطلب	ترشيح التكرار	تصرف الخادم	الدلالة
لا	غير منطبق	غير منطبق	Maybe
نعم	لا	إعادة تنفيذ الإجراء	At-least-once
نعم	نعم	إعادة إرسال الرد المحفوظ	At-most-once

Maybe

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

At-least-once

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

At-most-once

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

قاعدة اختيار سريعة لا إعادة إرسال = Maybe. إعادة إرسال بلا ترشيح = At-least-once. إعادة إرسال مع ترشيح وسجل نتيجة = At-most-once.

اختبر فهمك

يعيد العميل الطلب عند انتهاء المهلة، ويكتشف الخادم معرف الطلب المكرر ثم يعيد النتيجة المحفوظة. ما الدلالة؟

At-most-once؛ لأن الإعادة موجودة، والترشيح موجود، والخادم يعيد الرد بدل تنفيذ الإجراء ثانية.

08

تنفيذ RPC الشرائح 36-40

يمكن تطبيق RPC بدلالات مختلفة، وغالبًا تختار الأنظمة At-least-once أوAt-most-once. يخفي التنفيذ شبكة كاملة من الـStubs والـDispatcher ووحدات الاتصال خلف استدعاء واحد.

مكونات الشكل 7 ومسؤولية كل مكوّن
المكوّن	المكان	المسؤولية
Client Program	عملية العميل	يستدعي الإجراء كما لو كان محليًا.
Client Stub	عملية العميل	يجمع معرف الإجراء ومعاملاته، ويرسل، ثم يفك النتائج.
Communication Module	الطرفان	ينفذ الطلب-الرد ودلالة الإعادة والترشيح وإرسال النتائج.
Dispatcher	عملية الخادم	يختار Server Stub وفق معرف الإجراء.
Server Stub	عملية الخادم	يفك المعاملات ويستدعي الخدمة ثم يجمع القيم الراجعة.
Service Procedure	عملية الخادم	ينفذ منطق الإجراء الحقيقي في واجهة الخدمة.

مسار الطلب ثم الرد

1. Client Program يستدعي Client Stub

2. Client Stub: Marshalling وإرسال Request

3. وحدتا الاتصال تنفذان Request-Reply

4. Dispatcher يختار Server Stub

5. Server Stub: Unmarshalling ثم Service Procedure

6. النتيجة تجمع في Reply وتعود بالعكس

يمكن توليد Client Stub وServer Stub والـDispatcher آليًا من IDL الخدمة.

ينادي برنامج العميل الـClient Stub المحلي.
يجمع الـStub معرف الإجراء والمعاملات في Request ويرسلها عبر Communication Module.
تسلم وحدة اتصال الخادم الرسالة إلى Dispatcher.
يقرأ الـDispatcher معرف الإجراء ويختار Server Stub الصحيح.
يفك Server Stub المعاملات ويستدعي Service Procedure.
تعود القيم إلى Server Stub فيجمعها في Reply.
يفك Client Stub النتيجة ويعيدها إلى برنامج العميل.

علاقة RPC بـRMI Client Stub يشبه Proxy في RMI، وServer Stub يشبه Skeleton. المثال المذكور في الشرائح هو Sun RPC.

09

RMI ونموذج الكائن الموزع الشرائح 41-49

RMI يمد فكرة RPC إلى الكائنات. لا يكفي تحديد الإجراء؛ يجب معرفة الكائن الهدف عبر مرجع بعيد، وتحديد الطرائق المتاحة في واجهة بعيدة.

نموذج الكائن المحلي أولًا

Object Reference

وسيلة الوصول إلى كائن؛ الاستدعاء يحتاج المرجع واسم الطريقة والمعاملات.

Interface

مجموعة تواقيع طرائق، ويمكن لصنف واحد تنفيذ عدة واجهات كما في Java.

Action

يبدأ باستدعاء طريقة، وقد يغير حالة المستقبل أو يطلق استدعاءات أخرى.

حالة الكائن هي قيم متغيرات النسخة. ولأن حالة البرنامج الكائني مقسمة منطقيًا بين كائنات، يصبح توزيعها فعليًا بين عمليات وحواسيب امتدادًا طبيعيًا. أما Garbage Collection فيحرر مساحة الكائنات غير المستخدمة؛ تشير الشرائح إلى إدارة المبرمج في C++ وإدارة JVM في Java.

استدعاءات محلية وبعيدة

B وF مثالان للكائنات البعيدة. يحتاج A مرجعًا بعيدًا لـB، بينما يحتاج C مرجعًا عاديًا لـE داخل العملية نفسها.

Remote Object Reference

معرف فريد عالميًا في النظام الموزع يشير إلى كائن بعيد محدد، ويمكن تمريره كمعامل أو نتيجة لـRMI.

Remote Interface

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

قد تبدأ Action باستدعاء واحد ثم تمتد كسلسلة عبر عمليات وحواسيب مختلفة. يجب أن يتوفر المرجع البعيد للهدف؛ في مثال الشرائح يحتاج A مرجع B، وقد يحصل A من B على مرجع F كنتيجة للاستدعاء.

تحويل عناصر نموذج الكائن إلى نموذج موزع - الشريحة 49
العنصر المحلي	النظير الموزع	الوصف
Object References	Remote Object References	مرجع فريد عالميًا لكائن موزع ويمكن تمريره كمعامل.
Interfaces	Remote Interfaces	توصيف مجرد للطرائق القابلة للاستدعاء عن بعد، ويحدد باستخدام IDL.
Actions	Distributed Actions	سلسلة استدعاءات تبدأ بطريقة، وتستخدم RMI عند عبور حدود العملية.
Exceptions	Distributed Exceptions	استثناءات إضافية بسبب ضياع الرسالة أو فشل العملية.
Garbage Collection	Distributed Garbage Collection	يبقى الكائن ما دام له مرجع محلي أو بعيد واحد على الأقل، وإلا يزال بخوارزمية موزعة.

Distributed Garbage Collection

ينجز بتعاون جامع القمامة المحلي مع وحدة إضافية، وغالبًا يعتمد على Reference Counting.

Distributed Exception

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

10

تنفيذ RMI الشرائح 50-57

في الشكل 10 يستدعي الكائن A طريقة على B البعيد. يتوسط بينهما Proxy ووحدتا اتصال ومراجع، ثم Dispatcher وSkeleton على الخادم.

المكونات على جانبي RMI

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

الوحدات الأساسية
المكوّن	المسؤولية الدقيقة
Communication Module	Request/Reply، وتعاون الطرفين لتقديم دلالة مثل At-most-once، واختيار Dispatcher في الخادم.
Remote Reference Module	التحويل بين المرجع المحلي والبعيد، وإنشاء Remote Object Reference، وإدارة Remote Object Table.
Proxy	يجعل RMI شفافًا؛ يطبق الواجهة البعيدة ويجمع مرجع الهدف وoperationId والمعاملات ثم يفك الرد.
Skeleton	يفك المعاملات، ويستدعي الطريقة الحقيقية على الكائن البعيد، وينتظرها، ثم يجمع النتيجة.
Dispatcher	يستقبل الطلب ويختار طريقة Skeleton المناسبة باستخدام operationId.
Binder	يحفظ ربط الأسماء النصية بمراجع الكائنات البعيدة كي يجد العميل الخدمة.

Remote Object Table

جدول الخادم

يحوي مدخلات للكائنات البعيدة الموجودة في العملية. يسجل الكائن B في جدول الخادم.

جدول العميل

يحوي مدخلات للـProxies المحلية. يسجل Proxy الذي يمثل B في جدول العميل.

عند تمرير كائن بعيد للمرة الأولى كمعامل أو نتيجة، تطلب برمجيات RMI إنشاء Remote Object Reference وإضافته إلى الجدول.
عند وصول مرجع بعيد في Request أوReply، تطلب البرمجيات المرجع المحلي المقابل.
قد يشير المرجع المحلي إلى الكائن الحقيقي في الخادم أوإلى Proxy في العميل.
إذا لم يوجد المرجع في الجدول، تنشئ برمجيات RMI Proxy جديدًا وتضيفه الوحدة إلى الجدول.
تستخدم الوحدة خلال Marshalling وUnmarshalling لمراجع الكائنات البعيدة.

Proxy بالتفصيل

يوجد واحد لكل كائن بعيد تحمل العملية مرجعًا له. يتصرف محليًا ظاهريًا، لكنه يرسل رسالة ويحجب حتى الرد ثم يعيد النتيجة.

Skeleton بالتفصيل

لصنف الكائن البعيد Skeleton يطبق طرائق الواجهة بوظيفة وسيطة: Unmarshal ثم Invoke ثم Marshal.

Dispatcher بالتفصيل

واحد مع Skeleton لكل صنف بعيد. يجب أن يتفق مع Proxy على تخصيص operationId لكل طريقة.

رحلة RMI الكاملة

يبحث العميل في Binder عن اسم الخدمة ويحصل على Remote Object Reference للكائن B.
تحول وحدة المراجع المرجع إلى Proxy محلي أوتعيد Proxy مسجلًا مسبقًا.
يستدعي A طريقة على Proxy كما لو كان B محليًا.
يجمع Proxy مرجع B وoperationId والمعاملات ويرسل Request.
تستقبل وحدة اتصال الخادم الرسالة وتحدد Dispatcher.
يختار Dispatcher طريقة Skeleton وفق operationId.
يفك Skeleton المعاملات ويستدعي الطريقة الحقيقية في B.
يعيد B النتيجة، فيجمعها Skeleton داخل Reply.
تعود الرسالة، ويفك Proxy النتيجة، ثم يعيدها إلى A.

كيف تنشأ هذه الأصناف؟ يولد مترجم الواجهة Proxies وDispatchers وSkeletons آليًا؛ المثال المذكور rmic. ينشئ الخادم كائنًا بعيدًا واحدًا على الأقل ويسجله باسم، ثم يبحث العميل عن المرجع ويستدعي.

11

البرمجة الموزعة المعتمدة على الأحداث الشرائح 58-61

بدل أن يستدعي كائنٌ كائنًا آخر وينتظر، يعلن المنتج عن نوع حدث ويشترك المهتمون فيه. عند وقوع الحدث تصلهم Notification بصورة غير متزامنة.

أمثلة المحاضرة

تعديل مستند.
انتقال كتاب موسوم إلكترونيًا إلى موقع جديد.

خصائص النظام الحدثي

Heterogeneous: يربط مكونات لم تصمم أصلًا للعمل معًا.
Asynchronous: لا يحتاج الناشر إلى التزامن مع المشترك.

دورة Publish/Subscribe

يعلن مولد الحدث أنواع الأحداث التي سينشرها.
يشترك المستقبل في الأنواع التي تهمه.
عند وقوع الحدث تنشأ Notification وتحول إلى المشترك المناسب.

خدمة الأحداث تفصل الناشر عن المشترك

تحفظ Event Service قاعدة بيانات للأحداث المنشورة واهتمامات المشتركين، وتمنع اعتماد الناشر على مواقع المشتركين أو جاهزيتهم.

يعرض الرسم الأصلي ثلاثة ترتيبات: كائن اهتمام داخل الخدمة يرسل مباشرة إلى المشترك؛ كائن يمر إشعاره عبر Observer؛ وكائن اهتمام خارج حدود الخدمة مع Observer يعمل داخلها.

أدوار الكائنات المشاركة
الدور	التعريف
Object of Interest	كائن قد تهم تغيرات حالته كائنات أخرى.
Event	يحدث عند كائن الاهتمام عند اكتمال تنفيذ طريقة.
Notification	كائن يحمل معلومات عن الحدث.
Subscriber	كائن اشترك في نوع حدث لدى كائن آخر.
Observer	وسيط يفصل كائن الاهتمام عن مشتركيه ويمنع تعقيده.
Publisher	كائن يعلن أنه سينتج إشعارات لأنواع محددة؛ قد يكون كائن الاهتمام نفسه أوObserver.

دلالات تسليم الإشعارات
الدلالة	متى تناسب؟	مثال الشريحة
Unreliable	حين تكفي أحدث حالة ولا يلزم كل تحديث وسيط.	أحدث حالة للاعب في لعبة إنترنت.
Reliable	حين لا يجوز فقد إشعار مهم.	غرفة تداول Dealing Room.
Real-time	حين يجب الوصول ضمن حد زمني.	محطة طاقة نووية أومراقب مريض في مستشفى.

Forwarding

يرسل Observer إشعارات للمشتركين نيابة عن كائن اهتمام واحد أوأكثر.

Filtering

يمرر Observer الإشعار فقط إذا حقق Predicate محددًا.

Notification Mailbox

يؤخر الإشعار ويحفظه حتى يصبح المشترك مستعدًا للاستلام.

12

مسائل ومواقف محلولة

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

مسألة 1: ضاع Request قبل وصوله

المعطى: أرسل العميل عبر UDP ولم يصل رد.

تنتهي مهلة doOperation.
في Maybe يعود فشل بلا إعادة إرسال.
في At-least-once أوAt-most-once يعاد الطلب.
يستعمل الطلب المعاد requestId نفسه كي يكشف الخادم أي نسخة متأخرة من الأصل.

مسألة 2: نفذ الخادم عملية مالية ثم ضاع Reply

المعطى: العملية chargeCard(100) غير Idempotent.

يعيد العميل الطلب بعد Timeout.
يتعرف الخادم إلى زوج هوية العميل وrequestId.
إن أعاد التنفيذ يخصم المال مرتين؛ إذن At-least-once غير مناسبة.
يطبق At-most-once: يرشح النسخة ويعيد Reply المحفوظ في History.

مسألة 3: اختر R أوRR أوRRA

الحالة	الاختيار	السبب
إشعار لا يعيد قيمة	R	لا حاجة إلى Reply.
قراءة ملف وإرجاع المحتوى	RR	يلزم Request وReply.
يجب أن يعرف الخادم أن الرد وصل كي يحذف سجله	RRA	يلزم Acknowledge Reply.

مسألة 4: استنتج دلالة RPC من إجراءات التحمل

اسأل: هل يعيد العميل الطلب؟ إن لا، فالدلالة Maybe.
إن نعم، اسأل: هل يرشح الخادم الطلب المكرر؟ إن لا، فهي At-least-once.
إن نعم، اسأل: هل يعيد الخادم الرد المحفوظ من دون تنفيذ؟ إن نعم، فهي At-most-once.
افحص Idempotence دائمًا؛ العملية غير Idempotent تحتاج منع التكرار.

مسألة 5: أين يحدث الخلل في رحلة RMI؟

المعطى: وصل Request إلى الخادم لكن operationId لا يطابق أي طريقة.

Communication Module نجحت في النقل.
المرجع البعيد قد يكون صحيحًا لأن الطلب وصل إلى Dispatcher.
يفشل Dispatcher في اختيار طريقة Skeleton.
راجع اتفاق Proxy وDispatcher على تخصيص operationId من الواجهة نفسها.

مسألة 6: نظام مراقبة مريض

جهاز القياس هو Object of Interest وPublisher.
الإشعار يحمل هوية المريض والقراءة والوقت.
يطبق Observer مرشحًا لتمييز القراءة الحرجة.
ترسل القراءة الحرجة بدلالة Real-time.
يمكن حفظ التنبيه العادي في Notification Mailbox حتى يجهز تطبيق الطبيب.
لا ينتظر الجهاز الطبيب؛ يبقى النظام Asynchronous.

مقارنة نهائية بين RPC وRMI والأحداث
المعيار	RPC	RMI	Event-Based
الهدف	إجراء بعيد	طريقة كائن بعيد	مشتركون في نوع حدث
معرف الهدف	معرف الإجراء	Remote Object Reference وoperationId	نوع الحدث واهتمام المشترك
الوسيط المحلي	Client Stub	Proxy	Event Service/Observer
وسيط الخادم	Dispatcher وServer Stub	Dispatcher وSkeleton	لا يوجد خادم مستدعى بالمعنى نفسه
التزامن	متزامن غالبًا	متزامن غالبًا	غير متزامن

13

خريطة الشرائح الكاملة 61 من 61

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

افتح جرد الشرائح 1-61

الشريحة 1 · الغلاف والمصدر

العنوان والتاريخ 27/4/2026، واسم المحاضر، والفصول 4 و5 و6 و8، وكتاب Coulouris وزملائه والناشر Addison Wesley/Pearson.

الشريحة 2 · موضوعات المحاضرة

المقدمة، Request-Reply، RPC، RMI، والبرمجة الموزعة المعتمدة على الأحداث.

الشريحة 3 · التطبيق والكائن البعيد

التطبيق الموزع برامج متعاونة في عمليات مختلفة. تحتاج البرامج إلى عمليات بعيدة، والكائن المستقبل لـRMI يسمى Remote Object ويطبق Remote Interface.

الشريحة 4 · محورا الاتصال الأولان

External Data Representation يحول البنى إلى رسائل مع اختلاف تمثيلات الحواسيب، وRequest-Reply نمط ثنائي الاتجاه فوق تمرير الرسائل.

الشريحة 5 · RPC وRMI والأحداث

RPC إجراء بعيد يبدو محليًا، وRMI طريقة كائن بعيد تبدو محلية، والنظام الحدثي يوصل إشعارات غير متزامنة.

الشريحة 6 · تعريف Middleware

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

الشريحة 7 · طبقات Middleware

UDP/TCP ثم Marshalling والتمثيل الخارجي، ثم Request-Reply، ثم RPC/RMI، ثم التطبيقات والخدمات.

الشريحة 8 · شفافية الموقع والنقل

لا يعرف العميل موقع الهدف، ويمكن لبروتوكول Request-Reply المستخدم في RPC العمل فوق UDP أوTCP.

الشريحة 9 · شفافية العتاد والنظام واللغة

إخفاء ترتيب البايتات، والاستقلال عن نظام التشغيل، ودعم لغات متعددة؛ المثال CORBA وIDL.

الشريحة 10 · البنية مقابل البايتات

البرنامج يخزن بنى، والرسالة بايتات؛ يجب التحويل قبل الإرسال وإعادة البناء عند الوصول.

الشريحة 11 · External Data Representation

معيار متفق عليه. إما تمثيل خارجي بتحويلين أوصيغة المرسل مع مؤشر للصيغة وتحويل لدى المستقبل.

الشريحة 12 · Marshalling وUnmarshalling

الأولى تجمع البيانات للإرسال، والثانية تفك البيانات الواصلة لبناء عناصر مكافئة.

الشريحة 13 · الأساليب الثلاثة

CORBA CDR وJava Object Serialization وXML، مع تنفيذ Middleware للتحويلين تلقائيًا عادة.

الشريحة 14 · مقارنة أساليب التمثيل

CORBA للأنواع في معاملات/نتائج الاستدعاء وتحمل القيم فقط؛ Java تسطح كائنًا أوشجرة وهي خاصة بجافا؛ XML صيغة نصية. Java وXML تحملان معلومات النوع.

الشريحة 15 · طبيعة Request-Reply

يدعم العميل والخادم، متزامن غالبًا لأن العميل يحجب حتى الرد، والرد إقرار فعلي. يوجد بديل غير متزامن لاسترجاع الرد لاحقًا.

الشريحة 16 · لماذا UDP؟

لا حاجة إلى إقرار نقل منفصل، ولا كلفة إنشاء اتصال، ولا تحكم تدفق كبير عند قلة البيانات.

الشريحة 17 · العمليات الثلاث

doOperation في العميل، وgetRequest ثم اختيار الكائن والتنفيذ وsendReply في الخادم، مع سهم Request وسهم Reply.

الشريحة 18 · المطابقة وضمان التسليم

يطابق البروتوكول الطلبات بالردود، ويقدم ضمانات UDP المطلوبة، ويمكن لرد الخادم أن يكون إقرارًا بالطلب.

الشريحة 19 · تواقيع العمليات

التواقيع الكاملة لـdoOperation وgetRequest وsendReply، مع RemoteObjectRef وmethodId ومصفوفة المعاملات وعنوان العميل ومنفذه.

الشريحة 20 · بنية الرسالة

messageType وrequestId وobjectReference وmethodId وarguments، مع 0 للطلب و1 للرد.

الشريحة 21 · معرف الرسالة

معرف فريد مركب من requestId متزايد داخل المرسل ومعرف عملية المرسل مثل IP والمنفذ.

الشريحة 22 · نموذج فشل Request-Reply

Omission Failure وعدم ضمان ترتيب المرسل وفشل العمليات، مع Timeouts والطلب المكرر والرد الضائع وHistory.

الشريحة 23 · Timeout وإعادة الطلب

قد تعود doOperation بفشل أوتعيد الطلب. التكرار قد ينفذ العملية مرات، لذا يكشف الخادم هوية العميل وrequestId ويصفي النسخ.

الشريحة 24 · Idempotence وHistory

إذا لم يرسل الرد يكمل الخادم؛ وإن أرسله فإما يعيد التنفيذ أوالرد المخزن. تعرف Idempotent، وتشرح سجل الرد وتكلفة ذاكرته وحذف مدخلاته بعد مدة.

الشريحة 25 · أنماط التبادل

ثلاثة بروتوكولات في وجود فشل الاتصال: R وRR وRRA.

الشريحة 26 · جدول R وRR وRRA

R: Request فقط. RR: Request ثم Reply. RRA: Request ثم Reply ثم Acknowledge Reply.

الشريحة 27 · استخدام الأنماط

R بلا قيمة راجعة، وRR لمعظم العميل والخادم، وRRA بثلاث رسائل لتأكيد الرد.

الشريحة 28 · تعريف RPC

العميل يستدعي إجراء في برنامج خادم، والنظام يخفي ترميز وفك المعاملات والنتائج، ويبنى فوق Request-Reply.

الشريحة 29 · مدخلا فهم RPC

البرمجة بالواجهات ودلالات الاستدعاء في وجود الفشل.

الشريحة 30 · الواجهات في البرنامج

الوحدات تتواصل بالإجراءات أوالمتغيرات؛ الواجهة تحدد المتاح وتخفي التنفيذ وتجعل الوصول من خلال طرائق محددة.

الشريحة 31 · Service Interface

الوحدات موزعة على عمليات؛ الخادم يقدم إجراءات للعملاء. لا وصول مباشر لمتغير بعيد، بل رسائل وRequest-Reply.

الشريحة 32 · IDL

تسمح للغات مختلفة بالتعامل وتحدد نوع كل معامل واتجاهه Input/Output؛ المثال Sun XDR.

الشريحة 33 · خيارات تحمل الفشل

إعادة طلب، وترشيح تكرار، وحفظ نتائج لإعادة الرد من دون إعادة تنفيذ؛ تركيبها يحدد دلالة RPC.

الشريحة 34 · جدول دلالات RPC

لا إعادة = Maybe؛ إعادة بلا ترشيح مع إعادة تنفيذ = At-least-once؛ إعادة مع ترشيح وإعادة الرد = At-most-once.

الشريحة 35 · تفسير الدلالات

Maybe مرة أوصفر، At-least-once مرة أوأكثر/استثناء، At-most-once نتيجة أو استثناء مع منع التنفيذ المتكرر.

الشريحة 36 · تمهيد تنفيذ RPC

يمكن لـRPC وRMI اختيار الدلالات، وAt-least-once وAt-most-once هما الشائعان، ثم يقدم الشكل 7.

الشريحة 37 · بنية RPC

Service Interface، وCommunication Module، وClient Stub، وDispatcher، وServer Stub، وService Procedure. يمكن توليد الـStubs والـDispatcher من IDL.

الشريحة 38 · حدود RPC والتشابه

RPC للإجراءات لا الكائنات. Client Stub يشبه Proxy، وServer Stub يشبه Skeleton.

الشريحة 39 · Client Stub

يبدو إجراء محليًا لكنه يجمع المعرف والمعاملات ويرسل الطلب، ثم يفك النتائج عند الرد.

الشريحة 40 · جانب الخادم

Dispatcher يختار Server Stub، والـStub يفك ويستدعي الخدمة ويجمع النتائج. المثال Sun RPC.

الشريحة 41 · تمهيد RMI

RMI يمد RPC إلى الكائنات؛ المحاور: نموذج الكائن والكائنات الموزعة والنموذج الموزع والتنفيذ.

الشريحة 42 · نموذج الكائن

الكائن بيانات وطرائق ويتفاعل بالاستدعاء. الوصول عبر Object Reference، والاستدعاء يحتاج المرجع والطريقة والمعاملات.

الشريحة 43 · واجهة وفعل وجمع قمامة

الواجهة تواقيع، والفعل يغير الحالة أوينتج استدعاءات، وجمع القمامة يديره المبرمج في C++ وJVM في Java وفق الشريحة.

الشريحة 44 · حالة الكائن وتوزيعه

الحالة قيم Instance Variables؛ تقسيم البرنامج إلى كائنات يجعل توزيعها على عمليات وحواسيب امتدادًا طبيعيًا.

الشريحة 45 · نموذج الكائن الموزع

تمييز Local وRemote Invocation. B وF بعيدان، وC يحتاج مرجع E، وA يحتاج Remote Reference لـB، وB وF يحتاجان Remote Interfaces.

الشريحة 46 · المرجع والواجهة البعيدان

المرجع معرف فريد ويمكن تمريره؛ الكائنات البعيدة لا تعرض إلا طرائق الواجهة البعيدة للعمليات الأخرى.

الشريحة 47 · Distributed Actions

قد تمتد سلسلة الاستدعاء عبر عمليات وحواسيب. يحتاج A مرجع B، وقد يحصل من B على مرجع F كنتيجة بعيدة.

الشريحة 48 · جمع القمامة والاستثناء

جامع محلي مع وحدة إضافية، غالبًا Reference Counting. قد يفشل RMI بسبب التوزيع ويجب إخطار العميل باستثناء.

الشريحة 49 · جدول النموذج الموزع

مقارنة المراجع والواجهات والأفعال والاستثناءات وجمع القمامة بنظائرها الموزعة ووصف كل امتداد.

الشريحة 50 · تمهيد تنفيذ RMI

A يستدعي B بمرجع بعيد، وتعرض الشرائح التالية وحدات الاتصال والمراجع ثم برمجيات RMI فوقها.

الشريحة 51 · مخطط تنفيذ RMI

A وProxy ووحدتا الاتصال والمراجع في العميل، وDispatcher/Skeleton وB والوحدتان في الخادم، مع Request وReply.

الشريحة 52 · وحدتا الاتصال والمراجع

Communication Module تنفذ التبادل والدلالة وتختار Dispatcher؛ Remote Reference Module تترجم وتنشئ المراجع وتدير الجدول.

الشريحة 53 · Remote Object Table

B في جدول الخادم وProxy B في جدول العميل. ينشأ مرجع عند التمرير الأول، وينشأ Proxy إذا وصل مرجع غير موجود.

الشريحة 54 · Proxy

يجعل RMI شفافًا، واحد لكل كائن بعيد لدى العملية، ويجمع مرجع الهدف وoperationId والمعاملات وينتظر ويفك النتيجة.

الشريحة 55 · Skeleton

يفك معاملات الطلب، ويستدعي الطريقة المقابلة في الكائن البعيد، وينتظر، ثم يجمع النتيجة في Reply.

الشريحة 56 · Dispatcher

واحد مع Skeleton لكل صنف بعيد، يختار الطريقة بـoperationId، ويجب أن يتفق في الترقيم مع Proxy.

الشريحة 57 · التنفيذ وBinder

يولد مترجم الواجهة Proxies وDispatchers وSkeletons مثل rmic. الخادم ينشئ ويسجل، والعميل يبحث ويستدعي، والـBinder يربط الاسم بالمرجع.

الشريحة 58 · Event-Based Programming

تفاعل مع تغير في كائن آخر؛ أمثلة المستند والكتاب الموسوم. نشر نوع الحدث والاشتراك والإخطار. النظام Heterogeneous وAsynchronous.

الشريحة 59 · Event Service

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

الشريحة 60 · أدوار النظام الحدثي

Object of Interest وEvent وNotification وSubscriber وObserver وPublisher، مع دور Observer في الفصل وتجنب تعقيد الكائن.

الشريحة 61 · تسليم الإشعار

Unreliable للعبة، وReliable لغرفة التداول، وReal-time للمحطة النووية أوالمريض. أدوار Observer: Forwarding وFiltering وNotification Mailboxes.

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