• 0
Guest cold0zero

فهم بروتوكول SOAP

سؤال

فهم بروتوكول SOAP

تستحوذ الحوسبة الموزعة على اهتمام بالغ هذه الأيام. وأصبح تسهيل التفاعل بين

الشركات، وبين الشركات والمستهلكين، وقدرة التطبيقات والأنظمة المختلفة على

الاتصال بين بعضها البعض، أكثر أهمية الآن من الماضي. لكن الحلول التي ابتكرت

من قبل للحوسبة الموزعة، لم تصمم للبيئات مختلفة الخصائص، مثل شبكة إنترنت.

ما دفع إلى ابتكار أسلوب جديد، يلبي متطلبات الاستخدام في بيئة إنترنت، هو

البروتوكول البسيط للوصول إلى الكائناتSOAP ، (Simple Object Access

Protocol) وهو بروتوكول خفيف الوزن يسمح بتبادل المعلومات، في بيئة موزعة غير

مركزية (للحصول على معلومات أكثر عن هذا الموضوع، انظر www.w3.org/tr/soap).

يعرّف بروتوكول SOAP، آليّة تبادل رسائل لتشفير المعلومات ضمن غلاف XML.

ويستخدم SOAP غالباً، في تفسير قيم بارمترات الطرق (method) البعيدة وقت

التشغيل، وحشو تلك القيم ضمن وثيقة XML باستخدام تنسيق معين. ويتم بعد ذلك

نقل بيانات XML إلى المزود البعيد، باستخدام بروتوكول HTTP، و يمكن استخدام

بروتوكولات النقل الأخرى أيضاً. تعطى تلك الطرق البعيدة، هذه الأيام، اسماً

جذّاباً، حيث تسمى خدمات ويب (Web Service).

وتوجد أيضاً، العديد من المواصفات الأخرى لتنفيذ الطريق البعيدة، مثل CORBA

IIOP، وDCOM ORPC، وبروتوكول Java Remote Method Protocol. لكن الفائدة

الكبيرة التي يمتاز بها بروتوكول SOAP، أنه يرتكز على النصوص (عبر XML)،

بدلاً من الاعتماد على التشفير الثنائي (binary)، بالإضافة إلى أنه ليس

مملوكاً لشركة معينة. وتصبح الحوسبة الموزعة، لدى الاعتماد على بروتوكول

SOAP، مجرد مسألة استغلال الموارد المتوفرة على حاسوب بعيد، وكأن الحاسوب

البعيد والحاسوب المحلي المنادي، جهازاً واحداً. والهدف من ذلك، ربط الأنظمة

الموزعة معاً بشكل محكم، بحيث أنك عندما تنادي طريقة معينة، فإنك لا تعلم

(ونفترض أنك لا تهتم) إذا كان النداء سيعالج على النظام البعيد أو المحلي.

لكنك في الحالات الواقعية، ستهتم غالباً بما سيعالج الطريقة التي تناديها،

إذا وجدت أن إنجاز الطرق البعيدة يتأخر كثيراً، حيث تستغرق وقتاً أطول كي

تنهي مهماتها. ومع ذلك، دعنا في هذه المقالة نتجاهل مسائل التأخير، ونتصور أن

بروتوكول SOAP، يدمج الأنظمة الموزعة بشكل سلس تماماً.

السلاح السري لدى بروتوكول SOAP، وأحد مصادر قوته الحقيقة، أنه يستخدم

بروتوكول نقل عام، وهو غالباً بروتوكول HTTP. ولأن صد بيانات بروتوكول HTTP

في جدران نار الشركات، أمر لا يحدث تقريباً، فإن بروتوكول SOAP، المرتبط

ببروتوكول HTTP، يستطيع المرور بسهولة عبر جدران النار. بينما لا تستطيع

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

عناوين الشبكة التي تستخدمها عادة محظورة، بهدف تأمين أنظمة الحواسيب من دخول

الهكرة. المصدر الآخر لقوة بروتوكول SOAP، أنه يرتكز على XML. وهو يوفر بذلك

إمكانيات دمج الأنظمة التي لم تكن تستطيع سابقاً الاتصال مع بعضها البعض

والتشارك بالموارد. كيف ذلك؟ ما يحدث الآن أن عدد أنظمة الحواسيب التي تفهم

لغة XML، يزداد باضطراد في كل مكان تقريباً. فإذا وجدت طريقة لإدخال وثيقة

XML في نظامك، فالفرصة موجودة أن يوجد برنامج لتمكين النظام من قراءة وتفسير

المعلومات المشفرة ضمن XML. وصمم بروتوكول SOAP، ليخدم أهداف الحوسبة

البعيدة، بحيث يأخذ بارامترات الطرق بشكلها الفطري الثنائي، ويَحْمِل تلك

البارامترات على شكل معلومات XML، إلى المزود البعيد، حيث يقوم معالج SOAP

المقابل بنزع المعلومات المتضمنة في غلاف XML، ويعيدها إلى حالتها الثنائية

ويقدمها للمعالجة.

دعنا إذاً نرى كيف يعمل بروتوكول SOAP؟

