Listen to this article

सेवा उन्मुख संरचना

From Vigyanwiki
Revision as of 15:01, 7 May 2023 by alpha>Indicwiki (Created page with "{{short description|Architectural pattern in software design}} {{Use mdy dates|date=April 2015}} सॉफ्टवेयर इंजीनियरिंग में,...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

SOA की कई परिभाषाओं में से एक के अनुसार एक सेवा में चार गुण होते हैं:[3]

  1. यह तार्किक रूप से एक निर्दिष्ट परिणाम के साथ दोहराने योग्य व्यावसायिक गतिविधि का प्रतिनिधित्व करता है।
  2. यह स्वयंभू है।
  3. यह अपने उपभोक्ताओं के लिए एक ब्लैक बॉक्स है, जिसका अर्थ है कि उपभोक्ता को सेवा के आंतरिक कामकाज के बारे में पता नहीं होना चाहिए।
  4. यह अन्य सेवाओं से बना हो सकता है।[4]

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

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

सिंहावलोकन

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


अवधारणाओं को परिभाषित करना

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

अक्टूबर, 2009 में सेवा-उन्मुख वास्तुकला के लिए एक घोषणापत्र प्रकाशित किया गया था। यह छह मूल मूल्यों के साथ आया था जो इस प्रकार सूचीबद्ध हैं: रेफरी>"SOA मेनिफेस्ट". www.soa-manifesto.org. Archived from the original on July 25, 2017. Retrieved September 21, 2016.</ref>

  1. तकनीकी रणनीति की तुलना में व्यावसायिक मूल्य को अधिक महत्व दिया जाता है।
  2. परियोजना-विशिष्ट लाभों की तुलना में रणनीतिक लक्ष्यों को अधिक महत्व दिया जाता है।
  3. कस्टम इंटीग्रेशन की तुलना में इंट्रिंसिक इंटरऑपरेबिलिटी को ज्यादा महत्व दिया जाता है।
  4. विशिष्ट-उद्देश्य कार्यान्वयन की तुलना में साझा सेवाओं को अधिक महत्व दिया जाता है।
  5. अनुकूलन से अधिक लचीलेपन को महत्व दिया जाता है।
  6. प्रारंभिक पूर्णता की खोज की तुलना में विकासवादी शोधन को अधिक महत्व दिया जाता है।

SOA को निरंतरता के भाग के रूप में देखा जा सकता है जो वितरित कंप्यूटिंग की पुरानी अवधारणा से लेकर है[7][9] और मॉड्यूलर प्रोग्रामिंग, SOA के माध्यम से, और मैशअप (वेब ​​एप्लिकेशन हाइब्रिड), SaaS, और क्लाउड कम्प्यूटिंग (जो कुछ SOA की संतान के रूप में देखते हैं) की प्रथाओं पर।[10]


सिद्धांत

सेवा-उन्मुख वास्तुकला की सटीक संरचना से संबंधित कोई उद्योग मानक नहीं हैं, हालांकि कई उद्योग स्रोतों ने अपने सिद्धांतों को प्रकाशित किया है। इनमें से कुछ[11][12][13] निम्नलिखित को शामिल कीजिए:

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

पैटर्न

प्रत्येक SOA बिल्डिंग ब्लॉक तीन में से कोई भी भूमिका निभा सकता है:

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

सेवा उपभोक्ता-प्रदाता संबंध एक मानकीकृत सेवा अनुबंध द्वारा नियंत्रित होता है,[17] जिसमें एक व्यावसायिक भाग, एक कार्यात्मक भाग और एक तकनीकी भाग होता है।

सेवा संरचना सिद्धांत में दो व्यापक, उच्च-स्तरीय स्थापत्य शैली हैं: सेवा कोरियोग्राफी # सेवा कोरियोग्राफी और सेवा ऑर्केस्ट्रेशन। निचले स्तर के उद्यम एकीकरण पैटर्न जो किसी विशेष वास्तुशिल्प शैली से बंधे नहीं हैं, SOA डिजाइन में प्रासंगिक और योग्य बने रहेंगे।[18][19][20]


कार्यान्वयन दृष्टिकोण

सेवा-उन्मुख वास्तुकला को वेब सेवाओं या माइक्रोसर्विसेज के साथ लागू किया जा सकता है।[21] यह कार्यात्मक बिल्डिंग-ब्लॉक्स को मानक इंटरनेट प्रोटोकॉल पर सुलभ बनाने के लिए किया जाता है जो प्लेटफॉर्म और प्रोग्रामिंग भाषाओं से स्वतंत्र हैं। ये सेवाएं या तो नए अनुप्रयोगों का प्रतिनिधित्व कर सकती हैं या उन्हें नेटवर्क-सक्षम बनाने के लिए मौजूदा लीगेसी सिस्टम के चारों ओर केवल आवरण।[22] कार्यान्वयनकर्ता आमतौर पर वेब सेवा मानकों का उपयोग करके SOAs का निर्माण करते हैं। एक उदाहरण SOAP है, जिसने W3C के संस्करण 1.2 की सिफारिश के बाद व्यापक उद्योग स्वीकृति प्राप्त की है[23] (वर्ल्ड वाइड वेब कंसोर्टियम) 2003 में। ये मानक (वेब ​​सेवा विनिर्देशों की सूची के रूप में भी संदर्भित) अधिक अंतर-क्षमता और लॉक-इन से मालिकाना विक्रेता सॉफ़्टवेयर के लिए कुछ सुरक्षा प्रदान करते हैं। हालाँकि, कोई अन्य सेवा-आधारित तकनीक, जैसे खून , कोरबा, इंटरनेट कम्युनिकेशंस इंजन, [[प्रतिनिधित्ववादी स्थिति में स्थानांतरण]] या जीआरपीसी का उपयोग करके भी SOA को लागू कर सकता है।

आर्किटेक्चर विशिष्ट तकनीकों से स्वतंत्र रूप से काम कर सकते हैं और इसलिए तकनीकों की एक विस्तृत श्रृंखला का उपयोग करके कार्यान्वित किया जा सकता है, जिनमें निम्न शामिल हैं:

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

ये सेवाएं एक औपचारिक परिभाषा (या अनुबंध, उदाहरण के लिए, डब्लूएसडीएल) के आधार पर अंतर-संचालित करती हैं जो अंतर्निहित प्लेटफॉर्म और प्रोग्रामिंग भाषा से स्वतंत्र है। इंटरफ़ेस परिभाषा भाषा-विशिष्ट सेवा की जानकारी छिपाना। इसलिए SOA-आधारित प्रणालियाँ विकास तकनीकों और प्लेटफार्मों (जैसे Java, .NET, आदि) से स्वतंत्र रूप से कार्य कर सकती हैं। .NET प्लेटफॉर्म पर चलने वाली C# में लिखी गई सेवाएं और जावा प्लेटफॉर्म, एंटरप्राइज एडिशन प्लेटफॉर्म पर चलने वाली जावा में लिखी गई सेवाएं, उदाहरण के लिए, दोनों को एक सामान्य समग्र एप्लिकेशन (या क्लाइंट) द्वारा उपभोग किया जा सकता है। किसी भी प्लेटफ़ॉर्म पर चलने वाले एप्लिकेशन दूसरे पर चलने वाली सेवाओं का उपयोग वेब सेवाओं के रूप में भी कर सकते हैं जो पुन: उपयोग की सुविधा प्रदान करती हैं। प्रबंधित परिवेश COBOL लीगेसी सिस्टम को भी लपेट सकते हैं और उन्हें सॉफ़्टवेयर सेवाओं के रूप में प्रस्तुत कर सकते हैं।.[24] बीपीईएल जैसी उच्च-स्तरीय प्रोग्रामिंग भाषाएं और डब्ल्यूएस-सीडीएल और डब्लूएस-समन्वय जैसे विनिर्देश सेवा अवधारणा का विस्तार करते हैं, जो ठीक-दाने वाली सेवाओं के ऑर्केस्ट्रेशन को अधिक मोटे अनाज वाली व्यावसायिक सेवाओं में परिभाषित करने और समर्थन करने की एक विधि प्रदान करते हैं, जो आर्किटेक्ट बदले में कर सकते हैं। समग्र अनुप्रयोगों या उद्यम पोर्टल में कार्यान्वित वर्कफ़्लोज़ और व्यावसायिक प्रक्रियाओं में शामिल करें।

सेवा-उन्मुख मॉडलिंग एक SOA ढांचा है जो विभिन्न विषयों की पहचान करता है जो SOA चिकित्सकों को उनकी सेवा-उन्मुख संपत्ति की अवधारणा, विश्लेषण, डिजाइन और वास्तुकार करने के लिए मार्गदर्शन करता है। सेवा उन्मुख मॉडलिंग #सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क|सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क (SOMF) एक मॉडलिंग भाषा और एक कार्य संरचना या नक्शा प्रदान करता है जो एक सफल सेवा-उन्मुख मॉडलिंग दृष्टिकोण में योगदान करने वाले विभिन्न घटकों को दर्शाता है। यह उन प्रमुख तत्वों को दिखाता है जो सेवा विकास योजना के क्या करें पहलुओं की पहचान करते हैं। मॉडल चिकित्सकों को एक परियोजना योजना तैयार करने में सक्षम बनाता है and to identify the milestones of a service-oriented initiative. SOMF also provides a common modeling notation to address alignment between business and IT organizations.

डर्क क्रैफज़िग, कार्ल बांके और डर्क स्लैमा द्वारा SOA के तत्व[25]
SOA मेटा-मॉडल, द लिंथिकम ग्रुप, 2007

संगठनात्मक लाभ

कुछ उद्यम वास्तुकारों का मानना ​​है कि SOA व्यवसायों को बाजार की स्थितियों को बदलने के लिए अधिक तेज़ी से और अधिक लागत प्रभावी ढंग से प्रतिक्रिया करने में मदद कर सकता है।[26] वास्तुकला की यह शैली सूक्ष्म (कक्षाओं) स्तर के बजाय मैक्रो (सेवा) स्तर पर पुन: उपयोग को बढ़ावा देती है। यह मौजूदा आईटी (विरासत) संपत्तियों के साथ-और उनके उपयोग को भी आसान बना सकता है।

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

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

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

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

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

किसी सेवा को उस स्तर तक प्रलेखित करने में सहायता के लिए उदाहरण उपयोगी साबित हो सकते हैं जहां वह उपयोगी हो जाती है। जावा कम्युनिटी प्रोसेस के भीतर कुछ एपीआई के दस्तावेज अच्छे उदाहरण प्रदान करते हैं। चूंकि ये संपूर्ण हैं, कर्मचारी आम तौर पर केवल महत्वपूर्ण उपसमुच्चय का उपयोग करेंगे। Java Platform, Standard Edition|JSR-89 के भीतर 'ossjsa.pdf' फ़ाइल ऐसी फ़ाइल का उदाहरण है।[29]


आलोचना

SOA को वेब सेवाओं के साथ मिला दिया गया है;[30] हालाँकि, SOA शैली को शामिल करने वाले पैटर्न को लागू करने के लिए वेब सेवाएँ केवल एक विकल्प हैं। दूरस्थ प्रक्रिया कॉल (RPC) के देशी या बाइनरी रूपों की अनुपस्थिति में, अनुप्रयोग अधिक धीमी गति से चल सकते हैं और अधिक प्रसंस्करण शक्ति की आवश्यकता होती है, बढ़ती लागत। अधिकांश कार्यान्वयन इन ओवरहेड्स को लागू करते हैं, लेकिन SOA को प्रौद्योगिकियों (उदाहरण के लिए, जावा बिजनेस इंटीग्रेशन (JBI), विंडोज कम्युनिकेशन फाउंडेशन (WCF) और डेटा वितरण सेवा (DDS)) का उपयोग करके लागू किया जा सकता है, जो दूरस्थ प्रक्रिया कॉल या अनुवाद पर निर्भर नहीं होते हैं। एक्सएमएल या जेएसओएन। इसी समय, उभरती ओपन-सोर्स एक्सएमएल पार्सिंग टेक्नोलॉजीज (जैसे वीटीडी-एचएमएल ) और विभिन्न एक्सएमएल-संगत बाइनरी प्रारूपों ने एसओए प्रदर्शन में काफी सुधार करने का वादा किया है।[31][32][33] स्टेटफुल सेवाओं के लिए उपभोक्ता और प्रदाता दोनों को समान उपभोक्ता-विशिष्ट संदर्भ साझा करने की आवश्यकता होती है, जो या तो प्रदाता और उपभोक्ता के बीच आदान-प्रदान संदेशों में शामिल या संदर्भित होता है। इस बाधा में यह कमी है कि यदि सेवा प्रदाता को प्रत्येक उपभोक्ता के लिए साझा संदर्भ बनाए रखने की आवश्यकता होती है तो यह सेवा प्रदाता की समग्र मापनीयता को कम कर सकता है। यह एक सेवा प्रदाता और एक उपभोक्ता के बीच युग्मन को भी बढ़ाता है और सेवा प्रदाताओं को बदलने को और अधिक कठिन बना देता है।[34] अंतत:, कुछ आलोचकों का मानना ​​है कि SOA सेवाएं अभी भी उन अनुप्रयोगों द्वारा सीमित हैं जिनका वे प्रतिनिधित्व करते हैं।[35] सेवा-उन्मुख वास्तुकला द्वारा सामना की जाने वाली प्राथमिक चुनौती मेटाडेटा का प्रबंधन है। SOA पर आधारित वातावरण में कई सेवाएँ शामिल हैं जो कार्य करने के लिए एक दूसरे के बीच संचार करती हैं। इस तथ्य के कारण कि डिज़ाइन में संयोजन में काम करने वाली कई सेवाएँ शामिल हो सकती हैं, एक एप्लिकेशन लाखों संदेश उत्पन्न कर सकता है। आगे की सेवाएं विभिन्न संगठनों या यहां तक ​​कि प्रतिस्पर्धी फर्मों से संबंधित हो सकती हैं जो एक विशाल भरोसे का मुद्दा बना रही हैं। इस प्रकार SOA शासन चीजों की योजना में आता है।[36] SOA द्वारा सामना की जाने वाली एक और बड़ी समस्या एक समान परीक्षण ढांचे की कमी है। ऐसे कोई उपकरण नहीं हैं जो सेवा-उन्मुख वास्तुकला में इन सेवाओं के परीक्षण के लिए आवश्यक सुविधाएँ प्रदान करते हों। कठिनाई के प्रमुख कारण हैं:[37]

  • विषमता और समाधान की जटिलता।
  • स्वायत्त सेवाओं के एकीकरण के कारण परीक्षण संयोजनों का विशाल समूह।
  • विभिन्न और प्रतिस्पर्धी विक्रेताओं से सेवाओं का समावेश।
  • नई सुविधाओं और सेवाओं की उपलब्धता के कारण एक सेवा के रूप में प्लेटफॉर्म लगातार बदल रहा है।

एक्सटेंशन और वेरिएंट

घटना-संचालित वास्तुकला

Main article: Event-driven architecture

एप्लिकेशन प्रोग्रामिंग इंटरफेस

Main article: Application programming interfaces

एप्लिकेशन प्रोग्रामिंग इंटरफेस (एपीआई) ऐसे ढांचे हैं जिनके माध्यम से डेवलपर्स वेब एप्लिकेशन के साथ बातचीत कर सकते हैं।

वेब 2.0

टिम ओ'रेली ने वेब 2.0 शब्द को वेब-आधारित अनुप्रयोगों के कथित, तेजी से बढ़ते सेट का वर्णन करने के लिए गढ़ा।[38] एक विषय जिसने व्यापक कवरेज का अनुभव किया है, उसमें वेब 2.0 और सेवा-उन्मुख आर्किटेक्चर के बीच संबंध शामिल है।[which?]

SOA समान रूप से परिभाषित इंटरफेस के साथ सेवाओं में एप्लिकेशन लॉजिक को एनकैप्सुलेट करने और डिस्कवरी मैकेनिज्म के माध्यम से इन्हें सार्वजनिक रूप से उपलब्ध कराने का दर्शन है। जटिलता-छिपाने और पुन: उपयोग की धारणा, लेकिन शिथिल युग्मन सेवाओं की अवधारणा ने भी शोधकर्ताओं को दो दर्शन, SOA और वेब 2.0, और उनके संबंधित अनुप्रयोगों के बीच समानता पर विस्तार करने के लिए प्रेरित किया है। कुछ लोगों का तर्क है कि वेब 2.0 और SOA में महत्वपूर्ण रूप से भिन्न तत्व हैं और इस प्रकार समानांतर दर्शन नहीं माना जा सकता है, जबकि अन्य दो अवधारणाओं को पूरक मानते हैं और वेब 2.0 को वैश्विक SOA मानते हैं।[39] वेब 2.0 और SOA के दर्शन अलग-अलग उपयोगकर्ता की जरूरतों को पूरा करते हैं और इस प्रकार डिजाइन और वास्तविक दुनिया के अनुप्रयोगों में उपयोग की जाने वाली तकनीकों के संबंध में मतभेदों को उजागर करते हैं। हालाँकि, as of 2008, उपयोग-मामलों ने वेब 2.0 और SOA दोनों की तकनीकों और सिद्धांतों के संयोजन की क्षमता का प्रदर्शन किया।[39]


माइक्रोसर्विसेज

Main article: Microservices

माइक्रोसर्विसेज वितरित कंप्यूटिंग के निर्माण के लिए उपयोग की जाने वाली सेवा-उन्मुख वास्तुकला की एक आधुनिक व्याख्या है। माइक्रोसर्विस आर्किटेक्चर में सेवाएं[40] प्रक्रिया (कंप्यूटिंग) हैं जो एक लक्ष्य को पूरा करने के लिए संगणक संजाल पर एक दूसरे के साथ संवाद करती हैं। ये सेवाएं प्रौद्योगिकी अज्ञेय संचार प्रोटोकॉल का उपयोग करती हैं,[41] जो भाषा और ढांचों के चुनाव को समाहित करने में सहायता करते हैं, जिससे उनकी पसंद सेवा के लिए एक आंतरिक चिंता बन जाती है। माइक्रोसर्विसेज SOA के लिए एक नया अहसास और कार्यान्वयन दृष्टिकोण है, जो 2014 से (और DevOps की शुरुआत के बाद) लोकप्रिय हो गया है, और जो निरंतर तैनाती और अन्य चुस्त प्रथाओं पर भी जोर देता है।[42] माइक्रोसर्विसेज की कोई एक सामान्य रूप से स्वीकृत परिभाषा नहीं है। निम्नलिखित विशेषताओं और सिद्धांतों को साहित्य में पाया जा सकता है:

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

इंटरैक्टिव अनुप्रयोगों के लिए सेवा-उन्मुख आर्किटेक्चर

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


यह भी देखें

संदर्भ

  1. ↑ 1.0 1.1 "SOA Source Book - What Is SOA?". collaboration.opengroup.org. Retrieved March 30, 2021.
  2. ↑ "Chapter 1: Service Oriented Architecture (SOA)". msdn.microsoft.com. Archived from the original on July 7, 2017. Retrieved September 21, 2016.
  3. ↑ "सेवा-उन्मुख वास्तुकला मानक - द ओपन ग्रुप". www.opengroup.org.
  4. ↑ "What Is SOA?". www.opengroup.org. Archived from the original on August 19, 2016. Retrieved September 21, 2016.
  5. ↑ Velte, Anthony T. (2010). Cloud Computing: A Practical Approach. McGraw Hill. ISBN 978-0-07-162694-1.
  6. ↑ "एक सेवा-उन्मुख वास्तुकला की ओर पलायन, भाग 1". December 9, 2008. Archived from the original on December 9, 2008. Retrieved September 21, 2016.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  7. ↑ 7.0 7.1 Michael Bell (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. p. 3. ISBN 978-0-470-14111-3.
  8. ↑ Michael Bell (2010). सेवा-उन्मुख खोज और विश्लेषण के लिए SOA मॉडलिंग पैटर्न. Wiley & Sons. p. 390. ISBN 978-0-470-48197-4.
  9. ↑ Thomas Erl (June 2005). About the Principles. Serviceorientation.org
  10. ↑ "Application Platform Strategies Blog: SOA is Dead; Long Live Services". Apsblog.burtongroup.com. January 5, 2009. Archived from the original on January 15, 2009. Retrieved August 13, 2012.
  11. ↑ Yvonne Balzer Improve your SOA project plans, IBM, July 16, 2004
  12. ↑ Microsoft Windows Communication Foundation team (2012). "सेवा उन्मुख डिजाइन के सिद्धांत". msdn.microsoft.com. Retrieved September 3, 2012.
  13. ↑ Principles by Thomas Erl of SOA Systems Inc. eight specific service-orientation principles
  14. ↑ "4.4 Guidelines for Using Web Service Contract Technologies - Anatomy of a Web Service Contract". InformIT. June 11, 2021. Retrieved September 9, 2021.
  15. ↑ Tony Shan (2004). "Building a service-oriented e Banking platform". IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004. pp. 237–244. doi:10.1109/SCC.2004.1358011. ISBN 978-0-7695-2225-8. S2CID 13156128.2004
  16. ↑ Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014). "Exploring Cloud Service Brokering from an Interface Perspective". 2014 IEEE International Conference on Web Services. IEEE. pp. 329–336. doi:10.1109/ICWS.2014.55. ISBN 978-1-4799-5054-6. S2CID 17957063.
  17. ↑ Duan, Yucong (2012). "A Survey on Service Contract". 2012 13th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing. IEEE. pp. 805–810. doi:10.1109/SNPD.2012.22. ISBN 978-1-4673-2120-4. S2CID 1837914.
  18. ↑ Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf (2016). "उद्यम एकीकरण पैटर्न का एक दशक". IEEE Software. 33 (1): 13–19. doi:10.1109/MS.2016.11.{{cite journal}}: CS1 maint: multiple names: authors list (link)
  19. ↑ Rotem-Gal-Oz, Arnon (2012). एसओए पैटर्न. Manning Publications. ISBN 978-1933988269.
  20. ↑ Julisch, Klaus; Suter, Christophe; Woitalla, Thomas; Zimmermann, Olaf (2011). "Compliance by design – Bridging the chasm between auditors and IT architects" (PDF). Computers & Security. 30 (6–7): 410–426. CiteSeerX 10.1.1.390.3652. doi:10.1016/j.cose.2011.03.005.
  21. ↑ Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Web Services-Oriented Architecture in Production in the Finance Industry, Informatik-Spektrum 02/2004, Springer-Verlag, 2004
  22. ↑ "ववव.ीबम.कॉम". IBM. Retrieved September 10, 2016. {{cite web}}: Check |url= value (help)
  23. ↑ "SOAP Version 1.2 の公開について (W3C 勧告)" (in 日本語). W3.org. Retrieved August 13, 2012.
  24. ↑ Okishima, Haruhiru (2006). ". "कोबोल संपत्तियों का उपयोग करने वाले सिस्टम आर्किटेक्चर का केस स्टडी"" (PDF).
  25. ↑ Enterprise SOA. Prentice Hall, 2005
  26. ↑ Christopher Koch A New Blueprint For The Enterprise Archived January 16, 2009, at the Wayback Machine, CIO Magazine, March 1, 2005
  27. ↑ Elizabeth Millard (January 2005). "Building a Better Process". Computer User. Page 20.
  28. ↑ Brayan Zimmerli (November 11, 2009) Business Benefits of SOA, University of Applied Science of Northwestern Switzerland, School of Business
  29. ↑ JSR-000089 OSS Service Activation API Specification 1.0 Final Release. sun.com
  30. ↑ Joe McKendrick. "Bray: SOA too complex; 'just vendor BS'". ZDNet.
  31. ↑ Jimmy Zhang (February 20, 2008) "Index XML Documents with VTD-XML" Archived July 4, 2008, at the Wayback Machine. XML Journal.
  32. ↑ Jimmy Zhang (August 5, 2008) "i-Technology Viewpoint: The Performance Woe of Binary XML" Archived January 9, 2020, at the Wayback Machine. Microservices Journal.
  33. ↑ Jimmy Zhang (January 9, 2008) "Manipulate XML Content the Ximple Way" Archived July 30, 2017, at the Wayback Machine. devx.com.
  34. ↑ "कारण SOA स्थायी सॉफ़्टवेयर प्रदान नहीं कर रहा है". jpmorgenthal.com. June 19, 2009. Retrieved June 27, 2009.
  35. ↑ "SOA सेवाएं अभी भी उन अनुप्रयोगों द्वारा विवश हैं जिनका वे प्रतिनिधित्व करते हैं". zdnet.com. June 27, 2009. Retrieved June 27, 2009.
  36. ↑ "शासन परत". www.opengroup.org. Retrieved September 22, 2016.
  37. ↑ "How to Efficiently Test Service Oriented Architecture | WSO2 Inc". wso2.com. Retrieved September 22, 2016.
  38. ↑ "What Is Web 2.0". Tim O'Reilly. September 30, 2005. Retrieved June 10, 2008.
  39. ↑ 39.0 39.1 Christoph Schroth; Till Janner (2007). "Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services". IT Professional. 9 (3): 36–41. doi:10.1109/MITP.2007.60. S2CID 2859262. Retrieved February 23, 2008.
  40. ↑ Dragoni, Nicola; Giallorenzo, Saverio; Alberto Lluch Lafuente; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2016). "Microservices: yesterday, today, and tomorrow". arXiv:1606.04036v1 [cs.SE].
  41. ↑ James Lewis and Martin Fowler. "माइक्रोसर्विसेज".
  42. ↑ Balalaie, A.; Heydarnoori, A.; Jamshidi, P. (May 1, 2016). "Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture" (PDF). IEEE Software. 33 (3): 42–52. doi:10.1109/MS.2016.64. hdl:10044/1/40557. ISSN 0740-7459. S2CID 18802650.
  43. ↑ Frank Glinka; Allaithy Raed (2009). "अत्यधिक संवादात्मक वितरित अनुप्रयोगों के लिए एक सेवा-उन्मुख इंटरफ़ेस". European Conference on Parallel Processing. Lecture Notes in Computer Science. 6043: 266–277. doi:10.1007/978-3-642-14122-5_31. ISBN 978-3-642-14121-8. Retrieved February 9, 2021.
  44. ↑ Dieter Hildebrandt; Jan Klimke (2011). "Service-oriented interactive 3D visualization of massive 3D city models on thin clients". COM.Geo '11: Proceedings of the 2nd International Conference on Computing for Geospatial Research & Applications. COM.Geo '11: 1. doi:10.1145/1999320.1999326. ISBN 9781450306812. S2CID 53246415. Retrieved February 9, 2021.
  45. ↑ Mahy Aly; Michael Franke (2016). "सेवा उन्मुख इंटरएक्टिव मीडिया (SOIM) इंजन अनुकूलित संसाधन साझाकरण द्वारा सक्षम". 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE): 231–237. doi:10.1109/SOSE.2016.47. hdl:1854/LU-7215326. ISBN 978-1-5090-2253-3. S2CID 9511734. Retrieved February 9, 2021.
Wikimedia Commons has media related to [[commons:Category:सेवा उन्मुख संरचना|सेवा उन्मुख संरचना]].
Listen to this article (54 minutes)
Spoken Wikipedia icon
This audio file was created from a revision of this article dated 27 October 2011 (2011-10-27), and does not reflect subsequent edits.
(Audio help · More spoken articles)
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=सेवा_उन्मुख_संरचना&oldid=157772’