विहित प्रोटोकॉल पैटर्न: Difference between revisions
(→तर्क) |
(→उपयोग) |
||
| 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|एसओएपी]] आधारित वेब सेवाओं पर मानकीकरण करते समय, एसओएपी प्रोटोकॉल के विशिष्ट संस्करण अर्थात एसओएपी v 1.1 या एसओएपी v 1.2 पर भी सहमति की आवश्यकता होती है। | |||
==विचार== | ==विचार== | ||
संचार प्रोटोकॉल | संचार प्रोटोकॉल को मानकीकृत करने के लिए, प्रोटोकॉल की विशेषताएं सेवा संवाद आवश्यकताओं के साथ, सुरक्षा, दक्षता और संचालन समर्थन सहित, तुलना की जानी चाहिए। उदाहरण के रूप में, यदि एक सेवा संयोजन ने प्रकट संचालन समर्थन की आवश्यकता है, तो एसओएपी ओवर एचटीटीपी आरामदायक सेवाओं का उपयोग करने के सापेक्ष में एक बेहतर विकल्प होगा। | ||
कुछ मामलों में, सेवा बनाने के लिए उपयोग की जाने वाली | कुछ मामलों में, सेवा बनाने के लिए उपयोग की जाने वाली प्रौद्योगिकी पर निर्भर करता है, ऐसे मामलों में सेवा को विभिन्न प्रोटोकॉल सेट का समर्थन करना संभव हो सकता है, जिससे यह सेवा विभिन्न प्रकार के सेवा उपभोक्ताओं के लिए पहुंचयोग्य हो सके। उदाहरण के लिए,डब्ल्यूसीएफ का उपयोग करके, एक ही सेवा को एचटीटीपी और टीसीपी/आईपी प्रोटोकॉल का उपयोग करने के लिए समकालिक रूप से समनुरूप किया जा सकता है। | ||
संचार ढाँचा चुनते समय, परिपक्वता, स्केलेबिलिटी और किसी भी लाइसेंसिंग लागत को ध्यान में रखा जाना चाहिए क्योंकि निकट भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं का निर्माण ऐसी सेवाओं की पुन: प्रयोज्यता को प्रभावित करेगा और इसके लिए काफी समय और प्रयासों की आवश्यकता होगी। सेवा को पुनः प्रारूप करने के लिए. | संचार ढाँचा चुनते समय, परिपक्वता, स्केलेबिलिटी और किसी भी लाइसेंसिंग लागत को ध्यान में रखा जाना चाहिए क्योंकि निकट भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं का निर्माण ऐसी सेवाओं की पुन: प्रयोज्यता को प्रभावित करेगा और इसके लिए काफी समय और प्रयासों की आवश्यकता होगी। सेवा को पुनः प्रारूप करने के लिए. | ||
Revision as of 12:35, 4 July 2023
कैनोनिकल प्रोटोकॉल एक प्रारूप प्रतिमान है, जिसे सेवा-उन्मुख प्रारूप प्रतिमान के अंदर लागू किया जाता है, जिसका प्रयास होता है कि सेवा इन्वेंट्री में आपसी सम्बन्ध स्थापित हों। [1] यह सेवाओं के बीच संचार प्रोटोकॉल को मानकीकृत करके उन्हें एक-दूसरे के साथ संगत बनाने का प्रयास करता है। जब सेवाएँ विभिन्न संचार प्रोटोकॉल का उपयोग करती हैं तो यह संचार प्रोटोकॉल को सेतु की आवश्यकता को समाप्त कर देता है।[2]जब सेवाएं विभिन्न संचार प्रोटोकॉल का उपयोग करती हैं, तो कैनोनिकल प्रोटोकॉल के द्वारा ब्रिजिंग संचार प्रोटोकॉल की आवश्यकता को समाप्त किया जाता है।
तर्क
विभिन्न परियोजनाये संगठनों द्वारा विकसित सेवाएँ विभिन्न संचार तंत्रों पर आधारित हो सकती हैं। इसका तात्पर्य है कि एक सेवा इन्वेंट्री में विभिन्न सेवाओं के सेट हो सकते हैं, जो प्रत्येक विभिन्न प्रोटोकॉल सेट के अनुरूप होते हैं। जब विभिन्न संचार प्रोटोकॉल का उपयोग करने वाली सेवाओं को पुनः उपयोग करने के लिए संचार सेतु तंत्र की आवश्यकता होती है। उदाहरण के लिए, जेएमएस संदेशन प्रोटोकॉल का उपयोग करके विकसित सेवाएं जिन्हे विभिन्न सेवाएं उपयोग कर रही हो, वे सेवाएं जिनमें विभिन्न संचार प्रोटोकॉल का उपयोग होता है, उनसे असंगत होती हैं। एनईटी रिमोटिंग का उपयोग करने के लिए, इन दो प्रकार की सेवाओं का उपयोग करने के लिए कुछ मध्यवर्ती प्रौद्योगिकी होनी चाहिए, जो संचार प्रोटोकॉल की असमानता को आपस में जोड़ता है, इस तरह की मध्यवर्ती प्रौद्योगिकी का उपयोग करने से अतिरिक्त खर्च होता है जो संचार में विलंबता और अतिरिक्त संचार को जोड़ता है। इसके कारण सेवा को पुनर्गुणात्मक और पुनर्योज्य उपयोगी बनाने की क्षमता कम हो जाती है और यह सेवा एक सेवा संयोज्यता प्रारूप सिद्धांत के दिशानिर्देशों के विरुद्ध जाता है।
एक सेवा इन्वेंटरी प्रारूप करने के लिए, जहां सभी सेवाएं एक-दूसरे के साथ संगत हों जिससे वे विभिन्न समाधानों में संयोजित की जा सकें, कैननिकल प्रोटोकॉल पैटर्न के लागू होने से सेवाओं द्वारा उपयोग किए जाने वाले संचार प्रोटोकॉल को मानकीकृत किया जाना आवश्यक होता है। जब सभी सेवाएं एक ही संचार प्रोटोकॉल का उपयोग कर रही होती हैं, तो मध्यवर्ती प्रौद्योगिकी की आवश्यकता समाप्त हो जाती है और सेवाओं के मध्य संचार अधिक संगठित होता है।[3]
उपयोग
इस प्रारूप प्रतिरूप के लागू होने के लिए, एक ऐसी प्रौद्योगिकी संरचना का चयन करना आवश्यक होता है जो एक सामान्य संचार ढांचा प्रदान करती है, जिससे एक इन्वेंटरी में सभी सेवाएं एक ही संचार प्रोटोकॉल का उपयोग करके एक दूसरे के साथ संवाद कर सकें। यह सेवा इन्वेंटरी के अंदर सेवाओं का उपयोग कैसे किया जाएगा, इस पर निर्भर करता है। यदि सेवाएं केवल उन सेवा संयोजनों का भाग होंगी जो सदैव किसी विशेष संचार प्रोटोकॉल का उपयोग करते हैं तो उस संचार प्रोटोकॉल पर आधारित सभी सेवाएं उस सेवा इन्वेंटरी में बना सकते हैं, यद्यपि वह सबसे व्यापक उपयोग होने वाले प्रोटोकॉल न हो।
थॉमस एर्ल द्वारा प्रस्तावित कैननिकल प्रोटोकॉल पैटर्न सवाल का उत्तर देता है: "सेवाओं को प्रोटोकॉल ब्रिजिंग से बचाने के लिए कैसे प्रारूपित किया जा सकता है? समस्या यह है कि विभिन्न संचार प्रौद्योगिकियों का समर्थन करने वाली सेवाएं संगतता को कम करती हैं, तथा संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं और अवांछनीय प्रोटोकॉल ब्रिजिंग के लिए आवश्यकता उत्पन्न करती हैं। संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं, और अवांछनीय प्रोटोकॉल ब्रिजिंग उपायों की आवश्यकता का परिचय देती हैं। संरचना के लिए इसका समाधान एकल संचार प्रौद्योगिकी को एकमात्र या प्राथमिक माध्यम के रूप में स्थापित करना है जिसके द्वारा सेवाएं बातचीत कर सकती हैं। इसलिए, सेवा सूची सीमा के अंदर उपयोग किए जाने वाले संचार प्रोटोकॉल सभी सेवाओं के लिए मानकीकृत हैं ।
वेब सेवाओं रूपरेखा द्वारा सबसे परिपक्व और व्यापक उपयोग किए जाने वाले संचार तंत्रों में से एक प्रदान किया जाता है। संचार तंत्र का चयन करने के अतिरिक्त, वास्तविक संदेश प्रोटोकॉलों को भी मानकीकृत किया जाना चाहिए। उदाहरण के लिए, वेब सेवाएं क्या एसओएपी ओवर एचटीटीपी का उपयोग करके बनाई जाती हैं यह भी मानकीकृत होना चाहिए।
इसी प्रकार, एसओएपी आधारित वेब सेवाओं पर मानकीकरण करते समय, एसओएपी प्रोटोकॉल के विशिष्ट संस्करण अर्थात एसओएपी v 1.1 या एसओएपी v 1.2 पर भी सहमति की आवश्यकता होती है।
विचार
संचार प्रोटोकॉल को मानकीकृत करने के लिए, प्रोटोकॉल की विशेषताएं सेवा संवाद आवश्यकताओं के साथ, सुरक्षा, दक्षता और संचालन समर्थन सहित, तुलना की जानी चाहिए। उदाहरण के रूप में, यदि एक सेवा संयोजन ने प्रकट संचालन समर्थन की आवश्यकता है, तो एसओएपी ओवर एचटीटीपी आरामदायक सेवाओं का उपयोग करने के सापेक्ष में एक बेहतर विकल्प होगा।
कुछ मामलों में, सेवा बनाने के लिए उपयोग की जाने वाली प्रौद्योगिकी पर निर्भर करता है, ऐसे मामलों में सेवा को विभिन्न प्रोटोकॉल सेट का समर्थन करना संभव हो सकता है, जिससे यह सेवा विभिन्न प्रकार के सेवा उपभोक्ताओं के लिए पहुंचयोग्य हो सके। उदाहरण के लिए,डब्ल्यूसीएफ का उपयोग करके, एक ही सेवा को एचटीटीपी और टीसीपी/आईपी प्रोटोकॉल का उपयोग करने के लिए समकालिक रूप से समनुरूप किया जा सकता है।
संचार ढाँचा चुनते समय, परिपक्वता, स्केलेबिलिटी और किसी भी लाइसेंसिंग लागत को ध्यान में रखा जाना चाहिए क्योंकि निकट भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं का निर्माण ऐसी सेवाओं की पुन: प्रयोज्यता को प्रभावित करेगा और इसके लिए काफी समय और प्रयासों की आवश्यकता होगी। सेवा को पुनः प्रारूप करने के लिए.
संदर्भ
- Notes
- ↑ Service Inventory Archived March 13, 2010, at the Wayback Machine
- ↑ Matthew Dailey.Software Architecture Design Service Oriented Architectures (Part II) Archived 2011-07-24 at the Wayback Machine[Online].Date accessed: 25 April 2010.
- ↑ 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.
