ما المقصود بالبنية الخدمية (SOA)؟

تريح SOA مطور التطبيقات من بعض المهام، والذي كان عليه في السابق إعادة تطوير أو تكرار الوظائف الحالية أو كان عليه معرفة كيفية الاتصال أو توفير إمكانية التشغيل البيني مع الوظائف الحالية.

تجسد كل خدمة في SOA التعليمات البرمجية والبيانات المطلوبة لتشغيل وظيفة عمل كاملة ومستقلة (على سبيل المثال التحقق من ائتمان العميل أو حساب دفعة قرض شهرية أو معالجة طلب رهن عقاري).  توفر واجهات الخدمة اقتران واسع. هذا يعني أنه يمكن استدعاؤها مع معرفة قليلة أو من دون معرفة كيفية تنفيذ الخدمة في الأساس، ما يقلل من الارتباطات بين التطبيقات.

تُعد هذه الواجهة عقد خدمة بين مقدم الخدمة ومستهلك الخدمة. يمكن كتابة التعليمات البرمجية التي تشغل التطبيقات خلف واجهة الخدمة بلغة Java أو Microsoft .Net أو Cobol أو أي لغة برمجة أخرى، أو يمكن توفيرها كتطبيقات برمجية مجمعة من قبل المورد (على سبيل المثال، SAP) أو تطبيقات SaaS (على سبيل المثال، Salesforce CRM) أو يمكن الحصول عليها كتطبيقات مفتوحة المصدر.

غالبًا ما تحدد واجهات الخدمات بشكل متكرر باستخدام لغة تعريف خدمات الويب (WSDL) وهي بنية علامات قياسية تستند إلى xml (لغة الترميز الموسعة).

تُعرض الخدمات باستخدام بروتوكولات الشبكة القياسية—مثل بروتوكول الوصول إلى الكائنات البسيط (SOAP)/HTTP أو HTTP Restful (JSON/ HTTP)—لإرسال طلبات لقراءة البيانات أو تغييرها. تتحكم حوكمة الخدمات في دورة حياة التطوير، وفي المرحلة المناسبة التي تُنشر فيها الخدمات في سجل يُمكّن المطورين من العثور عليها بسرعة وإعادة استخدامها لإنشاء تطبيقات أو عمليات أعمال جديدة.

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

وبهذه الطريقة، تمثل SOA مرحلة مهمة في مسار عملية تطوير التطبيقات وتكاملها على مدى العقود القليلة الماضية. قبل ظهور SOA في أواخر التسعينيات، كان ربط التطبيق بالبيانات أو الوظائف الموجودة في نظام آخر يتطلب تكاملاً معقدًا من نقطة إلى نقطة—وهو تكامل كان على المطورين إعادة إنشائه جزئيًا أو كليًا في كل مشروع تطوير جديد. وقد سمح عرض هذه الوظائف من خلال خدمات SOA للمطور بإعادة استخدام الإمكانات الحالية بكل بساطة وربطها من خلال بنية SOA ESB(انظر أدناه).

على الرغم من أن SOA، وبنية الخدمات المصغرة الأحدث، يتشاركان في العديد من المصطلحات (مثل "الخدمة" و"البنية")، إلا أنهما مرتبطتان بشكل واسع فقط، وفي الواقع، تعملان في نطاقات مختلفة، كما هو موضح لاحقًا في هذه المقالة.

 ESB، أو ناقل الخدمات المؤسسية، هو نمط هيكلي يُنفذ بموجبه عنصر برمجي مركزي عمليات التكامل بين التطبيقات. ويجري عمليات التحول لنماذج البيانات، ويتولى الاتصال والمراسلة، وينفذ التوجيه، ويحول بروتوكولات الاتصال ، وربما يدير تجميع طلبات متعددة.

يستطيع ESB جعل عمليات التكامل والتحويل هذه متاحة كواجهة خدمة لإعادة استخدامها في التطبيقات الجديدة. عادةً ما يُنفذ نمط ESB باستخدام بيئة تشغيل مصمم خصوصًا للتكامل ومجموعة أدوات تساعد على ضمان أفضل إنتاجية ممكنة.

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

وهذا يتطلب الكثير من العمل (حتى لو كانت الواجهات قابلة لإعادة الاستخدام) ويتسبب في ظهور تحديات كبيرة متعلقة بالصيانة في المستقبل حيث أن كل اتصال هو اتصال من نقطة إلى نقطة. في الواقع، كانت ESBs تُعد، في النهاية، عنصرًا فعليًا في أي عملية تنفيذ SOA لدرجة أن المصطلحين يستخدمان أحيانًا كمرادفات، ما يتسبب في حدوث لبس.

وبالمقارنة مع البُنى التي سبقتها، قدمت SOA مزايا كبيرة للمؤسسات:

• مرونة أكبر في العمل، والوصول إلى السوق في وقت أسرع: إمكانية إعادة الاستخدام هي المفتاح. تُمكّن كفاءة إنشاء التطبيقات من الخدمات القابلة لإعادة الاستخدام - وهي لبنات البناء، بدلاً من إعادة الكتابة وإعادة الدمج في كل مشروع تطوير جديد، المطورين من إنشاء التطبيقات بسرعة أكبر بكثير استجابةً لفرص العمل الجديدة.
  يدعم النهج البنائي الخدمي سيناريوهات تكامل التطبيقات وتكامل البيانات وأتمتة أسلوب تنسيق الخدمات لعمليات الأعمال أو مهام سير العمل. يؤدي ذلك إلى تسريع تصميم البرمجيات وتطوير البرمجيات من خلال تمكين المطورين من قضاء وقت أقل بكثير في التكامل ووقت أكبر في التركيز على تقديم تطبيقاتهم وتحسينها.
