सेवाभिमुख आर्किटेक्चर (Service-oriented architecture)
कम्प्यूटिंग में, सेवाभिमुख आर्किटेक्चर (सर्विस ओरिएंटेड आर्किटेक्चर - SOA) की कई भिन्न परिभाषाएं हैं, जिनमें से कुछ सार्वजनिक रूप से चर्चित है। SOA सिद्धांतों के एक समुच्चय या एसी नियंत्रक अवधारणाओं को उपलब्ध कराने का एक प्रयास है जिनका उपयोग सिस्टम के विकास और एकीकरण की प्रवास्थाओं के दौरान किया जाता है।
सर्विस ओरिएंटेशन के लिए ऑपरेटिंग सिस्टम में सेवाओं के "ढीले संयोजन (loose coupling)" की आवश्यकता होती है और अन्य तकनीकों की आवश्यकता होती है जो अनुप्रयोगों के अंतर्गत आती हैं। SOA कार्यों को विभेदित इकाइयों, या सेवाओं में अलग करता है, जिसे विकासकर्ता एक नेटवर्क में उपलब्ध करता है, ताकि उपयोगकर्ता उन्हें अनुप्रयोगों के उत्पादन में संयोजित और पुनः उपयोग कर सके. एक सेवा से दूसरी सेवा को डेटा को पास करके या दो या अधिक सेवाओं के बीच एक गतिविधि के समन्वय के द्वारा ये सेवाएं एक दूसरे के साथ संचार करती हैं।
SOA की परिकल्पना सातत्य के एक प्रकार के रूप में की जा सकती है, जो की वितरित कम्प्यूटिंग या मॉड्यूलर प्रोग्रामिंग के विपरीत है।
SOA का कार्यान्वयन सोफ्टवेयर सेवाओं के जाल पर निर्भर करता है। सेवाओं में क्रियाशीलता की असंबंधित, ढीली युग्मित इकाईयां शामिल हैं जो उनमें एक दूसरे को कॉल एबम्बेडेड नहीं रखती. हर सेवा एक क्रिया को कार्यान्वित करती है, जैसे एक अकाउंट के लिए एक ऑनलाइन आवेदन को भरना, या एक ऑनलाइन बैंक-स्टेटमेंट को देखना, या ऑनलाइन बुकिंग करना या एयरलाइन टिकट का ऑर्डर करना. अपने स्रोत कोड में एक दूसरे के लिए कॉल से युक्त सेवाओं के बजाय वे परिभाषित प्रोटोकॉल का उपयोग करते हैं, जो मेटाडेटा विवरण का उपयोग करते हुए, कैसे सेवाएं संदेशों को पास (प्रवाहित) और पार्स करती हैं यह चित्रित करता है।
SOA विकासकर्ता आर्केस्ट्रेशन (orchestration) का उपयोग करके व्यक्तिगत SOA ओब्जेक्ट्स का सहयोग करते हैं। आर्केस्ट्रेशन (orchestration) की प्रक्रिया में विकासकर्ता सोफ्टवेयर की क्रियाशीलता (सेवाओं) को एक गैर-पदानुक्रमित व्यवस्था में (वर्ग पदानुक्रम के विपरीत) सम्बंधित करता है। इसके लिए वह एक ऐसे सोफ्टवेयर टूल (उपकरण) का उपयोग करता है जिसमें सभी उपलब्ध सेवाओं की एक पूरी सूचि, उनकी विशेषताएं शामिल होती है और साथ ही इन स्रोतों को उपयोग करने के अनुप्रयोग (एप्लिकेशन) के निर्माण के साधन भी शामिल होते हैं।
इन सब को अन्तर्निहित और सक्रिय करने के लिए पर्याप्त विवरण से युक्त मेटाडेटा की आवश्यकता होती है, जो न केवल इन सेवाओं के लाक्षणिक गुणों का वर्णन करता है, बल्कि उन्हें ड्राइव करने वाले डेटा का भी वर्णन करता है। प्रोग्रामर्स ने उस डेटा की सरंचना के लिए SOA में XML का व्यापक उपयोग किया है, जिसे वे लगभग एक विस्तृत वर्णन-कंटेनर में रखते हैं। इसी के अनुरूप, वेब सर्विसिज डिस्क्रिप्शन लेंग्वेज (WSDL) प्रारूपिक रूप से खुद सेवाओं का वर्णन करती है, जबकि SOAP प्रोटोकोल संचरण प्रोटोकोल का वर्णन करता है। क्या ये विवरण भाषाएं (description languages) जॉब के लिए सबसे श्रेष्ठ विकल्प हैं और क्या ये भविष्य में पसंदीदा बनेगीं/बनी रहेंगी, इस पर सार्वजनिक चर्चा बनी हुई हैं। SOA उन डेटा और सेवाओं पर निर्भर करता है जिसका विवरण मेटाडेटा के द्वारा किया जाता है, जिसे निम्न दो मानदंडों पर खरा उतरना चाहिए:लगभग पूरी तरह से मौजूदा सोफ्टवेयर सेवाओं से बनाए जाते "तदर्थ" अनुप्रयोगों (एप्लिकेशन) बनाने के लिए, क्रियाशीलता के काफी बड़े हिस्से को एक साथ शृंखला में रखने के लिए वपराशकर्ताओं को समर्थ बनाना - यह SOA का उद्देश्य है। ये हिस्से जितने बड़े होते हैं, किसी क्रियाशीलता के सेट को कार्यान्वित करने के आवश्यक इंटरफेस बिंदु उतने ही कम होते हैं; हालांकि, क्रियाशीलता के बहुत बड़े हिस्से, आसान पुनरुपयोग के लिए पर्याप्त दानेदार साबित नहीं भी हो सकते. प्रत्येक इंटरफेस अपने साथ प्रोसेसिंग ऑवरहेड का कुछ हिस्सा लाता है, इसलिए सेवाओं की ग्रेन्युलारिटी के चुनाव में प्रदर्शन पर विचार किया जाता है। SOA की विकास संभावनाएं सूचित करती हैं कि n-th अनुप्रयोग (एप्लिकेशन) के निर्माण की सीमांत लागत कम है, क्यों कि आवश्यक सभीं सोफ्टवेयर, अन्य अनुप्रयोगों (एप्लिकेशन) की आवश्यकता को संतुष्ट करने के हेतु, पहले से मौजूद होते हैं। आदर्श रूप में, एक नए अनुप्रयोग के निर्माण के लिए अब केवल ओर्केस्टेशन की आवश्यकता रहती है।
इसे ओपरेट करने के लिए, हिस्सों (chunks) के भीतर या निर्दिष्ट हिस्सों (chunks) के बीच कोई पारस्परिक क्रिया मौजूद नहीं होनी चाहिए. इसके बजाय, मनुष्य सापेक्ष "तदर्थ" तरीके में नव अप्रत्याशित आवश्यकताओं से प्रेरित हो कर, सेवाओं (ये सभी असंबंधित सहयोगी हैं) की अंतःक्रिया को निर्दिष्ट करते हैं। इस प्रकार से पारंपरिक कार्यों या वर्गों की तुलना में क्रियाशीलता की बड़ी इकाईयों के रूप में सेवाओं की जरूरतें ज्यादा होती हैं, नहीं तो ऐसे हजारों ग्रेन्युलर ओब्जेक्ट्स की अत्यधिक जटिलता अनुप्रयोग (एप्लिकेशन) डिजाइनर को बोज़ से परस्त कर देती है। प्रोग्रामर्स जावा, C, C++, C# या COBOL जैसी पारंपरिक भाषाओँ का उपयोग करके खुद सेवाओं का विकास करते हैं।
ढीला संयोजन SOA सेवाओं की एक विशेषता है, यह उन क्रियाओं के विपरीत हैं जिन्हें एक निष्पादन योग्य, गतिक रूप से लिंक लायब्रेरी या एक असेम्बली के निर्माण के लिए, लिंकर एक साथ बांधता हैं। SOA सेवाएं "सुरक्षित" आवरण (जैसे जावा या .NET) और मेमोरी के आवंटन एवं सुधार का प्रबंधन करनेवाली, "तदर्थ" और जुटने में देरी को अनुमति देनेवाली और कुछ अंश तक मध्यस्थ डेटा टाइपिंग उपलब्ध कराती अन्य प्रोग्रामिंग भाषाओं में भी चलती हैं।
2008 में, काफ़ी थर्ड पार्टी सोफ्टवेयर कंपनियां शुल्क के लिए सोफ्टवेयर सेवाएं पेश करने लगीं. भविष्य में, SOA सिस्टम में ऐसी थर्ड पार्टी सेवाएं शामिल होने की संभावना है, जो इन-हाउस निर्मित अन्य सेवाओं के साथ संयोजित होंगी. इसमें कई ग्राहकों और ग्राहक उपयोगों के लिए लागत के प्रसार की क्षमता है और यह उद्योगों के अंदर और उनके बीच, दोनों ही रूप में मानकीकरण को बढ़ावा देता है। विशेष रूप से, अब यात्रा उद्योग में सेवाओं और डेटा दोनों के पूर्ण रूप से परिभाषित और दस्तावेजीकृत समुच्चय उपलब्ध हैं, जो ऑफ़-द-शेल्फ सोफ्टवेयर सेवाओं का उपयोग करते हुए, किसी भी सक्षम सोफ्टवेयर इंजिनियर को ट्रेवल एजेंसी सोफ्टवेयर के निर्माण के लिए पर्याप्त हैं। अन्य उद्योग, जैसे कि वित्त उद्योगने भी इस दिशा में महत्वपूर्ण प्रगति करना शुरू कर दिया है।
एक आर्किटेक्चर के रूप में SOA अपने मूल डिजाइन-तत्त्व के रूप में सर्विस ओरिएंटेशन पर निर्भर करता है। यदि सर्विस एक साधारण इंटरफेस पेश करे जो इसमें अन्तर्निहित जटिलता को अलग रखता हो, तो उपयोगकर्ता सेवा के प्लेटफोर्म कार्यान्वयन के ज्ञान के बिना स्वतंत्र सेवाओं का उपयोग कर सकते हैं।
SOA एसे इंटरफेस के जरिए अपनी कार्यक्षमता को दर्शाने वाली सेवाओं पर निर्भर करता है जो अन्य अनुप्रयोग (एप्लिकेशन) और सेवाएं पढ़ कर इन सेवाओं का उपयोग कैसे किया जाये वह समझ सकती हैं।
कार्यों के प्रतिरूपकता के माध्यम से या वर्ग नामक पूर्वनिर्धारित क्रिया समूहों के उपयोग के द्वारा सोफ्टवेयर पुनरुपयोग को बढ़ावा देने के पूर्व प्रयासों की विशिष्ट प्रथाओं के सापेक्ष, SOA ओब्जेक्ट्स अक्सर 100 से 1000 गुना तक बड़े होते हैं।
एक SOA का कुशल उपयोग करने के लिए, निम्न आवश्यकताओं को पूरा करना आवश्यक है:निम्नलिखित मार्गदर्शक सिद्धांत SOA के विकास, रखरखाव और उपयोग के लिए बुनियादी नियमों को परिभाषित करते हैं।डिजाइन और सेवा की परिभाषा के सन्दर्भ में निम्नलिखित विशिष्ट आर्किटेक्चर सिद्धांत विशिष्ट शैलियों पर केन्द्रित हैं जो एक सिस्टम के आंतरिक व्यवहार को और इसके डिजाइन की शैली को प्रभावित करते हैं:निम्नलिखित सन्दर्भ एक SOA कार्यान्वयन को परिभाषित करने के लिए अतिरिक्त विचार उपलब्ध कराते हैं:
इसके अतिरिक्त, एक SOA कार्यान्वयन को परिभाषित करते समय निम्नलिखित कारकों/परिबलों पर विचार किया जा सकता है।वेब सेवाएं एक सर्विस-ओरिएंटेड आर्किटेक्चर को लागू कर सकती हैं। वेब सेवाएं क्रियाशील निर्माणात्मक-ब्लॉक बनाती हैं, जो प्रोग्रामिंग भाषाओं और प्लेटफोर्म से स्वतंत्र मानक इंटरनेट प्रोटोकोल पर सुलभ होते हैं। ये सेवाएं या तो नए अनुप्रयोगों (एप्लिकेशन) को अभिव्यक्त कर सकती हैं, या केवल मौजूदा सिस्टम के आवरण देती है, जिससे वे नेटवर्क-सक्षम हो जाते हैं।
प्रत्येक SOA निर्माण खंड एक या दोनों भूमिकाओं को निभा सकता है।ईम्लीमेन्टर्स सामान्यतया उन वेब सेवा मानकों (उदाहर्ण के लिए SOAP) का उपयोग करते हुए SOAs का निर्माण करते हैं जिसने उद्योग क्षेत्र में विस्तृत स्वीकृति प्राप्त कर ली है। ये मानक (जिन्हें वेब सेवा विनिर्देश भी कहा जाता है) अधिक अंतःक्रिया भी उपलब्ध करते हैं और मालिकाना विक्रेता सोफ्टवेयर के लिए लोक-इन से कुछ सुरक्षा भी उपलब्ध कराते हैं। हालांकि, जिनी, CORBA या REST जैसी किसी भी सेवा-आधारित तकनीक का उपयोग करते हुए SOA का कार्यान्वयन किया जा सकता है।
आर्किटेक्चर विशिष्ट तकनीकों के स्वतंत्र रूप से ऑपरेट कर सकते हैं। डिजाइनर तकनीकों की व्यापक रेंज का उपयोग करते हुए SOA का कार्यान्वयन कर सकते हैं, इनमें शामिल हैं:कार्यान्वयन इनमें से एक या अधिक प्रोटोकोल्स का उपयोग कर सकते हैं, उदाहरण के लिए, ये SOA अवधारणा के अनुरूप प्रक्रियाओं के बीच निर्धारित इंटरफेस-विनिर्देशन के अनुरूप डेटा के संचार के लिए एक फ़ाइल-प्रणाली तंत्र का उपयोग कर सकते हैं। कुंजी परिभाषित इंटरफेस के साथ की एक स्वतंत्र सेवा है, जिसका उपयोग एक मानक तरीके से उनके कार्यों को करने के लिए किया जा सकता है, सेवा को कोलिंग अनुप्रयोग के बारे में पहले से ज्ञान नहीं होता है और अनुप्रयोग के पास इस बारे में ज्ञान नहीं होता है कि कैसे सेवा वास्तव में अपना कार्य करती है।
SOA के कई कार्यान्वयन शुरू हो चुके हैं जो SOA 2.0 से जाने जाते अधिक विकसित आर्किटेक्चर के SOA अवधारणाओं के विकास को अपनाते हैं।
SOA उन अनुप्रयोगों (एप्लिकेशन) के विकास को सक्षम बनाता है जिन्हें ढीले संयोजन और अंतःक्रिया सेवाओं के संयोजन से बनाया गया है।
ये सेवाएं एक औपचारिक परिभाषा के आधार पर अंतःक्रिया करती हैं (या संकुचन, उदाहरण WSDL) जो अन्तर्निहित प्लेटफोर्म और प्रोग्रामिंग भाषा से स्वतंत्र होती है। इंटरफ़ेस परिभाषा भाषा-विशिष्ट सेवा के कार्यान्वयन को छुपाती है। इसलिए SOA आधारित सिस्टम विकास तकनीकों और प्लेटफोर्म (जैसे जावा, .NET आदि) से स्वतंत्र रूप में कार्य करता है। .NET प्लेटफोर्म पर चलने वाली C# जावा में लिखी गयी सेवाएं और जावा EE प्लेटफोर्म पर चलने वाली सेवाएं, उदाहरण के लिए, दोनों का उपभोग एक सामान्य मिश्रित अनुप्रयोग (या ग्राहक) के द्वारा किया जा सकता है। दोनों में से किसी भी प्लेटफोर्म पर चलने वाले अनुप्रयोग भी अन्य वेब सेवाओं पर चलने वाली सेवाओं का उपभोग कर सकते हैं जो पुनरुपयोग को बढ़ावा देती हैं। प्रबंधित परिवेश भी COBOL लिगेसी सिस्टम को आवरित कर सकता है और उन्हें सोफ्टवेयर सेवाओं के रूप में पेश करता है। इसने कई मुख्य सिस्टम्स के उपयोगी जीवन को अपरिमित रूप से बढ़ा दिया है, चाहे उन्होंने मूल रूप से किसी भी भाषा का प्रयोग किया हो.
जटिल एंटरप्राइज सिस्टम के भीतर SOA एकीकरण और समेकन की गतिविधियों का समर्थन करता है, लेकिन SOA दस्तावेजीकरण क्षमताओं और सेवाओं के लिए कोई विधि या ढांचा उपलब्ध नहीं कराता है।
उच्च स्तर की भाषाएं जैसे BPEL और विनिर्देशन जैसे WS-CDL और WS-समन्वयन सेवा की अवधारणा को विस्तृत करते हैं, इसके लिए वे परिभाषा की विधियां उपलब्ध करते हैं और सूक्ष्म-कणीय सेवाओं के अधिक स्थूल कणीय सेवाओं में ओर्केसट्रेशन का समर्थन करते हैं, जिसे आर्किटेक्ट कार्य प्रवाह में डाल सकता है और व्यापारिक प्रक्रियाएं कम्पोजिट अनुप्रयोगों या पोर्टल में कार्यान्वित की जाती हैं।
शोधकर्ताओं ने SOA के कार्यान्वयन के लिए सेवा अवयव आर्किटेक्चर के उपयोग की जांच शुरू की है।
सर्विस ओरिएंटेड मॉडलिंग SOA प्रेक्टिशनर को उसकी सर्विस ओरिएंटेड संपत्ति की अवधारणा, विश्लेषण, डिजाइन और आर्किटेक्ट के लिए गाइड करनेवाला एक एसा SOA फ्रेमवर्क है जो भिन्न अनुशासनों की पहचान करता है। सर्विस ओरिएंटेड मॉडलिंग फ्रेमवर्क (SOMF) भिन्न अवयवों का वर्णन करने वाले "नक़्शे" या एक कार्य सरंचना को प्रस्तुत करता है, जो एक सफल सर्विस ओरिएंटेड मोडलिंग दृष्टिकोण में योगदान देते हैं। यह उन मुख्य तत्त्वों निरूपित करता है, जो सेवा विकास योजना के "क्या किया जाए" पहलू की पहचान करते हैं। यह मॉडल प्रोजेक्ट योजना की रचना करने के लिए प्रेक्टिशनर को सक्षम बनता है और एक सर्विस ओरिएंटेड पहल के माइलस्टोनो की पहचान करने में मदद करता है। SOMF भी व्यापार और आईटी (IT) संगठनो के बीच संरेखण के लिए एक सामान्य मोडलिंग संकेतन उपलब्ध कराता है।
SOMF को निम्नलिखित सिद्धांतों के पूरा करने के लिए डिजाइन किया गया है:
टिप्पणीकारों ने SOA की कई परिभाषाएं प्रदान की हैं। ओएसिस समूह और ओपन समूह दोनों ने औपचारिक परिभाषाओं का निर्माण किया है।
ओएसिस SOA को निम्न रूप में परिभाषित करता है:
"भिन्न स्वामित्व रखनेवाले डोमेन्स के नियंत्रण में हो एसी वितरित क्षमताओं के उपयोग और संगठन के लिए एक प्रतिमान. " "यह प्रस्ताव रखने, खोज करने और पारस्परिक क्रिया के लिए समरूप साधन उपलब्ध कराता है और मापन योग्य पूर्वस्थितियों और अपेक्षाओं के साथ सुसंगत वांछित प्रभाव उत्पन्न करने के लिए क्षमताओं का उपयोग करता है।"
सेवा अनुबंध के लिए निम्नलिखित अवयवों की आवश्यकता होती है:  नेटवर्क प्रबंधन के क्षेत्र में SOA के सिद्धांतों को लागू किया जा रहा है। सेवाभिमुख नेटवर्क प्रबंधन आर्किटेक्चर के उदाहरणों में शामिल हैं ETSI से TS 188 001 "NGN प्रबंधन OSS आर्किटेक्चर" और ITU-T से सूचित M.3060 "अगली पीढ़ी के नेटवर्क प्रबंधन के सिद्धांत" .
SOA के बुनियादी ढांचे के प्रबंधन के उपकरणों में शामिल हैं:कुछ उद्यम (एन्टरप्राइज़) आर्किटेक्ट्स का मानना है कि बाजार की बदलती हुई परिस्थितियों में SOA व्यापार को जल्दी से और लागत प्रभावी ढंग से प्रतिभाव देने में मदद कर सकता है।  आर्किटेक्चर की यह शैली माइक्रो (छोटे यानी वर्ग) स्तर के बजाय मैक्रो (बड़े यानी सेवा) स्तर पर पुनरुपयोग को बढ़ावा देती है।
कुछ सन्दर्भों में, SOA को एक क्रांति के बजाय आर्किटेक्चर का क्रमिक-विकास माना जा सकता है। यह पूर्व सोफ्टवेयर आर्किटेक्चर की कई सर्वोत्तम प्रथाओं को अपने में बनाए रखता है। उदाहरण के लिए, संचार प्रणालियों में, अन्य उपकरणों के बात करने के लिए सही मायने में स्थिर बाइंडिंग का उपयोग करनेवाले समाधानों के क्षेत्र में बहुत कम विकास हुआ हैं। औपचारिक रूप से एक SOA दृष्टिकोण को अपनाने पर, ऐसे सिस्टम भली प्रकार से परिभाषित, बहुत अधिक अंतःक्रियात्मक इंटरफेस के महत्त्व पर दबाव डालने के लिए अपने आप को तैयार कर सकते हैं।
कुछ लोगों ने यह सवाल उठाया था कि क्या SOA मोड्यूलर प्रोग्रामिंग (1970s), घटना-ओरिएंटेड डिजाइन (1980s) या इंटरफेस/अवयव आधारित डिजाइन (1990s) जैसी अवधारणाओं को मात्र पुनर्जीवित करता है। SOA सेवा के कार्यान्वयन से उपयोगकर्ताओं (ग्राहकों) को अलग करने के उद्देश्य को बढ़ावा देता है। इसलिए सेवाओं को भिन्न वितरित प्लेटफार्मों पर चलाया जा सकता है और ये नेटवर्क पर उपलब्ध हो सकती हैं। इस से सेवाओं का पुनरुपयोग भी अधिकतम हो सकता है।
SOA एक आर्किटेक्चरल और डिजाइन अनुशासन है जिसे अंतःक्रिया क्षमता/इन्टेरोपेरेबिलिटी (जानकारी का विनिमय, पुनरुपयोग की क्षमता और संयोजन क्षमता) को बढ़ाने का, फेडरेशन (व्यक्तिगत स्वायतता और स्व-प्रशासन को बनाये रखते हुए अनुप्रयोगों और स्रोतों का एकीकरण) को बढ़ाने का और व्यापार और तकनीक डोमेन संरेखन को बढाने का लक्ष्य प्राप्त करने के लिए बनाया गया है।
सर्विस ओरिएंटेड आर्किटेक्चर (SOA), जटिल सोफ्टवेयर-प्रधान सिस्टम के निर्माण के लिए एक आर्किटेक्चरल दृष्टिकोण (या शैली) है, जो सार्वत्रिक रूप से एक दुसरे से जुडी हुई और अन्योन्याश्रित बिल्डिंग ब्लॉक्स के समूह यानि सेवाओं से बनता हैं।
सेवाओं के निर्माण के समय विश्लेषण और डिजाइन विधि के उपयोग के माध्यम से SOA अपने व्यापार और आईटी (आईटी) लाभ वसूल करता है। यह विधि सुनिश्चित करती है कि सेवाएं आर्किटेक्चरल दृष्टि और योजना के साथ सुसंगत रहें और वें सेवाभिमुख के सिद्धांतों का पालन करती रहें. SOA से व्यापार और प्रबंधन पहलूओं का समर्थन करने वाले तर्क कई प्रकाशनों में दिए गए हैं।
सिर्फ औपचारिक रूप से परिभाषित इंटरफेस के माध्यम से ही सेवा को क्रियाशीलता की एकमेव (स्टैंड-अलोन) इकाई उपलब्ध होती है। सेवाएं एक तरह की "नैनो उद्यमों (नैनो-एन्टरप्राइज्स)" हो सकती हैं जिनका निर्माण और सुधार आसान होता है। और सेवाएं "बड़े निगम" भी हो सकती हैं, जो गौण सेवाओं के समन्वित कार्य के रूप बनाई जाती है।
सेवाएं आमतौर पर सर्विस ओरिएंटेशन के निम्न सिद्धांतों का पालन करती हैं:SOA का परिपक्व रोलआउट प्रभावी रूप से संगठन के API को परिभाषित करता है।
सेवाओं के कार्यान्वयन को बड़ी परियोजनाओं से अलग परियोजनाओं के रूप में देखने के कारणों में शामिल हैं:SOA से होते अप्रत्यक्ष लाभ में शामिल है नाटकीय रूप से सरलीकृत परीक्षण. सेवाएं स्वायत्त, अवस्थाहीन हैं, पूरी तरह से दस्तावेजित इंटरफेस से युक्त हैं और कार्यान्वयन के क्रोस कटिंग चिंताओं से अलग हैं। उद्योग पहले कभी भी ऐसी परिस्थितियों से नहीं गुजरा है।
यदि संगठन में उपयुक्त परिभाषित परीक्षण डेटा हैं, तो जब एक सेवा का निर्माण किया जा रहा है, तब एक सम्बंधित स्टब का निर्माण किया जाता है, जो परीक्षण डेटा को प्रतिक्रया करता है। प्रतिगमन परीक्षण, लिपियों, डेटा और प्रतिभाव के एक पूरे सेट को भी सेवा के लिए काम में लिया जाता है। जो सेवाओं को मांगा गया है उसके तद्विषयक उपस्थित स्टब का उपयोग करते हुए एक 'ब्लैक बॉक्स' के रूप में भी परीक्षण किया जाता सकता है। जहां आद्य और दायरे से बाहर की सेवाएं स्टब हैं, जबकि जाल का शेष भाग पूरी सेवा के परीक्षण नियोजक है, एसे परीक्षण वातावरण का निर्माण किया जाता है। चूंकि प्रत्येक इंटरफेस पूरी तरह से दस्तावेजों से युक्त होता है, जो प्रतिगमन टेस्ट दस्तावेजीकरण का पूरा सेट होता है, इसलिए परीक्षण सेवाओं में समस्याओं की पहचान सरल बन जाती है। परीक्षण सेवा अपने दस्तावेजीकरण के अनुसार काम करती है एसा मान्य करने के लिए और वातावरण में मौजूदा सभी सेवाओं के परीक्षण मामले और दस्तावेजीकरण के बीच रिक्त स्थान ढूंढने के लिए ही परीक्षण विकसित किया जाता है। Idempotent सेवाओं की डेटा अवस्था का प्रबंधन एकमात्र जटिलता है।
सेवा के दस्तावेजीकरण में जहां वह उपयोगी हो उस स्तर पर उदाहरण सहायरूप सिद्ध होते है। जावा समुदाय प्रक्रिया में कुछ APIs के दस्तावेजीकरण अच्छे उदाहरण उपलब्ध कराते हैं। क्योंकि ये विस्तृत होते हैं, स्टाफ प्रारूपिक रूप से केवल महत्वपूर्ण उप-सेट का उपयोग करेंगे. JSR-89 के भीतर 'ossjsa.pdf' ऐसी फ़ाइल की एक मिसाल है।
एक स्पष्ट और आम चुनौती सामने आई, वह है, सेवा मेटाडेटा का प्रबंधन. SOA आधारित वातावरण में कई सेवाएं शामिल हो सकती हैं जो कार्य करने के लिए संदेशों का विनिमय करती हैं। डिजाइन के अनुसार, एकमात्र अनुप्रयोग कई मिलियन संदेशों को उत्पन्न कर सकता है। सेवाएं कैसे अंतर्क्रिया करती हैं, इस पर जानकारी उपलब्ध कराना और इसका प्रबंधन जटिल हो सकता है।
एक दूसरी चुनौती है, SOA स्थान में परीक्षण की कमी . ऐसे कोई अत्याधुनिक उपकरण नहीं हैं जो एक विशिष्ट आर्किटेक्चर में सभी नेतृत्वहीन सेवाओं (जिसमें वेब सेवाओं के साथ डेटाबेस सेवाएं और सन्देश शामिल हैं) की परीक्षण क्षमता उपलब्ध करायें. समस्तरीय विश्वास की कमी के कारण यह जरुरी है कि निर्माता और उपभोक्ता दोनों सेवाओं का निरंतर परीक्षण करते रहें. SOA का मुख्य उद्देश्य "व्यापार को चुस्ती/तेज़ी" प्रदान करना है। इसलिए एक परीक्षण ढांचे (निर्माण या खरीद) में निवेश करना महत्वपूर्ण है, जो आर्किटेक्चर में अपराधी को खोजने के लिए पारदर्शिता उपलब्ध कराएगा. व्यवसाय में तेजी के लिए आवश्यक है कि SOA सेवाओं को व्यापार प्रेरणा मॉडल (बिजनेस मोटिवेशन मॉडल - BMM) में दी गयी परिभाषा के अनुसार व्यापारिक उद्देश्यों और निर्देशों के द्वारा नियंत्रित किया जा सके.
अन्य एक और चुनौती सुरक्षा के उपयुक्त स्तर उपलब्ध कराने से सम्बंधित है। जब एक अनुप्रयोग जिसका उपयोग अन्य अनुप्रयोग भी कर सकते है एसी सेवाओं के रूप में अपनी क्षमताएं उजागर करती है तब अनुप्रयोग के भीतर में समाविष्ट सुरक्षा मॉडल पर्याप्त नहीं रहते. अर्थात, अनुप्रयोग-प्रबंधित सुरक्षा, सेवाओं की सुरक्षा के लिए सही मॉडल नहीं है। कई नई प्रौद्योगिकियों और मानकों ने SOA में सुरक्षा के लिए अधिक उपयुक्त मॉडल उपलब्ध कराने शुरू किए हैं। अधिक जानकारी के लिए देखें SOA सुरक्षा प्रविष्टि.
चूंकि SOA और WS-*विनिर्देशन प्रेक्टिशनर अपने आउट पुट को विस्तृत, अद्यतन और परिष्कृत करते हैं, उन्हें SOA आधारित सिस्टम पर काम करने के लिए कुशल लोगों की कमी की समस्या का सामना करना पड़ता है, इसमें सेवा ढांचे का निर्माण और सेवाओं का एकीकरण भी शामिल है।
अंतःचालन SOA कार्यान्वयन का एक महत्वपूर्ण पहलू होता है। WS-I संगठन ने संगतता को बल देने के लिए बेसिक प्रोफाइल (BP) और बेसिक सिक्योरिटी प्रोफाइल (BSP) का विकास किया है. वेब सेवाएं WS-I प्रोफाइल दिशानिर्देशों के मुताबिक हैं या नहीं ये तय करने के लिए WS-I ने परीक्षण उपकरण डिजाइन किये हैं। इसके अतिरिक्त, विश्वसनीय सुरक्षा प्रोफाइल पर काम करने के लिए एक और चार्टर की स्थापना की गयी है।
महत्वपूर्ण विक्रेता प्रचार SOA को घेरे हुए हैं; इससे ऐसी उम्मीदें बनती हैं, जिन्हें शायद पूरा नहीं भी किया जा सके. प्रारंभिक एडोप्टरों ने वास्तविक दुनिया की समस्याओं के सन्दर्भ में विकास और रनटाइम उत्पादों पर परीक्षण जारी रखे और इस कारण उत्पाद के ढेर बनते रहे. सोया आईटी (आईटी) लागत में कमी की कोई गारंटी नहीं देता है, ना ही बाजार में तेजी लाने की या प्रणालीयों में चुस्ती लाने की कोई गारंटी देता है। सफल SOA कार्यान्वयन ये सभी या इनमें से कुछ लाभ हो सकते हैं, यह सिस्टम आर्किटेक्चर और डिजाइन की गुणवत्ता और संबद्धता पर निर्भर करता है.
आंतरिक आईटी (IT) डिलीवरी संगठन नियमित SOA प्रयासों का आरंभ करते हैं और इनमें से कुछ व्यापार में अवधारणाओं को अनुपयुक्त तरीके से पेश करते हैं, जिससे उसके बारे में गलतफ़हमी बनी रहती है. इसे अपनाने से व्यापार के बजाय आईटी (IT) डिलीवरी की जरूरतें पूरी होने लगी, जिसके परिणामस्वरूप बाजार के अवसरों के लिए तुरंत प्रतिक्रिया देने वाले संगठन के बजाय सुपरलेटिव लैपटॉप प्रोविजनिंग सेवाओं से युक्त संगठन सामने आता है। यह संगठन SOA का कार्यान्वयन ठीक प्रकार से कर रहा है इस बारे में व्यापार नेतृत्व भी सहमत हो गया था।
SOA का सबसे महत्वपूर्ण लाभ यह है कि इसे आसानी से पुनःउपयोग में लिया जा सकता है। इसलिए अंततः हिसाबी जवाबदेहिता और वित्त मॉडलों का विकास संगठन में ही होना चाहिए. एक व्यवसाय इकाई को ऐसी सेवाओं के निर्माण के लिए प्रोत्साहित किया जाना चाहिए, जिसका उपयोग अन्य इकाइयां कर सकें. इसके विपरीत, इकाइयों को सेवाओं के पुनःप्रयोग के लिए प्रोत्साहित किया जाना चाहिए. इसके लिए प्रशासन के कुछ नए घटकों की आवश्यकता रहती हैःSOA की कुछ आलोचनाएं वेब सेवाओं के साथ SOA के संकलन पर निर्भर हैं। उदाहरण के लिए, कुछ आलोचकों का दावा है कि SOA का परिणाम XML की परतों की बढोतरी के रूप में होता है, जो XML पार्सिंग और संरचना को बताता है। दूरस्थ प्रक्रिया कॉल (रिमोट प्रोसिजर कॉल - RPC) के मूल या द्विआधारी रूपों के अभाव में, अनुप्रयोग की गति धीमी पड सकती हैं और उन्हें अधिक प्रोसेसिंग क्षमता की जरुरत पडती है, जो लागत में बढोतरी का कारण बनता है। अधिकांश कार्यान्वयनों में ये ओवरहेड शामिल हैं, लेकिन SOA को दूरस्थ प्रक्रिया कॉल्स या XML के माध्यम से अनुवाद पर निर्भर नहीं हो एसी प्रौद्योगिकियों (उदाहरण के लिए, जावा बिजनेस एकीकरण, (JBI)) का उपयोग करते हुए भी कार्यान्वित किया जा सकता है। उभरती हुई खुले स्रोत XML पार्सिंग प्रौद्योगिकियों (जैसे VTD-XML) और भिन्न XML-संगत द्विआधारी स्वरूपों से उत्पन्न होता है जो SOA के अच्छे प्रदर्शन के लिए वादा करते हैं।
अवस्थापूर्ण सेवाओं को समान उपभोक्ता-विशिष्ट सन्दर्भ को साझा करने के लिए उपभोक्ता और प्रदाता दोनों की आवश्यकता होती है, जो या तो इसमें शामिल होते हैं या उपभोक्ता और प्रदाता के बीच सन्देश विनिमय के द्वारा सन्दर्भित होते हैं। इस बाधा की कमी यह है कि यदि सेवा प्रदाता को प्रत्येक उपभोक्ता के लिए साझा सन्दर्भ को बनाये रखने की आवश्यकता हो, तो इससे सेवा प्रदाता की समग्र मापन क्षमता कम हो सकती है। यह सेवा प्रदाता और उपभोक्ता के बीच संयोजन को बढ़ाता है और सेवा प्रदाताओं बदलना अधिक मुश्किल बनाता है. अंततः, कुछ आलोचकों का मानना है कि SOA सेवाएं अभी भी उनके द्वारा अभिव्यक्त किये जाने वाले अनुप्रयोगों के द्वारा अत्यंत बाधित हैं.
एक और मुद्दा WS-* मानकों और उत्पादों (उदाहरण लेनदेन, सुरक्षा) के क्रमिक विकास से सम्बंधित है और जब तक SOA को अतिरिक्त बजट और अतिरिक्त सबूत-की-अवधारणा के लिए आकस्मिक कार्य के साथ पूर्ण रूप से प्रबंधित और अनुमानित न किया जाये, तब तक SOA इस प्रकार से नए जोखिमों को शामिल करता है।
कुछ आलोचक SOA को महज पहले से अच्छी तरह बने हुए आर्किटेक्चरों (खुला इंटरफेस, आदि) का स्वाभाविक विकास मानते हैं।
आई़़टी सिस्टम डिजाइन कभी कभी रूपांतरित सिस्टम की वांछनीयता को अनदेखा करते हैं। SOA आधारित सिस्टम, हार्ड कोड ऑपरेशन्स, संगठन की मालसमान और सेवाएं के साथ कई सिस्टम, इस प्रकार से अपनी ऑनलाइन सेवाएं और वैश्विक बाजार में व्यापारी चपलता को बाधित करते हैं।
डिजाइन प्रक्रिया में अगला कदम सेवा वितरण मंच (सर्विस डिलिवरी प्लेटफोर्म - SDP) और उसके कार्यान्वयन की परिभाषा को समाविष्ट करता हैं। SDP डिजाइन चरण में व्यावसायिक जानकारी मॉडल, पहचान प्रबंधन, उत्पादों, सामग्री, उपकरण और अंतिम उपयोगकर्ता सेवा विशेषताओं को और साथ ही क्या सिस्टम इतनी चपल है कि व्यापार और उसके ग्राहकों के क्रमिक विकास के साथ ताल रख पाए - इन मुद्दों को परिभाषित किया जाता है।
वेब 2.0, जो वेब गतिविधि की कथित "दूसरी पीढ़ी" है, इसमें प्राथमिक रूप से सहयोग और साझे के लिए दर्शकों को प्रदान की गई हुई जानकारी रखने की क्षमता एक विशेषता है। वेब 2.0 अनुप्रयोग अक्सर REST-ful वेब सेवाओं का प्रयोग करते हैं और सामान्य रूप से इसमें AJAX आधारित उपयोगकर्ता इंटरफेस होता है, जो वेब सिंडिकेशन, ब्लोग्स और विकीस का उपयोग करते हैं। जहां एक ओर वेब 2.0 के लिए कोई निर्धारित मानक नहीं हैं, यह मौजूदा वेब सर्वर आर्किटेक्चर और सेवाओं के उपयोग द्वारा निर्माण की विशेषता रखती है। इसलिए वेब 2.0 भी कुछ SOA विशेषताओं को प्रदर्शित करता है एसा कहा जा सकता है।
कुछ टिप्पणीकार मेशप (mashups) को वेब 2.0 अनुप्रयोग मानते हैं। "बिजनेस मेशप" शब्दप्रयोग को एसे वेब अनुप्रयोगों के वर्णन के लिए बनाया गया था, जो एक से अधिक स्रोतों से सामग्री को संयोजित करके, सर्विस ओरिएंटेड बिजनेस अनुप्रयोगों (SOBAs) के कई लक्षण रखनेवाले, एकीकृत उपयोगकर्ता अनुभव देते हैं। SOBAs एक कथात्मक तरीके से सेवाओं से बने अनुप्रयोग हैं। "वेब 2.0, मेशप और SOA के संघर्ष" के बारे में विवाद जारी है, जहां कुछ लोगों का कहना है कि वेब 2.0 अनुप्रयोग, SOA मिश्रण और बिजनेस अनुप्रयोगों का एक साकार रूप हैं।
वेब आधारित अनुप्रयोगों के कथित, शीघ्र विकसित होने वाले एक सेट का वर्णन करने के लिए टिम ओ'रेइल्ली ने "वेब 2.0" शब्दप्रयोग दिया.
वेब 2.0 और SOA के दर्शन उपयोगकर्ता की भिन्न आवश्यकताओं को सेवा प्रदान करते हैं और इस प्रकार से वास्तविक दुनिया के अनुप्रयोगों में प्रयुक्त तकनीकों और डिजाइन के सन्दर्भ में अंतर को स्पष्ट करते हैं। हालांकि, उपयोग-मामलों ने वेब 2.0 और SOA, दोनों के सिद्धांत और तकनीकों को संयोजित करने की संभावना का प्रदर्शित की है।
एक "सेवाओं के इंटरनेट" में, सभी लोग, मशीनें और सामान, कल के (भविष्य के) नेटवर्क ढांचे के माध्यम से पहुंच पाएंगे. इस प्रकार से इंटरनेट जीवन और व्यापार के सभी क्षेत्रों के लिए सेवाएं पेश करेगा, जैसे आभासी बीमा, ऑनलाइन बैंकिंग और संगीत और बहुत कुछ. इन सेवाओं को एक जटिल सेवा ढांचे की आवश्यकता रहेगी, जिसमें मांग और आपूर्ति को एक साथ लानेवाले सेवा वितरण मंच भी शामिल है। सेवाओं के इंटरनेट की निर्माणात्मक इकाइयों में शामिल हैं SOA, वेब 2.0 और प्रौद्योगिकी की ओर का अर्थविज्ञान; साथ ही नवीन व्यापारिक मॉडल और प्रणालीबद्ध एवं समुदाय आधारित नवाचार के प्रति दृष्टिकोण भी शामिल है।
हालांकि ओरेकल इंगित करता है कि गार्टनर एक नया शब्द दे रहे हैं, गार्टनर विश्लेषकों ने संकेत दिया है कि वे इसे विकसित SOA कहते है और इसे "SOA 2.0" नाम दिया जाएगा.  अधिकांश प्रमुख मध्यम विक्रेता (जैसे रेड हेट (Red Hat), वेबमेथड्स (webMethods), TIBCO सोफ्टवेयर, IBM, सन माइक्रोसिस्टम और ओरेकल) के पास वर्षों से SOA 2.0 गुणधर्मों के कुछ रूप रहे हैं।
SOA कार्यान्वयन को डिजिटल तंत्रिका तंत्र या जीरो लेटेंसी एन्टरप्राइज़ के रूप में ज्ञात विशाल दृष्टिकोण के प्रतिनिधित्व के रूप में वर्णित किया गया है।