विहित प्रोटोकॉल पैटर्न

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

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

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

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

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

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

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

कुछ मामलों में, सेवा बनाने के लिए उपयोग की जाने वाली तकनीक के आधार पर, विभिन्न प्रकार के सेवा उपभोक्ताओं के लिए सेवा को सुलभ बनाने के लिए प्रोटोकॉल के दो अलग-अलग सेट का समर्थन करना संभव हो सकता है (दोहरी प्रोटोकॉल डिजाइन पैटर्न) ). उदाहरण के लिए, विंडोज़ कम्युनिकेशन फाउंडेशन  का उपयोग करके, एक ही सेवा को एक ही समय में HTTP और TCP/IP प्रोटोकॉल का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है।

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

संदर्भ

 * Notes


 * Sources
 * Thomas Erl et al., (2009).SOA Design Patterns. Prentice Hall. ISBN 978-0-13-613516-6.

बाहरी संबंध

 * SOA Concepts
 * SOA Terms Glossary
 * SOA Design Patterns