بنية خدمية

البنية الخدمية (SOA) هي مجموعة من مبادئ تصميم الأنظمة تستخدم في مجال الحوسبة أثناء مراحل تطوير الأنظمة واندماجها. يقدم النظام الذي يستخدم هذه البنية وظائفه على هيئة حزمة من الخدمات المتعاونة التي يمكن استخدامها من قبل أنظمة مختلفة من مجالات تجارية متعددة.

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

تشرح بنية SOA كيفية اندماج تطبيقات ويب مستقلة تماما لخلق بيئة ويب، وتستخدم منصات برمجية متعددة. تعرف البنية واجهة الخدمات في صورة وظائف وبروتوكولات بدلا من تعريفها كواجهة برمجة تطبيقات API. يسمى المدخل لتطبيق SOA نقطة نهاية endpoint.

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

يمكن النظر إلى البنية الخدمية في إطار تطور تدريجي بدءً من المبادئ الأولى للحوسبة الموزعة[2] distributed computing والبرمجة التركيبية modular programming – مرورا بالبنية الخدمية – وصولا للممارسات الحالية في تطبيقات المزج mashups وتطبيقات ساس والحوسبة السحابية Cloud Computing (التي يراها البعض امتدادا للبنية الخدمية[3]).

الوصف

خلفية

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

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

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

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

حتى يعمل هذا النموذج يجب ألا يكون هناك تعامل بين الوحدات المحددة أو بداخل الوحدات نفسها، وبدلا من هذا يقوم الأفراد بتحديد التعاملات بين الخدمات (جميعهم أقران غير مرتبطين) حسب الحاجة وتدفعها المتطلبات المستجدة، لذا كانت الحاجة لأن تكون الخدمات وحدات وظيفية أكبر كثيرا من الدوال functions أو الفئات classes المعتادة خشية أن يؤدي التعقيد الناتج عن آلاف من هذه الكائنات الصغيرة إلى الضغط على البرنامج. المبرمجون يكتبون الخدمات نفسها بلغات تقليدية مثل جافا وC وC# وC++ وفيجوال بيسك وكوبول وPHP. تعتمد خدماتSOA على ميزة الارتباط الحر بمكاتب الربط الديناميكي أو ملفات التجميع assembly بعكس الدوال التي يتم ربطها معا لتكوين ملف تنفيذي. كما أن خدمات SOA تعمل في غلاف "آمن" (مثل جافا أو دوت نت) وفي لغات برمجة أخرى تقوم بإدارة توزيع الذاكرة واستعادتها وتتيح الربط المؤجل والربط حسب الحاجة وتوفر شكلا من أشكال التأكد من أنواع البيانات. منذ عام 2008 يتزايد عدد شركات برمجيات الطرف الثالث التي تقدم الخدمات البرمجية لقاء رسوم، في المستقبل قد تتألف أنظمة SOA من خدمات الطرف الثالث هذه وأخرى تم بناؤها بداخل الشركة صاحبة النظام، وفي هذا ميزة توزيع التكاليف على العديد من العملاء والعديد من الاستخدامات ونشر المعايير بداخل المجال نفسه أو بين المجالات وبعضها. مثلا مجال السفر الآن لديه مجموعة واضحة من الخدمات والبيانات الموثقة كافية ليتمكن أي مهندس برمجيات جيد من عمل برنامج وكالة سفريات باستخدام خدمات برمجية جاهزة بالكامل.[4] كما بدأت مجالات أخرى مثل المالية من تحقيق تقدم في هذا الاتجاه أيضا. تعتمد بنية SOA على الخدمية كمبدأ التصميم الأساسي.[5] إذا كانت واجهة الخدمة تخفي كل التعقيدات الموجودة وراءها فباستطاعة المستخدمين التعامل مع الخدمات المستقلة بدون معرفة المنصة البرمجية المستخدمة في بنائها.[6]

المتطلبات

لابد أن تتسم البنية بهذه المواصفات حتى تتمكن من استخدام بنية SOA بكفاءة:

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

المبادئ

تعرف المبادئ الإرشادية التالية القواعد الأساسية لتطوير وصيانة واستخدام بنية SOA:[7]

  • إعادة الاستخدام، التقسيم لوحدات صغيرة، التقسيم لوحدات وظيفية، التركيبية، التقسيم إلى مكونات والتعاون.
  • موافقة المعايير (العامة منها والخاصة بكل مجال).
  • تعريف الخدمات وتصنيفها وتقديمها وتوصيلها والمراقبة والتتبع

