logo

logo

logo

logo

logo

استدعاء الإجراء من بعد

استدعاء اجراء من بعد

Remote procedure call (RPC) - Appel de procédure distante(RPC)

استدعاء الإجراءات من بُعد

محمد جاسم المحمد

 

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

إذا كانت الإجراءات والبرامج التي تستدعي هذه الإجراءات تعمل على الحاسوب نفسه فإن عملية استدعاء الإجراء سهلة، إذ وفَّرت البرمجة الإجرائية (البنيوية) structural programming أو البرمجة الغرضية التوجه object-oriented programming آلية فعالة للقيام بذلك. يكفي في البرمجة الغرضية التوجه مثلاً الحصول على مرجع reference للصف class المراد استدعاء إحدى خدماته، ثم يمكن استدعاء الإجراء المطلوب بعد تمرير القيم المناسبة لموسطاته. لكن هذه الآلية البسيطة والفعالة لا تستطيع التعامل مع النظم البرمجية المتقدمة. ومع ظهور خدمات الوِب web services والنظم الموزَّعة عموماً distributed systems أصبح طالب الخدمة والخدمة ذاتها في أماكن متباعدة، وربما تعمل على حواسيب بعتاديات hardware مختلفة وتستخدم منصات برمجية مختلفة platforms، وتستخدم طرقاً مختلفة لتمثيل المعطيات.

الاستدعاء من بُعد Remote Procedure Call (RPC):

هو آلية تمكِّن من استدعاء إجراءات على حواسيب بعيدة من دون أن يقوم المبرمج بكتابة أي تعليمات خاصة. وبكلمات أبسط يستطيع المبرمج باستخدامها استدعاء إجراء على حاسوب بعيد وكأنه يقوم باستدعاء إجراء مخزَّن على الحاسوب نفسه.

مفاهيم أساسية:

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

برنامج تواجه الزبون client stub: يقوم بتحويل الاستدعاء لإجراء معين إلى رسالة يمكن إرسالها عبر الشبكة ليستقبلها الإجراء المخزَّن على المخدِّم. كما يقوم بتحويل نتيجة تنفيذ الإجراء إلى شكل يستطيع البرنامج المستدعي التعامل معه.

برنامج تواجه المخدِّم server stub: مكوّن برمجي يحوّل الطلبات القادمة إلى المخدِّم إلى استدعاء لإجراء معين على المخدِّم، حيث يقوم بتحليل الرسالة، واستخراج القيم منها، ثم استدعاء الإجراء المطلوب على المخدِّم. بالنسبة إلى المخدم يبدو طلب الإجراء وكأنه استدعاء داخلي وليس استدعاء من بُعد.

ويوضح الشكل (1) مبدأ عمل استدعاء الإجراء من بُعد.

الوصف: 13-1.psd
الشكل (1): مبدأ عمل استدعاء الإجراء من بعد

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

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

استدعاء الأغراض البعيدة «كوربا»common object request broker architecture (CORBA)

هو بنيان معياري وضعه فريق إدارة الأغراض object management group (OMG) لتوفير التوافق بين التطبيقات الموزّعة، وهو حل رائد لتمكين تبادل المعلومات بين التطبيقات بصورة مستقلة عن الأنظمة الأساسية للعتاديات، ولغات البرمجة وأنظمة التشغيل. تعدّ «كوربا» في جوهرها تصميماً لمقاول أغراض object request broker(ORB)، إذ يوفر هذا المقاول الآلية اللازمة للاتصال بين الأغراض الموزّعة محلياً أو على الحواسيب البعيدة. ومن مهماته الرئيسية تحديد موقع الكائن البعيد على الشبكة، وإرسال الاستدعاء إلى الكائن الواقع على المخدِّم، والتوقف لانتظار النتائج. وعندما تتوفر هذه النتائج يعيدها إلى طالب الخدمة (الزبون).

يعتمد البنيان CORBA على مفهوم «لغة تعريف الواجهة» interface definition language (IDL). وهي لغة تُستخدم لتعريف واجهات بين الأغراض بصورة مستقلة عن واجهات التطبيقات application programming interfaces (API). إضافة إلى ذلك يوفر المفهوم IDL القدرة على تحقيق التوافق بين الزبون/المخدِّم في بيئات غير متجانسة، وذلك عن طريق تعريف موحّد للبيانات والعمليات. لا تعدّ لغة تعريف الواجهة IDL في الواقع لغة برمجية، بل هي لغة تعريف واجهات (إجراءات ومعطيات وغيرها)، يمكن أن تُترجم إلى اللغة البرمجية التي كتب بها طالب الخدمة على شكل برنامج تواجه، وتُترجم إلى اللغة البرمجية التي كتب بها المخدِّم على شكل «هيكل» skelton. ويمكن توضيح طريقة عمل الاستدعاء CORBA في الشكل(2).

الوصف: 13-2.psd
CORBA الشكل (2): مبدأ عمل الاستدعاء

يوضح الشكل(2) أنه لاستدعاء إجراء في المخدِّم البعيد يقوم طالب الخدمة الزبون باستدعاء الإجراءات المتوفرة في برنامج التواجه، ويقوم المقاول ORB بمعالجة الطلب وإرساله إلى المخدِّم المناسب (الذي يحوي الخدمة المطلوبة) عن طريق «الهيكل» يقوم الإجراء المستدعى (المخزّن على المخدِّم) بتخديم الطلب وإعادة النتيجة إلى طالب الخدمة عن طريق المقاول ORB. ويتيح استخدام المقاول ORB إزالة التجانس بين طالب الخدمة والمخدِّم؛ إذ لا يفترض فيهما معرفة طريقة تمثيل بيانات الآخر أو اللغة البرمجية التي كُتب بها أو نظام التشغيل الذي يعمل تحته التطبيق. ويمثل الشكل (3) كيفية تطوير التطبيقات في البنية CORBA.

