بنية خدمية
نقاش > الفوائد

بعض مصممي المشاريع المؤسسية مقتنع بإمكانية مساعدة بنية SOA للمشاريع التجارية على الوصول إلى استجابة أسرع لظروف السوق المتغيرة بأقل التكاليف، ينشر هذا الاتجاه في التصميم فكرة إعادة الاستخدام على المستوى الواسع (الخدمات) وليس على المستوى الدقيق (الفئات classes)، يمكن أيضا أن يبسط عملية التواصل مع – واستخدام – مصادر تكنولوجيا المعلومات الموجودة بالفعل.
يمكن النظر إلى بنية SOA من بعض الزوايا كتطور وليس انقلاب في عالم التصميم، فهي تضم العديد من الممارسات المثلى الخاصة بالبنيات البرمجية التي سبقتها، في أنظمة الاتصالات مثلا نجد أن تطورا محدودا قد حدث في الحلول التي تستخدم ارتباطات ساكنة حقيقية للتواصل مع الأجهزة الأخرى في الشبكة، وبتبنيها لأسلوب SOA يمكن لهذه الأنظمة أن تضع نفسها في موقع التأكيد على أهمية وضوح الواجهات والتعاون فيما بينها.
البعض تساءل عما إذا كانت بنية SOA مجرد إحياء لمفاهيم مثل البرمجة التركيبية modular programming (السبعينيات) أو التصميم باستخدام الأحداث event-oriented design (الثمانينيات) أو التصميم بناء على الواجهة\المكون interface/component-based design (التسعينيات). تروج بنية SOA فكرة فصل المستخدمين (المستهلكين) عن كيفية تنفيذ الخدمة، بالتالي يمكن للخدمات أن تعمل على منصات موزعة مختلفة ويمكن الوصول إليها عبر الشبكات، ويمكن أن يؤدي هذا أيضا إلى رفع معدل إعادة استخدام الخدمات.
تحقق البنية الخدمية فوائدها التجارية والتقنية من خلال استخدام أسلوب يعتمد على التحليل والتصميم أثناء بناء الخدمات، هذا الأسلوب يضمن توافق الخدمات مع رؤيا التصميم وخارطة الطريق ويضمن التزامها بمبادئ الخدمية. الأدلة التي الوجه التجاري والإداري لبنية SOA تم نشرها في العديد من الدراسات.
الخدمة عبارة عن وحدة وظيفية مستقلة متاحة فقط من خلال واجهة معرفة بشكل رسمي. يمكن أن تكون الخدمات «مشاريع صغيرة» يسهل إنتاجها ورفع كفاءتها، ويمكن أيضا أن تكون «شركات عملاقة» تعمل بالتنسيق بين الخدمات الفرعية التابعة لها.
تلتزم الخدمات عموما بمبادئ الخدمية هذه:
التجريد
الاستقلالية
التركيبية
القابلية للاكتشاف
العقد الرسمي
الارتباط الحر
القابلية لإعادة الاستخدام
انعدام الحالة
تعرف عملية الاستخدام المتكاملة لبنية SOA واجهة برمجة التطبيقات الخاصة بالمؤسسة.
أسباب معاملة تطبيقات الخدمات كمشاريع منفصلة عن المشاريع الكبرى تشمل:
عملية الفصل توصل للسوق التجاري فكرة إمكانية توصيل الخدمات بسرعة وبشكل منفصل عن المشاريع الأضخم والأبطأ المنتشرة في المؤسسة، فيبدأ السوق في استيعاب الأنظمة وواجهات المستخدم المبسطة لاستدعاء هذه الخدمات، وهذا يدعم مفهوم خفة الحركة بمعنى انها ترعى الابتكارات التجارية وتقلل من الوقت المطلوب لانطلاقها إلى السوق.
تنشر عملية الفصل فكرة عدم ارتباط الخدمات بالمشاريع المتلقية للخدمة، وهذا يشجع جودة التصميم على قدر تصميم الخدمة بدون معرفة مستخدميها.
لا تدرج الوثائق والاختبارات المعدة بواسطة المصممين ضمن تفاصيل المشروع الكبير، تأتي أهمية هذا عند الحاجة لإعادة استخدام الخدمة فيما بعد.
أحد الفوائد الغير مباشرة لبنية SOA هي سهولة الاختبار المتناهية، فالخدمات مستقلة ومنعدمة الحالة وواجهاتها موثقة بالكامل ومنفصلة عن المسائل التطبيقية المتفرعة، لم يسبق للمجال التعامل مع هذه الحالة من قبل.
إذا كانت لدى المؤسسة بيانات اختبار معدة جيدا، يتم بناء قاعدة تتفاعل مع بيانات الاختبار أثناء بناء الخدمة، ثم يتم تسجيل مجموعة كاملة من اختبارات التراجع regression tests والسكربتات والبيانات والردود الخاصة بالخدمة. يمكن اختبار الخدمة بأسلوب «الصندوق الأسود» باستخدام القواعد الجاهزة للخدمات الأخرى التي تتواصل معها، يمكن إعداد بيئة الاختبار بحيث تكون الخدمات البسيطة أو الخارجية عبارة عن قواعد وبقية الشبكة هي اختبارات للخدمات الكاملة. عندما تكون كل الواجهات موثقة واختبارات التراجع الخاصة بها كذلك، يصبح من السهل التعرف على المشاكل في الخدمات التي تم اختبارها، تتأكد عملية الاختبار فقط من عمل الخدمة طبقا للوصف الخاص بها وتعثر على الثغرات الموجودة في وثائق الخدمة واختبارات كل الخدمات الموجودة في البيئة.
قد تفيد الأمثلة في توثيق الخدمة حتى تصل لمرحلة مفيدة. وتعتبر وثائق بعض واجهات برمجة التطبيقات من Java Community Process أمثلة جيدة، ولأن هذه الوثائق شاملة ومفصلة يستخدم طاقم العمل عادة الأجزاء الهامة فقط، يعد ملف 'ossjsa.pdf' في JSR-89 مثالا لمثل هذه الملفات.