أول بحث تم نشره عن الخدمية من وجهة نظر متخصصة معين قام به توماس إيرل من شركة SOA Systems، وقام توماس بتعريف ثمانية مبادئ خاصة بالخدمية وهذه المبادئ مشتركة بين كل منصات SOA الرئيسية. تم نشر هذه المبادئ تحت عنوان “Service-Oriented Architecture: Concepts, Technology, and Design”، على موقع www.soaprinciples.com للأبحاث، وفي نسخة سبتمبر 2005 من Web Services Journal (أنظر الخدمية).

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

بعض المؤلفين أضافوا المبادئ التالية أيضا:

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

تعرض المراجع التالية اعتبارات إضافية خاصة بشرح تطبيق SOA:

  • SOA Reference Architecture يقدم تصميم تم تنفيذه لتطبيق تجاري لبنية SOA ويشمل رسوم مفصلة للبنية ووصف للمكونات وشروط الاستخدام والأنماط التصميمية design patterns ووجهات نظر خاصة بالمعايير وأنماط الالتزام بالقوانين وقوالب المعايير إلخ.[8]
  • إدارة دورة الحياة SOA Practitioners Guide Part 3: Introduction to Services Lifecycle يشرح دورة حياة الخدمات ويعرض عملية مفصلة لإدارة الخدمات من خلال دورة حياة الخدمة من بداية إطلاقها حتى إنهائها أو تغيير أهدافها، كما أنه يشمل ملحق يحتوي على ممارسات التحكم والتنظيم المثلى والقوالب وتعليقات على أهم معايير بنية SOA ووصلات هامة للمزيد من المعلومات.
  • SOA Design Principles يقدم معلومات إضافية عن كيفية بناء بنية SOA باستخدام مبادئ تصميم الخدمة

كما يمكن أخذ هذه العوامل أيضا في الاعتبار عند تعريف تطبيق SOA:

  • كفاءة استخدام مصادر النظام
  • اكتمال الخدمة وآداؤها
  • اندماج التطبيقات التجارية

أسلوب خدمات الويب

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

يمكن أن تلعب كل وحدة في بنية SOA أحد أو كلا الدورين التاليين:

  1. مقدم خدمة - يقوم مقدم الخدمة بعمل خدمة ويب وربما اتاحة واجهتها ومعلومات الوصول إليها في سجل الخدمات. لابد أن يقرر مقدم الخدمة ما الخدمات التي سيجعلها متاحة وكيف يوازن بين الأمن وسهولة الإتاحة وكيف سيقيم الرسوم المطلوبة لقاء الخدمة و(إن لم تكن الخدمة تتطلب رسوم) إن كان وكيف سيستغلها لتحقيق فائدة أخرى، كما أنه أيضا لابد ان يقرر تحت أي تصنيف سيتم إدراج الخدمة لدى أي خدمة وسيط وأي نوع من اتفاقيات الشريك التجاري مطلوب الحصول عليه لاستخدام الخدمة. يسجل مقدم الخدمة كل الخدمات التي تشتمل عليها الخدمة ومستخدميها المحتملين. ثم يقرر مطور خدمة الوسيط مجال هذا الوسيط، الوسيط العام يكون متاحا من خلال الإنترنت بينما هناك وسيط خاص تستطيع فئة معينة فقط من المستخدمين الوصول إليه مثل مستخدمي الشبكة الداخلية لأحد الشركات. أيضا لابد من تحديد كم المعلومات التي سيتم اتاحتها، بعض الوسطاء يتخصصون في تقديم كم ضخم من الخدمات، بينما يركز آخرون على تقديم خدمات على مستوى عال من الثقة، البعض يعرض مدى واسع من التخصصات بينما يركز آخرون على مجال محدد، وهناك وسطاء تسجل لديها وسطاء آخرون. يقرر كل وسيط حسب نموذجه التجاري ما إذا كان سيركز على زيادة عدد طلبات البحث عن الخدمات أو عدد الخدمات المسجلة لديه أو مدى دقتها. يقدم سجل الوصف والاكتشاف والاندماج العالمي Universal Description Discovery and Integration (يودي) شرحا لكيفية نشر واكتشاف المعلومات الخاصة بخدمات الويب. يوجد تكنولوجيا أخرى تستخدم في وسيط الخدمات مثل ebXML (التجارة الإلكترونية باستخدام لغة XML) وتكنولوجيا أخرى مبنية على معيار ISO/IEC 11179 لسجل البيانات الوصفية.
  2. مستهلك الخدمة – يقوم مستهلك الخدمة أو عميل خدمة الويب بتحديد خدمات معينة في سجل الوسيط عن طريق عمليات البحث المختلفة ثم يقوم بالارتباط بمقدم الخدمة ليتمكن من استغلال أحد خدماته، أيا كانت الخدمات التي يحتاجها العميل فلابد أن يأخذها عبر الوسيط ثم يرتبط بالخدمة الأصلية ثم يبدأ في استخدامها، يمكنه الوصول إلى أكثر من خدمة إذا كان مقدم الخدمة يقدم عددا من الخدمات.

