विकिपीडिया

सेवाभिमुख आर्किटेक्चर (Service-oriented architecture)

कम्प्यूटिंग में, सेवाभिमुख आर्किटेक्चर (सर्विस ओरिएंटेड आर्किटेक्चर - SOA) की कई भिन्न परिभाषाएं हैं, जिनमें से कुछ सार्वजनिक रूप से चर्चित है। SOA सिद्धांतों के एक समुच्चय या ऐसी नियंत्रक अवधारणाओं को उपलब्ध कराने का एक प्रयास है जिनका उपयोग सिस्टम के विकास और एकीकरण की प्रवास्थाओं के दौरान किया जाता है।

सेवाभिमुख आर्किटेक्चर में परत अंतःक्रिया
ऐसा आर्किटेक्चर उन भिन्न व्यापार डोमेन के सन्दर्भ में इन्टरोपेरेबल सेवाओं (interoperable services) के रूप में पैकेज क्रियाशीलता के लिए प्रयास करता हैं, जो इसका प्रयोग करते हैं। एक कंपनी के कईं विभाग या विभिन्न संगठन एकीकृत हो सकते हैं या ऐसी सेवाओं का प्रयोग कर सकते हैं-चाहे उनके निजी ग्राहक सिस्टम काफी अलग हों - फिर भी सोफ्टवेयर मोड्यूल एक सेवा के रूप में उपलब्ध हो सकते हैं। SOA सोफ्टवेयर मोड्यूल एकीकरण के अन्य प्रकारों को विकसित करने के का एक प्रयास है। एक API को परिभाषित करने के बजाय, SOA इंटरफेस को प्रोटोकोल और क्रियाशीलता के सन्दर्भ में परिभाषित करता है। 
एक अंतिम बिंदु (endpoint) ऐसे एक SOA क्रियान्वयन के लिए एक प्रवेश बिंदु है।

सर्विस ओरिएंटेशन के लिए ऑपरेटिंग सिस्टम में सेवाओं के ढीले संयोजन (loose coupling) की आवश्यकता होती है और अन्य तकनीकों की आवश्यकता होती है जो अनुप्रयोगों के अंतर्गत आती हैं। SOA कार्यों को विभेदित इकाइयों, या सेवाओं में अलग करता है[1], जिसे विकासकर्ता एक नेटवर्क में उपलब्ध करता है, ताकि उपयोगकर्ता उन्हें अनुप्रयोगों के उत्पादन में संयोजित और पुनः उपयोग कर सके. एक सेवा से दूसरी सेवा को डेटा को पास करके या दो या अधिक सेवाओं के बीच एक गतिविधि के समन्वय के द्वारा ये सेवाएं एक दूसरे के साथ संचार करती हैं।

SOA की परिकल्पना सातत्य के एक प्रकार के रूप में की जा सकती है, जो की वितरित कम्प्यूटिंग या मॉड्यूलर प्रोग्रामिंग के विपरीत है।

विवरण

संपादित करें

परिचय

संपादित करें

SOA का कार्यान्वयन सोफ्टवेयर सेवाओं के जाल पर निर्भर करता है। सेवाओं में क्रियाशीलता की असंबंधित, ढीली युग्मित इकाईयां शामिल हैं जो उनमें एक दूसरे को कॉल एबम्बेडेड नहीं रखती. हर सेवा एक क्रिया को कार्यान्वित करती है, जैसे एक अकाउंट के लिए एक ऑनलाइन आवेदन को भरना, या एक ऑनलाइन बैंक-स्टेटमेंट को देखना, या ऑनलाइन बुकिंग करना या एयरलाइन टिकट का ऑर्डर करना. अपने स्रोत कोड में एक दूसरे के लिए कॉल से युक्त सेवाओं के बजाय वे परिभाषित प्रोटोकॉल का उपयोग करते हैं, जो मेटाडेटा विवरण का उपयोग करते हुए, कैसे सेवाएं संदेशों को पास (प्रवाहित) और पार्स करती हैं यह चित्रित करता है।

SOA विकासकर्ता आर्केस्ट्रेशन (orchestration) का उपयोग करके व्यक्तिगत SOA ओब्जेक्ट्स का सहयोग करते हैं। आर्केस्ट्रेशन (orchestration) की प्रक्रिया में विकासकर्ता सोफ्टवेयर की क्रियाशीलता (सेवाओं) को एक गैर-पदानुक्रमित व्यवस्था में (वर्ग पदानुक्रम के विपरीत) सम्बंधित करता है। इसके लिए वह एक ऐसे सोफ्टवेयर टूल (उपकरण) का उपयोग करता है जिसमें सभी उपलब्ध सेवाओं की एक पूरी सूचि, उनकी विशेषताएं शामिल होती है और साथ ही इन स्रोतों को उपयोग करने के अनुप्रयोग (एप्लिकेशन) के निर्माण के साधन भी शामिल होते हैं।

इन सब को अन्तर्निहित और सक्रिय करने के लिए पर्याप्त विवरण से युक्त मेटाडेटा की आवश्यकता होती है, जो न केवल इन सेवाओं के लाक्षणिक गुणों का वर्णन करता है, बल्कि उन्हें ड्राइव करने वाले डेटा का भी वर्णन करता है। प्रोग्रामर्स ने उस डेटा की सरंचना के लिए SOA में XML का व्यापक उपयोग किया है, जिसे वे लगभग एक विस्तृत वर्णन-कंटेनर में रखते हैं। इसी के अनुरूप, वेब सर्विसिज डिस्क्रिप्शन लेंग्वेज (WSDL) प्रारूपिक रूप से खुद सेवाओं का वर्णन करती है, जबकि SOAP प्रोटोकोल संचरण प्रोटोकोल का वर्णन करता है। क्या ये विवरण भाषाएं (description languages) जॉब के लिए सबसे श्रेष्ठ विकल्प हैं और क्या ये भविष्य में पसंदीदा बनेगीं/बनी रहेंगी, इस पर सार्वजनिक चर्चा बनी हुई हैं। 2008 के अनुसार  SOA उन डेटा और सेवाओं पर निर्भर करता है जिसका विवरण मेटाडेटा के द्वारा किया जाता है, जिसे निम्न दो मानदंडों पर खरा उतरना चाहिए:

  1. मेटाडेटा को ऐसे रूप में होना चाहिए जिससे सोफ्टवेयर सिस्टम उसका उपयोग परिभाषित सेवाओं की खोज और संयोजन द्वारा गतिशीलता से कॉन्फ़िगर[तथ्य वांछित] करने के लिए कर सके और जो एकजुटता और अखंडता भी बनाए रखे.
  2. मेटाडेटा को ऐसे रूप में होना चाहिए जो सिस्टम डिजाइनर समझ सकें और लागत एवं प्रयास के उचित व्यय के साथ उसका प्रबंधन कर सकें.

लगभग पूरी तरह से मौजूदा सोफ्टवेयर सेवाओं से बनाए जाते तदर्थ अनुप्रयोगों (एप्लिकेशन) बनाने के लिए, क्रियाशीलता के काफी बड़े हिस्से को एक साथ शृंखला में रखने के लिए वपराशकर्ताओं को समर्थ बनाना - यह SOA का उद्देश्य है। ये हिस्से जितने बड़े होते हैं, किसी क्रियाशीलता के सेट को कार्यान्वित करने के आवश्यक इंटरफेस बिंदु उतने ही कम होते हैं; हालांकि, क्रियाशीलता के बहुत बड़े हिस्से, आसान पुनरुपयोग के लिए पर्याप्त दानेदार साबित नहीं भी हो सकते. प्रत्येक इंटरफेस अपने साथ प्रोसेसिंग ऑवरहेड का कुछ हिस्सा लाता है, इसलिए सेवाओं की ग्रेन्युलारिटी के चुनाव में प्रदर्शन पर विचार किया जाता है। SOA की विकास संभावनाएं सूचित करती हैं कि n-th अनुप्रयोग (एप्लिकेशन) के निर्माण की सीमांत लागत कम है, क्यों कि आवश्यक सभीं सोफ्टवेयर, अन्य अनुप्रयोगों (एप्लिकेशन) की आवश्यकता को संतुष्ट करने के हेतु, पहले से मौजूद होते हैं। आदर्श रूप में, एक नए अनुप्रयोग के निर्माण के लिए अब केवल ओर्केस्टेशन की आवश्यकता रहती है।

इसे ओपरेट करने के लिए, हिस्सों (chunks) के भीतर या निर्दिष्ट हिस्सों (chunks) के बीच कोई पारस्परिक क्रिया मौजूद नहीं होनी चाहिए. इसके बजाय, मनुष्य सापेक्ष तदर्थ तरीके में नव अप्रत्याशित आवश्यकताओं से प्रेरित हो कर, सेवाओं (ये सभी असंबंधित सहयोगी हैं) की अंतःक्रिया को निर्दिष्ट करते हैं। इस प्रकार से पारंपरिक कार्यों या वर्गों की तुलना में क्रियाशीलता की बड़ी इकाईयों के रूप में सेवाओं की जरूरतें ज्यादा होती हैं, नहीं तो ऐसे हजारों ग्रेन्युलर ओब्जेक्ट्स की अत्यधिक जटिलता अनुप्रयोग (एप्लिकेशन) डिजाइनर को बोज़ से परस्त कर देती है। प्रोग्रामर्स जावा, C, C++, C# या COBOL जैसी पारंपरिक भाषाओँ का उपयोग करके खुद सेवाओं का विकास करते हैं।

