विहित प्रोटोकॉल पैटर्न: Difference between revisions
(→विचार) |
No edit summary |
||
| Line 1: | Line 1: | ||
विहित प्रोटोकॉल एक [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)|डिजाइन प्रतिरूप]] है जो सेवा-उन्मुख [[डिज़ाइन प्रतिमान|डिजाइन प्रतिरूप]] के अंदर लागू किया जाता है और जो प्रयास करता है कि सेवाओं को एक दूसरे के साथ संगत बनाया जा सके इसके द्वारा सेवाओं द्वारा उपयोग की जाने वाली संचार प्रोटोकॉलों को मानकीकृत किया जाता है। इससे सेवाओं को विभिन्न संचार प्रोटोकॉल का उपयोग करते हुए संचार के बीच युग्मक करने की आवश्यकता समाप्त हो जाता है। इसका अर्थ है कि जब एक सेवा दूसरी सेवा के साथ संचार करना चाहती है, तो उसे दूसरे संचार प्रोटोकॉल पर अधिकृत होने की आवश्यकता नहीं होती है। | |||
==तर्क== | == तर्क == | ||
विभिन्न | विभिन्न परियोजना टीमों द्वारा विकसित सेवाएँ विभिन्न संचार तंत्रों पर आधारित हो सकती हैं। परिणामस्वरूप, एक सेवा सूची में सेवाओं के विभिन्न सेट हो सकते हैं, जिनमें से प्रत्येक प्रोटोकॉल के एक अलग सेट के अनुरूप होता है। जब विभिन्न संचार प्रोटोकॉल वाली सेवाओं का पुन: उपयोग करने की बात आती है, तो किसी प्रकार के संचार युग्मक तंत्र की आवश्यकता होती है उदाहरण के लिए, जेएमएस मैसेजिंग प्रोटोकॉल का उपयोग करके विकसित सेवाएं .नेट रिमोटिंग का उपयोग करने वाली सेवाओं के साथ असंगत हैं, इसलिए इन दो प्रकार की सेवाओं का उपयोग करने के लिए, कुछ मिडलवेयर तकनीक की आवश्यकता होती है जो संचार प्रोटोकॉल असमानता को संदर्भित करती है। अतिरिक्त लागत के अतिरिक्त, ऐसी युग्मक तकनीक का उपयोग विलंबता और संचार को जोड़ता है। यह सेवा को पुन: प्रयोज्य और पुन: प्रयोज्य संसाधन से कम कर देता है और सेवा रचनात्मकत डिज़ाइन सिद्धांत के दिशानिर्देशों के विरुद्ध जाता है। | ||
एक सेवा | एक सेवा सूची का डिज़ाइन करने के लिए, जहां सभी सेवाएं एक-दूसरे के साथ समन्वययोग्य हों जिससे वे विभिन्न समाधानों में सम्मिलित किए जा सकें, विहित प्रोटोकॉल प्रतिरूप के अनुपालन का अनुमान लगाता है कि सेवाओं द्वारा उपयोग किए जाने वाले संचार प्रोटोकॉलों को मानकीकृत करना आवश्यक होता है। जब सभी सेवाएं एक ही संचार प्रोटोकॉल का उपयोग करती हैं, तो संचार प्रोटोकॉलों के बीच सेवाओं के बीच संचार को सुगम बनाने के लिए सेतु प्रौद्योगिकी की आवश्यकता समाप्त हो जाता है और सेवाओं के बीच संचार सुगम होता है।।<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 12: | Line 12: | ||
[[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 />समान संचार प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ एक-दूसरे से बात करने में सक्षम हैं और इसलिए उनका उपयोग कई सेवा संरचनाओं में किया जा सकता है।]]इस प्रारूप प्रतिरूप के लागू होने के लिए, एक ऐसी प्रौद्योगिकी संरचना का चयन करना आवश्यक होता है जो एक सामान्य संचार ढांचा प्रदान करती है, जिससे एक सूची में सभी सेवाएं एक ही संचार प्रोटोकॉल का उपयोग करके एक दूसरे के साथ संवाद कर सकें। यह सेवा सूची के अंदर सेवाओं का उपयोग कैसे किया जाएगा, इस पर निर्भर करता है। यदि सेवाएं केवल उन सेवा संयोजनों का भाग होंगी जो सदैव किसी विशेष संचार प्रोटोकॉल का उपयोग करते हैं तो उस संचार प्रोटोकॉल पर आधारित सभी सेवाएं उस सेवा सूची में बना सकते हैं, यद्यपि वह सबसे व्यापक उपयोग होने वाले प्रोटोकॉल न हो। | ||
[[थॉमस एर्ल]] द्वारा प्रस्तावित | [[थॉमस एर्ल]] द्वारा प्रस्तावित विहित प्रोटोकॉल प्रतिरूप सवाल का उत्तर देता है: "सेवाओं को प्रोटोकॉल युग्मक से बचाने के लिए कैसे प्रारूपित किया जा सकता है? समस्या यह है कि विभिन्न संचार प्रौद्योगिकियों का समर्थन करने वाली सेवाएं संगतता को कम करती हैं, तथा संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं और अवांछनीय प्रोटोकॉल युग्मक के लिए आवश्यकता उत्पन्न करती हैं। संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं, और अवांछनीय प्रोटोकॉल युग्मक उपायों की आवश्यकता का परिचय देती हैं। संरचना के लिए इसका समाधान एकल संचार प्रौद्योगिकी को एकमात्र या प्राथमिक माध्यम के रूप में स्थापित करना है जिसके द्वारा सेवाएं बातचीत कर सकती हैं। इसलिए, सेवा सूची सीमा के अंदर उपयोग किए जाने वाले संचार प्रोटोकॉल सभी सेवाओं के लिए मानकीकृत हैं । | ||
वेब सेवाओं रूपरेखा द्वारा सबसे परिपक्व और व्यापक उपयोग किए जाने वाले संचार तंत्रों में से एक प्रदान किया जाता है। संचार तंत्र का चयन करने के अतिरिक्त, वास्तविक संदेश प्रोटोकॉलों को भी मानकीकृत किया जाना चाहिए। उदाहरण के लिए, वेब सेवाएं क्या [[SOAP|एसओएपी]] ओवर [[HTTP|एचटीटीपी]] का उपयोग करके बनाई जाती हैं यह भी मानकीकृत होना चाहिए। | वेब सेवाओं रूपरेखा द्वारा सबसे परिपक्व और व्यापक उपयोग किए जाने वाले संचार तंत्रों में से एक प्रदान किया जाता है। संचार तंत्र का चयन करने के अतिरिक्त, वास्तविक संदेश प्रोटोकॉलों को भी मानकीकृत किया जाना चाहिए। उदाहरण के लिए, वेब सेवाएं क्या [[SOAP|एसओएपी]] ओवर [[HTTP|एचटीटीपी]] का उपयोग करके बनाई जाती हैं यह भी मानकीकृत होना चाहिए। | ||
Revision as of 12:38, 5 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.