بنية SOA وبروتوكولات خدمات الويب

يقوم المطورون عادة بتنفيذ بنية SOA باستخدام معايير خدمات الويب (مثل سواب)[2] الذي لاقى قبولا كبيرا في السوق التجاري بعد توصيات من W3C [9](رابطة الشبكة العالمية) بالإصدار1.2 في 2003. تتيح هذه المعايير (المسماة أيضا بلغات وصف خدمات الويب) تعاون أكثر وحماية من قيود شركات برمجيات الملكية. رغم هذا يمكن تطبيق بنية SOA باستخدام أي من تقنيات الخدمات مثل جيني أو كوربا أو ريست.

مفاهيم بنية SOA الأخرى

يمكن أن تعمل أي بنية بدون الاعتماد على تقنيات محددة. يمكن للمصممين إنشاء بنية SOA باستخدام عدد كبير من التقنيات مثل:

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

Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama[10]
SOA meta-model, The Linthicum Group, 2007

تتيح بنية SOA تطوير تطبيقات يتم بناؤها عن طريق دمج خدمات حرة ومتعاونة.[11]

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

لغات البرمجة عالية المستوى مثل BPFL واللغات الوصفية مثل WS-CDL وWS-Coordination توسع مفهوم الخدمة بتقديم وسيلة لتعريف ودعم توزيع الخدمات صغيرة الحجم على خدمات أكبر حجما يمكن للمصممين بدورهم إدماجها في خط سير العمل والعمليات التجارية التي يتم تنفيذها في تطبيقات مركبة أوبوابات تجارية.

بدأ الباحثون منذ عام 2008 في دراسة استخدام بنية المكون الخدمة Service Component Architecture في تطبيق بنية SOA. التصميم الخدمي هو هيكل لبنية SOA يعرف الطرق المختلفة التي يستخدمها الممارسون في تصور وتحليل وتصميم وبناء مصادرهم الخدمية. إطار التصميم الخدمي Service-oriented modeling framework (SOMF) يقدم لغة تصميم وإطار عمل أو "خريطة" توضح المكونات المختلفة التي تشارك في تصميم خدمي ناجح، فهي تشرح العناصر الرئيسية في توضيح "ما يجب فعله؟" في عملية تطوير الخدمات. الإطار يمكن الممارسين من وضع خطة مشروع وتحديد المحطات الرئيسية في الخطة الخدمية، كما أنه يقدم مفاهيم تصميم مشتركة تخص التعامل بين الشركات التجارية وشركات تكنولوجيا المعلومات.

يتعامل إطار التصميم الخدمي مع هذه المبادئ:

  • التتبع التجاري
  • تتبع ممارسات التصميم المثلى
  • التتبع التقني
  • عرض قيمة بنية SOA
  • إعادة الانتفاع بالأصول البرمجية
  • استراتيجيات اندماج بنية SOA
  • التجريد والتعميم التقني
  • تجريد مكونات التصميم

تعريفات بنية SOA

قدم المتخصصون عددا من التعريفات لبنية SOA، قامت مجموعة أويسيس[12] OASIS والمجموعة المفتوحة[13] بوضع تعريفات رسمية لها.

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

عقد الخدمة البرمجي

لابد أن يحتوي عقد الخدمة على المكونات التالية:

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

بنية إدارة الشبكة وSOA

بدأت مبادئ SOA تطبق منذ عام 2008 في مجال إدارة الشبكات، أمثلة للبنية الخدمية لإدارة الشبكات تشمل TS 188 001 NGN Management OSS Architecture من جمعية ETSI وتوصيات M.3060 Principles for the Management Of Next Generation Networks من قطاع أيتو - تي. أدوات إدارة بنية SOA التحتية تشمل:

  • برمجيات وحلول HP
  • محسن الآداء IPS من هيبرفورميكس
  • إطار تيفولي من IBM
  • شبكة عمليات Red Hat JBoss

نقاش

الفوائد

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

