एक सर्विस-ओरिएंटेड आर्किटेक्चर (SOA) कंप्यूटर सॉफ्टवेयर डिजाइन में एक आर्किटेक्चरल पैटर्न है जिसमें एप्लिकेशन कंपोनेंट्स संचार प्रोटोकॉल के माध्यम से अन्य घटकों को सेवाएं प्रदान करते हैं, आमतौर पर एक नेटवर्क पर। सेवा-उन्मुखता के सिद्धांत किसी भी उत्पाद, विक्रेता या प्रौद्योगिकी से स्वतंत्र हैं।
SOA सिर्फ एक दूसरे के साथ काम करने के लिए विभिन्न नेटवर्क पर सॉफ्टवेयर घटकों के लिए आसान बनाता है।
वेब सेवाएँ जो SOA आर्किटेक्चर के अनुसार बनाई जाती हैं, वे वेब सेवा को और अधिक स्वतंत्र बनाती हैं। स्वयं वेब सेवाएँ एक-दूसरे के साथ डेटा का आदान-प्रदान कर सकती हैं और अंतर्निहित सिद्धांतों के कारण, जिस पर वे बनाए गए हैं, उन्हें किसी भी प्रकार के मानव इंटरैक्शन की आवश्यकता नहीं है और किसी भी कोड संशोधनों की आवश्यकता नहीं है। यह सुनिश्चित करता है कि एक नेटवर्क पर वेब सेवाएं एक-दूसरे के साथ सहजता से बातचीत कर सकती हैं।
SOA कुछ प्रमुख सिद्धांतों पर आधारित है जिनका उल्लेख नीचे किया गया है
- मानकीकृत सेवा अनुबंध - सेवाएं एक सेवा विवरण का पालन करती हैं। एक सेवा में किसी प्रकार का विवरण होना चाहिए जो बताता है कि सेवा किस बारे में है। इससे क्लाइंट एप्लिकेशन के लिए यह समझना आसान हो जाता है कि सेवा क्या करती है।
- ढीली युग्मन - एक दूसरे पर कम निर्भरता। यह वेब सेवाओं की मुख्य विशेषताओं में से एक है जो बस बताती है कि वेब सेवाओं और वेब सेवा को लागू करने वाले क्लाइंट के बीच यथासंभव कम निर्भरता होनी चाहिए। इसलिए यदि सेवा की कार्यक्षमता किसी भी समय बदल जाती है, तो इसे क्लाइंट एप्लिकेशन को तोड़ना नहीं चाहिए या इसे काम करने से रोकना चाहिए।
- सेवा अमूर्तता - सेवा वे तर्क छिपाते हैं जो वे बाहरी दुनिया से अलग करते हैं। सेवा को यह उजागर नहीं करना चाहिए कि वह अपनी कार्यक्षमता को कैसे निष्पादित करता है; यह बस ग्राहक को यह बताता है कि यह क्या करता है और यह कैसे करता है पर नहीं।
- सेवा पुन: प्रयोज्य - तर्क का उपयोग अधिकतम पुन: उपयोग के इरादे से सेवाओं में विभाजित किया गया है। किसी भी विकास कंपनी में पुन: प्रयोज्य एक बड़ा विषय है, क्योंकि जाहिर है कि व्यक्ति एक ही कोड को बार-बार बनाने के लिए समय और प्रयास खर्च नहीं करना चाहेगा, जिसके लिए उन्हें कई अनुप्रयोगों की आवश्यकता होती है। इसलिए, एक बार जब किसी वेब सेवा के लिए कोड लिखा जाता है तो उसमें विभिन्न एप्लिकेशन प्रकारों के साथ क्षमता कार्य होना चाहिए।
- सेवा स्वायत्तता - सेवाओं का उन तर्क पर नियंत्रण होना चाहिए जो वे एनकैप्सुलेट करते हैं। सेवा सब कुछ जानती है कि यह किस प्रकार की कार्यक्षमता प्रदान करता है और इसलिए इसमें शामिल कोड पर भी पूर्ण नियंत्रण होना चाहिए।
- सेवा स्टेटलेसनेस - आदर्श रूप से, सेवाओं को स्टेटलेस होना चाहिए। इसका मतलब यह है कि सेवाओं को एक राज्य से दूसरे राज्य में सूचना को रोकना नहीं चाहिए। यह क्लाइंट एप्लिकेशन से किया जाना चाहिए। एक उदाहरण एक शॉपिंग साइट पर रखा गया ऑर्डर हो सकता है। अब आपके पास एक वेब सेवा हो सकती है जो आपको किसी विशेष वस्तु की कीमत देती है। लेकिन अगर आइटम किसी शॉपिंग कार्ट में जोड़े जाते हैं और वेब पेज उस पेज पर पहुंच जाता है जहां आप भुगतान करते हैं, तो आइटम की कीमत का भुगतान भुगतान पेज पर स्थानांतरित करने की जिम्मेदारी वेब सेवा द्वारा नहीं की जानी चाहिए। इसके बजाय, यह वेब एप्लिकेशन द्वारा किया जाना चाहिए।
- सेवा खोज क्षमता - सेवाएं खोजी जा सकती हैं (आमतौर पर सेवा रजिस्ट्री में)। हमने इसे पहले ही UDDI की अवधारणा में देखा है, जो एक रजिस्ट्री करता है जो वेब सेवा के बारे में जानकारी रख सकता है।
- सेवा संगतता - सेवाएं छोटी समस्याओं में बड़ी समस्याओं को तोड़ती हैं। किसी अनुप्रयोग की सभी कार्यक्षमता को कभी भी एक ही सेवा में एम्बेड नहीं करना चाहिए, बल्कि इसके बजाय, प्रत्येक सेवा को अलग व्यावसायिक कार्यक्षमता के साथ मॉड्यूल में तोड़ दें।
- सेवा इंटरऑपरेबिलिटी - सेवाओं को मानकों का उपयोग करना चाहिए जो विभिन्न ग्राहकों को सेवा का उपयोग करने की अनुमति देते हैं। वेब सेवाओं में, XML के रूप में मानकों और HTTP पर संचार यह सुनिश्चित करने के लिए उपयोग किया जाता है कि यह इस सिद्धांत के अनुरूप है।