ركزنا حتى الآن على التفاعلات بين الإنسان وخادم الويب، حيث يستخدم الإنسان متصفح الويب للتفاعل مع الخادم، ويستمر التفاعل استجابةً لمدخلاتٍ من قِبل المستخدم من خلال النقر على الروابط مثلًا، لكن هناك طلبٌ متزايد على التفاعل المباشر بين حاسوبٍ وحاسوبٍ آخر؛ كما تحتاج التطبيقات التي تتواصل مباشرةً مع بعضها بعضًا مثل التطبيقات الموصوفة أعلاه إلى بروتوكولات. نختم هذا القسم من خلال مناقشة تحديات بناء أعدادٍ كبيرة من بروتوكولات تطبيقٍ إلى تطبيق وبعض الحلول المقترحة.
تأتي الكثير من الدوافع لتمكين الاتصال المباشر من تطبيقٍ إلى تطبيق من عالم الأعمال، حيث تضمنت التفاعلات بين المؤسسات (الشركات أو المنظمات الأخرى) قديمًا بعض الخطوات اليدوية مثل ملء نموذج طلب أو إجراء مكالمةٍ هاتفية لتحديد ما إذا كانت بعض المنتجات في المخزن.
من الشائع وجود خطواتٍ يدوية حتى داخل مؤسسةٍ واحدة بين الأنظمة البرمجية التي لا يمكن أن تتفاعل مباشرةً لأنها مُطوَّرة بصورةٍ مستقلة، ولكن يجري حاليًا استبدال هذه التفاعلات اليدوية بالتفاعل المباشر من تطبيقٍ إلى تطبيق. قد يرسل تطبيق الطلب في المؤسسة A رسالةً إلى تطبيق تنفيذ الطلب في المؤسسة B، والذي سيستجيب على الفور مشيرًا إلى إمكانية تنفيذ الطلب من عدمها، وإذا لم تكن المؤسسة B قادرةً على ملء الطلب، فسيطلُب التطبيق في المؤسسة A مباشرةً من موّردٍ آخر أو يطلب عروضًا من مجموعة من الموّردين.
فيما يلي مثالٌ بسيط لما نتحدث عنه. لنفترض أنك اشتريت كتابًا من بائع تجزئة عبر الإنترنت مثل أمازون. يمكن أن ترسل لك أمازون مثلًا رقم التتبّع في رسالة بريد إلكتروني بمجرد شحن كتابك، وبعد ذلك يمكنك التوجه إلى موقع شركة الشحن الإلكتروني fedex مثلًا، وتتبّع الطرد، لكن يمكنك أيضًا تتبّع الطرد الخاص بك مباشرةً من موقع Amazon.com الإلكتروني.
يجب أن تكون أمازون قادرةً على إرسال استعلامٍ إلى شركة الشحن فيديكس وبتنسيقٍ تفهمه لتحقيق ذلك، وتفسير النتيجة وعرضها في صفحة ويب قد تحتوي على معلوماتٍ أخرى حول طلبك، كما يجب أن يكون لشركتي لأمازون وفيديكس بروتوكولًا لتبادل المعلومات اللازمة لتتبّع الطرود يُطلق عليه اسم بروتوكول تتبّع الطرود Package Tracking Protocol. هناك العديد من البروتوكولات المحتملة من هذا النوع ويُفضَّل أن تكون لدينا بعض الأدوات لتبسيط مهمة تحديدها وبنائها.
ليست التطبيقات الشبكية جديدةً حتى تلك التطبيقات التي تتخطى حدود المؤسسة، حيث يتجاوز البريد الإلكتروني وتصفح الويب هذه الحدود، ولكن الجديد في هذه المشكلة هو التوسّع، ولا نقصد التوسّع في حجم الشبكة، إنما في عدد الأنواع المختلفة لتطبيقات الشبكة.
لقد طوّرت مجموعةٌ صغيرة من خبراء الشبكات مواصفاتِ البروتوكولات وعمليات تطبيقها الخاصة بالتطبيقات التقليدية، مثل البريد الإلكتروني ونقل الملفات، وكان الخروج ببعض التقنيات التي تبسِّط وتؤتمت مهمة تصميم بروتوكول التطبيق وتنفيذه أمرًا ضروريًا للتمكّن من التطوير السريع لعددٍ كبير من تطبيقات الشبكة المحتملة. دُعِمت معماريتان لحل لهذه المشكلة، أُطلق عليهما اسم خدمات الويب Web Services، حيث أُخِذ هذا الاسم من مصطلح التطبيقات التي تقدّم خدمة الوصول عن بُعد إلى تطبيقات العميل من أجل تشكيل التطبيقات الشبكية، وتُعَد المصطلحات المستخدمة بمثابة اختصارٍ غير رسمي للتمييز بين معماريتَي خدمات الويب هما SOAP وREST.
يتمثل نهج معمارية SOAP في حل المشكلة من خلال إنشاء بروتوكولاتٍ مخصَّصة لكل تطبيقٍ شبكي من الناحية النظرية على الأقل. تتمثل العناصر الرئيسية لهذا النهج في إطار عملٍ لمواصفات البروتوكول، ومجموعات أدواتٍ برمجية لإنشاء تطبيقات البروتوكول تلقائيًا من المواصفات والمواصفات الجزئية المعيارية الممكن إعادة استخدامها عبر البروتوكولات.
يتمثل نهج معمارية REST في معالجة المشكلة في عدِّ خدمات الويب مثل موارد شبكة الويب العالمية، والتي تُحدَّد بواسطة معرّفات URIs، ويجري الوصول إليها عبر بروتوكول HTTP. تُعَد معمارية REST مجرد معمارية ويب، حيث تشمل نقاط القوة في معمارية الويب الاستقرارَ وقابلية التوسع المثبتة أي توسّع حجم الشبكة.
يُعَد عدم ملاءمة بروتوكول HTTP للأسلوب الإجرائي المعتاد أو الأسلوب الموجَّه بالعمليات لاستدعاء خدمة بعيدة نقطةَ ضعف، ولكن يجادل مؤيدو معمارية REST بأنه يمكن مع ذلك الكشف عن الخدمات المهمة باستخدام أسلوبٍ أكثر توجّهًا نحو البيانات، أو باستخدام أسلوب تمرير المستندات الذي يكون بروتوكول HTTP مناسبًا له.
بروتوكولات التطبيقات المخصصة باستخدام معياري WSDL وSOAP
تعتمد المعمارية التي يشار إليها بصورةٍ غير رسمية باسم معمارية SOAP على معيار لغة وصف خدمات الويب Web Services Description Language أو اختصارًا WSDL، ومعيار SOAP الذي نشأ اسمه مثل اختصار، إلا أنه لم يَعُد يمثل أي شيءٍ رسميًا.
لقد أصدر اتحاد شبكة الويب العالمية World Wide Web Consortium أو اختصارًا W3C هذين المعيارين، وهذه هي المعمارية التي نقصدها عادةً عند استخدامنا لمصطلح Web Services بدون أي وصفٍ سابق. لا تزال هذه المعايير قيد التطوير، لذلك ستكون مناقشتنا هنا مختصرة.
إن معيارا WSDL وSOAP هما إطارا عملٍ لتحديد وتنفيذ بروتوكولات التطبيق وبروتوكولات النقل على التوالي، حيث تُستخدمان معًا، لكن هذا ليس مطلوبًا؛ حيث يُستخدَم معيار WSDL لتحديد التفاصيل الخاصة بالتطبيق مثل العمليات المدعومة، وتنسيقات بيانات التطبيق لاستدعاء هذه العمليات أو الاستجابة لها، وما إذا كانت العملية متضمنةً استجابة أم لا؛ بينما يتمثل دور معيار SOAP في تسهيل تحديد بروتوكول النقل مع الدلالات المرغوبة فيما يتعلق بخصائص البروتوكول مثل الوثوقية والأمن.
يتكون كل من معياري WSDL وSOAP من لغة مواصفات البروتوكول المعتمدة على لغة XML مع التركيز على توفير مواصفات الأدوات البرمجية مثل المصرّفات الجذعية stub compilers وخدمات الدليل directory services. ويُعَد دعم إنشاء التطبيقات تلقائيًا أمرًا بالغ الأهمية في عالمٍ مليء بالعديد من البروتوكولات المخصَّصة لتجنب الجهد المبذول لتطبيق كل بروتوكول يدويًا.
يأخذ دعم البرمجيات نموذج مجموعات الأدوات وخوادم التطبيقات التي طوّرها الموّردون التابعون لجهةٍ خارجية، مما يسمح لمطوري خدمات الويب االتركيزَ أكثر على مشكلة الأعمال التي يحتاجون إلى حلها، مثل تتبّع الطرد الذي اشتراه العميل.
تعريف بروتوكولات التطبيق
اختار معيار WSDL نموذج تشغيل إجرائي لبروتوكولات التطبيق، وتتكون واجهة خدمة الويب المجردة من مجموعة من العمليات التي تملك اسمًا، وتمثل كل عمليةٍ تفاعلًا بسيطًا بين العميل وخدمة الويب، وتشبه هذه العملية إجراءً يمكن استدعاءه عن بعد في نظام RPC، مثل خدمة WSDL Primer من اتحاد W3C التي هي خدمة ويب لحجز الفنادق مع وجود عمليتين هما التحقق من التوافرية CheckAvailability والحجز MakeReservation.
تحدّد كلُّ عمليةٍ نمطَ تبادل الرسائل Message Exchange Pattern أو اختصارًا MEP الذي يعطي التسلسل الذي ستُرسَل هذه الرسائل وفقًا له، بما في ذلك رسائل الخطأ المُرسَلة عند حدوث خطأٍ ما يعطّل تدفق الرسائل.
لقد حُدِّدت العديد من أنماط MEP مسبقًا، ويمكن تحديد أنماط MEP مخصَّصة جديدة، لكن سيُستخدَم نمطان فقط من أنماط MEP عمليًا هما: نمط In-Only المتمثل برسالةٍ واحدة من العميل إلى الخدمة، ونمط In-Out المتمثل بطلبٍ من العميل وردٍّ مقابلٍ من الخدمة. قد تفوق تكاليف دعم مرونة نمط MEP فوائده. تُعَد أنماط MEP قوالبًا تمتلك عناصر نائبة placeholders عوضًا عن أنواع أو صيغ رسائلٍ محددة، لذلك يتضمن جزءٌ من تعريف العملية تحديدَ صيغ الرسائل التي ستُربَط مع العناصر النائبة في النمط.
لم تُعرَّف صيغ الرسائل على مستوى البت، والتي تُعَد نموذجيةً للبروتوكولات التي ناقشناها، حيث تُعرَّف بدلًا من ذلك مثل نموذج بيانات مجردة باستخدام لغة XML. ويوفر مخطط XML مجموعةً من أنواع البيانات الأولية وطرقًا لتعريف أنواع البيانات المركبة، حيث يمكن تمثيل البيانات المتوافقة مع صيغة معرّف مخطط XML أو نموذج البيانات المجرد الخاص به بصورةٍ ملموسة باستخدام لغة XML، أو باستخدام تمثيلٍ آخر مشابه لتمثيل الثنائي لمعيار Fast Infoset.
يفصل معيار WSDL أجزاء البروتوكول التي يمكن تحديدها تجريديًا، والتي هي العمليات وأنماط MEP وصيغ الرسائل المجردة، عن الأجزاء التي يجب أن تكون ملموسة. يحدّد الجزء الملموس من معيار WSDL البروتوكولَ الأساسي، وكيفية ربط أنماط MEP به، وما هو التمثيل المُستخدم على مستوى البت لتمثيل الرسائل الموجودة فعليًا، كما يُعرف هذا الجزء من المواصفات باسم الارتباط binding. على الرغم من أنه يُفضَّل وصفه بأنه تطبيق أو ربطٌ بتطبيق؛ يحتوي معيار WSDL على ارتباطات محدَّدة مسبقًا ببروتوكول HTTP والبروتوكولات المعتمدة على معيار SOAP مع معامِلاتٍ تسمح لمصمم البروتوكول بضبط الربط بتلك البروتوكولات.
اقتباسيوجد إطار عملٍ لتعريف ارتباطاتٍ جديدة، لكن بروتوكولات SOAP هي المهيمنة.
تتمثّل إحدى جوانب تخفيف معيار WSDL لمشكلة تحديد عددٍ كبير من البروتوكولات، في إعادة استخدام ما يُعَد أساسًا وحدات مواصفات specification modules. قد تتكون مواصفات معيار WSDL لخدمة الويب من عدة مستندات WSDL، كما يمكن أيضًا استخدام وثائق WSDL في مواصفات خدمة الويب الأخرى، وتسهّل هذه التركيبة النمطية modularity تطوير المواصفات والتأكد من احتواء مواصفتين من تلك المواصفات على بعض العناصر المتطابقة، مثل إمكانية دعم نفس الأداة لهما.
تساعد هذه التركيبة النمطية، مع قواعد معيار WSDL الافتراضية، أيضًا في الحفاظ على المواصفات من أن تصبح مُسهَبة بصورةٍ كبيرة بالنسبة لمصممي البروتوكول، ويجب أن تكون التركيبة النمطية لمعيار WSDL مألوفةً لأي شخص طوَّر أجزاءً برمجيةً كبيرة، وليس ضروريًا أن تكون وثيقة معيار WSDL مواصفاتٍ كاملة، حيث يمكنها مثلًا تحديد صيغة رسالةٍ واحدة.
تحدَّد المواصفات الجزئية بصورةٍ فريدة باستخدام مساحات أسماء XML؛ حيث تحدد كل وثيقة WSDL معرّفَ URI لمساحة الأسماء الهدف، وتُسمَّى التعريفات الجديدة في الوثيقة في سياق مساحة الأسماء تلك، ويمكن أن تتضمن إحدى وثائق WSDL مكوناتٍ من وثيقة أخرى من خلال تضمين including الوثيقة الأخرى، إذا اشتركت كلتا الوثيقتين في نفس مساحة الأسماء الهدف أو من خلال استيراد importing الوثيقة الثانية إذا اختلفت مساحات الأسماء الهدف.
تعريف بروتوكولات النقل
يطلَق على معيار SOAP أحيانًا بروتوكول، إلا أنه من الأفضل التفكير فيه على أنه إطار عملٍ لتحديد البروتوكولات، كما توضح مواصفات الإصدار 1.2 من معيار SOAP، أنه يوفّر معيار SOAP إطار عملٍ بسيط للمراسلة التي تهتم وظيفته الأساسية بتوفير قابلية التوسّع. يستخدم معيار SOAP عدة استراتيجيات مستخدَمة أيضًا مع معيار WSDL، بما في ذلك صيغ الرسائل المحدَّدة باستخدام مخطط لغة XML، والارتباطات بالبروتوكولات الأساسية وأنماط تبادل الرسائل وعناصر المواصفات القابلة لإعادة الاستخدام المحددة باستخدام مساحات أسماء XML.
يُستخدَم معيار SOAP لتعريف بروتوكولات النقل بالخصائص المطلوبة لدعم بروتوكول تطبيقٍ معين، ويهدف إلى تسهيل تحديد العديد من هذه البروتوكولات باستخدام مكوناتٍ قابلة لإعادة الاستخدام، حيث يملك كل مكونٍ معلومات الترويسة والمنطق الذي يدخل في تطبيق ميزةٍ معينة؛ فمن أجل تعريف بروتوكولٍ بمجموعةٍ معينة من الميزات، فما عليك سوى تشكيل المكونات المقابلة. دعنا نلقي نظرةً عن كثب على هذا الجانب من معيار SOAP.
لقد قدّم الإصدار 1.2 من معيار SOAP ميزةً تجريدية تشرحها المواصفات على النحو التالي:
اقتباسميزة معيار SOAP هي امتدادٌ لإطار عمل إرسال رسائل هذا المعيار، حيث لا يفرض معيار SOAP قيودًا على النطاق المحتمل لمثل هذه الميزة، إلا أن الميزات النموذجية قد تتضمن الوثوقية reliability والأمن security والارتباط correlation والتوجيه routing وأنماط تبادل رسائل MEP، مثل محادثات الطلب / الاستجابة والمحادثات أحادية الاتجاه ومحادثات الند للند.
يجب أن تتضمن مواصفات ميزة معيار SOAP ما يلي:
- معرّف URI الذي يعرّف الميزة.
- معلومات الحالة والمعالجة الموصوفة تجريديًا والمطلوبة في كل عقدة SOAP لتطبيق الميزة.
- المعلومات التي ستنتقل إلى العقدة التالية.
- إذا كانت الميزة من نمط MEP، فسيجري تبادل رسائل دورة الحياة والعلاقات المؤقتة أو السببية، مثل أن تتبَع الاستجاباتُ الطلبات وتُرسل الاستجابات إلى منشئ الطلب.
يُعَد إضفاء الطابع الرسمي على مفهوم ميزة البروتوكول مستوىً منخفضًا نوعًا ما، حيث يكاد أن يكون تصميمًا.
هناك استراتيجيتان لتحديد بروتوكول SOAP الذي سيطبّق الميزات. تعتمد الاستراتيجية الأولى على استخدام الطبقات، أي ربط بروتوكول معيار SOAP ببروتوكول أساسي بطريقةٍ نستطيع اشتقاق الميزات منها، حيث يمكننا الحصول على بروتوكول طلب / استجابة عن طريق ربط بروتوكول معيار SOAP ببروتوكول HTTP، مع وضع طلب SOAP ضمن طلب HTTP ورد SOAP ضمن استجابة HTTP.
يمكن أن يكون لدى بروتوكول معيار SOAP ارتباطًا ببروتوكول HTTP محددًا مسبقًا، أي يمكن تعريف الارتباطات الجديدة باستخدام إطار عمل ارتباطات بروتوكول SOAP.
تتضمن الاستراتيجيةُ الثانية الأكثر مرونةً لتنفيذ الميزات كتلَ ترويسات header blocks، حيث تتكون رسالة SOAP من مُغلَّفٍ Envelope، ويحتوي ترويسةً Header تحتوي بدورها على كتل ترويسة، وجسمًا يحتوي على الحمولة الموجَّهة للمستقبل النهائي. يوضّح الشكل التالي بنية هذه الرسالة.
تتوافق معلومات ترويسةٍ معينة مع ميزاتٍ معينة، مثل استخدام توقيعٍ رقمي لتطبيق الاستيثاق authentication ورقمٍ تسلسلي من أجل الوثوقية، ومجموعٍ اختباري لاكتشاف تلف الرسالة. تهدف كتلة ترويسة SOAP إلى تغليف معلومات الترويسة المتوافقة مع ميزةٍ معينة، ولا تكون المراسلات دائمًا واحدًا لواحد، وذلك نظرًا لامكانية تضمين كتل ترويسة متعددةٍ في ميزةٍ واحدة، أو استخدام كتلة ترويسةٍ واحدة في ميزاتٍ متعددة.
تُعَد وحدة module من إطار عمل SOAP مواصفات صياغة ودلالات كتلةٍ أو أكثر من كتل الترويسة، وتهدف كل وحدةٍ إلى توفير ميزةٍ أو أكثر ويجب عليها الإعلان عن الميزات التي تطبّقها.
إن الهدف من وحدات SOAP هو التمكّن من تشكيل بروتوكولٍ بمجموعة من الميزات ببساطة عن طريق تضمين كلٍّ من مواصفات الوحدة المقابلة؛ فإذا كان يتوجب على البروتوكول الخاص بك أن يحتوي على دلالاتٍ واستيثاقٍ مرةً واحدةً على الأكثر، فيجب تضمين الوحدات المقابلة في المواصفات الخاصة بك. يمثل هذا نهجًا جديدًا لتقسيم خدمات البروتوكول، وهو بديلٌ لطبقات البروتوكول التي رأيناها طوال هذا الكتاب، وهو يشبه إلى حدٍ ما تسوية سلسلةٍ من طبقات البروتوكول في بروتوكولٍ واحد، ولكن بطريقةٍ منظَّمة.
يبقى أن نرى كيف ستعمل ميزات ووحدات SOAP المقدّمة في الإصدار 1.2 من معيار SOAP عمليًا، حيث تتمثل نقطة الضعف الرئيسية لهذا المخطط في امكانية تداخل الوحدات مع بعضها بعضًا، لذلك يجب وجود مواصفاتٍ للوحدات لتحديد أي تفاعلاتٍ معروفة مع وحدات SOAP الأخرى، ولكن من الواضح أن هذا لا يخفف كثيرًا من المشكلة. من ناحيةٍ أخرى، قد تكون مجموعة الميزات والوحدات الأساسية التي توفر أهم الخصائص صغيرةً بما يكفي لتكون معروفةً ومفهومةً جيدًا.
توحيد معايير بروتوكولات خدمات الويب
لا يُعَد معيارَا WSDL وSOAP بروتوكولات، وإنما معاييرٌ لتحديد البروتوكولات. لا تكفي الموافقة على استخدام معيارَي WSDL وSOAP بالنسبة للمؤسسات المختلفة المعنية بتطبيق خدمات الويب المتفاعلة مع بعضها بعضًا لتحديد بروتوكولاتها؛ إذ يجب أن توافق أيضًا على توحيد standardize بروتوكولاتٍ محددة. ويمكنك أن تتخيل مثلًا رغبة تجار التجزئة وشركات الشحن عبر الإنترنت في توحيد بروتوكولٍ يتبادلون المعلومات من خلاله، على غرار مثال تتبّع الطرد البسيط في بداية هذا القسم.
يُعَد هذا التوحيد ضروريًا لدعم الأدوات، بالإضافة إلى إمكانية التشغيل البيني interoperability، ولكن يجب أن تختلف تطبيقات الشبكة المختلفة في هذه المعمارية عن صيغ الرسائل والعمليات التي تستخدمها على الأقل.
يُعالَج هذا التوتر بين التوحيد القياسي والتخصيص من خلال إنشاء معاييرٍ جزئية تسمى ملفات التعريف profiles، وهي مجموعةٌ من الإرشادات التي تضيّق أو تقيّد الخيارات المتاحة في معيارَي WSDL وSOAP، والمعايير الأخرى الممكن الرجوع إليها في تعريف البروتوكول، حيث يمكن في نفس الوقت حل الغموض أو الثغرات في تلك المعايير.
يضفي ملف التعريف عمليًا الطابع الرسمي على معيارٍ عملي ناشئ، ويُعرف ملف التعريف الأوسع والأكثر اعتمادًا باسم WS-I Basic Profile الذي اقترحته منظمة Web Services Interoperability Organization أو اختصارًا WS-I، وهي اتحادٌ صناعي، بينما حدّد اتحاد شبكة الويب العالمية W3C معياري WSDL وSOAP.
يحل ملف التعريف الأساسي بعضًا من الخيارات الأساسية التي واجهناها في تعريف خدمة الويب، والجدير بالذكر أنه يتطلب أن يكون معيار WSDL مرتبطًا حصريًا بمعيار SOAP وأن يكون معيار SOAP مرتبطًا حصريًا ببروتوكول HTTP، إضافةً إلى وجوب استخدام طريقة HTTP POST. كما يحدد ملف التعريف أيضًا إصدارات معياري WSDL وSOAP الواجب استخدامها.
يضيف ملف تعريف WS-I Basic Security Profile قيود أمانٍ إلى ملف التعريف الأساسي عن طريق تحديد كيفية استخدام طبقة SSL / TLS والمطالبة بالتوافق مع أمن خدمات الويب WS-Security؛ الذي يحدد كيفية استخدام العديد من التقنيات الموجودة، مثل شهادات المفتاح العام لتقنية X.509 ونظام كيربيروس لتوفير ميزات أمن بروتوكولات معيار SOAP.
أمن WS-Security هو أول مجموعةٍ متناميةٍ من المعايير التي بمستوى معيار SOAP، والتي وضعها الاتحاد الصناعي للنهوض بمعايير المعلومات المنظَّمة Organization for the Advancement of Structured Information Standards أو اختصارًا OASIS، حيث تتضمن المعايير المعروفة مجتمعةً باسم WS-* الوثوقية WS-Reliability وإرسال الرسائل الموثوق WS-ConfidenceMessaging، والتنسيق WS-Coordination، والمعامَلات الذرية الصغيرة WS-AtomicTransaction.
بروتوكول التطبيق المعمم مثل بروتوكول REST
تعتمد معمارية خدمات الويب WSDL / SOAP على افتراض أن أفضل طريقةٍ لدمج التطبيقات عبر الشبكات هي عن طريق البروتوكولات المخصَّصة لكل تطبيق، حيث صُمِّمت هذه المعمارية لتحديد وتطبيق كل تلك البروتوكولات عمليًا؛ بينما تعتمد معمارية خدمات الويب REST على افتراض أن أفضل طريقة لدمج التطبيقات عبر الشبكات هي عن طريق إعادة تطبيق النموذج الأساسي لمعمارية الويب العالمية.
يُعرف هذا النموذج الذي صاغه مهندس الويب روي فيلدينغ Roy Fielding، باسم نقل الحالة التمثيلية REpresentational State Transfer أو اختصارًا REST. ليست هناك حاجةً إلى معمارية REST جديدة لخدمات الويب، لأن المعمارية الحالية كافية، على الرغم من أن بعض الإضافات قد تكون ضرورية، وتُعَد خدمات الويب في معمارية الويب بمثابة موارد تحدّدها معرّفات URI، ويجري الوصول إليها عبر بروتوكول HTTP، وهو بروتوكول تطبيقات مُعمّمِة generic مع نظام عنونة معمّم.
يملك معيار WSDL عملياتٍ يعرّفها المستخدم، بينما يستخدم معيار REST مجموعةً صغيرةً من طرق بروتوكول HTTP المتاحة، مثل عمليتي GET وPOST. إذًا كيف يمكن لهذه الأساليب البسيطة توفير واجهةٍ لخدمة ويب غنية؟ من خلال استخدام نموذج REST، حيث يُحوَّل التعقيد من البروتوكول إلى الحمولة payload التي هي تمثيلٌ لحالة المورد المجرَّد، حيث يمكن لعملية GET أن تعيد تمثيلًا لحالة المورد الحالية، كما يمكن لعملية POST إرسال تمثيلٍ لحالة المورد المرغوبة على سبيل المثال.
تمثيل حالة المورد مجردٌ؛ أي لا يحتاج إلى أن يشبه كيفية تطبيق المورد فعليًا بواسطة نسخة خدمة ويب معينة، وليس من الضروري إرسال حالة مواردٍ كاملة في كل رسالة. يمكن تقليل حجم الرسائل عن طريق نقل أجزاء الحالة التي تهمنا فقط مثل الأجزاء المعدَّلة فقط. تشترك خدمات الويب في بروتوكولٍ وحيز عناوين مع موارد الويب الأخرى، لذلك يمكن تمرير أجزاءٍ من الحالات عن طريق دليلٍ معرّف URI حتى عند استخدام خدمات ويب أخرى.
يُفضَّل تلخيص هذا النهج على أنه أسلوبٌ موجَّهٌ بالبيانات أو أسلوب تمرير مستندات بدلًا من عدّه أسلوبًا إجرائيًا، ويتألف تحديد بروتوكول التطبيق في هذه المعمارية من تحديد بنية المستند أي تمثيل الحالة. تُعَد لغة XML ولغة ترميز الكائنات باستعمال جافاسكربت JavaScript Object Notation أو اختصارًا JSON ذات الوزن الخفيف، من أكثر لغات العرض استخدامًا لهذه الحالة.
وتعتمد إمكانية التشغيل البيني على الاتفاق بين خدمة الويب وعملائها على تمثيل الحالة، ويُطبَّق بالطبع نفس الشيء في معمارية SOAP؛ حيث يجب أن تكون خدمة الويب وعميلها متفقين على صيغة الحمولة، ويتمثل الفرق بينهما في اعتماد التشغيل البيني أيضًا في معمارية SOAP على الاتفاق على البروتوكول؛ أما في معمارية REST، يكون البروتوكول دائمًا هو بروتوكول HTTP، لذلك تتخلّص من مصدر مشاكل التشغيل البيني.
تتمثل إحدى ميزات ترويج معيار REST في تعزيز البنية التحتية التي نُشرت لدعم الويب، حيث يمكن لوكلاء الويب مثلًا فرض الأمن أو تخزين المعلومات في ذاكرةٍ مخبئية، واستخدام شبكات توزيع المحتوى CDN الموجودة لدعم تطبيقات RESTful.
كان لدى الويب وقتٌ لاستقرار المعايير وإثبات أنها تتّسع جيدًا على النقيض من معمارية WSDL / SOAP، كما أنه يأتي مع بعض الأمن على هيئة Secure Socket Layer / Transport Layer Security أو اختصارًا SSL / TLS، وقد يكون للويب ومعيار REST أيضًا ميزةً في قابلية التطور. أُتُعَد طرُ عمل معيارَي WSDL وSOAP مرنةً للغاية فيما يتعلق بالميزات والارتباطات الجديدة التي يمكن أن تدخل في تعريف البروتوكول، ولكن تختفي هذه المرونة بمجرد تعريف البروتوكول.
لقد صُمِّمت البروتوكولات المعيارية مثل بروتوكولHTTP مع توفير التوسع بطريقةٍ متوافقة مع الإصدارات السابقة، حيث تأخذ قابلية توسع بروتوكول HTTP الخاصة نموذج ترويساتٍ وطرقٍ جديدة وأنواع محتوى جديدة، لكن يحتاج مصممو البروتوكول الذين يستخدمون معمارية WSDL / SOAP إلى تصميم قابلية التوسع هذه في كل من البروتوكولات المخصَّصة لهم، ويجب على مصممي تمثيلات الحالة في معمارية REST أيضًا التصميم من أجل قابلية التطور.
من المجالات التي قد يكون فيها وجود معيار WSDL / SOAP ميزةً، هو مجال تكييف أو تغليف التطبيقات القديمة المكتوبة مسبقًا، لتتوافق مع خدمات الويب. تُعَد هذه نقطةً مهمة، لأن معظم خدمات الويب ستعتمد على التطبيقات القديمة في المستقبل القريب على الأقل، حيث تحتوي هذه التطبيقات عادةً على واجهةٍ إجرائية ترتبط مع عمليات معيار WSDL بصورةٍ أسهل من ارتباطها مع حالات معيار REST.
قد تتوقف منافسة معيار REST ومعيار WSDL / SOAP على مدى سهولة أو صعوبة ابتكار واجهاتٍ بأسلوب REST لكل خدمة ويب، وقد نجد أن بعض خدمات الويب مُقدَّمةٌ بصورةٍ أفضل بواسطة معيار WSDL / SOAP والبعض الآخر أفضلُ بواسطة معيار REST.
لقد كان البيع بالتجزئة عبر الإنترنت في أمازون من أوائل المتبنين لخدمات الويب في عام 2002، حيث أتاحت أمازون نظامها للجميع باستخدام كلٍّ من معماريتَي خدمات الويب، ولكن يستخدم غالبية المطورين واجهة REST وفقًا لبعض التقارير.
من خدمات الويب إلى الخدمات السحابية
إذا كانت خدمات الويب هي أن يرسل خادم الويب الذي ينفّذ تطبيقي طلبًا إلى خادم الويب الذي ينفّذ تطبيقك، فماذا نسمّي الخدمات التي نستخدمها لوضع تطبيقاتنا في السحابة لتصبح قابلةً للتطوير؟ يمكننا أن نطلق عليهما الخدمات السحابية Cloud Services إذا أردنا ذلك، ولكن هل هذا تمييزٌ فقط بدون فوارقٍ بينهما؟ الإجابة هي أنه الأمر يتوقف على عدّة أشياء.
يؤدي نقل عملية خادمٍ من جهازٍ حقيقي يعمل في غرفتك إلى جهازٍ افتراضي يعمل في مركز بيانات مزود السحابة، إلى نقل مسؤولية الحفاظ على تشغيل الجهاز من مسؤول النظام إلى فريق عمليات مزود السحابة، ولكن التطبيق لا يزال مُصممًا وفقًا لمعمارية خدمات الويب؛ أما إذا صُمِّم التطبيق من البداية لتشغيله على نظامٍ سحابيٍ أساسي قابلٍ للتطوير من خلال الالتزام بمعمارية الخدمات الصغيرة micro-services architecture على سبيل المثال، فإننا نقول أن التطبيق سحابيٌ أصلي cloud native، لذا فإن الفارق المهم هو بين الخدمات السحابية الأصلية مقابل خدمات الويب القديمة المنتشرة في السحابة.
من الصعب الإعلان بصورةٍ قاطعة عن تفوق الخدمات الصغيرة على خدمات الويب، إلا أن الاتجاه الحالي في الصناعة يفضّل بالتأكيد الخدمات الصغيرة. والأمر الأهم هنا هو النقاش الدائر حول استخدام آلية REST + Json مقابل آلية gRPC + Protbufs على أنها آلية RPC المفضلة لتطبيق الخدمات الصغيرة، مع الأخذ في الحسبان أن كليهما يعملان على ترويسة HTTP.
ترجمة -وبتصرّف- للقسم Traditional Applications من فصل Applications من كتاب Computer Networks: A Systems Approach.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.