विहित प्रोटोकॉल पैटर्न: Difference between revisions
(→विचार) |
No edit summary |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
विहित प्रोटोकॉल एक [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)|डिजाइन प्रतिरूप]] है जो सेवा-उन्मुख [[डिज़ाइन प्रतिमान|डिजाइन प्रतिरूप]] के अंदर लागू किया जाता है और जो प्रयास करता है कि सेवाओं को एक दूसरे के साथ संगत बनाया जा सके इसके द्वारा सेवाओं द्वारा उपयोग की जाने वाली संचार प्रोटोकॉलों को मानकीकृत किया जाता है। इससे सेवाओं को विभिन्न संचार प्रोटोकॉल का उपयोग करते हुए संचार के बीच युग्मक करने की आवश्यकता समाप्त हो जाता है। इसका अर्थ है कि जब एक सेवा दूसरी सेवा के साथ संचार करना चाहती है, तो उसे दूसरे संचार प्रोटोकॉल पर अधिकृत होने की आवश्यकता नहीं होती है। | विहित प्रोटोकॉल एक [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)|डिजाइन प्रतिरूप]] है जो सेवा-उन्मुख [[डिज़ाइन प्रतिमान|डिजाइन प्रतिरूप]] के अंदर लागू किया जाता है और जो प्रयास करता है कि सेवाओं को एक दूसरे के साथ संगत बनाया जा सके इसके द्वारा सेवाओं द्वारा उपयोग की जाने वाली संचार प्रोटोकॉलों को मानकीकृत किया जाता है। इससे सेवाओं को विभिन्न संचार प्रोटोकॉल का उपयोग करते हुए संचार के बीच युग्मक करने की आवश्यकता समाप्त हो जाता है। इसका अर्थ है कि जब एक सेवा दूसरी सेवा के साथ संचार करना चाहती है, तो उसे दूसरे संचार प्रोटोकॉल पर अधिकृत होने की आवश्यकता नहीं होती है। | ||
| Line 39: | 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: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]
उपयोग
इस डिज़ाइन प्रतिरूप के अनुप्रयोग के लिए एक प्रौद्योगिकी वास्तुकला को चुनने की आवश्यकता होती है जो एक सामान्य संचार ढांचा प्रदान करती है जिससे एक सूची में सभी सेवाएँ समान संचार प्रोटोकॉल का उपयोग करके एक दूसरे के साथ संचार कर सकें। यह सेवा सूची के अंदर सेवाओं का उपयोग कैसे किया जाएगा, इस पर निर्भर करता है। यदि सेवाएं केवल उन सेवा संयोजनों का भाग होंगी जो सदैव किसी विशेष संचार प्रोटोकॉल का उपयोग करते हैं तो उस संचार प्रोटोकॉल पर आधारित सभी सेवाएं उस सेवा सूची में बना सकते हैं, यद्यपि वह सबसे व्यापक उपयोग होने वाले प्रोटोकॉल न हो।
थॉमस एर्ल द्वारा प्रस्तावित विहित प्रोटोकॉल प्रतिरूप सवाल का उत्तर देता है: "सेवाओं को प्रोटोकॉल युग्मक से बचाने के लिए कैसे प्रारूपित किया जा सकता है? समस्या यह है कि विभिन्न संचार प्रौद्योगिकियों का समर्थन करने वाली सेवाएं संगतता को कम करती हैं, तथा संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं और अवांछनीय प्रोटोकॉल युग्मक के लिए आवश्यकता उत्पन्न करती हैं। संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं, और अवांछनीय प्रोटोकॉल युग्मक उपायों की आवश्यकता का परिचय देती हैं। संरचना के लिए इसका समाधान एकल संचार प्रौद्योगिकी को एकमात्र या प्राथमिक माध्यम के रूप में स्थापित करना है जिसके द्वारा सेवाएं बातचीत कर सकती हैं। इसलिए, सेवा सूची सीमा के अंदर उपयोग किए जाने वाले संचार प्रोटोकॉल सभी सेवाओं के लिए मानकीकृत हैं ।
सबसे परिपक्व और व्यापक रूप से उपयोग किए जाने वाले संचार तंत्रों में से एक वेब सेवा ढांचे द्वारा प्रदान किया जाता है। संचार ढाँचे को चुनने के अलावा, वास्तविक संदेश प्रोटोकॉल को भी मानकीकृत करने की आवश्यकता है। उदाहरण के लिए, क्या वेब सेवाएँ एचटीटीपी पर एसओएपी का उपयोग करके बनाई गई हैं
इसी प्रकार, एसओएपी आधारित वेब सेवाओं पर मानकीकरण करते समय, एसओएपी प्रोटोकॉल के विशिष्ट संस्करण अर्थात एसओएपी v 1.1 या एसओएपी v 1.2 पर भी सहमति की आवश्यकता होती है।
विचार
संचार प्रोटोकॉल को मानकीकृत करने के लिए, प्रोटोकॉल की विशेषताएं सेवा संवाद आवश्यकताओं के साथ, सुरक्षा, दक्षता और संचालन समर्थन सहित, तुलना की एचटीटीपी जानी चाहिए। उदाहरण के रूप में, यदि एक सेवा संयोजन ने प्रकट संचालन समर्थन की आवश्यकता है, तो एसओएपी सेवाओं का उपयोग करने के सापेक्ष में एक बेहतर विकल्प होगा।
कुछ विषयो में, सेवा सूची बनाने के लिए उपयोग की जाने वाली प्रौद्योगिकी पर निर्भर करता है, ऐसे विषयो में सेवा को विभिन्न प्रोटोकॉल सेट का समर्थन करना संभव हो सकता है, जिससे यह सेवा विभिन्न प्रकार के सेवा उपभोक्ताओं के लिए पहुंच योग्य हो सके। उदाहरण के लिए,डब्ल्यूसीएफ का उपयोग करके, एक ही सेवा को एचटीटीपी और टीसीपी/आईपी प्रोटोकॉल का उपयोग करने के लिए समकालिक रूप से समनुरूप किया जा सकता है।
संचार फ़्रेमवर्क का चयन करते समय, परिपक्वता, स्केलेबिलिटी और कोई लाइसेंसिंग लागतें भी ध्यान में लेनी चाहिए, क्योंकि नजदीकी भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं को बनाने से, ऐसी सेवाओं की पुनर्गुणात्मकता प्रभावित होगी और सेवा को पुन: डिज़ाइन करने के लिए काफी समय और प्रयास की आवश्यकता होगी।
संदर्भ
- Notes
- ↑ 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.