ढीला संयोजन SOA सेवाओं की एक विशेषता है, यह उन क्रियाओं के विपरीत हैं जिन्हें एक निष्पादन योग्य, गतिक रूप से लिंक लायब्रेरी या एक असेम्बली के निर्माण के लिए, लिंकर एक साथ बांधता हैं। SOA सेवाएं "सुरक्षित" आवरण (जैसे जावा या .NET) और मेमोरी के आवंटन एवं सुधार का प्रबंधन करनेवाली, तदर्थ और जुटने में देरी को अनुमति देनेवाली और कुछ अंश तक मध्यस्थ डेटा टाइपिंग उपलब्ध कराती अन्य प्रोग्रामिंग भाषाओं में भी चलती हैं।

2008 में, काफ़ी थर्ड पार्टी सोफ्टवेयर कंपनियां शुल्क के लिए सोफ्टवेयर सेवाएं पेश करने लगीं. भविष्य में, SOA सिस्टम[मूल शोध?] में ऐसी थर्ड पार्टी सेवाएं शामिल होने की संभावना है, जो इन-हाउस निर्मित अन्य सेवाओं के साथ संयोजित होंगी. इसमें कई ग्राहकों और ग्राहक उपयोगों के लिए लागत के प्रसार की क्षमता है और यह उद्योगों के अंदर और उनके बीच, दोनों ही रूप में मानकीकरण को बढ़ावा देता है। विशेष रूप से, अब यात्रा उद्योग में सेवाओं और डेटा दोनों के पूर्ण रूप से परिभाषित और दस्तावेजीकृत समुच्चय उपलब्ध हैं, जो ऑफ़-द-शेल्फ सोफ्टवेयर सेवाओं का उपयोग करते हुए, किसी भी सक्षम सोफ्टवेयर इंजिनियर को ट्रेवल एजेंसी सोफ्टवेयर के निर्माण के लिए पर्याप्त हैं।[2] अन्य उद्योग, जैसे कि वित्त उद्योगने भी इस दिशा में महत्वपूर्ण प्रगति करना शुरू कर दिया है।

एक आर्किटेक्चर के रूप में SOA अपने मूल डिजाइन-तत्त्व के रूप में सर्विस ओरिएंटेशन पर निर्भर करता है।[3] यदि सर्विस एक साधारण इंटरफेस पेश करे जो इसमें अन्तर्निहित जटिलता को अलग रखता हो, तो उपयोगकर्ता सेवा के प्लेटफोर्म कार्यान्वयन के ज्ञान के बिना स्वतंत्र सेवाओं का उपयोग कर सकते हैं।[4]

SOA एसे इंटरफेस के जरिए अपनी कार्यक्षमता को दर्शाने वाली सेवाओं पर निर्भर करता है जो अन्य अनुप्रयोग (एप्लिकेशन) और सेवाएं पढ़ कर इन सेवाओं का उपयोग कैसे किया जाये वह समझ सकती हैं।

कार्यों के प्रतिरूपकता के माध्यम से या वर्ग नामक पूर्वनिर्धारित क्रिया समूहों के उपयोग के द्वारा सोफ्टवेयर पुनरुपयोग को बढ़ावा देने के पूर्व प्रयासों की विशिष्ट प्रथाओं के सापेक्ष, SOA ओब्जेक्ट्स अक्सर 100 से 1000 गुना तक बड़े होते हैं।[उद्धरण चाहिए]

आवश्यकताएँ

संपादित करें

एक SOA का कुशल उपयोग करने के लिए, निम्न आवश्यकताओं को पूरा करना आवश्यक[उद्धरण चाहिए] है:

  • भिन्न सिस्टमों और प्रोग्रामिंग भाषाओं के बीच की अंतःक्रिया, संचार प्रोटोकोल के माध्यम से भिन्न प्लेटफार्मों पर अनुप्रयोगों (एप्लिकेशनो) के बीच एकीकरण के लिए आधार उपलब्ध कराती है। ऐसे संचार का एक उदाहरण संदेशों की अवधारणा पर निर्भर करता है। निर्धारित संदेश चैनलों में से संदेशों का उपयोग अंतिम अनुप्रयोग की जटिलता को कम करता है, इससे अनुप्रयोग के विकासकर्ता को संचार प्रोटोकोल की जटिल आवश्यकताओं के बजाय वस्तविक अनुप्रयोग क्रियाशीलता पर ध्यान देने में मदद मिलती है।
  • संसाधनों का एक संघ बनाने की इच्छा. एक फेडरेटेड डेटाबेस सिस्टम में डेटा के प्रवाह को स्थापित करना और बनाए रखना. इससे प्रत्येक डेटा तत्त्व के लिए एक सामान्य व्यापार प्रतिरूप के सन्दर्भ में नयी क्रियाशीलता के विकास में मदद मिलती है।

सिद्धांत

संपादित करें

निम्नलिखित मार्गदर्शक सिद्धांत SOA के विकास, रखरखाव और उपयोग के लिए बुनियादी नियमों को परिभाषित करते हैं।[5]

  • पुनरुपयोग, ग्रेन्युलेरिटी, प्रतिरूपकता, जवाबदेही अंग, अवयवीकरण (componentization) और अंतःक्रिया.
  • मानक-अनुपालन (सामान्य और उद्योग विशेष दोनों).
  • सेवाओं की पहचान और वर्गीकरण, प्रोविजनिंग और डिलीवरी और विनियमन और ट्रेकिंग.

डिजाइन और सेवा की परिभाषा के सन्दर्भ में निम्नलिखित विशिष्ट आर्किटेक्चर सिद्धांत विशिष्ट शैलियों पर केन्द्रित हैं जो एक सिस्टम के आंतरिक व्यवहार को और इसके डिजाइन की शैली को प्रभावित करते हैं:

  • सेवा एनकेप्सुलेशन - कई वेब सेवाओं को SOA के अंतर्गत उपयोग के लिए समेकित किया गया हैं। अक्सर ऐसी सेवाओं को SOA के अंतर्गत नियोजित नहीं किया गया था।
  • सेवा ढीला संयोजन - सेवाएं एक ऐसे सम्बन्ध को बनाये रखती हैं जो निर्भरताओं को न्यूनतम करता है और इसके लिए एकमात्र आवश्यकता एक दूसरे की प्रति जागरूकता को बनाये रखने की होती हैं।
  • सेवा अनुबंध - सेवाएं एक संचार समझौते का पालन करती हैं, जैसा कि सामूहिक रूप से एक या अधिक सेवा-विवरण दस्तावेजों के द्वारा परिभाषित किया गया है।
  • सेवा पृथक्करण -सेवा के अनुबंध के परे, सेवाएं बाहरी दुनिया से तर्क को छुपाती हैं।
  • सेवा के पुनरुपयोग की क्षमता - पुनरुपयोग को बढ़ावा देने के इरादे के साथ, तर्क सेवाओं में विभाजित है।
  • सेवा मिश्रण क्षमता - मिश्रित सेवाओं के निर्माण के लिए, सेवाओं के संग्रह को समन्वित और संयुक्त किया जा सकता है।
  • सेवा स्वायत्तता - सेवाओं का उस तर्क पर नियंत्रण होता है जिसे वे एनकेप्सुलेट करती हैं।
  • सेवा अनुकूलन - बाकी सब कुछ बराबर होने पर, उच्च-गुणवत्ता की सेवाओं को सामान्यतया कम गुणवता की सेवाओं की तुलना में ज्यादा पसंद किया जाता हैं।
  • सेवा खोज-क्षमता - सेवाओं को बाहरी रूप में विवरणात्मक होने के लिए डिजाइन किया जाता है, ताकि उन्हें उपलब्ध खोज प्रणाली के माध्यम से ढूंढा जा सके और उपयोग किया जा सके[6].
  • सेवा की प्रासंगिकता - कार्यशीलता एक ग्रेन्युलेरिटी पर उपस्थित होती है, जिसे उपयोगकर्ता के द्वारा एक अर्थपूर्ण सेवा के रूप में पहचाना जाता है।

निम्नलिखित सन्दर्भ एक SOA कार्यान्वयन को परिभाषित करने के लिए अतिरिक्त विचार उपलब्ध कराते हैं:

  • SOA सन्दर्भ आर्किटेक्चर विस्तृत आर्किटेक्चर आरेख, अवयव विवरण, विस्तृत आवश्यकताएं, डिजाइन पैटर्न, मानकों के बारे में अभिप्राय, नियमन अनुपालन पर पैटर्न, मानक टेम्पलेट आदि के साथ एक एन्टरप्राइज-व्यापक SOA कार्यान्वयन की कार्यकारी डिजाइन उपलब्ध कराता है[7].
  • जीवन चक्र प्रबंधन SOA प्रेकटिशनर्स गाइड भाग 3: सेवाओं के जीवन चक्र का परिचय, सेवाओं के जीवन चक्र का परिचय देता है और सेवास्थापना से सेवानिवृत्ति तक या सेवाओं को पुनः उद्देश्य देने तक की सेवा के समग्र जीवन चक्र के दौरान सेवा प्रबंधन के लिए एक विस्तृत प्रक्रिया उपलब्ध कराता है। इसमें एक ऐसा परिशिष्ट भी शामिल है जिसमें संगठन और प्रशासन की सर्वोत्तम प्रथाएं, टेम्पलेट, कुंजीरूप SOA मानकों पर टिप्पणियां और अधिक जानकारी के लिए बताये गए लिंक भी शामिल होते हैं।