انظر إلى الشكل 1، الذي يوضح العلاقة بين بروتوكول SOAP المنسق بلغة XML،

وبروتوكول حمله، أي بروتوكول HTTP في هذه الحالة. يستخدم بروتوكول HTTP

ترويسة لإعلام النظام المضيف بالمكان الذي توجه إليه الرزمة، وبمحتويات

الرزمة (وهو نص مرتكز على XML في هذه الحالة)، وغير ذلك من المعلومات. ويوجد

مدخل في ترويسة HTTP مخصص لبروتوكول SOAP، لتسهيل توجيه الرزم الآلي داخل

معمارية معالجة SOAP. وتملك البروتوكولات الأخرى المتطلبات ذاتها

.

يخدم SOAP Envelope (ظرف SOAP)، كغلاف للمعلومات المهمة فعلاً. ولاحظ، أنه

خلافاً للظرف البريدي، فإن الظرف SOAP Envelope لا يحمل عنوان المرسل إليه.

تصور SOAP Envelope على أنه يشبه مصنفاً يتضمن مجموعات من الملاحظات

والمعلومات، المفصولة عن بعضها بواسطة صفحات تبويب. وتتألف الأقسام المبوبة

من عنصر تروسية (Header) رسالة اختياري، وعنصر جسم الرسالة (Body)، وعناصر

XML أخرى يمكن أن يدرجها المستخدم حسب حاجته.

إذا كانت تروسية SOAP Header موجودة، فهي تتضمن معلومات الإدارة والتحكم، مثل

رقم الحساب، أو معرف الزبون. بينما يتضمن الجسم SOAP Body المعلومات التي

تريد أن تنقلها. ولنوضح ذلك أكثر، إليك الهيكل العام لرسالة SOAP نموذجية.

وتصور في هذا المثال أنك ترسل طلب شراء إلى طريقة بعيدة كي تعالجها:

-Envelope

- Header

- Account number

-Body

- Issue a purchase order

- P0 information

لا يختلف هذا الهيكل المبسط كثيراً عن نص SOAP XML الفعلي المبين في الشكل 2.

وتشاهد في المثال المبسط عقدة Envelope تحتوي على تروسية SOAP Header، وجسم

Body.

عقدة الترويسة Header مصممة كي تحتوي على معلومات واصفة للمعلومات

(meta-information)، مثل الخوارزمية المستخدمة لتشفير الجسم، أو المفتاح

العمومي الضروري لفك تشفير النص المشفر. أو يمكن للتروسية أن تحتوي على معرّف

تعامل، أو معرف سببية (كآلية سد منع) أو أي معلومات أخرى. وفي مثالنا السابق،

تحتوي التروسية على رقم الحساب. ويحتوي الجسم على عقدة ابن، تسمى

IssuePurchaseOrder، وهو أيضاً اسم الطريقة البعيدة. وتتطلب مواصفات SOAP أن

يكون الابن الأول لعنصر الجسم Body، هو الطريقة المطلوبة. وتذكّر أن الهدف من

بروتوكول SOAP، أن يكون على الأقل، بروتوكول تنفيذ للإجراءات البعيدة. ويفترض

هذا ضمناً أنه يجب إنجاز الطريقة على حاسوب بعيد لصالحك. وربما لا نعرف مالذي

ستعود به الطريقة إلينا في هذه الحالة، لأنه لا يوجد معلومات كافية عن ذلك في

رزمة SOAP، كما قدمنا (فهي رزمة طلب)، لكننا نعرف بالضبط ما هو اسم الطريقة،

وما هي بارامترات الدخل المطلوبة:

{some return value}

PurchaseOrder (PurchaseOrder po)

ونحن نعرف هذا لأن مواصفات SOAP تخبرنا أن الأبن الأول من الجسم، يتضمن عقدة

XML، لها اسم الطريقة المطلوبة ذاته. وأي أبناء لعقدة الطريقة تسمى بالأسلوب

ذاته بأسماء بارامترات الطريقة. ولأن للغة XML أيضاً القدرة على تمثيل أنواع

البيانات، مثل السلاسل الحرفية والأعداد الصحيحة، فإننا نستطيع أن نعالج

بيانات البارامتر بشكل صحيح.

وبالاعتماد على اسم الطريقة في مثالنا، يمكنك أن تخمن أن طريقة SOAP تلك، سوف

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

يمكن للحاسوب البعيد يمكن أن يعيد رزمة SOAP شبيهة بالتالي:

- Envelope

- Body

- IssuePurchaseOrderResponse

- IssuePurchaseOrderResult

- Results here…

ولا شك أن الاستجابة مشفرة أيضاً بلغة XML، كما في الشكل 3، حيث ترى عقدتي

SOAP Envelope، وBody، لكن اسماء عقد طريقة IssuePurchaseOrder تغيرت. وتعيد

الطريقة الأسماء ذاتها وكأنه تم توليدها بالطريقة التقليدية. وما يهم في

الأمر هنا هو تراتبية XML. ومرة أخرى فإن المعلومات التي تعيدها الطريقة

مشفرة بداية، كالأبن الأول لعقدة SOAP Body. وذلك الابن الأول للعقدة يجب أن

