SOA (البنية الخدمية)

menu icon

SOA (البنية الخدمية)

استكشاف البنية الخدمية (SOA)، وهي مرحلة هامة في تطور عملية تطوير وتكامل التطبيقات.

ما هي البنية الخدمية (SOA)؟

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

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

يمكن تطوير هذه الخدمات من البداية ولكن غالبا ما يتم إنشاؤها من خلال عرض وظائف من الأنظمة المتوارثة للسجلات كواجهات خدمة.

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

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

ما هي ESB؟

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

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

تعرف على المزيد حول حافلة خدمة المؤسسة من خلال قراءة "مقدمة عن حافلة خدمة المؤسسة (ESB)".

مزايا البنية الخدمية

مقارنة بالبنى التي سبقتها، تقدم البنية الخدمية مزايا كبيرة للمؤسسة:

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

أمثلة البنية الخدمية

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

  • تحولت شركة Delaware Electric إلى البنية الخدمية لدمج الأنظمة التي لم تكن تتواصل مع بعضها في السابق، مما أدى إلى قدرة كفاءات التطوير، التي ساعدت المؤسسة على البقاء، على الوفاء بالتزامتها خلال فترة خمس سنوات من التجميد الذي تفرضه الدولة على أسعار الكهرباء.
  • اعتمدت Cisco البنية الخدمية للتأكد من أن تجربتها في طلب المنتجات كانت متسقة عبر جميع المنتجات والقنوات من خلال عرض عمليات الطلب كخدمات يمكن لأقسام Cisco وعمليات الاستحواذ وشركاء الأعمال دمجها في مواقع الإنترنت الخاصة بهم.
  • قامت ‎Independence Blue Cross (IBC) في فيلادلفيا بتطبيق البنية الخدمية لضمان أن الجهات المختلفة التي تتعامل مع بيانات المريض — وكلاء خدمة عملاء IBC، مكاتب الأطباء، مستخدمو موقع IBC عبر الإنترنت — كانت تعمل مع نفس مصدر البيانات ('نسخة واحدة من الحقيقة').

البنية الخدمية مقابل الخدمات المصغرة

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

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

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

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

للحصول على مزيد من التعمق في الاختلافات بين البنية الخدمية والخدمات المصغرة، ارجع إلى "البنية الخدمية مقابل الخدمات المصغرة: ما الفرق؟"

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

البنية الخدمية وIBM Cloud

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

اتخذ الخطوة التالية:

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

بدء التعامل مع حساب IBM Cloud اليوم.