بنية خدمية
الوصف > خلفية

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