विहित प्रोटोकॉल पैटर्न: Difference between revisions

From Vigyanwiki
(Created page with "कैनोनिकल प्रोटोकॉल एक डिज़ाइन पैटर्न (कंप्यूटर विज्ञान) है, जिसे...")
 
No edit summary
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
कैनोनिकल प्रोटोकॉल एक [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)]] है, जिसे सेवा-उन्मुख [[डिज़ाइन प्रतिमान]] के भीतर लागू किया जाता है, जो एक सेवा सूची के भीतर [[सेवा (सिस्टम आर्किटेक्चर)]] बनाने का प्रयास करता है।<ref name='SI'>[http://www.whatissoa.com/p13.php Service Inventory] {{webarchive |url=https://web.archive.org/web/20100313072247/http://www.whatissoa.com/p13.php |date=March 13, 2010 }}</ref> सेवाओं द्वारा उपयोग किए जाने वाले [[संचार प्रोटोकॉल]] को मानकीकृत करके एक-दूसरे के साथ अंतरसंचालनीय। जब सेवाएँ विभिन्न संचार प्रोटोकॉल का उपयोग करती हैं तो यह संचार प्रोटोकॉल को पाटने की आवश्यकता को समाप्त कर देता है।<ref name='MD'>Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)] {{Webarchive|url=https://web.archive.org/web/20110724191904/http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 |date=2011-07-24 }}[Online].Date accessed: 25 April 2010.</ref>
विहित प्रोटोकॉल एक [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)|डिजाइन प्रतिरूप]] है जो सेवा-उन्मुख [[डिज़ाइन प्रतिमान|डिजाइन प्रतिरूप]] के अंदर लागू किया जाता है और जो प्रयास करता है कि सेवाओं को एक दूसरे के साथ संगत बनाया जा सके इसके द्वारा सेवाओं द्वारा उपयोग की जाने वाली संचार प्रोटोकॉलों को मानकीकृत किया जाता है। इससे सेवाओं को विभिन्न संचार प्रोटोकॉल का उपयोग करते हुए संचार के बीच युग्मक करने की आवश्यकता समाप्त हो  जाता है। इसका अर्थ है कि जब एक सेवा दूसरी सेवा के साथ संचार करना चाहती है, तो उसे दूसरे संचार प्रोटोकॉल पर अधिकृत होने की आवश्यकता नहीं होती है।


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