इसके अतिरिक्त, एक SOA कार्यान्वयन को परिभाषित करते समय निम्नलिखित कारकों/परिबलों पर विचार किया जा सकता है।

वेब सेवाओं दृष्टिकोण

संपादित करें

वेब सेवाएं एक सर्विस-ओरिएंटेड आर्किटेक्चर को लागू कर सकती हैं। वेब सेवाएं क्रियाशील निर्माणात्मक-ब्लॉक बनाती हैं, जो प्रोग्रामिंग भाषाओं और प्लेटफोर्म से स्वतंत्र मानक इंटरनेट प्रोटोकोल पर सुलभ होते हैं। ये सेवाएं या तो नए अनुप्रयोगों (एप्लिकेशन) को अभिव्यक्त कर सकती हैं, या केवल मौजूदा सिस्टम के आवरण देती है, जिससे वे नेटवर्क-सक्षम हो जाते हैं।

प्रत्येक SOA निर्माण खंड एक या दोनों भूमिकाओं को निभा सकता है।

  1. सेवा प्रदाता
    सेवा प्रदाता एक वेब सेवा का निर्माण करता है और संभवतया इसके इंटरफेस को प्रकाशित करता है और सर्विस रजिस्ट्री के लिए जानकारी उपलब्ध कराता है। प्रत्येक सेवा प्रदाता को यह निर्णय लेना चाहिए कि कौन सी सेवा को प्रदर्शित किया जाये, सुरक्षा और आसान उपलब्धता के बीच व्यापार-कैसे किया जाये, सेवाओं का मूल्य निर्धारण कैसे किया जाये, या (यदि कोई शुल्क लागू नहीं है तो) कैसे/क्या उन्हें अन्य मूल्यो के लिए काम में लिया जाये. प्रदाता को यह भी निर्धारित करना होता है कि एक दी गयी ब्रोकर सेवा के लिए इस सेवा को कौन सी श्रेणी में सूचीबद्ध किया जाना चाहिए और सेवा का उपयोग करने के लिए किस प्रकार के व्यापार सहभागी समझौते की आवश्यकता है। यह रजिस्टर करता है कि कौन सी सेवाएं इसके भीतर उपलब्ध हैं और सभी संभावित सेवा प्राप्तकर्ताओं की सूची बनाता है। इस के बात ब्रोकर को कार्यान्वित करने वाला ब्रोकर के स्कोप को निर्धारित करता है। सार्वजनिक ब्रोकर या दलाल इंटरनेट के माध्यम से उपलब्ध होते हैं, जबकि निजी दलाल सीमित दर्शकों के लिए ही उपलब्ध होते हैं, उदाहरण के लिए, एक कम्पनी इंट्रानेट के उपयोगकर्ता. इसके अलावा, प्रस्तुत जानकारी की मात्रा भी निर्धारित करनी होती है। कुछ दलाल कई सूचियों में विशेषज्ञ होते हैं। अन्य सूचीबद्ध सेवाओं में उच्च स्तरीय भरोसा पेश करते हैं। कुछ सेवाओं के एक व्यापक परिदृश्य को आवरित करते हैं और अन्य कोई उद्योग पर ध्यान केन्द्रित करते हैं। कुछ दलाल अन्य दलालो को उपलब्ध कराते हैं। व्यापार मॉडल के अनुसार, दलाल अनुरोध को, सूचियों की संख्या को और सूचियों की सटीकता को अधिकतम करने का प्रयास कर सकते हैं। यूनिवर्सल डिस्क्रिप्शन डिस्कवरी एंड इंटीग्रेशन (UDDI) विनिर्देशन वेब सेवाओं के बारे में जानकारी की खोज और प्रकाशन के तरीके को परिभाषित करता है। अन्य सेवा ब्रोकर तकनीकों में शामिल हैं (उदाहरण के लिए) ebXML (एक्सटेंसिबल मार्कअप भाषा का उपयोग करते हुए इलेक्ट्रोनिक बिजनेस) और वे जो ISO/IEC 11179 मेटाडेटा रजिस्ट्री (MDR) मानक पर आधारित हैं।
  2. सेवा उपभोक्ता
    सेवा उपभोक्ता या वेब सेवा का ग्राहक विभिन्न खोज ऑपरेशन्स का उपयोग करते हुए ब्रोकर रजिस्ट्री में प्रविष्टियों को स्थानीकृत करता है और इसके बाद कोई एक वेब सेवा को प्रेरित करने के लिए उसके सेवा प्रदाता से जुड़ जाता है। सेवा-उपभोक्ताओं को जो कोई भी सेवा की आवश्यकता होती है, उन्हें इसे ब्रोकर में लेना होता है, उसके बाद सम्बंधित सेवा के साथ इसे जोड़ना होता है और फिर इसका उपयोग करना होता है। यदि यह सेवा कई सेवाओं को एक साथ उपलब्ध कराती है, तो वे कई सेवाओं का उपयोग कर सकते हैं।

SOA और वेब सेवा प्रोटोकॉल

संपादित करें

ईम्लीमेन्टर्स सामान्यतया उन वेब सेवा मानकों (उदाहर्ण के लिए SOAP) का उपयोग करते हुए SOAs का निर्माण करते हैं जिसने[कब?] उद्योग क्षेत्र में विस्तृत स्वीकृति प्राप्त कर ली है। ये मानक (जिन्हें वेब सेवा विनिर्देश भी कहा जाता है) अधिक अंतःक्रिया भी उपलब्ध करते हैं और मालिकाना विक्रेता सोफ्टवेयर के लिए लोक-इन से कुछ सुरक्षा भी उपलब्ध कराते हैं। हालांकि, जिनी, CORBA या REST जैसी किसी भी सेवा-आधारित तकनीक का उपयोग करते हुए SOA का कार्यान्वयन किया जा सकता है।

अन्य SOA अवधारणायें

संपादित करें

आर्किटेक्चर विशिष्ट तकनीकों के स्वतंत्र रूप से ऑपरेट कर सकते हैं।[6] डिजाइनर तकनीकों की व्यापक रेंज का उपयोग करते हुए SOA का कार्यान्वयन कर सकते हैं, इनमें शामिल हैं:

कार्यान्वयन इनमें से एक या अधिक प्रोटोकोल्स का उपयोग कर सकते हैं, उदाहरण के लिए, ये SOA अवधारणा के अनुरूप प्रक्रियाओं के बीच निर्धारित इंटरफेस-विनिर्देशन के अनुरूप डेटा के संचार के लिए एक फ़ाइल-प्रणाली तंत्र का उपयोग कर सकते हैं। कुंजी परिभाषित इंटरफेस के साथ की एक स्वतंत्र सेवा है, जिसका उपयोग एक मानक तरीके से उनके कार्यों को करने के लिए किया जा सकता है, सेवा को कोलिंग अनुप्रयोग के बारे में पहले से ज्ञान नहीं होता है और अनुप्रयोग के पास इस बारे में ज्ञान नहीं होता है कि कैसे सेवा वास्तव में अपना कार्य करती है।[weasel words]SOA के कई कार्यान्वयन शुरू हो चुके हैं[कब?] जो SOA 2.0 से जाने जाते अधिक विकसित[उद्धरण चाहिए] आर्किटेक्चर के SOA अवधारणाओं के विकास को अपनाते हैं।

 
दिर्क क्राफजिग, कार्ल बान्के और दिर्क स्लामा द्वारा, एलिमेन्ट्स ऑफ SOA[8]
 
SOA मेटा-मॉडल, द लिन्थिकम समूह, 2007
चित्र:SOMF V 2.0.jpg
सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क (SOMF) संस्करण 2.0

SOA उन अनुप्रयोगों (एप्लिकेशन) के विकास को सक्षम बनाता है जिन्हें ढीले संयोजन और अंतःक्रिया सेवाओं के संयोजन से बनाया गया है।[9]

ये सेवाएं एक औपचारिक परिभाषा के आधार पर अंतःक्रिया करती हैं (या संकुचन, उदाहरण WSDL) जो अन्तर्निहित प्लेटफोर्म और प्रोग्रामिंग भाषा से स्वतंत्र होती है। इंटरफ़ेस परिभाषा भाषा-विशिष्ट सेवा के कार्यान्वयन को छुपाती है। इसलिए SOA आधारित सिस्टम विकास तकनीकों और प्लेटफोर्म (जैसे जावा, .NET आदि) से स्वतंत्र रूप में कार्य करता है। .NET प्लेटफोर्म पर चलने वाली C# जावा में लिखी गयी सेवाएं और जावा EE प्लेटफोर्म पर चलने वाली सेवाएं, उदाहरण के लिए, दोनों का उपभोग एक सामान्य मिश्रित अनुप्रयोग (या ग्राहक) के द्वारा किया जा सकता है। दोनों में से किसी भी प्लेटफोर्म पर चलने वाले अनुप्रयोग भी अन्य वेब सेवाओं पर चलने वाली सेवाओं का उपभोग कर सकते हैं जो पुनरुपयोग को बढ़ावा देती हैं। प्रबंधित परिवेश भी COBOL लिगेसी सिस्टम को आवरित कर सकता है और उन्हें सोफ्टवेयर सेवाओं के रूप में पेश करता है। इसने कई मुख्य सिस्टम्स के उपयोगी जीवन को अपरिमित रूप से बढ़ा दिया है, चाहे उन्होंने मूल रूप से किसी भी भाषा का प्रयोग किया हो.