البعض تساءل عما إذا كانت بنية SOA مجرد إحياء لمفاهيم مثل البرمجة التركيبية modular programming (السبعينيات) أو التصميم باستخدام الأحداث event-oriented design (الثمانينيات) أو التصميم بناء على الواجهة\المكون interface/component-based design (التسعينيات). تروج بنية SOA فكرة فصل المستخدمين (المستهلكين) عن كيفية تنفيذ الخدمة، بالتالي يمكن للخدمات أن تعمل على منصات موزعة مختلفة ويمكن الوصول إليها عبر الشبكات، ويمكن أن يؤدي هذا أيضا إلى رفع معدل إعادة استخدام الخدمات. تحقق البنية الخدمية فوائدها التجارية والتقنية من خلال استخدام أسلوب يعتمد على التحليل والتصميم أثناء بناء الخدمات، هذا الأسلوب يضمن توافق الخدمات مع رؤيا التصميم وخارطة الطريق ويضمن التزامها بمبادئ الخدمية. الأدلة التي الوجه التجاري والإداري لبنية SOA تم نشرها في العديد من الدراسات.[16]

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

  • التجريد
  • الاستقلالية
  • التركيبية
  • القابلية للاكتشاف
  • العقد الرسمي
  • الارتباط الحر
  • القابلية لإعادة الاستخدام
  • انعدام الحالة

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

أسباب معاملة تطبيقات الخدمات كمشاريع منفصلة عن المشاريع الكبرى تشمل:

  1. عملية الفصل توصل للسوق التجاري فكرة إمكانية توصيل الخدمات بسرعة وبشكل منفصل عن المشاريع الأضخم والأبطأ المنتشرة في المؤسسة، فيبدأ السوق في استيعاب الأنظمة وواجهات المستخدم المبسطة لاستدعاء هذه الخدمات، وهذا يدعم مفهوم خفة الحركة بمعنى انها ترعى الابتكارات التجارية وتقلل من الوقت المطلوب لانطلاقها إلى السوق.[18]
  2. تنشر عملية الفصل فكرة عدم ارتباط الخدمات بالمشاريع المتلقية للخدمة، وهذا يشجع جودة التصميم على قدر تصميم الخدمة بدون معرفة مستخدميها.
  3. لا تدرج الوثائق والاختبارات المعدة بواسطة المصممين ضمن تفاصيل المشروع الكبير، تأتي أهمية هذا عند الحاجة لإعادة استخدام الخدمة فيما بعد.

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

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

قد تفيد الأمثلة في توثيق الخدمة حتى تصل لمرحلة مفيدة. وتعتبر وثائق بعض واجهات برمجة التطبيقات من Java Community Process أمثلة جيدة، ولأن هذه الوثائق شاملة ومفصلة يستخدم طاقم العمل عادة الأجزاء الهامة فقط، يعد ملف 'ossjsa.pdf' في JSR-89 مثالا لمثل هذه الملفات.[19]

تحديات تبني بنية SOA

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

تحد آخر يتعلق بنقص الاختبارات في مجال SOA. لا يوجد أدوات متقدمة لاختبار كل الخدمات عديمة الرأس (بما فيها خدمات الرسائل وقواعد البيانات وخدمات الويب) في البنية العادية. افتقاد الثقة الأفقية يتطلب من منتجي الخدمة ومن مستخدميها الاختبار الدائم للخدمات. الهدف الرئيسي لبنية SOA هو خفة الحركة في المجال التجاري، بالتالي من المهم الاستثمار في هيكل للاختبارات (بإنشائه أو شرائه) يحقق الشفافية المطلوبة لاكتشاف عيوب البنية. الخفة التجارية تتطلب تحكم الأهداف والتوجيهات التجارية في خدمات SOA كما تم تعريفه في نموذج التحفيز التجاري.[20]

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

مع توسع ممارسي بنية SOA ولغات وصف خدمات الويب في المخرجات وتحديثها وتعديلها يواجههم نقص في الأشخاص المؤهلين للعمل مع الأنظمة تستخدم بنية SOA بما فيها اندماج الخدمات وإنشاء البنية التحتية للخدمات.

أصبح التعاون مسألة هامة في تطبيقات SOA. قامت مؤسسة[21] WS-I بتطوير بروفايل رئيسي وبروفايل أمني رئيسي لفرض التوافق، كما أنها صممت أدوات اختبار للمساعدة على التأكد من التزام خدمات الويب بتوجيهات بروفايل WS-I، بالإضافة إلى وضع ميثاق جديد للعمل على بروفايل موثوق وآمن. تحيط ضجة تجارية هائلة ببنية SOA، مما قد يؤدي إلى توقعات مبالغ فيها. المنتجات مستمرة في التطور حيث يختبر المتبنون الأوائل منتجات وقت العمل runtime مع مشاكل حقيقية. لا تضمن بنية SOA تقليل تكاليف تكنولوجيا المعلومات أو زيادة خفة الأنظمة أو تقليل الوقت المطلوب للانطلاق إلى السوق، قد تحقق تطبيقات SOA الناجحة بعض أو كل هذه الفوائد حسب مستوى جودة ودقة بنية النظام وتصميمه.[22][23]

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

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

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

