بنية خدمية  البنية الخدمية (SOA) هي مجموعة من مبادئ تصميم الأنظمة تستخدم في مجال الحوسبة أثناء مراحل تطوير الأنظمة واندماجها. يقدم النظام الذي يستخدم هذه البنية وظائفه على هيئة حزمة من الخدمات المتعاونة التي يمكن استخدامها من قبل أنظمة مختلفة من مجالات تجارية متعددة.  كما أن البنية الخدمية تتيح لمستخدمي الخدمات – مثل تطبيقات الويب - طريقة للتعرف على خدمات SOA الموجودة، فمثلا قد تقدم مجموعة من الأقسام المنفصلة بداخل شركة ما عددا من خدمات SOA بأكثر من لغة برمجة، ويستفيد عملاؤهم من الواجهة الواضحة والسهلة لهذه الخدمات. تستخدم لغة XML في التواصل مع واجهة خدمات SOA عادة وليس بالضرورة.  تشرح بنية SOA كيفية اندماج تطبيقات ويب مستقلة تماما لخلق بيئة ويب، وتستخدم منصات برمجية متعددة. تعرف البنية واجهة الخدمات في صورة وظائف وبروتوكولات بدلا من تعريفها كواجهة برمجة تطبيقات API. يسمى المدخل لتطبيق SOA نقطة نهاية endpoint.  تتطلب الخدمية وجود ارتباط حر بين الخدمات وأنظمة التشغيل وأي تقنية برمجية أخرى مستخدمة في التطبيقات. تقسم البنية الوظائف إلى مجموعة من الوحدات المستقلة – أو الخدمات،– يقدمها المبرمجون على الشبكة حتى يتمكن المستخدمون من إعادة استخدامها ودمجها لبناء التطبيقات. يتواصل المستخدمون مع هذه الخدمات من خلال تداول البيانات في صياغات مشتركة وواضحة أو بتنسيق نشاط معين بين خدمتين أو أكثر.  يمكن النظر إلى البنية الخدمية في إطار تطور تدريجي بدءً من المبادئ الأولى للحوسبة الموزعة distributed computing والبرمجة التركيبية modular programming – مرورا بالبنية الخدمية – وصولا للممارسات الحالية في تطبيقات المزج mashups وتطبيقات ساس والحوسبة السحابية Cloud Computing (التي يراها البعض امتدادا للبنية الخدمية). تعتمد تطبيقات البنية الخدمية على شبكة من الخدمات البرمجية. تضم الخدمات وحدات وظيفية منفصلة حرة الارتباط لا تستدعي بعضها البعض من الداخل. تقوم كل خدمة بتنفيذ إجراء واحد مثل ملء طلب لإنشاء حساب على الإنترنت أو الاطلاع على معاملات بنكية أو حجز تذكرة طيران. بدلا من أن تستدعي الخدمات بعضها البعض من داخل أكوادها تستخدم الخدمات مجموعة محددة من البروتوكولات التي تصف كيفية إرسال الرسائل الرسائل والتعامل معها من خلال البيانات الوصفية بيانات وصفية.  يقوم مطورو SOA بربط كائنات SOA من خلال عملية التوزيع حيث يقوم المطور بتجميع الوظائف البرمجية (الخدمات) في بناء غير هرمي باستخدام آداة برمجية تحتوي على قائمة كاملة بكل الخدمات المتوفرة ومواصفاتها وكيفية بناء تطبيق باستخدام هذه المصادر. يتطلب القيام بكل هذا بيانات وصفية على قدر كافي من التفصيل لا لوصف خصائص الخدمات فقط بل والبيانات التي تحركها أيضا. استخدم المبرمجون لغة XML بكثافة مع بنية SOA لتنظيم البيانات التي يحيطونها بغلاف يحتوي على وصف شامل. كما تستخدم لغة وصف خدمات الويب (WSDL) لوصف الخدمات نفسها يستخدم بروتوكول سواب لوصف بروتوكولات الاتصال. يبقى التساؤل مفتوح حول ما إذا كانت هذه اللغات الوصفية هي أفضل ما يمكن القيام به وهل ستبقى الخيار الأفضل في المستقبل أم لا. تعتمد بنية SOA منذ عام 2008 على بيانات وخدمات توصف من خلال بيانات وصفية تخضع للشروط التالية: تهدف بنية SOA إلى السماح للمستخدمين بربط وحدات وظيفية ضخمة معا لبناء تطبيقات حسب الحاجة تعتمد بالكامل تقريبا على خدمات جاهزة. وكلما إزداد حجم هذه الوحدات كلما قلت نقاط الواجهة المطلوبة لتنفيذ مجموعة من الوظائف، إلا أن الوحدات الضخمة قد لا يكون حجمها ملائما بما يكفي لإعادة استخدامها بسهولة. كل واجهة برمجية لديها استهلاك إَضافي من المعالجة، لذا لابد من الأخذ في الاعتبار كفاءة الآداء عند تحديد حجم الوحدات المكونة للخدمات. تبشر بنية SOA بانخفاض التكلفة الهامشية للبرنامج رقم س، حيث أن كل البرمجيات المطلوبة لتلبية حاجات التطبيقات الأخرى موجودة بالفعل. نظريا لا يتطلب الأمر أكثر من عملية التوزيع لإنتاج تطبيق جديد.  حتى يعمل هذا النموذج يجب ألا يكون هناك تعامل بين الوحدات المحددة أو بداخل الوحدات نفسها، وبدلا من هذا يقوم الأفراد بتحديد التعاملات بين الخدمات (جميعهم أقران غير مرتبطين) حسب الحاجة وتدفعها المتطلبات المستجدة، لذا كانت الحاجة لأن تكون الخدمات وحدات وظيفية أكبر كثيرا من الدوال functions أو الفئات classes المعتادة خشية أن يؤدي التعقيد الناتج عن آلاف من هذه الكائنات الصغيرة إلى الضغط على البرنامج. المبرمجون يكتبون الخدمات نفسها بلغات تقليدية مثل جافا وC وC# وC++ وفيجوال بيسك وكوبول وPHP. تعتمد خدماتSOA على ميزة الارتباط الحر بمكاتب الربط الديناميكي أو ملفات التجميع assembly بعكس الدوال التي يتم ربطها معا لتكوين ملف تنفيذي. كما أن خدمات SOA تعمل في غلاف «آمن» (مثل جافا أو دوت نت) وفي لغات برمجة أخرى تقوم بإدارة توزيع الذاكرة واستعادتها وتتيح الربط المؤجل والربط حسب الحاجة وتوفر شكلا من أشكال التأكد من أنواع البيانات. منذ عام 2008 يتزايد عدد شركات برمجيات الطرف الثالث التي تقدم الخدمات البرمجية لقاء رسوم، في المستقبل قد تتألف أنظمة SOA من خدمات الطرف الثالث هذه وأخرى تم بناؤها بداخل الشركة صاحبة النظام، وفي هذا ميزة توزيع التكاليف على العديد من العملاء والعديد من الاستخدامات ونشر المعايير بداخل المجال نفسه أو بين المجالات وبعضها. مثلا مجال السفر الآن لديه مجموعة واضحة من الخدمات والبيانات الموثقة كافية ليتمكن أي مهندس برمجيات جيد من عمل برنامج وكالة سفريات باستخدام خدمات برمجية جاهزة بالكامل. كما بدأت مجالات أخرى مثل المالية من تحقيق تقدم في هذا الاتجاه أيضا. تعتمد بنية SOA على الخدمية كمبدأ التصميم الأساسي. إذا كانت واجهة الخدمة تخفي كل التعقيدات الموجودة وراءها فباستطاعة المستخدمين التعامل مع الخدمات المستقلة بدون معرفة المنصة البرمجية المستخدمة في بنائها.  لابد أن تتسم البنية بهذه المواصفات حتى تتمكن من استخدام بنية SOA بكفاءة:  تعرف المبادئ الإرشادية التالية القواعد الأساسية لتطوير وصيانة واستخدام بنية SOA:  أول بحث تم نشره عن الخدمية من وجهة نظر متخصصة معين قام به توماس إيرل من شركة SOA Systems، وقام توماس بتعريف ثمانية مبادئ خاصة بالخدمية وهذه المبادئ مشتركة بين كل منصات SOA الرئيسية. تم نشر هذه المبادئ تحت عنوان “Service-Oriented Architecture: Concepts, Technology, and Design”، على موقع www.soaprinciples.com للأبحاث، وفي نسخة سبتمبر 2005 من Web Services Journal (أنظر الخدمية).  بعض المؤلفين أضافوا المبادئ التالية أيضا:  تعرض المراجع التالية اعتبارات إضافية خاصة بشرح تطبيق SOA: كما يمكن أخذ هذه العوامل أيضا في الاعتبار عند تعريف تطبيق SOA:  يمكن تطبيق البنية الخدمية باستخدام خدمات الويب، تقدم خدمات الويب وحدات بنائها الوظيفي من خلال بروتوكولات الإنترنت المعيارية بشكل لا يعتمد على المنصات أو لغات البرمجة، يمكن أن تمثل هذه الخدمات تطبيقات جديدة أو مجرد غلاف حول أنظمة قديمة حتى تمكنها من العمل عبر الشبكة.  يمكن أن تلعب كل وحدة في بنية SOA أحد أو كلا الدورين التاليين:  يقوم المطورون عادة بتنفيذ بنية SOA باستخدام معايير خدمات الويب (مثل سواب) الذي لاقى قبولا كبيرا في السوق التجاري بعد توصيات من W3C (رابطة الشبكة العالمية) بالإصدار1.2 في 2003. تتيح هذه المعايير (المسماة أيضا بلغات وصف خدمات الويب) تعاون أكثر وحماية من قيود شركات برمجيات الملكية. رغم هذا يمكن تطبيق بنية SOA باستخدام أي من تقنيات الخدمات مثل جيني أو كوربا أو ريست.  يمكن أن تعمل أي بنية بدون الاعتماد على تقنيات محددة. يمكن للمصممين إنشاء بنية SOA باستخدام عدد كبير من التقنيات مثل: يمكن أن تستخدم التطبيقات واحدا أو أكثر من هذه البروتوكولات ويمكن أن تستخدم مثلا أسلوب نظام الملفات لإرسال بيانات مطابقة لمواصفات الواجهة بين مجموعة من العمليات المتوافقة مع مفهوم بنية SOA. الفكرة الأساسية هي خدمات منفصلة ذات واجهة محددة يمكن استدعاؤها للقيام بوظيفتها طبقا للمعايير بدون أن يكون للخدمة معرفة مسبقة بالتطبيق الذي سيقوم باستدعائها وبدون الحاجة لأن يكون التطبيق على علم بكيفية قيام الخدمة بمهامها. بدأ العديد من مطبقي بنية SOA في تبني مفاهيم SOA المتطورة في بنية أكثر تقدما تسمى SOA 2.0.  تتيح بنية SOA تطوير تطبيقات يتم بناؤها عن طريق دمج خدمات حرة ومتعاونة.  تتعامل هذه الخدمات مع بعضها البعض بناء على تعريف رسمي (أو عقد مثل WSDL) لا يعتمد على المنصة أو لغة البرمجة المستخدمة، تعريف الواجهة يخفي تفاصيل الخدمة التي تستخدم لغة معينة، بالتالي يمكن للأنظمة التي تستخدم بنية SOA العمل بدون الارتباط بتقنيات ومنصات التطوير المختلفة (مثل جافا ودوت نت وغيرها)، فيمكن للخدمات المكتوبة بلغة سي شارب وتعمل على منصات دوت نت والخدمات المكتوبة بلغة الجافا وتعمل على منصة جافا أن تستخدم من قبل تطبيق (أو عميل) مركب مشترك، يمكن أيضا للتطبيقات التي تعمل على أي من المنصتين استخدام خدمات تعمل على المنصة الأخرى بصفتها خدمة ويب تسهل إعادة الاستخدام. يمكن للبيئات التي تخضع للإدارة تغليف أنظمة كوبول القديمة وتقديمها كخدمات برمجية، يطيل هذا من عمر العديد من الأنظمة الرئيسية لمدى طويل بغض النظر عن اللغة الأصلية المستخدمة في بنائها. يمكن لبنية SOA أن تدعم عمليات الاندماج والاتحاد في الأنظمة التجارية المعقدة، ولكنها لا تقدم طريقة محددة أو هيكلا لتوثيق الإمكانيات أو الخدمات.  لغات البرمجة عالية المستوى مثل BPFL واللغات الوصفية مثل WS-CDL وWS-Coordination توسع مفهوم الخدمة بتقديم وسيلة لتعريف ودعم توزيع الخدمات صغيرة الحجم على خدمات أكبر حجما يمكن للمصممين بدورهم إدماجها في خط سير العمل والعمليات التجارية التي يتم تنفيذها في تطبيقات مركبة أوبوابات تجارية.  بدأ الباحثون منذ عام 2008 في دراسة استخدام بنية المكون الخدمة Service Component Architecture في تطبيق بنية SOA. التصميم الخدمي هو هيكل لبنية SOA يعرف الطرق المختلفة التي يستخدمها الممارسون في تصور وتحليل وتصميم وبناء مصادرهم الخدمية. إطار التصميم الخدمي Service-oriented modeling framework (SOMF) يقدم لغة تصميم وإطار عمل أو «خريطة» توضح المكونات المختلفة التي تشارك في تصميم خدمي ناجح، فهي تشرح العناصر الرئيسية في توضيح «ما يجب فعله؟» في عملية تطوير الخدمات. الإطار يمكن الممارسين من وضع خطة مشروع وتحديد المحطات الرئيسية في الخطة الخدمية، كما أنه يقدم مفاهيم تصميم مشتركة تخص التعامل بين الشركات التجارية وشركات تكنولوجيا المعلومات.  يتعامل إطار التصميم الخدمي مع هذه المبادئ:  قدم المتخصصون عددا من التعريفات لبنية SOA، قامت مجموعة أويسيس OASIS والمجموعة المفتوحة بوضع تعريفات رسمية لها.  تعرفها أويسيس كما يلي: نموذج لتنظيم واستخدام إمكانيات موزعة ربما تكون خاضعة لملكيات مختلفة، وهي تقدم أسلوبا موحدا لتقديم واكتشاف والتعامل مع واستخدام الإمكانيات لتحقيق النتائج المرجوة المتوافقة مع الشروط والتوقعات المسبقة.  لابد أن يحتوي عقد الخدمة على المكونات التالية:  بدأت مبادئ SOA تطبق منذ عام 2008 في مجال إدارة الشبكات، أمثلة للبنية الخدمية لإدارة الشبكات تشمل TS 188 001 NGN Management OSS Architecture من جمعية ETSI وتوصيات M.3060 Principles for the Management Of Next Generation Networks من قطاع أيتو - تي. أدوات إدارة بنية SOA التحتية تشمل:  بعض مصممي المشاريع المؤسسية مقتنع بإمكانية مساعدة بنية 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 مثالا لمثل هذه الملفات.  أحد التحديات الواضحة والمتكررة تتعلق بإدارة البيانات الوصفية الخاصة بالخدمات. قد تضم البيئة المبنية علة بنية SOA العديد من الخدمات التي تتبادل رسائل فيما بينها لآداء بعض المهام، وحسب التصميم المستخدم قد يرسل التطبيق الواحد ملايين الرسائل. تقديم وإدارة المعلومات الخاصة بكيفية تواصل الخدمات فيما بينها قد يصبح معقدا، ويصبح الأمر أكثر تعقيدا عندما تكون هذه الخدمات خارجية وتابعة لمؤسسات أخرى بداخل الشركة نفسها أو حتى شركات أخرى (شركاء، مزودين إلخ)، ويؤدي هذا إلى مشاكل كبيرة في الثقة بين المجموعات، وهنا يأتي دور تحكم بنية SOA.  تحد آخر يتعلق بنقص الاختبارات في مجال SOA. لا يوجد أدوات متقدمة لاختبار كل الخدمات عديمة الرأس (بما فيها خدمات الرسائل وقواعد البيانات وخدمات الويب) في البنية العادية. افتقاد الثقة الأفقية يتطلب من منتجي الخدمة ومن مستخدميها الاختبار الدائم للخدمات. الهدف الرئيسي لبنية SOA هو خفة الحركة في المجال التجاري، بالتالي من المهم الاستثمار في هيكل للاختبارات (بإنشائه أو شرائه) يحقق الشفافية المطلوبة لاكتشاف عيوب البنية. الخفة التجارية تتطلب تحكم الأهداف والتوجيهات التجارية في خدمات SOA كما تم تعريفه في نموذج التحفيز التجاري.  أحد التحديات الأخرى يتعلق بتحقيق مستويات مقبولة من الأمن. قد لا تكفي النماذج الأمنية الموجودة بداخل التطبيقات عندما تتيح هذا التطبيقات إمكانياتها في هيئة خدمات يمكن استخدامها من قبل تطبيقات أخرى، بمعنى أن إدارة الأمن بواسطة التطبيقات ليس هو النموذج الصحيح لتأمين الخدمات. بدأت عدد من التقنيات والمعايير الجديدة في الظهور وهي تقدم نماذج أكثر ملاءمة لتأمين بنية SOA.  مع توسع ممارسي بنية SOA ولغات وصف خدمات الويب في المخرجات وتحديثها وتعديلها يواجههم نقص في الأشخاص المؤهلين للعمل مع الأنظمة تستخدم بنية SOA بما فيها اندماج الخدمات وإنشاء البنية التحتية للخدمات.  أصبح التعاون مسألة هامة في تطبيقات SOA. قامت مؤسسة WS-I بتطوير بروفايل رئيسي وبروفايل أمني رئيسي لفرض التوافق، كما أنها صممت أدوات اختبار للمساعدة على التأكد من التزام خدمات الويب بتوجيهات بروفايل WS-I، بالإضافة إلى وضع ميثاق جديد للعمل على بروفايل موثوق وآمن. تحيط ضجة تجارية هائلة ببنية SOA، مما قد يؤدي إلى توقعات مبالغ فيها. المنتجات مستمرة في التطور حيث يختبر المتبنون الأوائل منتجات وقت العمل runtime مع مشاكل حقيقية. لا تضمن بنية SOA تقليل تكاليف تكنولوجيا المعلومات أو زيادة خفة الأنظمة أو تقليل الوقت المطلوب للانطلاق إلى السوق، قد تحقق تطبيقات SOA الناجحة بعض أو كل هذه الفوائد حسب مستوى جودة ودقة بنية النظام وتصميمه.  تقوم مؤسسات التوصيل الداخلي لتكنولوجيا المعلومات كل حين وآخر ببعض الجهود في مجال SOA يؤدي بعضها إلى عرض المفاهيم بشكل خاطئ على السوق التجاري ويظل هناك لبس في استيعاب هذه المفاهيم. تبني الفكرة يبدأ في تلبية احتياجات توصيل تكنولوجيا المعلومات بدلا من الاحتياجات التجارية، وهو ما ينتج عنه مثلا مؤسسة بها خدمات مميزة لتجهيز أجهزة اللابتوب بدلا من مؤسسة سريعة الاستجابة للفرص التجارية. القيادة التجارية أيضا ستصبح واثقة من آداء المؤسسة بشكل جيد مع بنية SOA.  أحد أهم مزايا بنية SOA هي سهولة إعادة الاستخدام، ويخدم هذا في النهاية تطور نماذج التمويل والمساءلة بداخل المؤسسة. لابد من تشجيع كل وحدة تجارية على بناء خدمات تستطيع الوحدات الأخرى استخدامها، وبالعكس لابد من تشجيع الوحدات على إعادة استخدام الخدمات، وهذا يتطلب بعض مكونات التحكم الجديدة:  بعض الانتقادات ترجع إلى الخلط بين بنية SOA وخدمات الويب، فمثلا يدعي بعض النقاد أن بنية SOA تؤدي إلى إضافة طبقات XML، مما يذهب بنا إلى مسألة تحليل وتركيب لغة XML. في غياب الصيغ الثنائية أو الأصلية لنداء الإجراء البعيد RPC قد تعمل التطبيقات بشكل أبطأ وتستهلك قدرات معالجة أكبر مما يؤدي إلى زيادة التكاليف، أغلب التطبيقات تواجه هذه المشاكل ولكن يمكن تطبيق بنية SOA باستخدام تقنيات (مثل اندماج جافا التجاري وخدمة توزيع البيانات) لا تعتمد على النداءات البعيدة أو الترجمة من خلال XML، في نفس الوقت التقنيات التي ظهرت مؤخرا لتحليل لغة XML (مثل VTD/XML) والعديد من الصيغ الثنائية المتوافقة مع XMLتبشر جميعا برفع آداء SOA بشكل كبير.  تتطلب الخدمات التي تحتفظ ببيانات الحالة مشاركة السياق الخاص بالمستهلك بين مقدم الخدمة والمستهلك ويتم تضمينه أو الإشارة إليه في الرسائل المتبادلة بين المقدم والمستهلك. هذا الشرط به عيب وهو إمكانية انخفاض قدرة مقدم الخدمة على التوسع إذا أضطر للاحتفاظ بالسياق المشترك لكل مستخدم، كما أنه يؤدي إلى زيادة الارتباط بين مقدم الخدمة والمستخدم مما يزيد من صعوبة التبديل بين مقدمي الخدمات. أخيرا بعض النقاد يشعرون أن خدمات SOA ما زالت تخضع لقيود التطبيقات التي تمثلها.  هناك قلق آخر بخصص التطور الحالي في معايير ومنتجات خدمات الويب (مثل المعاملات والأمن) بالتالي يمكن أن تأتي بنية SOA بمخاطر جديدة ما لم يتم إدارتها وتقدير ميزانيتها الإضافية واحتمال القيام بعمل إضافي لإثبات الفكرة. بعض النقاد ينظرون إلى بنية SOA باعتبارها مجرد تطور صريح لبنيات منتشرة حاليا (مثل الواجهات المفتوحة). أحيانا تغفل تصميمات نظام تكنولوجيا المعلومات الرغبة في تعديل الأنظمة بحرية. بعض الأنظمة – بما فيها الأنظمة التي تستخدم بنية SOA – تكتب كود ثابت لعمليات ومنتجات وخدمات المؤسسة، وبالتالي تقلل من خفة حركة خدماتها على الإنترنت وتجارتها في السوق العالمي.  تتعلق الخطوة التالية في عملية التصميم بتعريف منصة توصيل الخدمة Service Delivery Platform (SDP) وتطبيقها. في مرحلة تصميم منصة توصيل الخدمة يتم تعريف نماذج المعلومات التجارية وإدارة الهوية والمنتجات والمحتوى، والأجهزة، ومواصفات خدمة العميل ومدى خفة النظام وقدرته بالتالي على التعامل مع تطورات السوق والعملاء.  في عام 2009، في ندوة SOA الدولية الثانية قامت مجموعة مختلطة مكونة من 17 ممارس مستقل وشركة – «مجموعة عمل بيان SOA الرسمي» – بالإعلان عن نشر بيان SOA الرسمي. البيان هو مجموعة من الأهداف والمبادئ الإرشادية التي تهدف لعرض فهم واضح ورؤيا لبنية SOA ومفهوم الخدمية، كان هدف البيان هو إنقاذ مفهوم بنية SOA من استخدام المجتمع التجاري المفرط له و«تزايد المعلومات المغلوطة واللبس بشكل كبير».  يقدم البيان تعريفا واسعا لبنية SOA والفوائد التي سيحصل عليها الموقعون وبعض المبادئ الإرشادية، ويقدم الأولويات التالية: وفي عام 2010 كانت 700 دولة قد وقعت على البيان وتم ترجمته لتسع لغات.  خارطة الطريق إلى بنية SOA تشمل: ستكون الكائنات المختلفة في أحد حالات الاستعداد.       SOA، ويب 2.0، خدمات عبر الماسنجر، وتطبيقات المزج ويب 2.0 – «الجيل الثاني» لنشاط الويب – يقدم ميزة قدرة الزوار على الإسهام بالمعلومات بغرض التعاون والمشاركة كأحد مزاياه الرئيسية. تستخدم تطبيقات ويب 2.0 غالبا خدمات ويب بنية ريست وتعتمد عادة على واجهات أجاكس وتستغل نقابة الويب والمدونات ومستودعات ويكي. بالرغم أنه لا يوجد معايير لويب 2.0 ولكن مواصفاته تشكلت بالبناء على البنية الموجودة لخادم الويب وباستخدام الخدمات. بالتالي يمكن القول أن ويب 2.0 يشتمل على بعض مواصفات بنية SOA.  كما ينظر بعض المتخصصين إلى تطبيقات المزج (تهجين تطبيقات الويب) باعتبارها تطبيقات ويب 2.0. تم تحريف مصطلح «تطبيقات المزج التجارية» ليشير إلى تطبيقات الويب التي تدمج محتوى من أكثر من مصدر في تجربة عميل متكاملة تشترك في العديد من مواصفاتها مع التطبيقات الخدمية التجارية، وهي تطبيقات مكونة من خدمات في صيغة إعلانية. هناك حوار دائر حول «تصادم ويب 2.0 وتطبيقات المزج وبنية SOA» والبعض يقول أن تطبيقات ويب 2.0 هي تحقيق لتطبيقات SOA المركبة والتجارية.  اخترع تيم أوريلي مصطلح «ويب 2.0» لوصف مجموعة ملحوظة سريعة النمو من تطبيقات الويب. أحد المواضيع التي تلقت تغطية مكثفة هو العلاقة بين ويب 2.0 والبنية الخدمية (SOA)، تعتبر بنية SOA فلسفة تغليف منطق التطبيقات بداخل خدمات بواجهة معرفة بشكل موحد واتاحة هذه الخدمات للاستخدام العام من خلال أساليب الاكتشاف. لقد شجعت مفاهيم إخفاء التعقيد وإعادة الاستخدام والارتباط الحر بين الخدمات الباحثين على البحث عن التفاصيل المتشابهة بين الفلسفتين، بنية SOA وويب 2.0 وتطبيقاتهم. البعض يقول أن لكل منهما عناصر مختلفة تماما بالتالي لا يمكن اعتبارهم «فلسفتين متوازيتين»، بينما يرى البعض أن كلا المفهومين متكاملين وير ويب 2.0 كنموذج أشمل من SOA.  تخدم فلسفتي ويب 2.0 وSOA احتياجات مختلفة للمستخدمين بالتالي تبدو الاختلافات في التصميم والتقنيات المستخدمة في التطبيقات الحقيقية، ولكن من عام 2008 بينت حالات الاستخدام إمكانية دمج تقنيات ومبادئ كلا الفلسفتين. في عالم إنترنت الخدمات كل الأشخاص والآلات والمنتجات باستطاعتها استخدام البنية التحتية لشبكة الغد، بالتالي سيقدم الإنترنت خدمات في كل نواحي الحياة والمجالات التجارية مثل التأمين الافتراضي والخدمات البنكية عبر الإنترنت والموسيقى إلخ. ستتطلب هذه الخدمات بنية تحتية معقدة وتشمل منصات توصيل الخدمة التي ستوفق بين العرض والطلب. وحدات بناء إنترنت الخدمات تشمل SOA وويب 2.0 ودلائل تقنية ونماذج تجارية مبتكرة أيضا وأساليب الابتكار المجتمعي المنظم.  برغم أن أوراكل تقول أن جارتنر قد اخترع مصطلخا جديدا، تحليل جارتنر يقول أنهم يسمونه بنية SOA المتقدمة ويشيرون إليها باسم "SOA 2.0. أغلب شركات البرمجيات الوسيطة (مثل ريد هات وويب ميثودز وتيبكو سوفتوير وآي بي إم وصن ميكروسيستمز وأوراكل) كانت لديها شكل من أشكال SOA 2.0 على مدى سنين.  وصفت تطبيقات SOA بأنها تمثل جزء من رؤيا أكبر تعرف باسم الجهاز العصبي الرقمي أو مشروع اللا تأخير.  أحد أساليب تطوير بنية SOA تستغل مبادئ تطوير البرمجيات النحيفة.