जटिल एंटरप्राइज सिस्टम के भीतर SOA एकीकरण और समेकन की गतिविधियों का समर्थन करता है, लेकिन SOA दस्तावेजीकरण क्षमताओं और सेवाओं के लिए कोई विधि या ढांचा उपलब्ध नहीं कराता है।

उच्च स्तर की भाषाएं जैसे BPEL और विनिर्देशन जैसे WS-CDL और WS-समन्वयन सेवा की अवधारणा को विस्तृत करते हैं, इसके लिए वे परिभाषा की विधियां उपलब्ध करते हैं और सूक्ष्म-कणीय सेवाओं के अधिक स्थूल कणीय सेवाओं में ओर्केसट्रेशन का समर्थन करते हैं, जिसे आर्किटेक्ट कार्य प्रवाह में डाल सकता है और व्यापारिक प्रक्रियाएं कम्पोजिट अनुप्रयोगों या पोर्टल में कार्यान्वित की जाती हैं।[उद्धरण चाहिए]

2008 के अनुसार शोधकर्ताओं ने SOA के कार्यान्वयन के लिए सेवा अवयव आर्किटेक्चर के उपयोग की जांच शुरू की है।

सर्विस ओरिएंटेड मॉडलिंग[1] SOA प्रेक्टिशनर को उसकी सर्विस ओरिएंटेड संपत्ति की अवधारणा, विश्लेषण, डिजाइन और आर्किटेक्ट के लिए गाइड करनेवाला एक एसा SOA फ्रेमवर्क है जो भिन्न अनुशासनों की पहचान करता है। सर्विस ओरिएंटेड मॉडलिंग फ्रेमवर्क (SOMF) भिन्न अवयवों का वर्णन करने वाले "नक़्शे" या एक कार्य सरंचना को प्रस्तुत करता है, जो एक सफल सर्विस ओरिएंटेड मोडलिंग दृष्टिकोण में योगदान देते हैं। यह उन मुख्य तत्त्वों निरूपित करता है, जो सेवा विकास योजना के "क्या किया जाए" पहलू की पहचान करते हैं। यह मॉडल प्रोजेक्ट योजना की रचना करने के लिए प्रेक्टिशनर को सक्षम बनता है और एक सर्विस ओरिएंटेड पहल के माइलस्टोनो की पहचान करने में मदद करता है। SOMF भी व्यापार और आईटी (IT) संगठनो के बीच संरेखण के लिए एक सामान्य मोडलिंग संकेतन उपलब्ध कराता है।

SOMF को निम्नलिखित सिद्धांतों के पूरा करने के लिए डिजाइन[किसके द्वारा?] किया गया है:

  • व्यापार ट्रेस करने की क्षमता
  • आर्किटेक्चर की सर्वोत्तम प्रथाओं का पता लगाने की क्षमता
  • प्रौद्योगिकीय ट्रेस-क्षमता
  • SOA मूल्य सिद्धांत
  • सॉफ्टवेयर संपत्ति का पुनरुपयोग
  • SOA एकीकरण रणनीति
  • तकनीकी सार और सामान्यीकरण
  • आर्किटेक्चर के अवयवों का सार

SOA परिभाषाएं

संपादित करें

टिप्पणीकारों ने SOA की कई परिभाषाएं प्रदान की हैं। ओएसिस समूह[10] और ओपन समूह[11] दोनों ने औपचारिक परिभाषाओं का निर्माण किया है।

ओएसिस SOA को निम्न रूप में परिभाषित करता है:

भिन्न स्वामित्व रखनेवाले डोमेन्स के नियंत्रण में हो एसी वितरित क्षमताओं के उपयोग और संगठन के लिए एक प्रतिमान. यह प्रस्ताव रखने, खोज करने और पारस्परिक क्रिया के लिए समरूप साधन उपलब्ध कराता है और मापन योग्य पूर्वस्थितियों और अपेक्षाओं के साथ सुसंगत वांछित प्रभाव उत्पन्न करने के लिए क्षमताओं का उपयोग करता है।

सेवा अनुबंध

संपादित करें

सेवा अनुबंध[उद्धरण चाहिए] के लिए निम्नलिखित अवयवों की आवश्यकता होती है:

  • शीर्षक (Header)
    • नाम- सेवा का नाम. सेवा की परिभाषा नहीं, बल्कि सामान्य शब्दों में केवल यह सेवा क्या करती है उसे इंगित करना है।
    • संस्करण- इस सेवा अनुबध का संस्करण
    • मालिक- सेवा के प्रभारी व्यक्ति या टीम इनचार्ज
    • उत्तरदायित्व आवंटन (RACI)
      • जिम्मेदार - इस अनुबंध/सेवा के डिलिवरेबल्स के लिए जिम्मेदार भूमिका/व्यक्ति/टीम.
अनुबंध के सभी संस्करण.
      • जवाबदेह - इस अनुबंध/सेवा के सन्दर्भ में अंतिम फैसला लेने वाला.
      • परामर्शक - वह जिसके साथ इस अनुबंध/सेवा पर काम करने से पहले सलाह ली जाती है। यह दो-तरफ़ा संचार है। फैसले पर या उस फैसले के कार्यान्वयन पर इन लोगों का प्रभाव रहता है।
      • सूचित - कोई फैसला लिया जा रहा है या कोई क्रिया की जा रही है उसके बारे में जिसे सूचित किया जाना चाहिए वह. यह एक तरफ़ा संचार है। फैसले से या उस फैसले के कार्यान्वयन से इन लोगों का प्रभाव पड सकता है, लेकिन उस पर उनका कोई नियंत्रण नहीं होता है।
    • प्रकार - यह सेवा का प्रकार है: यह उन परतों को विभेदित करने में मदद करता है जिसमें यह रहता है। विभिन्न कार्यान्वयनों के सेवा के प्रकार भिन्न होंगे. सेवा के प्रकार के उदाहरणों में शामिल हैं:
      • प्रस्तुति (Presentation)
      • प्रक्रिया (Process)
      • व्यवसाय (Business)
      • आंकडे (Data)
      • एकीकरण (Integration)
  • क्रियात्मक
    • क्रियात्मक आवश्यकता (आवश्यकता दस्तावेजों से) - विशिष्ट बुलेटेड आइटमों में क्रियाशीलता को - यानि कि यह सेवा वास्तव में क्या पूर्ण/सिद्ध करेगी वह सूचित करता है। क्रियाशीलता प्राप्त हो गयी है, यह साबित करने के लिए भाषा को परीक्षण मामलों को प्रोत्साहित करना चाहिए.
    • सेवा संचालन - विधियों, क्रिया आदि. क्रियाशीलता के कौन से हिस्से को वह उपलब्ध कराता है एसे सन्दर्भ में स्पष्ट करना चाहिए.
    • प्रेरण - यह इंगित करता है कि कैसे सेवा को प्रेरित किया जाये. इसमें URL, इंटरफेस, आदि शामिल हैं। एक ही सेवा के लिए एकाधिक प्रेरण पथ हो सकते हैं। कोई अपने आंतरिक और कुछ बाहरी ग्राहकों के लिए समान क्रियाशीलता - पर प्रत्येक के भिन्न प्रेरण के साधन और इंटरफेस रख सकता है। उदाहरण:
      • SOAP
      • REST
      • घटनाक्रम ट्रिगर
  • गैर-क्रियात्मक
    • सुरक्षा बाधाएं - भूमिका या व्यक्तिगत सहभागियों आदि के सन्दर्भ में इस सेवा को कौन निष्पादित कर सकता है और वे कौन सी प्रेरण प्रणाली को प्रेरित कर सकते हैं उन्हें परिभाषित करता है।
    • सेवा की गुणवत्ता - स्वीकार्य विफलता दर को निर्धारित करता है।
    • आदान-प्रदान (Transactional) - क्या यह बड़े आधान-प्रदान के हिस्से के रूप में कार्य करने में सक्षम है और यदि ऐसा है तो हम उसे कैसे नियंत्रित कर सकते हैं?
    • सेवा स्तर का समझौता - जितने समय तक सेवा को अपना कार्य करने की अनुमति होती है वह विलंबता की राशि निर्धारित करता है।
    • अर्थ विज्ञान - सेवा के विवरण और इंटरफेस में प्रयुक्त शब्दों के अर्थ को परिभाषित या स्पष्ट करता है।
    • प्रक्रिया - यदि इस अनुबंधित सेवा की कोई प्रक्रिया है तो उसका वर्णन करता है।

SOA और नेटवर्क प्रबंधन आर्किटेक्चर

संपादित करें

2008 के अनुसार  नेटवर्क प्रबंधन के क्षेत्र में SOA के सिद्धांतों को लागू[किसके द्वारा?] किया जा रहा है।[किसके द्वारा?] सेवाभिमुख नेटवर्क प्रबंधन आर्किटेक्चर के उदाहरणों में शामिल हैं ETSI से TS 188 001 NGN प्रबंधन OSS आर्किटेक्चर और ITU-T से सूचित M.3060 अगली पीढ़ी के नेटवर्क प्रबंधन के सिद्धांत .