انتقادات بنية SOA

بعض الانتقادات[25] ترجع إلى الخلط بين بنية SOA وخدمات الويب، فمثلا يدعي بعض النقاد أن بنية SOA تؤدي إلى إضافة طبقات XML، مما يذهب بنا إلى مسألة تحليل وتركيب لغة XML. في غياب الصيغ الثنائية أو الأصلية لنداء الإجراء البعيد RPC قد تعمل التطبيقات بشكل أبطأ وتستهلك قدرات معالجة أكبر مما يؤدي إلى زيادة التكاليف، أغلب التطبيقات تواجه هذه المشاكل ولكن يمكن تطبيق بنية SOA باستخدام تقنيات (مثل اندماج جافا التجاري وخدمة توزيع البيانات) لا تعتمد على النداءات البعيدة أو الترجمة من خلال XML، في نفس الوقت التقنيات التي ظهرت مؤخرا لتحليل لغة XML (مثل VTD/XML) والعديد من الصيغ الثنائية المتوافقة مع XMLتبشر جميعا برفع آداء SOA بشكل كبير.[26][27][28]

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

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

تتعلق الخطوة التالية في عملية التصميم بتعريف منصة توصيل الخدمة Service Delivery Platform (SDP) وتطبيقها. في مرحلة تصميم منصة توصيل الخدمة يتم تعريف نماذج المعلومات التجارية وإدارة الهوية والمنتجات والمحتوى، والأجهزة، ومواصفات خدمة العميل ومدى خفة النظام وقدرته بالتالي على التعامل مع تطورات السوق والعملاء.

بيان SOA الرسمي

في عام 2009، في ندوة SOA الدولية الثانية قامت مجموعة مختلطة مكونة من 17 ممارس مستقل وشركة – "مجموعة عمل بيان SOA الرسمي" – بالإعلان عن نشر بيان SOA الرسمي.[31] البيان هو مجموعة من الأهداف والمبادئ الإرشادية التي تهدف لعرض فهم واضح ورؤيا لبنية SOA ومفهوم الخدمية، كان هدف البيان هو إنقاذ مفهوم بنية SOA من استخدام المجتمع التجاري المفرط له و"تزايد المعلومات المغلوطة واللبس بشكل كبير". يقدم البيان تعريفا واسعا لبنية SOA والفوائد التي سيحصل عليها الموقعون وبعض المبادئ الإرشادية، ويقدم الأولويات التالية:

  • القيمة التجارية على الاستراتيجية التقنية
  • الأهداف الاستراتيجية على الفوائد الخاصة بالمشروع
  • جوهرية التعاون على الاندماج المخصوص
  • الخدمات المشتركة على التطبيقات ذات الأهداف الخاصة
  • المرونة على الآداء الأمثل
  • رفع الآداء باستمرار التطوير على محاولة الوصول للكمال الأولي

وفي عام 2010 كانت 700 دولة قد وقعت على البيان وتم ترجمته لتسع لغات.

خارطة الطريق

خارطة الطريق إلى بنية SOA تشمل:

  • فهم الحالة النهائية للسوق مع أول إصدار
  • جمع بيانات عن حالة صيانة العملية التجارية حاليا والتطبيقات والاندماجات والأمن والبيانات الرئيسية والتحكم
  • تقليل فجوة الاستعداد بين الكيانات المتعددة في بنية SOA

ستكون الكائنات المختلفة في أحد حالات الاستعداد.

صيانة العملية التجارية
  • حسب الغرض: يتم تعريف العمليات عند وحسب الحاجة
  • موثقة: الإجراءات التجارية موثقة في ملفات منفصلة
  • منظمة: تستخدم أدوات إدارة العمليات حتى لو لم تكن متصلة
  • الخدمات: تصمم العمليات كخدمات من خلال آداة معيارية لإدارة العمليات

