البرنامج التعليمي لخدمات الويب 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 هو البروتوكول المستخدم لتبادل البيانات بين التطبيقات. فيما يلي بعض الأسباب وراء استخدام الصابون.

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

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

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

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

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

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

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

لنفترض أننا أردنا إرسال نوع بيانات منظم يحتوي على مزيج من "اسم البرنامج التعليمي" و"البرنامج التعليمي" Descript"أيون"، ثم نقوم بتعريف النوع المعقد كما هو موضح أدناه.

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

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

عنصر نص يحتوي على معلومات الاتصال والاستجابة – هذا العنصر هو ما يحتوي على البيانات الفعلية التي يجب إرسالها بين خدمة الويب والتطبيق المستدعي. فيما يلي مثال لخدمة ويب SOAP لنص SOAP الذي يعمل بالفعل على النوع المعقد المحدد في قسم الرأس. فيما يلي استجابة اسم البرنامج التعليمي والبرنامج التعليمي Descriptالأيون الذي يتم إرساله إلى تطبيق الاتصال الذي يستدعي خدمة الويب هذه.

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

هيكل رسالة SOAP

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

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

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

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

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

كما يتضح من رسالة SOAP أعلاه، فإن الجزء الأول من رسالة SOAP هو عنصر المغلف الذي يستخدم لتغليف رسالة SOAP بأكملها.
العنصر التالي هو نص SOAP والذي يحتوي على تفاصيل الرسالة الفعلية.
تحتوي رسالتنا على خدمة ويب تحمل اسم "Guru99WebService".
تقبل "Guru99Webservice" معلمة من النوع "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 API للإصدار 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 2".

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

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

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

ويرد أدناه مثال على رسالة الخطأ. يتم إنشاء الخطأ إذا كان السيناريو حيث يحاول العميل استخدام طريقة تسمى 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 API، لننظر إلى الرسم البياني أدناه لمعرفة كيفية عمل هذا الاتصال. في هذا المثال، لنفترض أن الخادم يستضيف خدمة ويب توفر طريقتين

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

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

يحتوي نموذج الاتصال أعلاه على القيود الخطيرة التالية

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

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

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

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

الآن في هذا البرنامج التعليمي 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) في هذه الخطوة،

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

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

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

سنقوم بإضافة ملف خدمة ويب إلى مشروعنا

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

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

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

شرح الكود:

يوفر سطر التعليمات البرمجية هذا اسمًا لملف خدمة الويب الخاص بك. هذه خطوة مهمة لأنها تفسح المجال لتطبيق العميل للاتصال بخدمة الويب عبر اسم خدمة الويب.
عادةً ما يتم استخدام ملف فئة لتغليف وظائف خدمة الويب. لذا فإن ملف الفئة سيحتوي على تعريف لجميع أساليب الويب التي ستوفر بعض الوظائف لتطبيق العميل.
هنا تُعرف [WebMethod] بأنها سمة تصف وظيفة. تقوم الخطوة التالية بإنشاء وظيفة تسمى "Guru99WebService"، ولكن مع تضمين هذه الخطوة الخاصة بإضافة سمة [WebMethod]، يتم التأكد من إمكانية استدعاء هذه الطريقة بواسطة تطبيق العميل. إذا لم تكن هذه السمة موجودة، فلا يمكن مطلقًا استدعاء الأسلوب بواسطة تطبيق العميل.
نقوم هنا بتعريف وظيفة تسمى "Guru99WebService" والتي سيتم استخدامها لإرجاع سلسلة إلى تطبيق العميل المتصل. هذه الوظيفة عبارة عن خدمة ويب يمكن استدعاؤها بواسطة أي تطبيق عميل.
نحن نستخدم بيان الإرجاع لإرجاع السلسلة "هذه خدمة ويب Guru99" إلى تطبيق العميل.

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

الإخراج:

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

الإخراج أعلاه،

يوضح بوضوح أنه من خلال استدعاء طريقة الويب، يتم إرجاع السلسلة "هذه خدمة ويب Guru99".
يتيح لك Visual Studio أيضًا عرض طلب رسالة SOAP والاستجابة لها والتي يتم إنشاؤها عند استدعاء خدمة الويب المذكورة أعلاه.

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

شرح الكود:

الجزء الأول من رسالة SOAP هو عنصر المغلف وهو ما تمت مناقشته في الفصول السابقة. هذا هو عنصر التغليف الموجود في كل رسالة SOAP.
يعد نص SOAP العنصر التالي ويحتوي على التفاصيل الفعلية لرسالة SOAP.
الجزء الثالث هو العنصر الذي يحدد أننا نريد الاتصال بالخدمة التي تسمى "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>

شرح الكود:

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

الملخص

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

قد ترغب:

ما هو SOAP؟

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

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

ذات المواد

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

هيكل رسالة SOAP

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

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

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

الملخص