SOA के बुनियादी ढांचे के प्रबंधन के उपकरणों में शामिल हैं:

चर्चा

संपादित करें

लाभ

संपादित करें

कुछ उद्यम (एन्टरप्राइज़) आर्किटेक्ट्स का मानना है कि बाजार की बदलती हुई परिस्थितियों में SOA व्यापार को जल्दी से और लागत प्रभावी ढंग से प्रतिभाव देने में मदद कर सकता है।[12] आर्किटेक्चर की यह शैली माइक्रो (छोटे यानी वर्ग) स्तर के बजाय मैक्रो (बड़े यानी सेवा) स्तर पर पुनरुपयोग को बढ़ावा देती है। 

यह उपस्थित IT (लिगेसी) संपत्ति के आंतिरिक संपर्क को और उस के उपयोग को सरल बनता है।

कुछ सन्दर्भों में, SOA को एक क्रांति के बजाय आर्किटेक्चर का क्रमिक-विकास माना जा सकता है। यह पूर्व सोफ्टवेयर आर्किटेक्चर की कई सर्वोत्तम प्रथाओं को अपने में बनाए रखता है। उदाहरण के लिए, संचार प्रणालियों में, अन्य उपकरणों के बात करने के लिए सही मायने में स्थिर बाइंडिंग का उपयोग करनेवाले समाधानों के क्षेत्र में बहुत कम विकास हुआ हैं। औपचारिक रूप से एक SOA दृष्टिकोण को अपनाने पर, ऐसे सिस्टम भली प्रकार से परिभाषित, बहुत अधिक अंतःक्रियात्मक इंटरफेस के महत्त्व पर दबाव डालने के लिए अपने आप को तैयार कर सकते हैं।[13]

कुछ[कौन?] लोगों ने यह सवाल उठाया था कि क्या SOA मोड्यूलर प्रोग्रामिंग (1970s), घटना-ओरिएंटेड डिजाइन (1980s) या इंटरफेस/अवयव आधारित डिजाइन (1990s)[उद्धरण चाहिए] जैसी अवधारणाओं को मात्र पुनर्जीवित करता है। SOA सेवा के कार्यान्वयन से उपयोगकर्ताओं (ग्राहकों) को अलग करने के उद्देश्य को बढ़ावा देता है। इसलिए सेवाओं को भिन्न वितरित प्लेटफार्मों पर चलाया जा सकता है और ये नेटवर्क पर उपलब्ध हो सकती हैं। इस से सेवाओं का पुनरुपयोग भी अधिकतम हो सकता है।[उद्धरण चाहिए]

SOA एक आर्किटेक्चरल और डिजाइन अनुशासन है जिसे [किसके द्वारा?] अंतःक्रिया क्षमता/इन्टेरोपेरेबिलिटी (जानकारी का विनिमय, पुनरुपयोग की क्षमता और संयोजन क्षमता) को बढ़ाने का, फेडरेशन (व्यक्तिगत स्वायतता और स्व-प्रशासन को बनाये रखते हुए अनुप्रयोगों और स्रोतों का एकीकरण) को बढ़ाने का और व्यापार और तकनीक डोमेन संरेखन को बढाने का लक्ष्य प्राप्त करने के लिए बनाया गया है।[उद्धरण चाहिए]

सर्विस ओरिएंटेड आर्किटेक्चर (SOA), जटिल सोफ्टवेयर-प्रधान सिस्टम के निर्माण के लिए एक आर्किटेक्चरल दृष्टिकोण (या शैली) है, जो सार्वत्रिक रूप से एक दुसरे से जुडी हुई और अन्योन्याश्रित बिल्डिंग ब्लॉक्स के समूह यानि सेवाओं से बनता हैं।

सेवाओं के निर्माण के समय विश्लेषण और डिजाइन विधि के उपयोग के माध्यम से SOA अपने व्यापार और आईटी (आईटी) लाभ वसूल करता है। यह विधि सुनिश्चित करती है कि सेवाएं आर्किटेक्चरल दृष्टि और योजना के साथ सुसंगत रहें और वें सेवाभिमुख के सिद्धांतों का पालन करती रहें. SOA से व्यापार और प्रबंधन पहलूओं का समर्थन करने वाले तर्क कई प्रकाशनों में दिए गए हैं।[14]

सिर्फ औपचारिक रूप से परिभाषित इंटरफेस के माध्यम से ही सेवा को क्रियाशीलता की एकमेव (स्टैंड-अलोन) इकाई उपलब्ध होती है। सेवाएं एक तरह की "नैनो उद्यमों (नैनो-एन्टरप्राइज्स)" हो सकती हैं जिनका निर्माण और सुधार आसान होता है। और सेवाएं "बड़े निगम" भी हो सकती हैं, जो गौण सेवाओं के समन्वित कार्य के रूप बनाई जाती है।

सेवाएं आमतौर पर सर्विस ओरिएंटेशन के निम्न सिद्धांतों का पालन करती हैं:

  • पृथक्करण/सारांश
  • स्वायत्तता
  • संयोजन (मिश्रण) क्षमता
  • खोज पाने/करने की क्षमता
  • औपचारिक अनुबंध
  • ढीला संयोजन
  • पुनरुपयोग की क्षमता
  • अवस्थारहित होना

SOA का परिपक्व रोलआउट प्रभावी रूप से संगठन के API को परिभाषित करता है।

सेवाओं के कार्यान्वयन को बड़ी परियोजनाओं से अलग परियोजनाओं के रूप में देखने के कारणों में शामिल हैं:

  1. संगठन में सामान्य एसे बड़े और धीमी गति के प्रोजेक्ट से अलग रहकर सेवाओं को जल्दी और स्वतंत्र रूप से डिलीवर किया जा सकता है, एसी व्यापार अवधारणा को विभाजन बढ़ावा देता है। व्यापार प्रणालीयों को और सेवाओं पर सरलीकृत उपयोगकर्ता इंटरफेस को समझना शुरू करता है। यह चंचलता (एजीलिटी) को समर्थन देता है।
  2. विभाजन उपभोक्ता प्रोजेक्ट्स से सेवाओं के असंयोजन को बढ़ावा देता है। अब तक में यह अच्छे डिजाइन को प्रोत्साहित करता है क्योंकि जब सेवा को डिजाइन किया जाता है तब यह ज्ञात नहीं होता है की उसका उपभोक्ता कौन होगा.
  3. सेवा के दस्तावेजीकरण और परीक्षण कलाकृतियों को बड़ी परियोजनाओं के विवरण में शामिल नहीं किया जाता है। यह तब महत्वपूर्ण होता है जब सेवा को बाद में फिर से काम में लिया जाना हो.

SOA से होते अप्रत्यक्ष लाभ में शामिल है नाटकीय रूप से सरलीकृत परीक्षण. सेवाएं स्वायत्त, अवस्थाहीन हैं, पूरी तरह से दस्तावेजित इंटरफेस से युक्त हैं और कार्यान्वयन के क्रोस कटिंग चिंताओं से अलग हैं। उद्योग[which?] पहले कभी भी ऐसी परिस्थितियों से नहीं गुजरा है।[उद्धरण चाहिए]

यदि संगठन में उपयुक्त परिभाषित परीक्षण डेटा हैं, तो जब एक सेवा का निर्माण किया जा रहा है, तब एक सम्बंधित स्टब का निर्माण किया जाता है, जो परीक्षण डेटा को प्रतिक्रया करता है। प्रतिगमन परीक्षण, लिपियों, डेटा और प्रतिभाव के एक पूरे सेट को भी सेवा के लिए काम में लिया जाता है। जो सेवाओं को मांगा गया है उसके तद्विषयक उपस्थित स्टब का उपयोग करते हुए एक 'ब्लैक बॉक्स' के रूप में भी परीक्षण किया जाता सकता है। जहां आद्य और दायरे से बाहर की सेवाएं स्टब हैं, जबकि जाल का शेष भाग पूरी सेवा के परीक्षण नियोजक है, एसे परीक्षण वातावरण का निर्माण किया जाता है। चूंकि प्रत्येक इंटरफेस पूरी तरह से दस्तावेजों से युक्त होता है, जो प्रतिगमन टेस्ट दस्तावेजीकरण का पूरा सेट होता है, इसलिए परीक्षण सेवाओं में समस्याओं की पहचान सरल बन जाती है। परीक्षण सेवा अपने दस्तावेजीकरण के अनुसार काम करती है एसा मान्य करने के लिए और वातावरण में मौजूदा सभी सेवाओं के परीक्षण मामले और दस्तावेजीकरण के बीच रिक्त स्थान ढूंढने के लिए ही परीक्षण विकसित किया जाता है। Idempotent सेवाओं की डेटा अवस्था का प्रबंधन एकमात्र जटिलता है।

सेवा के दस्तावेजीकरण में जहां वह उपयोगी हो उस स्तर पर उदाहरण सहायरूप सिद्ध होते है। जावा समुदाय प्रक्रिया में कुछ APIs के दस्तावेजीकरण अच्छे उदाहरण उपलब्ध कराते हैं। क्योंकि ये विस्तृत होते हैं, स्टाफ प्रारूपिक रूप से केवल महत्वपूर्ण उप-सेट का उपयोग करेंगे. JSR-89 के भीतर 'ossjsa.pdf' ऐसी फ़ाइल की एक मिसाल है।[15]