==तर्क==
एक सेवा सूची का डिज़ाइन करने के लिए, जहां सभी सेवाएं एक-दूसरे के साथ समन्वययोग्य हों जिससे वे विभिन्न समाधानों में सम्मिलित किए जा सकें, विहित प्रोटोकॉल प्रतिरूप के अनुपालन का अनुमान लगाता है कि सेवाओं द्वारा उपयोग किए जाने वाले संचार प्रोटोकॉलों को मानकीकृत करना आवश्यक होता है। जब सभी सेवाएं एक ही संचार प्रोटोकॉल का उपयोग करती हैं, तो संचार प्रोटोकॉलों के बीच सेवाओं के बीच संचार को सुगम बनाने के लिए सेतु प्रौद्योगिकी की आवश्यकता समाप्त हो जाता है और सेवाओं के बीच संचार सुगम होता है।।<ref name='SODI'>Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 30 April 2010. {{webarchive |url=https://web.archive.org/web/20100328211319/http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 |date=March 28, 2010 }}</ref>
विभिन्न परियोजना टीमों द्वारा विकसित सेवाएँ विभिन्न संचार तंत्रों पर आधारित हो सकती हैं। परिणामस्वरूप, एक सेवा सूची में सेवाओं के अलग-अलग सेट हो सकते हैं, जिनमें से प्रत्येक प्रोटोकॉल के एक अलग सेट के अनुरूप होता है। जब विभिन्न संचार प्रोटोकॉल वाली सेवाओं का पुन: उपयोग करने की बात आती है, तो किसी प्रकार के संचार ब्रिजिंग तंत्र की आवश्यकता होती है। उदाहरण के लिए, [[ जावा संदेश सेवा ]] मैसेजिंग प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ .NET रिमोटिंग का उपयोग करने वाली सेवाओं के साथ असंगत हैं, इसलिए इन दो प्रकार की सेवाओं का उपयोग करने के लिए, कुछ [[ मध्यस्थ ]] तकनीक की आवश्यकता होती है जो संचार प्रोटोकॉल असमानता को पाटती है। अतिरिक्त लागत के अलावा, ऐसी ब्रिजिंग तकनीक का उपयोग [[विलंबता (इंजीनियरिंग)]] और संचार ओवरहेड को जोड़ता है। यह सेवा को कम पुन: प्रयोज्य और पुन: प्रयोज्य बनाता है<ref name="SvcComposition">[http://www.whatissoa.com/p12.php Service Composition] {{webarchive |url=https://web.archive.org/web/20100311045214/http://www.whatissoa.com/p12.php |date=March 11, 2010 }}</ref> संसाधन और सेवा संयोजन सिद्धांत डिज़ाइन सिद्धांत के दिशानिर्देशों के विरुद्ध जाता है।
 
एक सेवा सूची को डिज़ाइन करने के लिए जहां सभी सेवाएं एक-दूसरे के साथ इंटरऑपरेबल होती हैं ताकि उन्हें अलग-अलग समाधानों में बनाया जा सके, कैनोनिकल प्रोटोकॉल पैटर्न का अनुप्रयोग सेवाओं द्वारा उपयोग किए जाने वाले संचार प्रोटोकॉल को मानकीकृत करने का निर्देश देता है। जब सभी सेवाएँ समान संचार प्रोटोकॉल का उपयोग कर रही हैं, तो ब्रिजिंग तकनीक की आवश्यकता समाप्त हो जाती है और सेवाओं के बीच संचार अधिक सुव्यवस्थित हो जाता है।<ref name='SODI'>Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 30 April 2010. {{webarchive |url=https://web.archive.org/web/20100328211319/http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 |date=March 28, 2010 }}</ref>




Line 11: Line 10:


[[File:SOA DP Canonical Protocol A.JPG|thumb|alt=Diagram A|आरेख A<br />विभिन्न संचार प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ एक-दूसरे से बात करने में असमर्थ हैं।]]
[[File:SOA DP Canonical Protocol A.JPG|thumb|alt=Diagram A|आरेख A<br />विभिन्न संचार प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ एक-दूसरे से बात करने में असमर्थ हैं।]]
[[File:SOA DP Canonical Protocol B.JPG|thumb|alt=Diagram B|आरेख बी<br />समान संचार प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ एक-दूसरे से बात करने में सक्षम हैं और इसलिए उनका उपयोग कई सेवा संरचनाओं में किया जा सकता है।]]इस डिज़ाइन पैटर्न के अनुप्रयोग के लिए एक प्रौद्योगिकी वास्तुकला को चुनने की आवश्यकता होती है जो एक सामान्य संचार ढांचा प्रदान करती है ताकि एक इन्वेंट्री में सभी सेवाएँ समान संचार प्रोटोकॉल का उपयोग करके एक दूसरे के साथ संचार कर सकें। यह इस बात पर निर्भर करता है कि सेवा सूची के भीतर सेवाओं का उपयोग कैसे किया जाएगा। यदि सेवाएँ केवल उन सेवा संरचनाओं का हिस्सा बनने जा रही हैं जो हमेशा एक विशेष संचार प्रोटोकॉल (दक्षता और सुरक्षा कारणों से) का उपयोग करती हैं, तो उस सेवा सूची के भीतर सभी सेवाएँ ऐसे संचार प्रोटोकॉल पर बनाई जा सकती हैं, भले ही वह न हो सबसे व्यापक रूप से उपयोग किया जाने वाला प्रोटोकॉल।
[[File:SOA DP Canonical Protocol B.JPG|thumb|alt=Diagram B|आरेख बी<br />समान संचार प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ एक-दूसरे से बात करने में सक्षम हैं और इसलिए उनका उपयोग कई सेवा संरचनाओं में किया जा सकता है।]]इस डिज़ाइन प्रतिरूप के अनुप्रयोग के लिए एक प्रौद्योगिकी वास्तुकला को चुनने की आवश्यकता होती है जो एक सामान्य संचार ढांचा प्रदान करती है जिससे एक सूची में सभी सेवाएँ समान संचार प्रोटोकॉल का उपयोग करके एक दूसरे के साथ संचार कर सकें। यह सेवा सूची के अंदर सेवाओं का उपयोग कैसे किया जाएगा, इस पर निर्भर करता है। यदि सेवाएं केवल उन सेवा संयोजनों का भाग होंगी जो सदैव किसी विशेष संचार प्रोटोकॉल का उपयोग करते हैं तो उस संचार प्रोटोकॉल पर आधारित सभी सेवाएं उस सेवा सूची में बना सकते हैं, यद्यपि वह सबसे व्यापक उपयोग होने वाले प्रोटोकॉल न हो।
 
[[थॉमस एर्ल]] द्वारा प्रस्तावित विहित प्रोटोकॉल प्रतिरूप सवाल का उत्तर देता है: "सेवाओं को प्रोटोकॉल युग्मक  से बचाने के लिए कैसे प्रारूपित किया जा सकता है? समस्या यह है कि विभिन्न संचार प्रौद्योगिकियों का समर्थन करने वाली सेवाएं संगतता को कम करती हैं, तथा संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं और अवांछनीय प्रोटोकॉल युग्मक  के लिए आवश्यकता उत्पन्न करती हैं। संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं, और अवांछनीय प्रोटोकॉल युग्मक उपायों की आवश्यकता का परिचय देती हैं। संरचना के लिए इसका समाधान एकल संचार प्रौद्योगिकी को एकमात्र या प्राथमिक माध्यम के रूप में स्थापित करना है जिसके द्वारा सेवाएं बातचीत कर सकती हैं। इसलिए, सेवा सूची सीमा के अंदर उपयोग किए जाने वाले संचार प्रोटोकॉल सभी सेवाओं के लिए मानकीकृत हैं ।


[[थॉमस एर्ल]] द्वारा कैनोनिकल प्रोटोकॉल पैटर्न इस प्रश्न का उत्तर देता है: प्रोटोकॉल ब्रिजिंग से बचने के लिए सेवाओं को कैसे डिज़ाइन किया जा सकता है?<ref name="SOA Patterns.org">[http://www.soapatterns.org/canonical_protocol.php SOA Patterns - Canonical Protocol] {{webarchive |url=https://web.archive.org/web/20091214071205/http://www.soapatterns.org/canonical_protocol.php |date=December 14, 2009 }}</ref> समस्या यह है कि विभिन्न संचार प्रौद्योगिकियों का समर्थन करने वाली सेवाएँ अंतरसंचालनीयता से समझौता करती हैं, संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं, और अवांछनीय प्रोटोकॉल ब्रिजिंग उपायों की आवश्यकता का परिचय देती हैं। आर्किटेक्चर के लिए इसका समाधान एकल संचार प्रौद्योगिकी को एकमात्र या प्राथमिक माध्यम के रूप में स्थापित करना है जिसके द्वारा सेवाएं बातचीत कर सकती हैं। इसलिए, सेवा सूची सीमा के भीतर उपयोग किए जाने वाले संचार प्रोटोकॉल (प्रोटोकॉल संस्करणों सहित) सभी सेवाओं के लिए मानकीकृत हैं (आरेख देखें)।
सबसे परिपक्व और व्यापक रूप से उपयोग किए जाने वाले संचार तंत्रों में से एक वेब सेवा ढांचे द्वारा प्रदान किया जाता है। संचार ढाँचे को चुनने के अलावा, वास्तविक संदेश प्रोटोकॉल को भी मानकीकृत करने की आवश्यकता है। उदाहरण के लिए, क्या वेब सेवाएँ एचटीटीपी पर एसओएपी का उपयोग करके बनाई गई हैं


सबसे परिपक्व और व्यापक रूप से उपयोग किए जाने वाले संचार तंत्रों में से एक वेब सेवा ढांचे द्वारा प्रदान किया जाता है। संचार ढाँचे को चुनने के अलावा, वास्तविक संदेश प्रोटोकॉल को भी मानकीकृत करने की आवश्यकता है। उदाहरण के लिए, क्या वेब सेवाएँ [[HTTP]] पर [[SOAP]] का उपयोग करके बनाई गई हैं या केवल [[RESTful]] सेवाओं का उपयोग करके बनाई गई हैं। इसी प्रकार, SOAP आधारित वेब सेवाओं पर मानकीकरण करते समय, SOAP प्रोटोकॉल के विशिष्ट संस्करण यानी SOAP v 1.1 या SOAP v 1.2 पर भी सहमति की आवश्यकता होती है।
इसी प्रकार, [[SOAP|एसओएपी]] आधारित वेब सेवाओं पर मानकीकरण करते समय, एसओएपी प्रोटोकॉल के विशिष्ट संस्करण अर्थात एसओएपी  v 1.1 या एसओएपी v 1.2 पर भी सहमति की आवश्यकता होती है।


==विचार==
==विचार==


संचार प्रोटोकॉल पर मानकीकरण करने के लिए, सुरक्षा, दक्षता और लेनदेन समर्थन सहित सेवा इंटरैक्शन आवश्यकताओं के साथ प्रोटोकॉल की विशेषताओं की तुलना करने की आवश्यकता है। उदाहरण के लिए, वेब सेवाओं के मामले में, यदि किसी सेवा संरचना को स्पष्ट लेनदेन समर्थन की आवश्यकता होती है, तो HTTP पर SOAP RESTful सेवाओं का उपयोग करने से बेहतर विकल्प होगा।
संचार प्रोटोकॉल को मानकीकृत करने के लिए, प्रोटोकॉल की विशेषताएं सेवा संवाद आवश्यकताओं के साथ, सुरक्षा, दक्षता और संचालन समर्थन सहित, तुलना की एचटीटीपी जानी चाहिए। उदाहरण के रूप में, यदि एक सेवा संयोजन ने प्रकट संचालन समर्थन की आवश्यकता है, तो एसओएपी सेवाओं का उपयोग करने के सापेक्ष में एक बेहतर विकल्प होगा।


कुछ मामलों में, सेवा बनाने के लिए उपयोग की जाने वाली तकनीक के आधार पर, विभिन्न प्रकार के सेवा उपभोक्ताओं के लिए सेवा को सुलभ बनाने के लिए प्रोटोकॉल के दो अलग-अलग सेट का समर्थन करना संभव हो सकता है (दोहरी प्रोटोकॉल डिजाइन पैटर्न)<ref name='DP'>[http://www.soapatterns.org/dual_protocols.php Dual Protocols design pattern] {{webarchive |url=https://web.archive.org/web/20091214065529/http://www.soapatterns.org/dual_protocols.php |date=December 14, 2009 }}</ref>). उदाहरण के लिए, [[ विंडोज़ कम्युनिकेशन फाउंडेशन ]] का उपयोग करके, एक ही सेवा को एक ही समय में HTTP और TCP/IP प्रोटोकॉल का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है।
कुछ विषयो में, सेवा सूची बनाने के लिए उपयोग की जाने वाली प्रौद्योगिकी पर निर्भर करता है, ऐसे विषयो  में सेवा को विभिन्न प्रोटोकॉल सेट का समर्थन करना संभव हो सकता है, जिससे यह सेवा विभिन्न प्रकार के सेवा उपभोक्ताओं के लिए पहुंच योग्य हो सके। उदाहरण के लिए,डब्ल्यूसीएफ का उपयोग करके, एक ही सेवा को एचटीटीपी और टीसीपी/आईपी प्रोटोकॉल का उपयोग करने के लिए समकालिक रूप से समनुरूप किया जा सकता है।


संचार ढाँचा चुनते समय, परिपक्वता, स्केलेबिलिटी और किसी भी लाइसेंसिंग लागत को ध्यान में रखा जाना चाहिए क्योंकि निकट भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं का निर्माण ऐसी सेवाओं की पुन: प्रयोज्यता को प्रभावित करेगा और इसके लिए काफी समय और प्रयासों की आवश्यकता होगी। सेवा को पुनः डिज़ाइन करने के लिए.
संचार फ़्रेमवर्क का चयन करते समय, परिपक्वता, स्केलेबिलिटी और कोई लाइसेंसिंग लागतें भी ध्यान में लेनी चाहिए, क्योंकि नजदीकी भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं को बनाने से, ऐसी सेवाओं की पुनर्गुणात्मकता प्रभावित होगी और सेवा को पुन: डिज़ाइन करने के लिए काफी समय और प्रयास की आवश्यकता होगी।


== संदर्भ ==
== संदर्भ ==
Line 36: Line 37:
* [http://www.soaglossary.com/ SOA Terms Glossary]
* [http://www.soaglossary.com/ SOA Terms Glossary]
* [http://www.soapatterns.org SOA Design Patterns]
* [http://www.soapatterns.org SOA Design Patterns]
[[Category: सेवा-उन्मुख (व्यावसायिक कंप्यूटिंग)]]


[[Category: Machine Translated Page]]
[[Category:Created On 26/06/2023]]
[[Category:Created On 26/06/2023]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Webarchive template wayback links]]
[[Category:सेवा-उन्मुख (व्यावसायिक कंप्यूटिंग)]]

Latest revision as of 08:23, 16 July 2023

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

तर्क

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

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


उपयोग

Diagram A
आरेख A
विभिन्न संचार प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ एक-दूसरे से बात करने में असमर्थ हैं।
Diagram B
आरेख बी
समान संचार प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ एक-दूसरे से बात करने में सक्षम हैं और इसलिए उनका उपयोग कई सेवा संरचनाओं में किया जा सकता है।

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

थॉमस एर्ल द्वारा प्रस्तावित विहित प्रोटोकॉल प्रतिरूप सवाल का उत्तर देता है: "सेवाओं को प्रोटोकॉल युग्मक से बचाने के लिए कैसे प्रारूपित किया जा सकता है? समस्या यह है कि विभिन्न संचार प्रौद्योगिकियों का समर्थन करने वाली सेवाएं संगतता को कम करती हैं, तथा संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं और अवांछनीय प्रोटोकॉल युग्मक के लिए आवश्यकता उत्पन्न करती हैं। संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं, और अवांछनीय प्रोटोकॉल युग्मक उपायों की आवश्यकता का परिचय देती हैं। संरचना के लिए इसका समाधान एकल संचार प्रौद्योगिकी को एकमात्र या प्राथमिक माध्यम के रूप में स्थापित करना है जिसके द्वारा सेवाएं बातचीत कर सकती हैं। इसलिए, सेवा सूची सीमा के अंदर उपयोग किए जाने वाले संचार प्रोटोकॉल सभी सेवाओं के लिए मानकीकृत हैं ।

सबसे परिपक्व और व्यापक रूप से उपयोग किए जाने वाले संचार तंत्रों में से एक वेब सेवा ढांचे द्वारा प्रदान किया जाता है। संचार ढाँचे को चुनने के अलावा, वास्तविक संदेश प्रोटोकॉल को भी मानकीकृत करने की आवश्यकता है। उदाहरण के लिए, क्या वेब सेवाएँ एचटीटीपी पर एसओएपी का उपयोग करके बनाई गई हैं

इसी प्रकार, एसओएपी आधारित वेब सेवाओं पर मानकीकरण करते समय, एसओएपी प्रोटोकॉल के विशिष्ट संस्करण अर्थात एसओएपी v 1.1 या एसओएपी v 1.2 पर भी सहमति की आवश्यकता होती है।

विचार

संचार प्रोटोकॉल को मानकीकृत करने के लिए, प्रोटोकॉल की विशेषताएं सेवा संवाद आवश्यकताओं के साथ, सुरक्षा, दक्षता और संचालन समर्थन सहित, तुलना की एचटीटीपी जानी चाहिए। उदाहरण के रूप में, यदि एक सेवा संयोजन ने प्रकट संचालन समर्थन की आवश्यकता है, तो एसओएपी सेवाओं का उपयोग करने के सापेक्ष में एक बेहतर विकल्प होगा।

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

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

संदर्भ

Notes
  1. ↑ Mauro. et al. Service Oriented Device Integration - An Analysis of SOA Design Patterns. [Online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 30 April 2010. Archived March 28, 2010, at the Wayback Machine
Sources
  • Thomas Erl et al., (2009).SOA Design Patterns. Prentice Hall. ISBN 978-0-13-613516-6.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=विहित_प्रोटोकॉल_पैटर्न&oldid=218718’