شرح خدمات الويب SOAP: ما هو بروتوكول SOAP؟

ما هو SOAP؟

بروتوكول SOAP هو بروتوكول قائم على لغة XML للوصول إلى خدمات الويب عبر بروتوكول HTTP. وله بعض المواصفات التي يمكن استخدامها في جميع التطبيقات.

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

تم تطوير SOAP كلغة وسيطة بحيث يمكن للتطبيقات المبنية على لغات برمجة مختلفة التحدث بسهولة مع بعضها البعض وتجنب جهود التطوير الشديدة.

مقدمة الصابون

في عالمنا اليوم، يوجد عدد هائل من التطبيقات المبنية على لغات برمجة مختلفة. على سبيل المثال، قد يكون هناك تطبيق ويب مصمم بلغة برمجة معينة. Javaوآخر في .Net، وآخر في PHP.

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

إحدى الطرق المستخدمة لمكافحة هذا التعقيد هي استخدام XML (لغة الترميز القابلة للتوسيع) كلغة وسيطة لتبادل البيانات بين التطبيقات.

يمكن لكل لغة برمجة فهم لغة ترميز XML. ومن ثم، تم استخدام لغة XML كوسيلة أساسية لتبادل البيانات.

لكن لا توجد مواصفات قياسية لاستخدام لغة XML في جميع لغات البرمجة لتبادل البيانات. وهنا يأتي دور برامج SOAP.

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

مزايا الصابون

SOAP هو البروتوكول المستخدم لتبادل البيانات بين التطبيقات. فيما يلي بعض الأسباب وراء استخدام الصابون.

• عند التطويرping تتطلب خدمات الويب القائمة على بروتوكول SOAP لغةً للتواصل بين هذه الخدمات وتطبيقات العميل. يُعدّ SOAP الوسيلة الأمثل التي طُوّرت خصيصًا لهذا الغرض. كما يُوصي بهذا البروتوكول اتحاد W3C، وهو الهيئة المسؤولة عن جميع معايير الويب.
• SOAP هو بروتوكول خفيف الوزن يُستخدم لتبادل البيانات بين التطبيقات. لاحظ الكلمة الأساسية "ضوءبما أن برمجة SOAP تعتمد على لغة XML، وهي لغة تبادل بيانات خفيفة الوزن، فإن SOAP كبروتوكول يندرج أيضًا في نفس الفئة.
• تم تصميم بروتوكول SOAP ليكون مستقلاً عن المنصة ونظام التشغيل. لذا، يمكن لبروتوكول SOAP العمل مع أي تطبيقات تعتمد على لغات برمجة مختلفة. Windows و لينكس المنصات.
• يعمل بروتوكول SOAP على بروتوكول HTTP، وهو البروتوكول الافتراضي المستخدم في جميع تطبيقات الويب. لذا، لا يتطلب تشغيل خدمات الويب المبنية على بروتوكول SOAP على شبكة الإنترنت العالمية أي تعديلات أو تخصيصات.

كتل بناء الصابون

تحدد مواصفات SOAP شيئًا يُعرف باسم "رسالة الصابون"، وهو ما يتم إرساله إلى خدمة الويب وتطبيق العميل.

يوضح الرسم التخطيطي أدناه لهندسة SOAP الكتل الأساسية المختلفة لرسالة SOAP.

رسالة SOAP ليست سوى مستند XML يحتوي على المكونات التالية.

• An مغلف العنصر الذي يُعرّف مستند XML كرسالة SOAP – هذا هو الجزء الحاوي من رسالة SOAP ويُستخدم لتغليف جميع التفاصيل الواردة فيها. وهو العنصر الجذر في رسالة SOAP.
• A رأس عنصر يحتوي على معلومات الترويسة - يمكن أن يحتوي عنصر الترويسة على معلومات مثل بيانات اعتماد المصادقة التي يمكن للتطبيق المُستدعي استخدامها. كما يمكن أن يحتوي على تعريفات لأنواع البيانات المعقدة التي يمكن استخدامها في رسالة SOAP. بشكل افتراضي، يمكن أن تحتوي رسالة SOAP على معلمات قد تكون من أنواع بسيطة مثل السلاسل النصية والأرقام، أو قد تكون من نوع كائن معقد.