الاندماج
  • نقطة إلى نقطة: تتعامل التطبيقات مباشرة مع واجهة الطرف المطلوب
  • الارتباط الحر: بعض التطبيقات تستخدم تطبيق وسيط يقدم الواجهة بشكل مجرد
  • الخدمات الساكنة: الخدمات موجودة ولكن مرتبطة بتطبيقات أخرى ساكنة
  • الربط الديناميكي: يتم ربط الخدمات الساكنة بشكل ديناميكي من خلال نموذج ناشر\مشترك
  • الخدمات الديناميكية: الخدمات القادرة على معرفة متى تكون مطلوبة والاستجابة كما ينبغي

التطبيقات
  • المستقلة: تطبيقات تتطلب جهود كبيرة في الواجهة
  • المغلفة بخدمة: التطبيقات المغلفة لتعمل كخدمات
  • واجهات برمجة التطبيقات المكشوفة: التطبيقات لديها واجهات برمجية تعتمد على الخدمات
  • الخدمات المكشوفة: هذا يجعل التطبيقات قابلة لإعادة الاستخدام
  • الاكتشاف الديناميكي: يمكن اكتشاف التطبيقات للتطبيقات الأخرى

الأمن
  • التحقق والترخيص على مستوى التطبيق: يتم الوصول لكل تطبيق في الصومعة الخاصة به
  • التحكم الحر في عملية التحقق: بعض التطبيقات تعمل على بروتوكول LDAP
  • التحقق المقيد والمحكوم بالمجلدات: يدعم نظام SSO في أغلب التطبيقات
  • التحكم المركزي في الهوية وإدارة الوصول

البيانات الرئيسية
  • تتحكم التطبيقات بها: كل التطبيقات تتحكم في البيانات الرئيسية الخاصة بها
  • المشاركة الجزئية: بعض التطبيقات تشارك بياناتها الرئيسية ولكن ليس كل البيانات الرئيسية
  • الصيانة المركزية للبيانات الرئيسيسة: أغلب البيانات الرئيسية مشتركة ويتم صيانتها بواسطة بعض تطبيقات إدارة البيانات الرئيسية

امتدادات

SOA، ويب 2.0، خدمات عبر الماسنجر، وتطبيقات المزج ويب 2.0 – "الجيل الثاني" لنشاط الويب – يقدم ميزة قدرة الزوار على الإسهام بالمعلومات بغرض التعاون والمشاركة كأحد مزاياه الرئيسية. تستخدم تطبيقات ويب 2.0 غالبا خدمات ويب بنية ريست وتعتمد عادة على واجهات أجاكس وتستغل نقابة الويب والمدونات ومستودعات ويكي. بالرغم أنه لا يوجد معايير لويب 2.0 ولكن مواصفاته تشكلت بالبناء على البنية الموجودة لخادم الويب وباستخدام الخدمات. بالتالي يمكن القول أن ويب 2.0 يشتمل على بعض مواصفات بنية SOA.[32][33][34]

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

ويب 2.0

اخترع تيم أوريلي مصطلح "ويب 2.0 " لوصف مجموعة ملحوظة سريعة النمو من تطبيقات الويب.[35] أحد المواضيع التي تلقت تغطية مكثفة هو العلاقة بين ويب 2.0 والبنية الخدمية (SOA)، تعتبر بنية SOA فلسفة تغليف منطق التطبيقات بداخل خدمات بواجهة معرفة بشكل موحد واتاحة هذه الخدمات للاستخدام العام من خلال أساليب الاكتشاف. لقد شجعت مفاهيم إخفاء التعقيد وإعادة الاستخدام والارتباط الحر بين الخدمات الباحثين على البحث عن التفاصيل المتشابهة بين الفلسفتين، بنية SOA وويب 2.0 وتطبيقاتهم. البعض يقول أن لكل منهما عناصر مختلفة تماما بالتالي لا يمكن اعتبارهم "فلسفتين متوازيتين"، بينما يرى البعض أن كلا المفهومين متكاملين وير ويب 2.0 كنموذج أشمل من SOA.[33]

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

برغم أن أوراكل تقول أن جارتنر قد اخترع مصطلخا جديدا، تحليل جارتنر يقول أنهم يسمونه بنية SOA المتقدمة ويشيرون إليها باسم "SOA 2.0.[37] أغلب شركات البرمجيات الوسيطة (مثل ريد هات وويب ميثودز وتيبكو سوفتوير وآي بي إم وصن ميكروسيستمز وأوراكل) كانت لديها شكل من أشكال SOA 2.0 على مدى سنين.

الجهاز العصبي الرقمي

وصفت تطبيقات SOA بأنها تمثل جزء من رؤيا أكبر تعرف باسم الجهاز العصبي الرقمي[38][39] أو مشروع اللا تأخير.[40]