• إمكانية استخدام الوظائف القديمة في أسواق جديدة: تتيح SOA المصممة بشكل جيد للمطورين سهولة أخذ الوظائف "المعزولة" في منصة أو بيئة حوسبة واحدة وتوسيع نطاقها لتشمل بيئات وأسواق جديدة. على سبيل المثال، استخدمت العديد من الشركات SOA لعرض وظائف من الأنظمة المالية القائمة على الكمبيوتر المركزي في تطبيقات الويب الجديدة. وهذا يُمكّن عملاءها من خدمة أنفسهم بالعمليات والمعلومات التي لم يكن الوصول إليها في السابق متاحًا إلا من خلال التفاعل المباشر مع موظفي الشركة أو شركاء الأعمال.
• تحسين التعاون بين الأعمال وتكنولوجيا المعلومات: في SOA، يمكن تعريف الخدمات بمصطلحات الأعمال (على سبيل المثال، "إنشاء عرض أسعار تأمين" أو "حساب عائد الاستثمار في المعدات الرأسمالية"). وهذا يُمكّن محللي الأعمال من العمل بفعالية أكبر مع المطورين على معارف مهمة—مثل نطاق عملية الأعمال المحددة باستخدام الخدمات أو الآثار المترتبة على الأعمال من تغيير العمليات—والتي يمكن أن تؤدي إلى نتائج أفضل.

بحلول عام 2010، كانت تطبيقات SOA تسير بخطى سريعة في الشركات الرائدة في كل صناعة تقريبًا. على سبيل المثال:

تحولت شركة Delaware Electric إلى SOA لدمج الأنظمة التي لم تكن تتواصل مع بعضها في السابق، ما أدى إلى كفاءات في التطوير ساعدت المؤسسة على البقاء قادرة ماديًا خلال تثبيت أسعار الكهرباء بأمر من الولاية لمدة خمس سنوات.

تبنت Cisco بنية SOA للتأكد من أن تجربة طلب منتجاتها كانت متسقة عبر جميع المنتجات والقنوات من خلال عرض عمليات الطلب كخدمات قد تدمجها أقسام Cisco وعمليات الاستحواذ وشركاء الأعمال في مواقعهم الإلكترونية.

نفذت Independence Blue Cross (IBC) في فيلادلفيا بنية SOA للمساعدة على ضمان أن المكونات المختلفة التي تتعامل مع بيانات المرضى—وكلاء خدمة عملاء IBC وعيادات الأطباء ومستخدمي موقع IBC الإلكتروني—كانوا يتعاملون مع مصدر البيانات نفسه ("مصدر واحد للحقيقة").

لقد ملأ الخبراء بضعة آلاف من الصفحات المطبوعة والرقمية للمقارنة بين SOA والخدمات المصغرة، وتوضيح التفاصيل الدقيقة لعلاقتهما ببعضهما. وفي سياق هذه المقالة، تتمثل أوجه الاختلاف الرئيسية بين الاثنين في اقتران العناصر ونطاق الاستخدام:

SOA هو أسلوب هيكلي للتكامل ومفهوم مؤسسي. وهو يتيح إمكانية عرض التطبيقات الحالية عبر واجهات مقترنة بشكل واسع، كل منها يتوافق مع وظيفة عمل تُمكّن التطبيقات في جزء واحد من المؤسسة الكبيرة من إعادة استخدام الوظائف الموجودة في تطبيقات أخرى.

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

نشأت بنية الخدمات المصغرة واكتسبت زخمًا مع ظهور تقنيات المحاكاة الافتراضية، والحوسبة السحابية، وممارسات تطوير الأسلوب الرشيق، وعمليات التطوير. تنشأ معظم مزايا الخدمات المصغرة في هذه السياقات من فصل العناصر، ما يبسط ويحسن ما يلي:

• سرعة وإنتاجية المطورين: تُمكّن الخدمات المصغرة المطورين من دمج تقنيات جديدة في جزء واحد من التطبيق من دون التأثير على بقية التطبيق. يمكن تعديل أي عنصر واختباره ونشره بشكل مستقل عن العناصر الأخرى، ما يسرّع دورات التكرار.
• قابلية التوسع: يمكن للخدمات المصغرة تحقيق أقصى استفادة من قابلية التوسع السحابي—يمكن توسيع نطاق أي عنصر بشكل مستقل عن العناصر الأخرى لتحقيق أسرع استجابة ممكنة لمتطلبات أحمال التشغيل والاستخدام الأكثر كفاءة للموارد.
• المرونة: مرة أخرى، بفضل الفصل، لا يؤثر فشل إحدى الخدمات المصغرة في الخدمات الأخرى. ويمكن لكل خدمة مصغرة أن تعمل وفقا لمتطلبات التوافر الخاصة بها من دون ربط العناصر الأخرى أو التطبيق بأكمله بمتطلبات التوافر المشتركة الأكبر.

للتعرف بشكل أعمق على أوجه الاختلاف بين SOA والخدمات المصغرة، راجع مقارنة بين SOA والخدمات المصغرة: ما الفرق؟

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

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