يُعرض أدناه مثال بسيط لخدمة SOAP لنوع بيانات معقد. لنفترض أننا نريد إرسال نوع بيانات مُهيكل يحتوي على مزيج من "اسم البرنامج التعليمي" و"البرنامج التعليمي". Descriptإذا استخدمنا "ion"، فسنُعرّف النوع المركب كما هو موضح أدناه. يُعرّف النوع المركب بواسطة وسم العنصر. ثم يتم تعريف جميع العناصر المطلوبة للهيكل مع أنواع البيانات الخاصة بها في مجموعة الأنواع المعقدة.

<xsd:complexType>
   <xsd:sequence>
      <xsd:element name="Tutorial Name" type="string"/>
      <xsd:element name="Tutorial Description" type="string"/>
   </xsd:sequence>
</xsd:complexType>

A الجسد العنصر الذي يحتوي على معلومات الاستدعاء والاستجابة - هذا العنصر هو ما يحتوي على البيانات الفعلية التي يجب إرسالها بين خدمة الويب والتطبيق المُستدعي. فيما يلي مثال على نص SOAP لخدمة ويب، والذي يعمل فعليًا على النوع المُركب المُحدد في قسم الترويسة. إليك استجابة اسم البرنامج التعليمي والبرنامج التعليمي Descriptالأيون الذي يتم إرساله إلى تطبيق الاتصال الذي يستدعي خدمة الويب هذه.

<soap:Body>
   <GetTutorialInfo>
      <TutorialName>Web Services</TutorialName>
      <TutorialDescription>All about web services</TutorialDescription>
   </GetTutorialInfo>
</soap:Body>

هيكل رسالة SOAP

شيء واحد يجب ملاحظته هو أن رسائل SOAP يتم إنشاؤها تلقائيًا بواسطة خدمة الويب عند استدعائها.

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

كما نوقش في الموضوع السابق من هذا الدرس التعليمي حول بروتوكول SOAP، فإن رسالة SOAP البسيطة تحتوي على العناصر التالية:

• عنصر المغلف
• عنصر العنوان، و
• عنصر الجسم
• عنصر الخطأ (اختياري)

دعونا نلقي نظرة على مثال أدناه لرسالة SOAP بسيطة ونرى ما يفعله كل عنصر بالفعل.

1. كما يتضح من رسالة SOAP أعلاه، فإن الجزء الأول من رسالة SOAP هو عنصر المغلف الذي يستخدم لتغليف رسالة SOAP بأكملها.
2. العنصر التالي هو نص SOAP والذي يحتوي على تفاصيل الرسالة الفعلية.
3. تحتوي رسالتنا على خدمة ويب تحمل اسم "Guru"99 خدمة ويب".
4. في "Guruيقبل "99Webservice" معلمة من النوع 'int' واسمها TutorialID.

الآن، سيتم تمرير رسالة SOAP أعلاه بين خدمة الويب وتطبيق العميل.

يمكنك أن ترى مدى فائدة المعلومات المذكورة أعلاه لتطبيق العميل. تُخبر رسالة SOAP تطبيق العميل باسم خدمة الويب، والمعلمات التي يتوقعها، ونوع كل معلمة تستقبلها خدمة الويب.

عنصر مغلف الصابون

الجزء الأول من كتلة البناء هو SOAP Envelope.

يتم استخدام مغلف SOAP لتغليف جميع التفاصيل الضرورية لرسائل SOAP، والتي يتم تبادلها بين خدمة الويب وتطبيق العميل.

يتم استخدام عنصر مغلف SOAP للإشارة إلى بداية ونهاية رسالة SOAP. يتيح ذلك لتطبيق العميل الذي يستدعي خدمة الويب معرفة متى تنتهي رسالة SOAP.

يمكن ملاحظة النقاط التالية على عنصر مغلف SOAP.

• يجب أن تحتوي كل رسالة SOAP على عنصر غلاف رئيسي. وجود عنصر الغلاف إلزاميٌّ للغاية في رسالة SOAP.
• يجب أن يحتوي كل عنصر من عناصر الظرف على عنصر واحد على الأقل من عناصر جسم الصابون.
• إذا كان عنصر المغلف يحتوي على عنصر رأس، فيجب ألا يحتوي على أكثر من عنصر واحد، ويجب أن يظهر كالطفل الأول للمغلف، قبل عنصر النص الأساسي.
• يتغير المغلف عندما تتغير إصدارات SOAP.
• يقوم معالج SOAP المتوافق مع الإصدار 1.1 بإنشاء خطأ عند تلقي رسالة تحتوي على مساحة اسم المغلف الإصدار 1.2.
• يقوم معالج SOAP المتوافق مع الإصدار 1.2 بإنشاء خطأ عدم تطابق الإصدار إذا تلقى رسالة لا تتضمن مساحة اسم المغلف الإصدار 1.2.