بنية SOA نحيفة

أحد أساليب تطوير بنية SOA تستغل مبادئ تطوير البرمجيات النحيفة.[41]

مراجع
  1. Bell_, Michael (2010)، SOA Modeling Patterns for Service-Oriented Discovery and Analysis، Wiley & Sons، ص. 390، ISBN 978-0470481974.
  2. Erl, Thomas. Serviceorientation.org – About the Principles, 2005-2006 نسخة محفوظة 23 أكتوبر 2007 على موقع واي باك مشين.
  3. Application Platform Strategies Blog: SOA is Dead; Long Live Services نسخة محفوظة 23 ديسمبر 2017 على موقع واي باك مشين.
  4. OpenTravel نسخة محفوظة 20 يناير 2018 على موقع واي باك مشين.
  5. An alternative view, particularly after initial deployments, denies that SOAs properly ought to dictate physical implementation, so the formal definition should not include "network". High-performance SOAs may not be viable, especially if deployed to distributed nodes on a network. Separate nodes for every (or most) services could become prohibitively expensive.
  6. Channabasavaiah, Holley and Tuggle, Migrating to a service-oriented architecture, آي بي إم DeveloperWorks, 16 December 2003. نسخة محفوظة 09 ديسمبر 2008 على موقع واي باك مشين.
  7. Yvonne Balzer Improve your SOA project plans, آي بي إم, 16 July 2004 نسخة محفوظة 09 ديسمبر 2008 على موقع واي باك مشين.
  8. SOA Practitioners Guide Part 2: SOA Reference Architecture نسخة محفوظة 23 ديسمبر 2011 على موقع واي باك مشين.
  9. SOAP Version 1.2 の公開について (W3C 勧告) نسخة محفوظة 17 يوليو 2017 على موقع واي باك مشين.
  10. Enterprise SOA. Prentice Hall, 2005
  11. Cardoso, Jorge (2006)، "Foreword"، Semantic Web Services, Processes and Applications، SEMANTIC WEB AND BEYOND: Computing for Human Experience، Foreword by Frank Leymann، Springer، xxi، ISBN 978-0-387-30239-3، مؤرشف من الأصل في 9 مارس 2016، اطلع عليه بتاريخ 11 سبتمبر 2019، The corresponding architectural style is called "service-oriented architecture": fundamentally, it describes how service consumers and service providers can be decoupled via discovery mechanisms resulting in loosely coupled systems. Implementing a service-oriented architecture means to deal with heterogeneity and interoperability concerns. {{استشهاد بكتاب}}: روابط خارجية في |الأخير= (مساعدة)
  12. SOA Reference Model definition نسخة محفوظة 27 أكتوبر 2017 على موقع واي باك مشين.
  13. SOA – Documents – Document details نسخة محفوظة 11 فبراير 2012 على موقع واي باك مشين.
  14. Christopher Koch A New Blueprint For The Enterprise, CIO Magazine, March 1, 2005 نسخة محفوظة 16 يناير 2009 على موقع واي باك مشين.
  15. Bieberstein et al., Service-Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap (The developerWorks Series) (Hardcover), IBM Press books, 2005, 978-0131870024
  16. Martin van den berg et al. SOA for Profit, A Manager's Guide to Success with Service-Oriented Architecture (Hardcover), 978-9075414141
  17. M. Hadi Valipour, Bavar AmirZafari, Kh. Niki Maleki, Negin Daneshpour, A Brief Survey of Software Architecture Concepts and Service Oriented Architecture, in Proceedings of 2nd IEEE International Conference on Computer Science and Information Technology, ICCSIT'09, pp 34-38, Aug 2009, China. "نسخة مؤرشفة"، مؤرشف من الأصل في 14 مارس 2020، اطلع عليه بتاريخ 20 مايو 2020.{{استشهاد ويب}}: صيانة CS1: BOT: original-url status unknown (link)
  18. Brayan Zimmerli Business Benefits of SOA, University of Applied Science of Northwestern Switzerland, School of Business, 11 November 2009 نسخة محفوظة 04 أغسطس 2012 على موقع واي باك مشين.
  19. https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=7854-oss_service_activation-1.0-fr-spec-oth-JSpec@CDS-CDS_Developer— JSR-89 Spec download نسخة محفوظة 2011-07-26 على موقع واي باك مشين.
  20. From the Business Motivation Model(BMM) to SOA, Journal Of Object Technology – November/December 2008 نسخة محفوظة 19 يونيو 2017 على موقع واي باك مشين.
  21. WS-I Basic Profile نسخة محفوظة 09 يوليو 2017 على موقع واي باك مشين.
  22. Is There Real Business Value Behind the Hype of SOA?, Computerworld, June 19, 2006. نسخة محفوظة 16 يناير 2009 على موقع واي باك مشين. [وصلة مكسورة]
  23. See also: WS-MetadataExchange OWL-S
  24. The Overlapping Worlds of SaaS and SOA نسخة محفوظة 30 يونيو 2017 على موقع واي باك مشين.
  25. Tim Bray, XML co-founder – http://blogs.zdnet.com/service-oriented/?p=597 نسخة محفوظة 2009-01-24 على موقع واي باك مشين.
  26. Index XML documents with VTD-XML نسخة محفوظة 04 يوليو 2008 على موقع واي باك مشين. [وصلة مكسورة]
  27. The Performance Woe of Binary XML نسخة محفوظة 9 يناير 2020 على موقع واي باك مشين. [وصلة مكسورة]
  28. Manipulate XML Content the Ximple Way نسخة محفوظة 30 يوليو 2017 على موقع واي باك مشين.
  29. "The Reason SOA Isn't Delivering Sustainable Software"، jpmorgenthal.com، 19 يونيو 2009، مؤرشف من الأصل في 7 يوليو 2009، اطلع عليه بتاريخ 27 يونيو 2009.
  30. "SOA services still too constrained by applications they represent"، zdnet.com، 27 يونيو 2009، مؤرشف من الأصل في 2 يوليو 2009، اطلع عليه بتاريخ 27 يونيو 2009.
  31. SOA Manifesto Official WebsiteDate Accessed: 02 October 2010. نسخة محفوظة 25 يوليو 2017 على موقع واي باك مشين.
  32. Dion Hinchcliffe Is Web 2.0 The Global SOA?, SOA Web Services Journal, 28 October 2005 نسخة محفوظة 07 أغسطس 2016 على موقع واي باك مشين.
  33. Schroth, Christoph ; Janner, Till; (2007)، "Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services"، IT Professional 9 (2007), Nr. 3, pp. 36-41, IEEE Computer Society، مؤرشف من الأصل في 03 ديسمبر 2013، اطلع عليه بتاريخ 23 فبراير 2008. {{استشهاد بدورية محكمة}}: Cite journal requires |journal= (مساعدة)صيانة CS1: extra punctuation (link) صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)
  34. Hoyer, Volker ; Stanoesvka-Slabeva, Katarina; Janner, Till; Schroth, Christoph; (2008)، "Enterprise Mashups: Design Principles towards the Long Tail of User Need"، Proceedings of the 2008 IEEE International Conference on Services Computing (SCC 2008)، مؤرشف من الأصل في 12 يونيو 2013، اطلع عليه بتاريخ 08 يوليو 2008. {{استشهاد بدورية محكمة}}: Cite journal requires |journal= (مساعدة)صيانة CS1: extra punctuation (link) صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)
  35. "What Is Web 2.0"، Tim O'Reilly، 30 سبتمبر 2005، مؤرشف من الأصل في 27 أبريل 2012، اطلع عليه بتاريخ 10 يونيو 2008.
  36. Ruggaber, Rainer; (2007)، "Internet of Services—A SAP Research Vision" (PDF)، IEEE Computer Society، مؤرشف من الأصل (PDF) في 19 فبراير 2012، اطلع عليه بتاريخ 23 فبراير 2008. {{استشهاد بدورية محكمة}}: Cite journal requires |journal= (مساعدة)صيانة CS1: extra punctuation (link) صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)
  37. Yefim Natis & Roy Schulte Advanced SOA for Advanced Enterprise Projects, Gartner, July 13, 2006 نسخة محفوظة 04 نوفمبر 2013 على موقع واي باك مشين.
  38. "From Web to Boarding Area: Delta's SOA is Ready"، مؤرشف من الأصل في 30 يناير 2019، اطلع عليه بتاريخ 02 مايو 2009.
  39. "The Value of An Enterprise Architecture"، مؤرشف من الأصل في 9 مارس 2016، اطلع عليه بتاريخ 02 مايو 2009.
  40. "Moving Toward the Zero Latency Enterprise"، مؤرشف من الأصل في 19 يوليو 2009، اطلع عليه بتاريخ 02 مايو 2009.
  41. "Lean Development Applied to SOA"، مؤرشف من الأصل في 3 مارس 2016، اطلع عليه بتاريخ 16 أغسطس 2010.
  • بوابة علم الحاسوب
  • بوابة تقنية المعلومات
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.