الوصف: 13-3.psd
CORBA الشكل (3): مبدأ تطوير التطبيقات وفق البنية

ينبغي أولاً تعريف الواجهات بوساطة اللغة IDL لكل الخدمات المطلوب ربطها بالمقاول ORB، ثم ينبغي تحويلها إلى اللغة البرمجية التي كتب بها المخدِّم وطالب الخدمة. يجري بعد ذلك ربط كل البرامج - ومنها الواجهات - بمكتبة المقاول ORB، وبعد ذلك يجري تشغيل المخدِّم وطالب الخدمة ويصبح بإمكانهما تبادل المعلومات.

خدمات الوِب:

وهي برنامج مصمّم لتمكين الاتصال بين تطبيقات الوِب web application. لكل خدمة وِب واجهة توصف بوساطة لغة تسمى لغة «وصف خدمة الوِب» WSDL . تبين الواجهة العديد من المعلومات المفيدة حول خدمة الوِب مثل عنوان هذه الخدمة على الوِب، ومتحولات الدخل، والعمليات الأساسية التي تقوم بها الخدمة، وغيرها من المعلومات الضرورية للاتصال بها. إضافة إلى ذلك - وكجزء أساسي من أي خدمة وب - يُحدّد وصف لشكل الرسائل التي تقبلها هذه الخدمة. يجري عادة وصف شكل الرسالة من خلال اللغة XSD، وقد يكون هذا الوصف ضمن الواجهة أو معرّفاً برابط link داخل الواجهة.

يقوم طالب خدمة باستدعاء خدمة وب بإرسال رسالة message محدّدة. توصّف قواعد الاتصال بخدمات الوِب بوساطة البروتوكول simple object access protocol (SOAP) الذي يحدد (1) شكل الرسالة المقبولة من قبل خدمة الوِب. يوصف شكل الرسالة بوساطة اللغة extendable markup language (XML)  (2) طريقة نقل الرسائل بين طالب الخدمة وخدمة الوِب، وغالباً ما يعتمد على بروتوكولات أخرى مثل RPC أو HTTP للقيام بنقل هذه الرسائل.

للعثور على خدمات الوِب ومن ثمّ استدعاؤها يعلن مصمّمو خدمات الوِب عن خدماتهم عن طريق دليل يسمى تكامل الوصف والاستكشاف العمومي universal description, discovery integration (UDDI) الذي يسمح لمطوري خدمات الوِب بتسجيل هذه الخدمات، ويسمح أيضاً لطالبي الخدمة بالعثور على الخدمات المناسبة، يوضح الشكل(4) خطوات استدعاء خدمة وِب.

الوصف: 13-4.psd
الشكل (4): خطوات استدعاء خدمة وب

أول خطوة هي اكتشاف خدمة وِب التي تلبي المتطلبات، على سبيل المثال: إذا جرى البحث عن خدمة وب تعطي معلومات عن حالة الطقس في المدن السورية يجري الاتصال بخدمة اكتشاف خدمات الوِب (الدليل UDDI مثلاً)، ثم يقوم دليل الخدمات بإرسال عنوان المخدِّم الذي يحوي الخدمة المطلوبة إن وجدت. وبعد معرفة مكان خدمة الوِب، فإن الخطوة التالية هي معرفة كيف يمكن استدعاء هذه الخدمة، ومن ثم يقوم المخدِّم الذي يحوي خدمة الوِب المطلوبة بإرسال وثيقة الوصف WSDL عن كيفية استدعاء الخدمة المطلوبة، ويجري إرسال طلب استدعاء الخدمة بوساطة البروتوكول SOAP، وأخيراً تُنفّذ الخدمة المطلوبة وتعاد النتيجة عن طريق رسالة عبر البروتوكول SOAP.

يُلاحظ من الشكل (4) أن خدمات الوِب هي وسيلة لاستدعاء خدمات بعيدة. هذه الوسيلة تجعل الاتصال ممكناً بين تطبيقات غير متجانسة (مكتوبة بلغات برمجية مختلفة، تملك أنواع بيانات مختلفة،…إلخ)، حيث إن طالب الخدمة مستقل عن طريقة تمثيل البيانات ولغة البرمجة ونظام التشغيل وبنية الحاسوب الذي تعمل عليه الخدمة. كل ما يجب أن يعرفه طالب الخدمة هو كيف يحلل وثائق وصف خدمات الوِب، وكيف يستخدم بروتوكول استدعاء الخدمة SOAP.

مراجع للاستزادة:

- مجموعة إدارة الكائنات OMG. http://www.omg.org

- ائتلاف الشبكة العنكبوتية العالمية -

World Wide Web Consortium. www.w3.org/TR/ws-arch/.

- توصيف بنية CORBA . /http://www.corba.org

- J. Shirley, W. Rosenberry, Microsoft RPC Programming Guide, Sebastopol, CA : O’Reilly, 2006.


التصنيف : الهندسة المعلوماتية
النوع : الهندسة المعلوماتية
المجلد: المجلد الثاني
رقم الصفحة ضمن المجلد : 0
مشاركة :

اترك تعليقك



آخر أخبار الهيئة :

البحوث الأكثر قراءة

هل تعلم ؟؟

عدد الزوار حاليا : 555
الكل : 29652554
اليوم : 32564