فيما يلي مثال على واجهة برمجة تطبيقات SOAP للإصدار 1.2 من عنصر غلاف SOAP.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
   <soap:Body>
      <Guru99WebService xmlns="http://tempuri.org/">
         <TutorialID>int</TutorialID>
      </Guru99WebService>
   </soap:Body>
</SOAP-ENV:Envelope>

رسالة الخطأ

عند إرسال طلب إلى خدمة ويب SOAP، يمكن أن تكون الاستجابة المُعادة إما استجابة ناجحة أو استجابة خطأ. في حالة الاستجابة الناجحة، تكون الاستجابة من الخادم دائمًا رسالة SOAP. أما في حالة حدوث أخطاء SOAP، فتُعاد كأخطاء "HTTP 500".

تتكون رسالة خطأ SOAP من العناصر التالية.

1. <faultCode> – هذا هو الرمز الذي يُحدد نوع الخطأ. يمكن أن يكون رمز الخطأ أحد القيم التالية:
   1. SOAP-ENV:VersionMismatch – يحدث هذا عند مواجهة مساحة اسم غير صالحة لعنصر SOAP Envelope.
   2. SOAP-ENV:MustUnderstand - لم يتم فهم العنصر الفرعي المباشر لعنصر الرأس، مع تعيين السمة mustUnderstand على "1".
   3. SOAP-ENV:Client - تم تشكيل الرسالة بشكل غير صحيح أو تحتوي على معلومات غير صحيحة.
   4. SOAP-ENV:Server - حدثت مشكلة في الخادم، لذا لا يمكن متابعة الرسالة.
2. – هذه هي الرسالة النصية التي تحتوي على وصف تفصيلي للخطأ.
3. (خياري) – هذه سلسلة نصية تشير إلى من تسبب في الخطأ.
4. (خياري) – هذا هو العنصر الخاص برسائل الخطأ الخاصة بالتطبيق. لذلك قد يحتوي التطبيق على رسالة خطأ محددة لسيناريوهات مختلفة لمنطق الأعمال.

مثال لرسالة الخطأ

فيما يلي مثال على رسالة خطأ. يظهر هذا الخطأ عندما يحاول العميل استخدام دالة تُسمى TutorialID في الفئة GetTutorial. وتظهر رسالة الخطأ التالية في حال عدم وجود هذه الدالة في الفئة المُعرَّفة.

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
      <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
      <faultstring xsi:type="xsd:string">
         Failed to locate method (GetTutorialID) in class (GetTutorial)
      </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

الإخراج:

عند تنفيذ الكود أعلاه، سيظهر خطأ مثل "فشل في تحديد موقع الطريقة (GetTutorialID) في الفئة (GetTutorial)".

نموذج التواصل الصابوني

تتم جميع الاتصالات بواسطة SOAP عبر بروتوكول HTTP. قبل SOAP، كان هناك الكثير من خدمات ويب استخدم أسلوب RPC (استدعاء الإجراء البعيد) القياسي للاتصال. كان هذا هو أبسط نوع من التواصل، لكن كان به الكثير من القيود.

في هذا الدرس التعليمي حول واجهة برمجة تطبيقات SOAP، دعونا ننظر إلى الرسم التخطيطي أدناه لنرى كيف تتم هذه العملية. في هذا المثال، لنفترض أن الخادم يستضيف خدمة ويب توفر طريقتين كما يلي:

• GetEmployee – سيؤدي هذا إلى الحصول على جميع تفاصيل الموظفين.
• SetEmployee – سيؤدي هذا إلى تحديد قيمة التفاصيل مثل قسم الموظف وراتبه وما إلى ذلك وفقًا لذلك.

في الاتصال العادي بنمط RPC، يقوم العميل فقط باستدعاء الأساليب الموجودة في طلبه وإرسال المعلمات المطلوبة إلى الخادم، ثم يرسل الخادم الاستجابة المطلوبة.