يكون القيمة العائدة من الطريقة. وبما أن القيمة العائدة لا تملك اسماً، فهي

عائدة من مجرد تنفيذ الطريقة، فإنها تسمى عرفاً، النتيجة result، أو

مشتقاتها، كما في اسم العقدة المنتهية بكلمة Result، في الشكل 3. وتعيد

الطريقة هنا قيمة منطقية (Boolean)، وإذا كان للطريقة قيم بارامترات خرج،

فإنك ستجدها مشفرة كعقد أقرباء لعقدة النتيجة.

أسلوب مختلف

تعتمد الطريقة التي وصفنا فيها SAOP على مواصفات SOAP، وفي الطريقة التي

شرحناها، تشير رزمتي الطلب والاستجابة إلى أننا نعود إلى SOAP بأسلوب نداء

الإجراء البعيد، وهي الطريقة التي بدأت فيها SOAP. ولا يوجد أي طريقة لنرسل

إلى موقع بعيد أي شيء مختلف عن مواصفات SOAP. وعليك أن تشفر البيانات وفقاً

لتلك المواصفات، وإذا لم تفعل فإن الطرف المستقبل لن يستطيع تفسير المحتويات.

نستخدم اليوم بروتوكول SOAP على نطاق أوسع. فبالإضافة إلى بروتوكولRPC SOAP،

نستخدم Massaging SOAP أيضاًَ. ويشير RPC عموماً إلى تشفير SOAP وفقاً

لمواصفات SOAP في الفصلين الخامس والسابع. بينما لبروتوكولMessaging SOAP، من

جهة أخرى، شكل حر أكثر، حيث تشفّر المعلومات بأي طريقة، ويمكن أن يكشفها مزود

المعالجة. لكن إذا تم تشفير المعلومات بأي طريقة تريدها تقريباً، كيف يمكن

ترسل بنية الرزمة إلى الزبائن المحتملين؟

يجيب على ذلك بروتوكول أحدث من بروتوكول SOAP، هو لغة وصف خدمات ويب Web

Services Description Language (WSDL). حيث يعرف WSDL القطع التي تتألف منها

رزمة SOAP، ويصف كيف يتم ترتيبها داخل الرزمة ذاتها. ولأن بروتوكول WSDL

يعتمد على لغة XML أيضاً، فإننا نستطيع أن نعالج تلك المعلومات بالخوارزميات،

مثل بروتوكول SOAP.

يصف بروتوكول WSDL ثلاثة أساليب استخدام أخرى لبروتوكول SOAP، بالإضافة إلى

سيناريو الطلب/الإجابة العام. ففي سيناريو الطلب/الاستجابة، يطلب الزبون

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

نقطتا نهاية للعمل هنا، هما الزبون والمزود.

الأساليب الأخرى، هي SOAP باتجاه واحد، حيث يرسل الزبون المعلومات إلى المزود

بدون أن يهتم بالاستجابة (مثل ملاحظة بالبريد الإلكتروني)، وأسلوب الالتماس

(solicit-mode) حيث يطلب المزود المعلومات من الزبون (كما في فحص الحالة)

وأسلوب الإعلام (notification) حيث يرسل المزود المعلومات (مثل إرسال حدث)

إلى الزبون بدون الاعتبار للاستجابة. ويعتمد الأسلوب الذي تختاره على وجهة

نظرك للأمر، وفي أي لحظة يمكن أن تجد نفسك زبوناً ومزوداً.

ويصبح SOAP أكثر قوة ومرونة، عندما يجمع مع WSDL. وهذه التركيبة هي المحرك

الأساس لخدمات ويب. وكما في أي تقنية، فإن التفاصيل المقترنة ببروتوكول SOAP

كثيرة ومتنوعة. لكن الحقيقة أنه بسيط وسهل الاستخدام. وإذا كان لديك مزود

ويب، ووصول إلى شبكة وحواسيب زبون، وتستطيع معالجة XML، فإنه يمكنك إنشاء

مزود SOAP في وقت قصير نسبياً، لطريقة SOAP واحدة على الأقل. وتحول معظم

الناس اليوم إلى أنظمة كاملة الوظائف، مصممة لمعالجة المعلومات المرتكزة على

SOAP. ويوجد حلول جاهزة متوفرة لحواسيب آي بي إم الفائقة، وحواسيب أنظمة

لينكس، وويندوز، ومجموعة واسعة من الأنظمة الأخرى. فإذا كان أحد تلك الحلول

يلبي متطلباتك، يمكنك أن توفر وقت التطوير باستخدامه، وفي الحالة المعاكسة،

ستجد أن التعامل مع بروتوكول SOAP ليس صعباً جداً, ويجده معظم الناس ممتعاًَ

وطريفاً.

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

1 إجابات على هذا السؤال .

  • 0

مقال رائع ينم عن وعي وإدراك ونتمنى مثل هذه المقالات التقنية و المعروضة بشكل مبسط وميسور.

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
زوار
This topic is now closed to further replies.

  • يستعرض القسم حالياً   0 members

    لا يوجد أعضاء مسجلين يشاهدون هذه الصفحة .