SOA को अपनाने में चुनौतियां

संपादित करें

एक स्पष्ट और आम चुनौती सामने आई, वह है, सेवा मेटाडेटा का प्रबंधन.[उद्धरण चाहिए] SOA आधारित वातावरण में कई सेवाएं शामिल हो सकती हैं जो कार्य करने के लिए संदेशों का विनिमय करती हैं। डिजाइन के अनुसार, एकमात्र अनुप्रयोग कई मिलियन संदेशों को उत्पन्न कर सकता है। सेवाएं कैसे अंतर्क्रिया करती हैं, इस पर जानकारी उपलब्ध कराना और इसका प्रबंधन जटिल हो सकता है। 

जब इन सेवाओं की डिलीवरी कंपनी के ही भिन्न संगठनों के द्वारा की जाती है या यहां तक की अलग अलग कंपनियों (भागीदारों, आपूर्तिकर्ताओं, आदि) के द्वारा की जाती है तब यह और भी जटिल हो जाता है। इससे दलों (टीम) में भरोसे को लेकर बड़े मुद्दे सामने आते हैं और इसलिए SOA प्रशासन प्रस्तुत बनता है।

एक दूसरी चुनौती है, SOA स्थान में परीक्षण की कमी . ऐसे कोई अत्याधुनिक उपकरण नहीं हैं जो एक विशिष्ट आर्किटेक्चर में सभी नेतृत्वहीन सेवाओं (जिसमें वेब सेवाओं के साथ डेटाबेस सेवाएं और सन्देश शामिल हैं) की परीक्षण क्षमता उपलब्ध करायें. समस्तरीय विश्वास की कमी के कारण यह जरुरी है कि निर्माता और उपभोक्ता दोनों सेवाओं का निरंतर परीक्षण करते रहें. SOA का मुख्य उद्देश्य व्यापार को चुस्ती/तेज़ी प्रदान करना है।[उद्धरण चाहिए] इसलिए एक परीक्षण ढांचे (निर्माण या खरीद) में निवेश करना महत्वपूर्ण है, जो आर्किटेक्चर में अपराधी को खोजने के लिए पारदर्शिता उपलब्ध कराएगा. व्यवसाय में तेजी के लिए आवश्यक है कि SOA सेवाओं को व्यापार प्रेरणा मॉडल (बिजनेस मोटिवेशन मॉडल - BMM) में दी गयी परिभाषा के अनुसार व्यापारिक उद्देश्यों और निर्देशों के द्वारा नियंत्रित किया जा सके[16].

अन्य एक और चुनौती सुरक्षा के उपयुक्त स्तर उपलब्ध कराने से सम्बंधित है। जब एक अनुप्रयोग जिसका उपयोग अन्य अनुप्रयोग भी कर सकते है एसी सेवाओं के रूप में अपनी क्षमताएं उजागर करती है तब अनुप्रयोग के भीतर में समाविष्ट सुरक्षा मॉडल पर्याप्त नहीं रहते. अर्थात, अनुप्रयोग-प्रबंधित सुरक्षा, सेवाओं की सुरक्षा के लिए सही मॉडल नहीं है। कई नई प्रौद्योगिकियों और मानकों ने[कब?] SOA में सुरक्षा के लिए अधिक उपयुक्त मॉडल उपलब्ध कराने शुरू किए हैं। अधिक जानकारी के लिए देखें SOA सुरक्षा प्रविष्टि.

चूंकि SOA और WS-*विनिर्देशन प्रेक्टिशनर अपने आउट पुट को विस्तृत, अद्यतन और परिष्कृत करते हैं, उन्हें SOA आधारित सिस्टम पर काम करने के लिए कुशल लोगों की कमी की समस्या का सामना करना पड़ता है, इसमें सेवा ढांचे का निर्माण और सेवाओं का एकीकरण भी शामिल है।

अंतःचालन SOA कार्यान्वयन का एक महत्वपूर्ण पहलू होता है। WS-I संगठन ने संगतता को बल देने के लिए बेसिक प्रोफाइल (BP) और बेसिक सिक्योरिटी प्रोफाइल (BSP) का विकास किया है[17]. वेब सेवाएं WS-I प्रोफाइल दिशानिर्देशों के मुताबिक हैं या नहीं ये तय करने के लिए WS-I ने परीक्षण उपकरण डिजाइन किये हैं। इसके अतिरिक्त, विश्वसनीय सुरक्षा प्रोफाइल पर काम करने के लिए एक और चार्टर की स्थापना की गयी है।

महत्वपूर्ण विक्रेता प्रचार SOA को घेरे हुए हैं; इससे ऐसी उम्मीदें बनती हैं, जिन्हें शायद पूरा नहीं भी किया जा सके. प्रारंभिक एडोप्टरों ने वास्तविक दुनिया की समस्याओं के सन्दर्भ में विकास और रनटाइम उत्पादों पर परीक्षण जारी रखे और इस कारण उत्पाद के ढेर बनते रहे. सोया आईटी (आईटी) लागत में कमी की कोई गारंटी नहीं देता है, ना ही बाजार में तेजी लाने की या प्रणालीयों में चुस्ती लाने की कोई गारंटी देता है। सफल SOA कार्यान्वयन ये सभी या इनमें से कुछ लाभ हो सकते हैं, यह सिस्टम आर्किटेक्चर और डिजाइन की गुणवत्ता और संबद्धता पर निर्भर करता है[18][19].

आंतरिक आईटी (IT) डिलीवरी संगठन नियमित SOA प्रयासों का आरंभ करते हैं और इनमें से कुछ व्यापार[उद्धरण चाहिए] में अवधारणाओं को अनुपयुक्त तरीके से पेश करते हैं, जिससे उसके बारे में गलतफ़हमी बनी रहती है[किसके द्वारा?]. इसे अपनाने से व्यापार के बजाय आईटी (IT) डिलीवरी की जरूरतें पूरी होने लगी, जिसके परिणामस्वरूप बाजार के अवसरों के लिए तुरंत प्रतिक्रिया देने वाले संगठन के बजाय सुपरलेटिव लैपटॉप प्रोविजनिंग सेवाओं से युक्त संगठन सामने आता है। यह संगठन SOA का कार्यान्वयन ठीक प्रकार से कर रहा है इस बारे में व्यापार नेतृत्व भी सहमत हो गया था।

SOA का सबसे महत्वपूर्ण लाभ यह है कि इसे आसानी से पुनःउपयोग में लिया जा सकता है। इसलिए अंततः हिसाबी जवाबदेहिता और वित्त मॉडलों का विकास संगठन में ही होना चाहिए.[उद्धरण चाहिए] एक व्यवसाय इकाई को ऐसी सेवाओं के निर्माण के लिए प्रोत्साहित किया जाना चाहिए, जिसका उपयोग अन्य इकाइयां कर सकें. इसके विपरीत, इकाइयों को सेवाओं के पुनःप्रयोग के लिए प्रोत्साहित किया जाना चाहिए. इसके लिए प्रशासन के कुछ नए घटकों की आवश्यकता रहती हैः

  • सेवाओं का निर्माण करने वाली प्रत्येक व्यापार इकाई के पास सेवा-स्तर के दायित्वों को पूरा करने के लिए एक उपयुक्त समर्थन सरंचना होनी चाहिए और अन्य लोगों को लाभ पहुंचाने के लिए ही मौजूदा सेवाओं को बढ़ावा दिया जाना चाहिए. व्यवसाय अग्रणीओं के लिए यह प्रारूपिक रूप से बाहर की बात है।
  • सेवाओं का उपभोग करने वाली प्रत्येक व्यापार इकाई, बाह्य परियोजना परिचर निर्भरता, आदि के साथ अपने नियंत्रण के बाहर सेवाओं के पुनः उपयोग के संभावित जोखिम का स्वीकार करती है।
  • उपरोक्त समस्याओं का सामना करने के लिए एक नवीन वित्त मॉडल की जरुरत रहती है।[उद्धरण चाहिए] व्यापार इकाइयां सामान्यतः परियोजना के दौरान सहायता के लिए और बाद में वातावरण का संचालन करने के लिए आईटी (IT) संगठनों को भुगतान करती हैं। कॉर्पोरेट सेवाओं को इन लागतो पर सेवा प्रदाताओं को कुछ छूट देनी चाहिए और सेवा प्रदाता के लिए व्यावसायिक इकाइयों के उपभोग से आंतरिक राजस्व धाराओं को बनाया जाना चाहिए.[उद्धरण चाहिए] बस पुराने तरीके से निर्माण की तरह, ये धाराएं उपभोक्ता की लागत से कम होनी चाहिए. यहीं पर SOA तैनाती SaaS मुद्रीकरण आर्किटेक्चर से लाभ प्राप्त कर सकते है[20].

SOA की आलोचना

संपादित करें