يُعاني نموذج الاتصال المذكور أعلاه من القيود الخطيرة التالية:

1. ليست لغة مستقلة - سيكون الخادم الذي يستضيف الطرق بلغة برمجة معينة، وعادةً ما تكون الاستدعاءات إلى الخادم بتلك اللغة البرمجية فقط.
2. ليس البروتوكول القياسي - عند إجراء مكالمة إلى الإجراء البعيد، لا يتم تنفيذ المكالمة عبر البروتوكول القياسي. كانت هذه مشكلة نظرًا لأن معظم الاتصالات عبر الويب يجب أن تتم عبر بروتوكول HTTP.
3. الجدران النارية - نظرًا لأن مكالمات RPC لا تمر عبر البروتوكول العادي، فيجب فتح منافذ منفصلة على الخادم للسماح للعميل بالاتصال بالخادم. عادةً ما تقوم جميع جدران الحماية بحظر هذا النوع من حركة المرور، وكان الأمر يتطلب عمومًا الكثير من التكوينات لضمان عمل هذا النوع من الاتصال بين العميل والخادم.

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

1. يقوم العميل بتنسيق المعلومات المتعلقة باستدعاء الإجراء وأي وسائط في رسالة SOAP، ثم يرسلها إلى الخادم كجزء من طلب HTTP. تُعرف عملية تغليف البيانات في رسالة SOAP هذه باسم التنظيم.
2. يقوم الخادم بعد ذلك بفك تشفير الرسالة المرسلة من العميل، ويتحقق مما طلبه، ثم يرسل الاستجابة المناسبة إلى العميل كرسالة SOAP. وتُعرف هذه العملية بفك التشفير.ping يُعرف الطلب الذي يرسله العميل باسم تفكيك الحرس.

مثال عملي للصابون

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

هذا الموضوع سوف ننظر في استخدام Microsoft.Net Framework لبناء خدمة ويب ASMX. يدعم هذا النوع من خدمات الويب كلاً من الإصدار 1.1 من SOAP والإصدار 1.2.

تقوم خدمات الويب ASMX تلقائيًا بإنشاء ملف لغة تعريف خدمة الويب (WSDL) وثيقة. مطلوب مستند WSDL هذا بواسطة تطبيق العميل المتصل حتى يعرف التطبيق ما تستطيع خدمة الويب القيام به.

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

سيعرض لنا Visual Studio أيضًا رسالة SOAP المتبادلة بين خدمة الويب والتطبيق المُستدعي. يُمكنك إتمام الخطوة الأولى لإعداد تطبيق خدمة الويب باتباع الخطوات التالية. يُرجى التأكد من تثبيت Visual Studio 2013 على جهازك لهذا المثال.

الخطوة 1) الخطوة الأولى هي إنشاء تطبيق ويب ASP.Net فارغ. من Visual Studio 2013، انقر فوق خيار القائمة ملف-> مشروع جديد.

بمجرد النقر على خيار مشروع جديد، سيمنحك Visual Studio مربع حوار آخر لاختيار نوع المشروع وإعطاء التفاصيل اللازمة للمشروع. سيتم شرح ذلك في الخطوة التالية.

الخطوة 2) في هذه الخطوة،

1. تأكد من اختيار أولا C# قالب ويب لتطبيق ASP.NET. يجب أن يكون المشروع من هذا النوع لإنشاء مشروع خدمات SOAP. باختيار هذا الخيار، سيقوم Visual Studio بتنفيذ الخطوات اللازمة لإضافة الملفات المطلوبة لأي تطبيق ويب.
2. قم بتسمية مشروعك، وفي حالتنا تم تسميته webservice.asmx. ثم تأكد من تحديد موقع تخزين ملفات المشروع.

بمجرد الانتهاء، سترى ملف المشروع الذي تم إنشاؤه في مستكشف الحلول في Visual Studio 2013.

الخطوة 3) في هذه الخطوة، سنضيف ملف خدمة ويب إلى مشروعنا.

1. أولاً، انقر بزر الماوس الأيمن على ملف المشروع كما هو موضح أدناه.

