विहित प्रोटोकॉल पैटर्न: Difference between revisions
(Created page with "कैनोनिकल प्रोटोकॉल एक डिज़ाइन पैटर्न (कंप्यूटर विज्ञान) है, जिसे...") |
No edit summary |
||
| 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>जब सेवाएं विभिन्न संचार प्रोटोकॉल का उपयोग करती हैं, तो कैनोनिकल प्रोटोकॉल के द्वारा ब्रिजिंग संचार प्रोटोकॉल की आवश्यकता को समाप्त किया जाता है। | ||
==तर्क== | ==तर्क== | ||
विभिन्न परियोजना टीमों द्वारा विकसित सेवाएँ विभिन्न संचार तंत्रों पर आधारित हो सकती हैं। परिणामस्वरूप, एक सेवा सूची में सेवाओं के अलग-अलग सेट हो सकते हैं, जिनमें से प्रत्येक प्रोटोकॉल के एक अलग सेट के अनुरूप होता है। जब विभिन्न संचार प्रोटोकॉल वाली सेवाओं का पुन: उपयोग करने की बात आती है, तो किसी प्रकार के संचार ब्रिजिंग तंत्र की आवश्यकता होती है। उदाहरण के लिए, [[ जावा संदेश सेवा ]] मैसेजिंग प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ .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> संसाधन और सेवा संयोजन सिद्धांत | विभिन्न परियोजना टीमों द्वारा विकसित सेवाएँ विभिन्न संचार तंत्रों पर आधारित हो सकती हैं। परिणामस्वरूप, एक सेवा सूची में सेवाओं के अलग-अलग सेट हो सकते हैं, जिनमें से प्रत्येक प्रोटोकॉल के एक अलग सेट के अनुरूप होता है। जब विभिन्न संचार प्रोटोकॉल वाली सेवाओं का पुन: उपयोग करने की बात आती है, तो किसी प्रकार के संचार ब्रिजिंग तंत्र की आवश्यकता होती है। उदाहरण के लिए, [[ जावा संदेश सेवा ]] मैसेजिंग प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ .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 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 />समान संचार प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ एक-दूसरे से बात करने में सक्षम हैं और इसलिए उनका उपयोग कई सेवा संरचनाओं में किया जा सकता है।]]इस प्रारूप प्रतिरूप के अनुप्रयोग के लिए एक प्रौद्योगिकी वास्तुकला को चुनने की आवश्यकता होती है जो एक सामान्य संचार ढांचा प्रदान करती है ताकि एक इन्वेंट्री में सभी सेवाएँ समान संचार प्रोटोकॉल का उपयोग करके एक दूसरे के साथ संचार कर सकें। यह इस बात पर निर्भर करता है कि सेवा सूची के अंदर सेवाओं का उपयोग कैसे किया जाएगा। यदि सेवाएँ केवल उन सेवा संरचनाओं का हिस्सा बनने जा रही हैं जो हमेशा एक विशेष संचार प्रोटोकॉल (दक्षता और सुरक्षा कारणों से) का उपयोग करती हैं, तो उस सेवा सूची के अंदर सभी सेवाएँ ऐसे संचार प्रोटोकॉल पर बनाई जा सकती हैं, भले ही वह न हो सबसे व्यापक रूप से उपयोग किया जाने वाला प्रोटोकॉल। | ||
[[थॉमस एर्ल]] द्वारा कैनोनिकल प्रोटोकॉल | [[थॉमस एर्ल]] द्वारा कैनोनिकल प्रोटोकॉल प्रतिरूप इस प्रश्न का उत्तर देता है: प्रोटोकॉल ब्रिजिंग से बचने के लिए सेवाओं को कैसे प्रारूप किया जा सकता है?<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 पर भी सहमति की आवश्यकता होती है। | सबसे परिपक्व और व्यापक रूप से उपयोग किए जाने वाले संचार तंत्रों में से एक वेब सेवा ढांचे द्वारा प्रदान किया जाता है। संचार ढाँचे को चुनने के अलावा, वास्तविक संदेश प्रोटोकॉल को भी मानकीकृत करने की आवश्यकता है। उदाहरण के लिए, क्या वेब सेवाएँ [[HTTP]] पर [[SOAP]] का उपयोग करके बनाई गई हैं या केवल [[RESTful]] सेवाओं का उपयोग करके बनाई गई हैं। इसी प्रकार, SOAP आधारित वेब सेवाओं पर मानकीकरण करते समय, SOAP प्रोटोकॉल के विशिष्ट संस्करण यानी SOAP v 1.1 या SOAP v 1.2 पर भी सहमति की आवश्यकता होती है। | ||
| Line 21: | Line 22: | ||
संचार प्रोटोकॉल पर मानकीकरण करने के लिए, सुरक्षा, दक्षता और लेनदेन समर्थन सहित सेवा इंटरैक्शन आवश्यकताओं के साथ प्रोटोकॉल की विशेषताओं की तुलना करने की आवश्यकता है। उदाहरण के लिए, वेब सेवाओं के मामले में, यदि किसी सेवा संरचना को स्पष्ट लेनदेन समर्थन की आवश्यकता होती है, तो HTTP पर SOAP RESTful सेवाओं का उपयोग करने से बेहतर विकल्प होगा। | संचार प्रोटोकॉल पर मानकीकरण करने के लिए, सुरक्षा, दक्षता और लेनदेन समर्थन सहित सेवा इंटरैक्शन आवश्यकताओं के साथ प्रोटोकॉल की विशेषताओं की तुलना करने की आवश्यकता है। उदाहरण के लिए, वेब सेवाओं के मामले में, यदि किसी सेवा संरचना को स्पष्ट लेनदेन समर्थन की आवश्यकता होती है, तो 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 प्रोटोकॉल का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है। | ||
संचार ढाँचा चुनते समय, परिपक्वता, स्केलेबिलिटी और किसी भी लाइसेंसिंग लागत को ध्यान में रखा जाना चाहिए क्योंकि निकट भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं का निर्माण ऐसी सेवाओं की पुन: प्रयोज्यता को प्रभावित करेगा और इसके लिए काफी समय और प्रयासों की आवश्यकता होगी। सेवा को पुनः | संचार ढाँचा चुनते समय, परिपक्वता, स्केलेबिलिटी और किसी भी लाइसेंसिंग लागत को ध्यान में रखा जाना चाहिए क्योंकि निकट भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं का निर्माण ऐसी सेवाओं की पुन: प्रयोज्यता को प्रभावित करेगा और इसके लिए काफी समय और प्रयासों की आवश्यकता होगी। सेवा को पुनः प्रारूप करने के लिए. | ||
== संदर्भ == | == संदर्भ == | ||
Revision as of 23:16, 3 July 2023
कैनोनिकल प्रोटोकॉल एक प्रारूप प्रतिमान है, जिसे सेवा-उन्मुख प्रारूप प्रतिमान के अंदर लागू किया जाता है, जिसका प्रयास होता है कि सेवा इन्वेंट्री में आपसी सम्बन्ध स्थापित हों। [1] यह सेवाओं के बीच संचार प्रोटोकॉल को मानकीकृत करके उन्हें एक-दूसरे के साथ संगत बनाने का प्रयास करता है। जब सेवाएँ विभिन्न संचार प्रोटोकॉल का उपयोग करती हैं तो यह संचार प्रोटोकॉल को सेतु की आवश्यकता को समाप्त कर देता है।[2]जब सेवाएं विभिन्न संचार प्रोटोकॉल का उपयोग करती हैं, तो कैनोनिकल प्रोटोकॉल के द्वारा ब्रिजिंग संचार प्रोटोकॉल की आवश्यकता को समाप्त किया जाता है।
तर्क
विभिन्न परियोजना टीमों द्वारा विकसित सेवाएँ विभिन्न संचार तंत्रों पर आधारित हो सकती हैं। परिणामस्वरूप, एक सेवा सूची में सेवाओं के अलग-अलग सेट हो सकते हैं, जिनमें से प्रत्येक प्रोटोकॉल के एक अलग सेट के अनुरूप होता है। जब विभिन्न संचार प्रोटोकॉल वाली सेवाओं का पुन: उपयोग करने की बात आती है, तो किसी प्रकार के संचार ब्रिजिंग तंत्र की आवश्यकता होती है। उदाहरण के लिए, जावा संदेश सेवा मैसेजिंग प्रोटोकॉल का उपयोग करके विकसित की गई सेवाएँ .NET रिमोटिंग का उपयोग करने वाली सेवाओं के साथ असंगत हैं, इसलिए इन दो प्रकार की सेवाओं का उपयोग करने के लिए, कुछ मध्यस्थ तकनीक की आवश्यकता होती है जो संचार प्रोटोकॉल असमानता को पाटती है। अतिरिक्त लागत के अलावा, ऐसी ब्रिजिंग तकनीक का उपयोग विलंबता (इंजीनियरिंग) और संचार ओवरहेड को जोड़ता है। यह सेवा को कम पुन: प्रयोज्य और पुन: प्रयोज्य बनाता है[3] संसाधन और सेवा संयोजन सिद्धांत प्रारूप सिद्धांत के दिशानिर्देशों के विरुद्ध जाता है।
एक सेवा सूची को प्रारूप करने के लिए जहां सभी सेवाएं एक-दूसरे के साथ इंटरऑपरेबल होती हैं ताकि उन्हें अलग-अलग समाधानों में बनाया जा सके, कैनोनिकल प्रोटोकॉल प्रतिरूप का अनुप्रयोग सेवाओं द्वारा उपयोग किए जाने वाले संचार प्रोटोकॉल को मानकीकृत करने का निर्देश देता है। जब सभी सेवाएँ समान संचार प्रोटोकॉल का उपयोग कर रही हैं, तो ब्रिजिंग तकनीक की आवश्यकता समाप्त हो जाती है और सेवाओं के बीच संचार अधिक सुव्यवस्थित हो जाता है।[4]
उपयोग
इस प्रारूप प्रतिरूप के अनुप्रयोग के लिए एक प्रौद्योगिकी वास्तुकला को चुनने की आवश्यकता होती है जो एक सामान्य संचार ढांचा प्रदान करती है ताकि एक इन्वेंट्री में सभी सेवाएँ समान संचार प्रोटोकॉल का उपयोग करके एक दूसरे के साथ संचार कर सकें। यह इस बात पर निर्भर करता है कि सेवा सूची के अंदर सेवाओं का उपयोग कैसे किया जाएगा। यदि सेवाएँ केवल उन सेवा संरचनाओं का हिस्सा बनने जा रही हैं जो हमेशा एक विशेष संचार प्रोटोकॉल (दक्षता और सुरक्षा कारणों से) का उपयोग करती हैं, तो उस सेवा सूची के अंदर सभी सेवाएँ ऐसे संचार प्रोटोकॉल पर बनाई जा सकती हैं, भले ही वह न हो सबसे व्यापक रूप से उपयोग किया जाने वाला प्रोटोकॉल।
थॉमस एर्ल द्वारा कैनोनिकल प्रोटोकॉल प्रतिरूप इस प्रश्न का उत्तर देता है: प्रोटोकॉल ब्रिजिंग से बचने के लिए सेवाओं को कैसे प्रारूप किया जा सकता है?[5] समस्या यह है कि विभिन्न संचार प्रौद्योगिकियों का समर्थन करने वाली सेवाएँ अंतरसंचालनीयता से समझौता करती हैं, संभावित उपभोक्ताओं की मात्रा को सीमित करती हैं, और अवांछनीय प्रोटोकॉल ब्रिजिंग उपायों की आवश्यकता का परिचय देती हैं। आर्किटेक्चर के लिए इसका समाधान एकल संचार प्रौद्योगिकी को एकमात्र या प्राथमिक माध्यम के रूप में स्थापित करना है जिसके द्वारा सेवाएं बातचीत कर सकती हैं। इसलिए, सेवा सूची सीमा के अंदर उपयोग किए जाने वाले संचार प्रोटोकॉल (प्रोटोकॉल संस्करणों सहित) सभी सेवाओं के लिए मानकीकृत हैं (आरेख देखें)।
सबसे परिपक्व और व्यापक रूप से उपयोग किए जाने वाले संचार तंत्रों में से एक वेब सेवा ढांचे द्वारा प्रदान किया जाता है। संचार ढाँचे को चुनने के अलावा, वास्तविक संदेश प्रोटोकॉल को भी मानकीकृत करने की आवश्यकता है। उदाहरण के लिए, क्या वेब सेवाएँ HTTP पर SOAP का उपयोग करके बनाई गई हैं या केवल RESTful सेवाओं का उपयोग करके बनाई गई हैं। इसी प्रकार, SOAP आधारित वेब सेवाओं पर मानकीकरण करते समय, SOAP प्रोटोकॉल के विशिष्ट संस्करण यानी SOAP v 1.1 या SOAP v 1.2 पर भी सहमति की आवश्यकता होती है।
विचार
संचार प्रोटोकॉल पर मानकीकरण करने के लिए, सुरक्षा, दक्षता और लेनदेन समर्थन सहित सेवा इंटरैक्शन आवश्यकताओं के साथ प्रोटोकॉल की विशेषताओं की तुलना करने की आवश्यकता है। उदाहरण के लिए, वेब सेवाओं के मामले में, यदि किसी सेवा संरचना को स्पष्ट लेनदेन समर्थन की आवश्यकता होती है, तो HTTP पर SOAP RESTful सेवाओं का उपयोग करने से बेहतर विकल्प होगा।
कुछ मामलों में, सेवा बनाने के लिए उपयोग की जाने वाली तकनीक के आधार पर, विभिन्न प्रकार के सेवा उपभोक्ताओं के लिए सेवा को सुलभ बनाने के लिए प्रोटोकॉल के दो अलग-अलग सेट का समर्थन करना संभव हो सकता है (दोहरी प्रोटोकॉल डिजाइन प्रतिरूप)[6]). उदाहरण के लिए, विंडोज़ कम्युनिकेशन फाउंडेशन का उपयोग करके, एक ही सेवा को एक ही समय में HTTP और TCP/IP प्रोटोकॉल का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है।
संचार ढाँचा चुनते समय, परिपक्वता, स्केलेबिलिटी और किसी भी लाइसेंसिंग लागत को ध्यान में रखा जाना चाहिए क्योंकि निकट भविष्य में अप्रचलित होने वाले प्रोटोकॉल का उपयोग करके सेवाओं का निर्माण ऐसी सेवाओं की पुन: प्रयोज्यता को प्रभावित करेगा और इसके लिए काफी समय और प्रयासों की आवश्यकता होगी। सेवा को पुनः प्रारूप करने के लिए.
संदर्भ
- 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.
- ↑ Service Composition Archived March 11, 2010, at the Wayback Machine
- ↑ 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
- ↑ SOA Patterns - Canonical Protocol Archived December 14, 2009, at the Wayback Machine
- ↑ Dual Protocols design pattern Archived December 14, 2009, at the Wayback Machine
- Sources
- Thomas Erl et al., (2009).SOA Design Patterns. Prentice Hall. ISBN 978-0-13-613516-6.