SOA की कुछ आलोचनाएं[21] वेब सेवाओं के साथ SOA के संकलन पर निर्भर हैं। उदाहरण के लिए, कुछ आलोचकों[कौन?] का दावा है कि SOA का परिणाम XML की परतों की बढोतरी के रूप में होता है, जो XML पार्सिंग और संरचना को बताता है। दूरस्थ प्रक्रिया कॉल (रिमोट प्रोसिजर कॉल - RPC) के मूल या द्विआधारी रूपों के अभाव में, अनुप्रयोग की गति धीमी पड सकती हैं और उन्हें अधिक प्रोसेसिंग क्षमता की जरुरत पडती है, जो लागत में बढोतरी का कारण बनता है। अधिकांश कार्यान्वयनों में ये ओवरहेड शामिल हैं, लेकिन SOA को दूरस्थ प्रक्रिया कॉल्स या XML के माध्यम से अनुवाद पर निर्भर नहीं हो एसी प्रौद्योगिकियों (उदाहरण के लिए, जावा बिजनेस एकीकरण, (JBI)) का उपयोग करते हुए भी कार्यान्वित किया जा सकता है। उभरती हुई खुले स्रोत XML पार्सिंग प्रौद्योगिकियों (जैसे VTD-XML) और भिन्न XML-संगत द्विआधारी स्वरूपों से उत्पन्न होता है जो SOA के अच्छे प्रदर्शन के लिए वादा करते हैं।[22][23][24]

अवस्थापूर्ण सेवाओं को समान उपभोक्ता-विशिष्ट सन्दर्भ को साझा करने के लिए उपभोक्ता और प्रदाता दोनों की आवश्यकता होती है, जो या तो इसमें शामिल होते हैं या उपभोक्ता और प्रदाता के बीच सन्देश विनिमय के द्वारा सन्दर्भित होते हैं। इस बाधा की कमी यह है कि यदि सेवा प्रदाता को प्रत्येक उपभोक्ता के लिए साझा सन्दर्भ को बनाये रखने की आवश्यकता हो, तो इससे सेवा प्रदाता की समग्र मापन क्षमता कम हो सकती है। यह सेवा प्रदाता और उपभोक्ता के बीच संयोजन को बढ़ाता है और सेवा प्रदाताओं बदलना अधिक मुश्किल बनाता है[25]. अंततः, कुछ आलोचकों का मानना है कि SOA सेवाएं अभी भी उनके द्वारा अभिव्यक्त किये जाने वाले अनुप्रयोगों के द्वारा अत्यंत बाधित हैं[26].

एक और मुद्दा WS-* मानकों और उत्पादों (उदाहरण लेनदेन, सुरक्षा) के क्रमिक विकास से सम्बंधित है और जब तक SOA को अतिरिक्त बजट और अतिरिक्त सबूत-की-अवधारणा के लिए आकस्मिक कार्य के साथ पूर्ण रूप से प्रबंधित और अनुमानित न किया जाये, तब तक SOA इस प्रकार से नए जोखिमों को शामिल करता है।

कुछ आलोचक[कौन?] SOA को महज पहले से अच्छी तरह बने हुए आर्किटेक्चरों (खुला इंटरफेस, आदि) का स्वाभाविक विकासcurrently के अनुसार  मानते हैं।

आई़़टी सिस्टम डिजाइन कभी कभी रूपांतरित सिस्टम की वांछनीयता को अनदेखा करते हैं। SOA आधारित सिस्टम, हार्ड कोड ऑपरेशन्स, संगठन की मालसमान और सेवाएं के साथ कई सिस्टम, इस प्रकार से अपनी ऑनलाइन सेवाएं और वैश्विक बाजार में व्यापारी चपलता को बाधित करते हैं।[उद्धरण चाहिए]

डिजाइन प्रक्रिया में अगला[which?] कदम सेवा वितरण मंच (सर्विस डिलिवरी प्लेटफोर्म - SDP) और उसके कार्यान्वयन की परिभाषा को समाविष्ट करता हैं। SDP डिजाइन चरण में व्यावसायिक जानकारी मॉडल, पहचान प्रबंधन, उत्पादों, सामग्री, उपकरण और अंतिम उपयोगकर्ता सेवा विशेषताओं को और साथ ही क्या सिस्टम इतनी चपल है कि व्यापार और उसके ग्राहकों के क्रमिक विकास के साथ ताल रख पाए - इन मुद्दों को परिभाषित किया जाता है।

एक्सटेंशन्स

संपादित करें

SOA, वेब 2.0, मेसेन्जर्स और मेश पर सेवाएं

संपादित करें

वेब 2.0, जो वेब गतिविधि की कथित "दूसरी पीढ़ी" है, इसमें प्राथमिक रूप से सहयोग और साझे के लिए दर्शकों को प्रदान की गई हुई जानकारी रखने की क्षमता एक विशेषता है। वेब 2.0 अनुप्रयोग अक्सर REST-ful वेब सेवाओं का प्रयोग करते हैं और सामान्य रूप से इसमें AJAX आधारित उपयोगकर्ता इंटरफेस होता है, जो वेब सिंडिकेशन, ब्लोग्स और विकीस का उपयोग करते हैं। जहां एक ओर वेब 2.0 के लिए कोई निर्धारित मानक नहीं हैं, यह मौजूदा वेब सर्वर आर्किटेक्चर और सेवाओं के उपयोग द्वारा निर्माण की विशेषता रखती है। इसलिए वेब 2.0 भी कुछ SOA विशेषताओं को प्रदर्शित करता है एसा कहा जा सकता है।[27][28][29]

कुछ टिप्पणीकार [कौन?] मेशप (mashups) को वेब 2.0 अनुप्रयोग मानते हैं। "बिजनेस मेशप" शब्दप्रयोग को एसे वेब अनुप्रयोगों के वर्णन के लिए बनाया[किसके द्वारा?] गया था, जो एक से अधिक स्रोतों से सामग्री को संयोजित करके, सर्विस ओरिएंटेड बिजनेस अनुप्रयोगों (SOBAs) के कई लक्षण रखनेवाले, एकीकृत उपयोगकर्ता अनुभव देते हैं। SOBAs एक कथात्मक तरीके से सेवाओं से बने अनुप्रयोग हैं। "वेब 2.0, मेशप और SOA के संघर्ष" के बारे में विवाद जारी है, जहां कुछ लोगों का कहना है कि वेब 2.0 अनुप्रयोग, SOA मिश्रण और बिजनेस अनुप्रयोगों का एक साकार रूप हैं।[30]

वेब 2.0

संपादित करें

वेब आधारित अनुप्रयोगों के कथित, शीघ्र विकसित होने वाले एक सेट का वर्णन करने के लिए टिम ओ'रेइल्ली ने "वेब 2.0" शब्दप्रयोग दिया[31]. 

व्यापक कवरेज का अनुभव करनेवाले एक विषय में, वेब 2.0 और सेवाभिमुख आर्किटेक्चर (SOAs) के बीच का सम्बन्ध शामिल है। SOA को समान रूप से परिभाषित इंटरफेस के साथ सेवाओं में अनुप्रयोगों से युक्त एक दर्शन माना जाता[किसके द्वारा?] है और इसे खोज क्रियाविधि के माध्यम से सार्वजनिक रूप से उपलब्ध कराया जाता है। 
जटिलता को छुपाना और पुनरुपयोग का मुद्दा और साथ ही ढीले संयोजन सेवा की अवधारणा ने शोधकर्ताओं को दो दर्शनों, SOA और वेब 2.0, के बीच समानता पर और उनके सम्बंधित अनुप्रयोगों पर विस्तृत विचार करने के लिए प्रेरित किया। कुछ लोगो का कहना है कि वेब 2.0 और SOA बहुत भिन्न तत्त्व हैं और इस प्रकार से उन्हें "समान्तर दर्शन" नहीं कहा जा सकता है, जबकि अन्य लोगों का मानना है कि दोनों अवधारणाएं संपूरक है और वेब 2.0, SOA का वैश्विक रूप है[28].

वेब 2.0 और SOA के दर्शन उपयोगकर्ता की भिन्न आवश्यकताओं को सेवा प्रदान करते हैं और इस प्रकार से वास्तविक दुनिया के अनुप्रयोगों में प्रयुक्त तकनीकों और डिजाइन के सन्दर्भ में अंतर को स्पष्ट करते हैं। हालांकि, 2008 के अनुसार  उपयोग-मामलों ने वेब 2.0 और SOA, दोनों के सिद्धांत और तकनीकों को संयोजित करने की संभावना का प्रदर्शित की है।[28]

एक "सेवाओं के इंटरनेट" में, सभी लोग, मशीनें और सामान, कल के (भविष्य के) नेटवर्क ढांचे के माध्यम से पहुंच पाएंगे.[उद्धरण चाहिए] इस प्रकार से इंटरनेट जीवन और व्यापार के सभी क्षेत्रों के लिए सेवाएं पेश करेगा, जैसे आभासी बीमा, ऑनलाइन बैंकिंग और संगीत और बहुत कुछ. इन सेवाओं को एक जटिल सेवा ढांचे की आवश्यकता रहेगी, जिसमें मांग और आपूर्ति को एक साथ लानेवाले सेवा वितरण मंच भी शामिल है। सेवाओं के इंटरनेट की निर्माणात्मक इकाइयों में शामिल हैं SOA, वेब 2.0 और प्रौद्योगिकी की ओर का अर्थविज्ञान; साथ ही नवीन व्यापारिक मॉडल और प्रणालीबद्ध एवं समुदाय आधारित नवाचार के प्रति दृष्टिकोण भी शामिल है।[32]

