خدمات الويب هي معايير محددة لتبادل البيانات عبر الويب. هذا لا يعني أن خدمات الويب سوف تتعرض للإنترنت، ولكن هناك مجموعة متفق عليها من "معايير الويب" التي تدعمها العديد من المنتجات. عند تحديد المعيار الذي سيتم اعتماده، فإن الشيء الأكثر أهمية الذي يجب مراعاته هو في كثير من الأحيان نصيحة الموظفين الفنيين.
وقد يوصونك، بالترتيب، بمعيار يسهل تنفيذه، ويحتوي على أوسع دعم فني للمنتج، ومن المرجح أن يعمل بشكل جيد في بيئتك. من أجل تنفيذ SOA بنجاح والذي سيصمد أمام اختبار الزمن ويستمر في التوسع في المستقبل، فإن كل هذه العوامل الثلاثة مهمة للغاية.
WS-I
تتخصص منظمة قابلية التشغيل البيني لخدمات الويب (WS-I) في تطوير أفضل الممارسات لمعايير الويب لضمان إمكانية التشغيل البيني عبر أنظمة التشغيل أو الأنظمة الأساسية أو لغات البرمجة المختلفة. WS-I مسؤول عن تحديد وثائق أفضل الممارسات مثل أمان خدمات الويب والمواصفات الفنية لمعالجة خدمات الويب. تساعد هذه الوثائق المطورين والشركات على التوافق مع الممارسات التي يستخدمها الآخرون لضمان قابلية تشغيل المستخدم.
تنشر WS-I أيضًا المواصفات الفنية ومجموعات الاختبار والعينات حول كيفية نشر هذه البروتوكولات. في الواقع، WS-I هي هيئة إدارية تم تشكيلها من قبل العديد من المنظمات مثل Microsoft وIBM، وتتمثل مهمتها في تعزيز خدمات الويب القابلة للتشغيل البيني.
اتفاقية الاستخدام
تعتمد خدمات الويب على البروتوكولات للتأكد من أن التواصل مفيد. ويجب الاتفاق مسبقًا على محتوى البيانات المرسلة بين الخدمات للتأكد من معرفة الطرفين بالمحتوى الذي يتم استلامه. يعد SOAP مثالاً على البروتوكول الأكثر استخدامًا على نطاق واسع عند تبادل البيانات. يستخدم SOAP لغة برمجة XML، مما يسمح للطرفين بفك تشفير ما يتم إرساله وتنسيق المعلومات المرسلة ذهابًا وإيابًا.
يوضح
سنقوم بتغطية بعض الهندسة المعمارية قريبًا وسنشير أيضًا إلى بعض بروتوكولات خدمة الويب. ومن المهم عدم الخلط بين هذين الأمرين. لذلك دعونا نقدمها بإيجاز أدناه.
إن بنيات البرامج مثل REST وRPC ليست بروتوكولات. إنها طرق تحدد كيفية تنفيذ الاتفاقية.
WSDL (لغة وصف خدمات الويب) هي لغة تُستخدم لوصف خدمة ويب معينة بطريقة منسقة بحيث تتمكن التطبيقات من تحليل الخدمة. لا توفر WSDL نفسها أي وظيفة في شكل تفاعلات خدمات الويب.
تحدد البروتوكولات نفسها، مثل SOAP أو XML-RPC أو DCOM، بالضبط كيفية تسليم الرسائل وكيف يفهم البرنامج البيانات التي يتلقاها.
هناك نوعان رئيسيان من البنى في SOA: عائلة بروتوكولات RPC ونهج نقل الحالة التمثيلية (REST).
RPC
تسمح طريقة استدعاء الإجراء عن بعد (RPC) للمبرمجين باستدعاء موارد نظام بعيد تمامًا مثل "استدعاء" الموارد المحلية عند البرمجة على نظام ما. عيب الخدمات ذات نمط RPC هو أن الأشخاص يميلون إلى استخدامها كما لو كانوا على دراية بلغة البرمجة على النظام الأساسي المحدد. ومن السهل أيضًا استدعاء إجراء عن بعد إذا كان هو نفس الإجراء المحلي.
هذا المنطق ينتهك مفهوم "الاقتران السائب". إن مفهوم الاقتران السائب يعني في الواقع أن العملية عن بعد لا ينبغي أن تعتمد على أي نظام تشغيل أو لغة برمجة محددة.
SOAP هو البروتوكول اللاحق لـ XML-RPC وهو مجرد استدعاء إجراء عن بعد يحتوي على معلوماته في XML. يستخدم SOAP بروتوكول HTTP لإرسال البيانات، وهو أمر جميل وبسيط، إلا أنه يحتوي على بعض العيوب. على الرغم من ذلك، لا تزال معظم خدمات الويب هذه الأيام تستخدم بروتوكول HTTP للاتصال حيث أنها مبنية باستخدام بروتوكول SOAP.
استراحة
يختلف نهج نقل الحالة التمثيلية (REST) بشكل أساسي عن استدعاءات الإجراءات عن بعد لأنه يعمل على مستوى مختلف. يشبه استدعاء REST أي طلب ويب آخر عبر بروتوكول HTTP، بينما يبدو استدعاء RPC مثل استدعاء دالة قياسي. ينصب تركيز REST على العمل باستخدام موارد مستقرة بدلاً من الرسائل الفردية، مما يؤدي إلى طريقة تفاعل أكثر معيارية ومفهومة على نطاق واسع، تمامًا مثل بروتوكول HTTP نفسه. يتعامل REST مع نقل أجزاء من البيانات البسيطة، بينما ينقل RPC العمليات المعقدة.
هل يجب استخدام REST أو RPC؟
إن مسألة ما إذا كان يجب استخدام REST هي بالتأكيد مسألة جيدة. يبدو وكأنه طريق المستقبل. ومع ذلك، يجب دمج SOA الخاص بك في كل جزء من البرامج التي تستخدمها حاليًا. كان اعتماد REST بطيئًا، ويرجع ذلك أساسًا إلى دعم خدمة الويب. على الرغم من أن نظام REST يمكنه استخدام WSDL لوصف رسالة SOAP عبر HTTP، إلا أنه لا يوجد دعم كافٍ لاستخدامه فعليًا. على سبيل المثال، لا يدعم Apache حتى الطرق المطلوبة لاستخدام REST دون تثبيت وحدة البرنامج الإضافي.
هناك معايير أخرى ليست جزءًا من عائلة خدمات الويب. ولكن، كما قد تتوقع، لا تحظى هذه المعايير بدعم واسع النطاق. جيني، WCF وCORBA هي بعض الأمثلة. عندما يقدم لك أحد البائعين منتجًا يدعم فقط إحدى التقنيات المذكورة أعلاه، فإنك تريد الهروب، وليس الابتعاد. أصبحت خدمات الويب الآن مدعومة على نطاق واسع. سوف ينمو استخدام خدمات الويب فقط. يُقال إن SOA نفسها جديدة وغير مستقرة ومحفوفة بالمخاطر. ومع ذلك، يمكن تخفيف هذه المخاطر إلى حد كبير عند اختيار معيار خدمات الويب المناسب الذي يتمتع بدعم فني واسع النطاق.
أخيرًا، يعد الالتزام ببرنامج SOAP القديم عبر نوع ما من أنظمة نمط RPC حاليًا آلية قابلة للتطبيق لبناء SOA باستخدام خدمات الويب. إذا قمت بذلك، فإنك تقلل بشكل كبير من فرص تقييد البائع.