2. بمجرد النقر بزر الفأرة الأيمن على ملف المشروع، يمكنك اختيار خيار "إضافة -> خدمة ويب (ASMX)" لإضافة ملف خدمة ويب. ما عليك سوى إدخال اسم "خدمة تعليمية" في خانة اسم ملف خدمة الويب.

الخطوة 4) أضف الكود التالي إلى ملف asmx الخاص بخدمة البرنامج التعليمي لديك.

Code التفسير:

1. يوفر سطر التعليمات البرمجية هذا اسمًا لملف خدمة الويب الخاص بك. هذه خطوة مهمة لأنها تفسح المجال لتطبيق العميل للاتصال بخدمة الويب عبر اسم خدمة الويب.
2. عادةً ما يتم استخدام ملف فئة لتغليف وظائف خدمة الويب. لذا فإن ملف الفئة سيحتوي على تعريف لجميع أساليب الويب التي ستوفر بعض الوظائف لتطبيق العميل.
3. يُعرف [WebMethod] هنا بأنه سمة تصف دالة. وتُنشئ الخطوة التالية دالة تُسمى "Guruيُتيح تطبيق 99WebService، من خلال إضافة سمة [WebMethod]، إمكانية استدعاء هذه الطريقة من قِبل تطبيق العميل. في حال عدم وجود هذه السمة، فلن يتمكن تطبيق العميل من استدعاء الطريقة نهائيًا.
4. هنا نقوم بتعريف دالة تسمى 'Guruتُستخدم الدالة '99WebService' لإعادة سلسلة نصية إلى تطبيق العميل المُستدعي. هذه الدالة عبارة عن خدمة ويب يمكن لأي تطبيق عميل استدعاؤها.
5. نستخدم عبارة الإرجاع لإرجاع السلسلة النصية "This is a Guru99 خدمة الويب" لتطبيق العميل.

إذا تم تنفيذ الكود بنجاح، سيتم عرض الإخراج التالي عند تشغيل الكود في المتصفح.

الإخراج:

• تُظهر المخرجات بوضوح أن اسم خدمة الويب الخاصة بنا هو "Guru"خدمة الويب 99"، وهي نتيجة إعطاء اسم لخدمة الويب الخاصة بنا.
• يمكننا أيضًا ملاحظة أنه بإمكاننا استدعاء خدمة الويب. إذا نقرنا على زر "استدعاء"، فسنحصل على الاستجابة التالية في متصفح الويب.

الناتج أعلاه:

• يُظهر ذلك بوضوح أنه من خلال استدعاء طريقة الويب، فإن السلسلة "This is a Guruيتم إرجاع "خدمة الويب 99".
• يتيح لك Visual Studio أيضًا عرض طلب رسالة SOAP والاستجابة لها والتي يتم إنشاؤها عند استدعاء خدمة الويب المذكورة أعلاه.

يظهر أدناه طلب SOAP الذي يتم إنشاؤه عند استدعاء خدمة الويب.

Code التفسير:

1. الجزء الأول من رسالة SOAP هو عنصر الغلاف، الذي تمت مناقشته في الفصول السابقة. هذا هو العنصر المُغلِّف الموجود في كل رسالة SOAP.
2. يعد نص SOAP العنصر التالي ويحتوي على التفاصيل الفعلية لرسالة SOAP.
3. أما الجزء الثالث فهو العنصر الذي يحدد أننا نريد استدعاء الخدمة التي تسمى "Guru99WebService'.

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Body>
      <Guru99WebServiceResponse xmlns="http://tempuri.org/">
         <Guru99WebServiceResult>string</Guru99WebServiceResult>
      </Guru99WebServiceResponse>
   </soap:Body>
</soap:Envelope>

Code التفسير:

1. الجزء الأول من رسالة SOAP هو عنصر الغلاف، الذي تمت مناقشته في الفصول السابقة. هذا هو العنصر المُغلِّف الموجود في كل رسالة SOAP.
2. يعد نص SOAP العنصر التالي ويحتوي على التفاصيل الفعلية لرسالة SOAP.
3. الجزء المثير للاهتمام الذي ستراه الآن هو خاصية "string". تُخبر هذه الخاصية تطبيق العميل بأن خدمة الويب المُستدعاة تُعيد كائنًا من نوع سلسلة نصية. وهذا مفيد جدًا، لأنه لولاها لما عرف تطبيق العميل ما تُعيده خدمة الويب.

الأسئلة الشائعة