हालांकि ओरेकल इंगित करता है[उद्धरण चाहिए] कि गार्टनर एक नया शब्द दे रहे हैं, गार्टनर विश्लेषकों ने संकेत दिया है कि वे इसे विकसित SOA कहते है और इसे "SOA 2.0" नाम दिया जाएगा.[33] अधिकांश प्रमुख मध्यम विक्रेता (जैसे रेड हेट (Red Hat), वेबमेथड्स (webMethods), TIBCO सोफ्टवेयर, IBM, सन माइक्रोसिस्टम और ओरेकल) के पास वर्षों से SOA 2.0 गुणधर्मों के कुछ रूप रहे हैं।[उद्धरण चाहिए]

डिजिटल तंत्रिका तंत्र (Digital Nervous System)

संपादित करें

SOA कार्यान्वयन को डिजिटल तंत्रिका तंत्र[34][35] या जीरो लेटेंसी एन्टरप्राइज़[36] के रूप में ज्ञात विशाल दृष्टिकोण के प्रतिनिधित्व के रूप में वर्णित किया गया है।

इन्हें भी देखें

संपादित करें

बाहरी कड़ियाँ

संपादित करें

सन्दर्भ

संपादित करें
  1. ↑ अ आ Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. पपृ॰ 3. आई॰ऍस॰बी॰ऍन॰ 978-0-470-14111-3.
  2. ↑ "संग्रहीत प्रति". मूल से 20 जनवरी 2018 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  3. ↑ विशेष रूप से प्रारम्भिक तैनाती के बाद, एक वैकल्पिक दृश्य, बताता है कि SOAs ठीक से लागू करने के लिए भौतिक कार्यान्वयन जरूरी है, इसलिए उसकी औपचारिक परिभाषा में "नेटवर्क" शामिल नहीं होना चाहिए. उच्च निष्पादन SOAs, व्यावहारिक नहीं होंगे, खास कर अगर नेटवर्क पर वितरित नोड से तैनात किए जाएंगे. तमाम (या अधिकांश) सेवाओं के लिए अलग नोड्स अत्यंत महंगे हो सकते हैं।
  4. ↑ चन्नाबसवयाह, होली और टुगल, सेवाभिमुख आर्किटेक्चर की और स्थानान्तरण Archived 2008-12-09 at the वेबैक मशीन, IBM डैवलपरवर्क्स, 16 दिसम्बर 2003
  5. ↑ य्वोन्ने बाल्ज़र आपके SOA प्रोजेक्ट प्लान में सुधारीए Archived 2008-12-09 at the वेबैक मशीन, IBM 16 जुलाई 2004
  6. ↑ अ आ थॉमस अर्ल Serviceorientation.org – सिद्धांतो के बारे में Archived 2007-05-02 at the वेबैक मशीन, 2005-2006
  7. ↑ "SOA प्रेक्टिशनर्स गाइड भाग 2: SOA सन्दर्भ आर्किटेक्चर" (PDF). मूल (PDF) से 23 दिसंबर 2011 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  8. ↑ एंटरप्राइस SOA. प्रेन्टिस हॉल, 2005
  9. ↑ Cardoso, Jorge (2006). "Foreword". Semantic Web Services, Processes and Applications. SEMANTIC WEB AND BEYOND: Computing for Human Experience. Foreword by Frank Leymann. स्प्रिंगर. xxi. आई॰ऍस॰बी॰ऍन॰ 978-0-387-30239-3. The corresponding architectural style is called "service-oriented architecture": fundamentally, it describes how service consumers and service providers can be decoupled via discovery mechanisms resulting in loosely coupled systems. Implementing a service-oriented architecture means to deal with heterogeneity and interoperability concerns. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)
  10. ↑ "SOA सन्दर्भ मॉडल परिभाषा". मूल से 27 अक्तूबर 2017 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  11. ↑ "SOA - दस्तावेज़ - दस्तावेज़ विवरण". मूल से 11 फ़रवरी 2012 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  12. ↑ क्रिस्टोफर कोच एन्टरप्राइज़ के लिए एक नया ब्लू प्रिंट Archived 2009-01-16 at the वेबैक मशीन CIO पत्रिका, 1 मार्च 2005
  13. ↑ बीबरस्तेईन et al., सेवाभिमुख आर्किटेक्चर (SOA) कम्पास: बिजनेस वेल्यु, प्लानिंग और एन्टरप्राइज़ रोड मेप, (द डेवलपरवर्क्स श्रृंखला) (हार्ड कवर), IBM प्रेस बुक्स, 2005, 978-0131870024
  14. ↑ मार्टिन वैन डेन बर्ग et al. SOA फोर प्रोफिट, ए मेनेजर्स गाइड टु सक्सेस विथ सर्विस ओरिएंटेड आर्किटेक्चर (हार्ड कवर)
  15. ↑ https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=7854-oss_service_activation-1.0-fr-spec-oth-JSpec@CDS-CDS_Developer Archived 2011-07-26 at the वेबैक मशीन — JSR-89 Spec download
  16. ↑ "व्यापार प्रेरण मॉडल (BBM) से SOA तक. ऑब्जेक्ट टेक्नोलोजी की जर्नल -नवम्बर/दिसंबर 2008". मूल से 19 जून 2017 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  17. ↑ "WS-I बेसिक प्रोफाइल". मूल से 9 जुलाई 2017 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  18. ↑ इस धेर रीअल बिजनेस वेल्यू बिहाईन्ड द हाइप ऑफ SOA? Archived 2009-01-16 at the वेबैक मशीन, कम्प्यूटरवर्ल्ड, जून,19 जून 2006.
  19. ↑ यह भी देखें: WS मेटाडेटाएक्सचेंज OWL-S
  20. ↑ "द ओवरलेपिंग वर्ल्ड्स ऑफ SaaS एन्ड SOA". मूल से 30 जून 2017 को पुरालेखित. अभिगमन तिथि 15 जून 2020.
  21. ↑ टीम ब्रेय, XML सह-संस्थापक – http://blogs.zdnet.com/service-oriented/?p=597 Archived 2009-01-24 at the वेबैक मशीन
  22. ↑ "VTD-XML के साथ सूचकांक XML दस्तावेज". मूल से 4 जुलाई 2008 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  23. ↑ "बाइनरी XML की प्रदर्शन हाय". मूल से 9 जनवरी 2020 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  24. ↑ "मल्टीपल XML कन्टेन्ट द Ximple वे". मूल से 30 जुलाई 2017 को पुरालेखित. अभिगमन तिथि 9 अप्रैल 2010.
  25. ↑ "The Reason SOA Isn't Delivering Sustainable Software". jpmorgenthal.com. 19 जून 2009. मूल से 7 जुलाई 2009 को पुरालेखित. अभिगमन तिथि 27 जून 2009. |date= में तिथि प्राचल का मान जाँचें (मदद)
  26. ↑ "SOA services still too constrained by applications they represent". zdnet.com. 27 जून 2009. मूल से 2 जुलाई 2009 को पुरालेखित. अभिगमन तिथि 27 जून 2009. |date= में तिथि प्राचल का मान जाँचें (मदद)
  27. ↑ डायोन हिन्चक्लिफ इज वेब 2.0 द ग्लोबल SOA? Archived 2016-08-07 at the वेबैक मशीन, SOA वेब सर्विसिस जर्नल, 28 अक्टूबर 2005
  28. ↑ अ आ इ Schroth, Christoph ; Janner, Till; (2007). "Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services". IT Professional 9 (2007), Nr. 3, p. 36-41, IEEE Computer Society. अभिगमन तिथि: Archived 2013-12-03 at the वेबैक मशीन
  29. ↑ Hoyer, Volker ; Stanoesvka-Slabeva, Katarina; Janner, Till; Schroth, Christoph; (2008). "Enterprise Mashups: Design Principles towards the Long Tail of User Need". Proceedings of the 2008 IEEE International Conference on Services Computing (SCC 2008). अभिगमन तिथि: Archived 2013-06-12 at the वेबैक मशीन
  30. ↑ जेसन ब्लूमबर्ग मेशप्स (Mashups) एन्ड SOBAs: विच इज द टैल एन्ड विच इज द डॉग? Archived 2008-09-22 at the वेबैक मशीन, झेपथिन्क
  31. ↑ "What Is Web 2.0". Tim O'Reilly. 30 सितंबर 2005. मूल से 15 अप्रैल 2013 को पुरालेखित. अभिगमन तिथि 10 जून 2008.
  32. ↑ Ruggaber, Rainer; (2007). "Internet of Services—A SAP Research Vision". IEEE Computer Society. अभिगमन तिथि:
  33. ↑ येफिस नातिस और रॉय स्चुल्टे एडवान्स SOA फोर एडवान्स्ड एंटरप्राइज़ प्रोजेक्ट्स Archived 2013-11-04 at the वेबैक मशीन, गार्टनर, जुलाई 3, 2006
  34. ↑ "From Web to Boarding Area: Delta's SOA is Ready". मूल से 22 जनवरी 2009 को पुरालेखित. अभिगमन तिथि 2 मई 2009.
  35. ↑ "The Value of An Enterprise Architecture". मूल से 9 मार्च 2016 को पुरालेखित. अभिगमन तिथि 2 मई 2009.
  36. ↑ "Moving Toward the Zero Latency Enterprise". मूल से 19 जुलाई 2009 को पुरालेखित. अभिगमन तिथि 2 मई 2009.

साँचा:Software Engineering

"https://hi.wikipedia.org/w/index.php?title=सेवाभिमुख_आर्किटेक्चर_(Service-oriented_architecture)&oldid=6289524" से प्राप्त