👏🏻 👩🏿‍🤝‍👩🏼 🎺 एक सेवा को विकसित करने के तरीके के रूप में उपभोक्ता-संचालित अनुबंध 📄 🍅 🐋

- आपूर्तिकर्ता की सफलता का रहस्य उपभोक्ताओं को गुणवत्ता वाले उत्पाद प्रदान करना है ... ओह, अर्थात् सेवा। अच्छी तरह से और यह भी महत्वपूर्ण है कि पिछड़े संगतता के उल्लंघन के साथ सभी गंभीर नहीं।
वाल्टर व्हाइट

अनुवादक से

यह क्या है

यह उपभोक्ता-प्रेरित अनुबंध (सीडीसी) टेम्पलेट का वर्णन करने वाले लेख का अनुवाद है।
मूल को मार्टिन रॉबलर की वेबसाइट पर इयान रॉबिन्सन द्वारा प्रकाशित किया गया है।

वह क्यों है?

एक माइक्रोसैस आर्किटेक्चर में, सेवाओं के बीच निर्भरता समस्याओं का एक स्रोत है। सीडीसी टेम्पलेट इन समस्याओं को एक तरह से हल करने में मदद करता है जो सेवा और उसके उपभोक्ताओं दोनों के लिए उपयुक्त है। Fowler ने उपभोक्ता-प्रवृत्त संविदा को अपने मुख्य लेख में microservice आर्किटेक्चर: Microservices पर उद्धृत किया।

यह किसके लिए है

यह लेख विशेष रूप से एक ही संगठन के भीतर कई उपभोक्ताओं के लिए सेवाओं को विकसित करने वाली टीमों और ऐसी सेवाओं का उपभोग करने वाली टीमों के लिए उपयोगी होगा।

शर्तों के बारे में

मैंने उपभोक्ता-चालित अनुबंधों का रूसी में अनुवाद नहीं किया - हम बातचीत में टेस्ट-प्रेरित विकास का अनुवाद नहीं करते हैं। यदि आवश्यक हो, तो आप विकल्प ग्राहक-उन्मुख अनुबंध का उपयोग कर सकते हैं।
प्रदाता अनुबंध और उपभोक्ता अनुबंध को आपूर्तिकर्ता अनुबंध और उपभोक्ता अनुबंध के रूप में अनुवादित किया जाता है - उनका रूसी में स्थायी उपयोग होता है।
किसी सेवा (सेवा विकास) का विकास या विकास - शोधन, सेवा कार्यक्षमता का विस्तार।
सेवा का समुदाय (सेवा समुदाय) - आपूर्तिकर्ता और इस सेवा के सभी उपभोक्ता।

प्रस्तावना

यह आलेख डेवलपर्स और सेवाओं के उपभोक्ताओं के बीच उत्पन्न होने वाली समस्याओं पर चर्चा करता है, उदाहरण के लिए, जब आपूर्तिकर्ता अपने अनुबंध का हिस्सा बदलते हैं, विशेष रूप से, दस्तावेज़ अनुपूरक। उनसे निपटने के लिए दो रणनीतियों का वर्णन किया गया है:

विस्तार बिंदुओं को जोड़ना।
प्राप्त संदेशों का "पर्याप्त" सत्यापन।

दोनों रणनीतियाँ अनुबंध में बदलाव से उपभोक्ताओं को बचाने में मदद करती हैं, लेकिन सेवा प्रदाता को जानकारी नहीं देती हैं:

इन रणनीतियों का उपयोग करने के लिए सबसे अच्छा कैसे;
सेवा विकसित होने के साथ ही क्या करना चाहिए।

लेख उपभोक्ता-प्रेरित अनुबंध टेम्पलेट का वर्णन करता है, जो आपूर्तिकर्ताओं को अपने ग्राहकों को बेहतर ढंग से समझने की अनुमति देता है और उपभोक्ताओं के लिए सेवा के विकास पर ध्यान केंद्रित करता है।

सेवा विकास का उदाहरण

सेवाओं को विकसित करते समय हमारे सामने आने वाली कुछ समस्याओं को समझने के लिए, एक साधारण उत्पाद खोज पर विचार करें, जो आपको हमारी उत्पाद सूची में खोज करने की अनुमति देता है। खोज परिणाम में निम्नलिखित संरचना है:

चित्र 1: खोज परिणाम आरेख

खोज परिणामों के साथ एक उदाहरण दस्तावेज इस प्रकार है:

<?xml version="1.0" encoding="utf-8"?> <Products xmlns="urn:example.com:productsearch:products"> <Product> <CatalogueID>101</CatalogueID> <Name>Widget</Name> <Price>10.99</Price> <Manufacturer>Company A</Manufacturer> <InStock>Yes</InStock> </Product> <Product> <CatalogueID>300</CatalogueID> <Name>Fooble</Name> <Price>2.00</Price> <Manufacturer>Company B</Manufacturer> <InStock>No</InStock> </Product> </Products>

उत्पाद खोज वर्तमान में दो अनुप्रयोगों के उपयोग में है: एक आंतरिक विपणन अनुप्रयोग और एक बाहरी पुनर्विक्रेता वेब अनुप्रयोग। दोनों ग्राहक प्रसंस्करण से पहले प्राप्त दस्तावेजों को सत्यापित करने के लिए एक्सएसडी का उपयोग करते हैं। आंतरिक एप्लिकेशन कैटलॉग, नाम, मूल्य और निर्माता क्षेत्रों का उपयोग करता है; बाहरी अनुप्रयोग - फ़ील्ड कैटलॉग, नाम और मूल्य। उनमें से कोई भी इनस्टॉक क्षेत्र का उपयोग नहीं करता है: हालांकि इसे एक विपणन अनुप्रयोग के लिए माना जाता था, इसे विकास के प्रारंभिक चरण में बाहर कर दिया गया था।

किसी सेवा को विकसित करने के सबसे सामान्य तरीकों में से एक एक या अधिक उपभोक्ताओं के लिए दस्तावेज़ में फ़ील्ड जोड़ना है। क्लाइंट और सर्वर भागों को कैसे लागू किया गया था, इस पर निर्भर करते हुए, यहां तक कि इस तरह के सरल परिवर्तनों से व्यवसाय और उसके भागीदारों के लिए महंगा परिणाम हो सकते हैं।

हमारे उदाहरण में, उत्पाद खोज सेवा कुछ समय के लिए चलने के बाद, एक दूसरा पुनर्विक्रेता इसका उपयोग करना चाहता है, लेकिन प्रत्येक उत्पाद के लिए विवरण फ़ील्ड को जोड़ने के लिए कहता है। ग्राहकों की व्यवस्था के तरीके के कारण, इस परिवर्तन के आपूर्तिकर्ता और मौजूदा ग्राहकों दोनों के लिए महत्वपूर्ण और महंगा परिणाम हैं। उनमें से प्रत्येक की लागत इस बात पर निर्भर करती है कि हम परिवर्तन को कैसे लागू करते हैं। कम से कम दो तरीके हैं जिनसे हम "सेवा समुदाय" के सदस्यों के बीच परिवर्तनों की लागत साझा कर सकते हैं। सबसे पहले, हम अपने मूल स्कीमा को बदल सकते हैं और प्रत्येक उपभोक्ता को खोज परिणामों को सही ढंग से जांचने के लिए स्कीमा की अपनी प्रति अपडेट करने की आवश्यकता होती है। आपूर्तिकर्ता के बीच प्रणाली को बदलने की लागत आपूर्तिकर्ता के बीच वितरित की जाती है, जो परिवर्तन के लिए इस तरह के अनुरोध के साथ सामना करता है, फिर भी कुछ बदलाव करेगा; और जो उपभोक्ता अद्यतन कार्यक्षमता में रुचि नहीं रखते हैं। दूसरी ओर, हम एक नए ग्राहक के लिए दूसरा ऑपरेशन और स्कीम जोड़ सकते हैं और मौजूदा ऑपरेशन और मौजूदा ग्राहकों के लिए स्कीम रख सकते हैं। अब सभी सुधार आपूर्तिकर्ता के पक्ष में हैं, लेकिन सेवा की जटिलता और इसके समर्थन की लागत बढ़ रही है।

इंटरल्यूड: बर्न एसओए

सेवाओं का उपयोग करने के मुख्य लाभ हैं:

संगठनात्मक लचीलापन बढ़ा।
परिवर्तनों को लागू करने के लिए कम समग्र लागत।

SOA समर्पित, पुन: प्रयोज्य सेवाओं में व्यावसायिक कार्यों को करके लचीलापन बढ़ाता है। फिर इन सेवाओं का उपयोग किया जाता है और मुख्य व्यावसायिक प्रक्रियाओं को पूरा करने के लिए ऑर्केस्ट्रेटेड किया जाता है। यह सेवाओं के बीच निर्भरता को कम करके परिवर्तनों की लागत को कम करता है, जिससे उन्हें परिवर्तनों या अनियोजित घटनाओं के जवाब में जल्दी से पुनर्निर्माण और धुन करने की अनुमति मिलती है।

हालांकि, एक व्यवसाय पूरी तरह से इन लाभों का एहसास तभी कर सकता है जब एसओए का कार्यान्वयन सेवाओं को स्वतंत्र रूप से विकसित करने की अनुमति देता है। स्वतंत्रता बढ़ाने के लिए, हम सेवा अनुबंध बनाते हैं। इसके बावजूद, हमें उपभोक्ताओं को आपूर्तिकर्ता के रूप में अक्सर संशोधित करने के लिए मजबूर किया जाता है, मुख्यतः क्योंकि उपभोक्ता आपूर्तिकर्ता के अनुबंध के विशिष्ट संस्करण पर निर्भर करते हैं। अंत में, आपूर्तिकर्ता अनुबंध के किसी भी तत्व को संशोधित करने में बेहद सतर्क होने लगते हैं; विशेष रूप से, क्योंकि उन्हें पता नहीं है कि उपभोक्ता इस अनुबंध को कैसे लागू करते हैं। सबसे खराब स्थिति में, उपभोक्ताओं को अपने आंतरिक तर्क के हिस्से के रूप में दस्तावेज़ की संपूर्ण रूपरेखा का वर्णन करते हुए, आपूर्तिकर्ता से बंधा हुआ है।

अनुबंध सेवा स्वतंत्रता सुनिश्चित करते हैं; विरोधाभासी रूप से, वे आपूर्तिकर्ताओं और उपभोक्ताओं को अवांछनीय तरीकों से भी बांध सकते हैं। हमारे एसओए में लागू किए गए अनुबंधों के कार्य और भूमिका के बारे में सोचने के बिना, हम अपनी सेवाओं को "गुप्त" संचार के लिए उजागर करते हैं। सेवा के उपभोक्ता कोड में अनुबंध को कैसे लागू करते हैं, साथ ही कार्यान्वयन प्रतिबंध (आपूर्तिकर्ता और उपभोक्ता दोनों के लिए) की कमी के बारे में किसी भी जानकारी का अभाव, एक साथ SOA के कथित लाभों को कम कर देता है। संक्षेप में, एक उद्यम सेवाओं के टायर के लिए शुरू होता है।

स्कीमा संस्करण

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

दोनों चरम समस्याएं समस्याएं पैदा करती हैं जो व्यवसाय के लिए मूल्य प्रदान नहीं करती हैं और सिस्टम के स्वामित्व की कुल लागत को बढ़ाती हैं। स्पष्ट और निहित "नो वर्जन" रणनीतियाँ उन प्रणालियों की ओर ले जाती हैं जो अपनी अंतःक्रियाओं में अप्रत्याशित होती हैं, खराब रूप से विकसित होती हैं, और उनमें सुधार की उच्च लागत होती है। दूसरी ओर, बिग बैंग रणनीतियां अत्यधिक परस्पर सेवा परिदृश्य बनाती हैं, जिसमें सर्किट परिवर्तन सभी आपूर्तिकर्ताओं और उपभोक्ताओं को प्रभावित करते हैं, उपलब्धता को प्रभावित करते हैं, विकास को धीमा करते हैं, और लाभ के अवसरों को कम करते हैं।

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

विस्तार अंक

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

यहाँ खोज परिणाम दस्तावेज़ की हमारी मूल रूपरेखा है:

 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:example.com:productsearch:products" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:example.com:productsearch:products" id="Products"> <xs:element name="Products" type="Products" /> <xs:complexType name="Products"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="Product" type="Product" /> </xs:sequence> </xs:complexType> <xs:complexType name="Product"> <xs:sequence> <xs:element name="CatalogueID" type="xs:int" /> <xs:element name="Name" type="xs:string" /> <xs:element name="Price" type="xs:double" /> <xs:element name="Manufacturer" type="xs:string" /> <xs:element name="InStock" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema>

अब समय में वापस रोल करते हैं, और बहुत शुरुआत से हम अपनी सेवा के लिए एक संगत, विस्तृत योजना का संकेत देंगे:

 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:example.com:productsearch:products" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:example.com:productsearch:products" id="Products"> <xs:element name="Products" type="Products" /> <xs:complexType name="Products"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="Product" type="Product" /> </xs:sequence> </xs:complexType> <xs:complexType name="Product"> <xs:sequence> <xs:element name="CatalogueID" type="xs:int" /> <xs:element name="Name" type="xs:string" /> <xs:element name="Price" type="xs:double" /> <xs:element name="Manufacturer" type="xs:string" /> <xs:element name="InStock" type="xs:string" /> <xs:element minOccurs="0" maxOccurs="1" name="Extension" type="Extension" /> </xs:sequence> </xs:complexType> <xs:complexType name="Extension"> <xs:sequence> <xs:any minOccurs="1" maxOccurs="unbounded" namespace="##targetNamespace" processContents="lax" /> </xs:sequence> </xs:complexType> </xs:schema>

इस डिज़ाइन में प्रत्येक उत्पाद के लिए एक वैकल्पिक विस्तार तत्व शामिल है। एक्सटेंशन तत्व में लक्ष्य नामस्थान से एक या अधिक तत्व हो सकते हैं:

चित्र 2: एक्स्टेंसिबल सर्च रिजल्ट स्कीमा

अब जब हमें एक उत्पाद विवरण जोड़ने के लिए कहा जाता है, तो हम एक अतिरिक्त विवरण तत्व के साथ एक नया स्कीमा प्रकाशित कर सकते हैं, जिसे प्रदाता विस्तार बिंदु में सम्मिलित करता है। यह ProductSearch को उत्पाद विवरणों वाले परिणाम वापस करने की अनुमति देता है, और उपभोक्ता पूरे दस्तावेज़ को मान्य करने के लिए नई योजना का उपयोग करते हैं। पुरानी योजना का उपयोग करने वाले उपभोक्ता नहीं टूटेंगे, हालांकि वे विवरण फ़ील्ड को संसाधित नहीं करेंगे। एक नया खोज परिणाम दस्तावेज़ इस तरह दिखता है:

 <?xml version="1.0" encoding="utf-8"?> <Products xmlns="urn:example.com:productsearch:products"> <Product> <CatalogueID>101</CatalogueID> <Name>Widget</Name> <Price>10.99</Price> <Manufacturer>Company A</Manufacturer> <InStock>Yes</InStock> <Extension> <Description>Our top of the range widget</Description> </Extension> </Product> <Product> <CatalogueID>300</CatalogueID> <Name>Fooble</Name> <Price>2.00</Price> <Manufacturer>Company B</Manufacturer> <InStock>No</InStock> <Extension> <Description>Our bargain fooble</Description> </Extension> </Product> </Products>

संशोधित योजना इस प्रकार है:

 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:example.com:productsearch:products" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:example.com:productsearch:products" id="Products"> <xs:element name="Products" type="Products" /> <xs:complexType name="Products"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="Product" type="Product" /> </xs:sequence> </xs:complexType> <xs:complexType name="Product"> <xs:sequence> <xs:element name="CatalogueID" type="xs:int" /> <xs:element name="Name" type="xs:string" /> <xs:element name="Price" type="xs:double" /> <xs:element name="Manufacturer" type="xs:string" /> <xs:element name="InStock" type="xs:string" /> <xs:element minOccurs="0" maxOccurs="1" name="Extension" type="Extension" /> </xs:sequence> </xs:complexType> <xs:complexType name="Extension"> <xs:sequence> <xs:any minOccurs="1" maxOccurs="unbounded" namespace="##targetNamespace" processContents="lax" /> </xs:sequence> </xs:complexType> <xs:element name="Description" type="xs:string" /> </xs:schema>

ध्यान दें कि एक्स्टेंसिबल स्कीमा का पहला संस्करण दूसरे के साथ संगत है, और दूसरा पहले के साथ पीछे संगत है। हालांकि, यह लचीलापन बढ़ी हुई जटिलता की कीमत पर आता है। एक्स्टेंसिबल स्कीमा हमें अप्रत्याशित परिवर्तन करने की अनुमति देते हैं, लेकिन वे ऐसी सुविधाएँ प्रदान करते हैं जिनकी कभी आवश्यकता नहीं हो सकती है; जब हम हार गए:

एक साधारण डिजाइन से अभिव्यक्ति
कंटेनर के मेटा-सूचना तत्वों को पेश करके डेटा की स्पष्ट प्रस्तुति।

आगे हम विलुप्त योजनाओं पर चर्चा नहीं करेंगे। यह कहने के लिए पर्याप्त है कि विस्तार बिंदु हमें सेवा के आपूर्तिकर्ताओं और उपभोक्ताओं को प्रभावित किए बिना, आरेख और दस्तावेजों में प्रत्यक्ष और पिछड़े संगत परिवर्तन करने की अनुमति देते हैं। हालांकि, योजना का विस्तार करने से हमें सिस्टम के विकास को नियंत्रित करने में मदद नहीं मिलती है जब हमें अनुबंध में उल्लंघन करने वाले बदलाव की आवश्यकता होती है।

अनुकूलता को तोड़ना

- हां, हमारी टीम ने नवीनतम रिलीज में पिछड़ी संगतता का उल्लंघन किया! वे सिर्फ प्रोटोकॉल के मामूली अनुकूलन का विरोध नहीं कर सकते थे ... खैर, बुरा मत मानना, स्वीटी!
कार्ला बोरिन

हमारी ProductSearch सेवा इस उत्पाद की उपलब्धता को इंगित करने वाले खोज परिणामों में शामिल है। यह सेवा एक प्राचीन इन्वेंट्री सिस्टम के लिए एक महंगी कॉल का उपयोग करके इस क्षेत्र को भरती है - एक निर्भरता जो बनाए रखने के लिए महंगी है। आपूर्तिकर्ता इस निर्भरता को दूर करना, डिज़ाइन को साफ करना और समग्र प्रणाली के प्रदर्शन में सुधार करना चाहेगा। और अधिमानतः, उपभोक्ताओं को प्रभावित किए बिना। उपभोक्ताओं के साथ संवाद करते हुए, आपूर्तिकर्ता टीम को पता चलता है कि उपभोक्ता अनुप्रयोगों में से कोई भी वास्तव में इस क्षेत्र के साथ कुछ भी नहीं करता है; यह महंगा होने के नाते, यह बेमानी है।

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

हमारा सेवा समुदाय अपने विकास में निराश है, क्योंकि प्रत्येक उपभोक्ता में एक "छिपी हुई" निर्भरता है, जो उपभोक्ता के आंतरिक तर्क में आपूर्तिकर्ता के पूरे अनुबंध को दर्शाता है। उपभोक्ता, XSD सत्यापन का उपयोग करते हुए और कुछ हद तक, कोड में दस्तावेज़ योजना के लिए स्थैतिक बंधन, केवल अपने हिस्से की परवाह किए बिना पूरे आपूर्तिकर्ता अनुबंध को स्पष्ट रूप से स्वीकार करते हैं।

डेविड ऑर्चर्ड कुछ सुराग देता है कि हम इस समस्या से कैसे बच सकते हैं, विश्वसनीयता के सिद्धांत का उल्लेख करते हुए: "कार्यान्वयन को अपने व्यवहार में रूढ़िवादी होना चाहिए और यह दूसरों से स्वीकार करता है में उदार होना चाहिए।" हम सेवा विकास के संदर्भ में इस सिद्धांत को मजबूत कर सकते हैं कि संदेश प्राप्तकर्ताओं को "पर्याप्त" सत्यापन करना चाहिए: अर्थात्, उन्हें केवल उनके द्वारा उपयोग किए जाने वाले डेटा को संसाधित करना चाहिए, और उन्हें प्राप्त डेटा का स्पष्ट रूप से सीमित या लक्षित सत्यापन करना चाहिए - जैसा कि अनुमानित रूप से असीमित सत्यापन के विपरीत है। XSD प्रोसेसिंग में निहित सभी या कुछ भी नहीं।

स्कीमेट्रोन

एक तरह से हम उपभोक्ता-पक्ष सत्यापन को कॉन्फ़िगर कर सकते हैं, दस्तावेज़ तत्वों के लिए रास्तों के लिए मास्क या नियमित अभिव्यक्ति का उपयोग करना है, संभवतः स्कैमट्रॉन जैसे वृक्ष संरचना सत्यापन भाषा का उपयोग करना। स्कैमेट्रॉन का उपयोग करते हुए, प्रत्येक ProductSearch उपयोगकर्ता निर्दिष्ट कर सकता है कि वे खोज परिणामों में क्या अपेक्षा करते हैं:

 <?xml version="1.0" encoding="utf-8" ?> <schema xmlns="http://www.ascc.net/xml/schematron"> <title>ProductSearch</title> <ns uri="urn:example.com:productsearch:products" prefix="p"/> <pattern name="Validate search results"> <rule context="*//p:Product"> <assert test="p:CatalogueID">Must contain CatalogueID node</assert> <assert test="p:Name">Must contain Name node</assert> <assert test="p:Price">Must contain Price node</assert> </rule> </pattern>

स्कैमेट्रॉन कार्यान्वयन आमतौर पर एक स्केमैट्रॉन स्कीमा का अनुवाद करते हैं, जैसे कि यह एक, एक एक्सएसएलटी परिवर्तन में जो संदेश प्राप्तकर्ता दस्तावेज़ को मान्य करने के लिए आवेदन कर सकता है।

ध्यान दें कि इस आरेख में स्रोत दस्तावेज़ में तत्वों के बारे में धारणाएं नहीं हैं जो उपभोक्ता एप्लिकेशन द्वारा आवश्यक नहीं हैं। इस प्रकार, केवल आवश्यक तत्वों का सत्यापन स्पष्ट रूप से वर्णित है। स्रोत दस्तावेज़ के स्कीमा में परिवर्तन को सत्यापन के दौरान अस्वीकार नहीं किया जाएगा यदि वे स्केमैट्रॉन स्कीमा में वर्णित स्पष्ट अपेक्षाओं का उल्लंघन नहीं करते हैं, भले ही यह पहले से आवश्यक तत्वों को हटा दें।

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

इस प्रक्रिया के अंत में, ProductSearch प्रतिसाद योजना इस प्रकार दिखाई देती है:

 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:example.com:productsearch:products" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:example.com:productsearch:products" id="Products"> <xs:element name="Products" type="Products" /> <xs:complexType name="Products"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="Product" type="Product" /> </xs:sequence> </xs:complexType> <xs:complexType name="Product"> <xs:sequence> <xs:element name="CatalogueID" type="xs:int" /> <xs:element name="Name" type="xs:string" /> <xs:element name="Price" type="xs:double" /> <xs:element name="Manufacturer" type="xs:string" /> <xs:element name="Description" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema>

उपभोक्ता द्वारा संचालित अनुबंध

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

ध्यान देने वाली पहली बात यह है कि दस्तावेज़ योजनाएं केवल एक हिस्सा है जो एक सेवा प्रदाता को उपभोक्ताओं को प्रदान करना चाहिए ताकि वे इसकी कार्यक्षमता का उपयोग कर सकें। हम इस आउटसोर्स जानकारी को एक विक्रेता अनुबंध कहते हैं ।

आपूर्तिकर्ता अनुबंध

विक्रेता अनुबंध इस कार्यक्षमता का उपयोग करने के लिए आवश्यक निर्यात तत्वों के एक सेट के रूप में सेवा की कार्यक्षमता का वर्णन करता है। सेवा विकास के संदर्भ में, एक अनुबंध निर्यात तत्वों के एक सेट के लिए एक कंटेनर है जो व्यावसायिक कार्यों का वर्णन करता है। इन मदों की एक सूची में शामिल हैं:

दस्तावेजों की योजनाएं । हमने पहले ही विस्तार से योजनाओं पर चर्चा की है। इंटरफेस के साथ, दस्तावेज़ योजनाएं आपूर्तिकर्ता के अनुबंध के कुछ हिस्से हैं, जिनमें से परिवर्तन सबसे अधिक संभावना है क्योंकि सेवा विकसित होती है; लेकिन शायद इस वजह से वे ऐसे हिस्से भी हैं जिनके साथ हमारे पास विभिन्न सेवा विकास रणनीतियों के साथ सबसे अधिक कार्यान्वयन का अनुभव है, जैसे कि विस्तार बिंदु और दस्तावेज़ तत्वों के लिए रास्तों का उपयोग करना।
इंटरफेस। अपने सरलतम रूप में, प्रदाता इंटरफेस में निर्यात लेनदेन हस्ताक्षरों का एक सेट शामिल होता है जिसका उपयोग उपभोक्ता आपूर्तिकर्ता के व्यवहार को नियंत्रित करने के लिए कर सकता है। मैसेजिंग सिस्टम आम तौर पर अपेक्षाकृत सरल लेनदेन हस्ताक्षरों का निर्यात करते हैं और उनके द्वारा एक्सचेंज किए जाने वाले संदेशों के अंदर व्यावसायिक सामग्री डालते हैं। इस तरह के सिस्टम में, संदेशों को हेडर या संदेश के शरीर में इनकोडिंग शब्दार्थ के अनुसार संसाधित किया जाता है। RPC- , , - . , , , , .
. , , "-" "fire-and-forget". , . , , . , «» , , , "" . , " ", , . , , .
. , , , , . , . Web- WS-Policy , WS-SecurityPolicy, " ", .
. , , , , . .

, , , , . , : , . , - , , , , . , , WS-Basic, .

, . , , , .

, ? , , (, ) , . , , , , - . .

. , , , .
. .
. / (. "Validity of Data in Bounded Space and Time" Data on the Outside vs. Data on the Inside ). , .

, — , — . Schematron . , , . , , , , "" , . , , , - , .

, /, , ( ). , , , .

, , , , , . , , .

. . .
. , . - , - . , , . , . , ; .
. , / .

Consumer-Driven Contracts

. , , , . , , . , . , Consumer-Driven Contracts .

---, . , , . ; , , .

Consumer-Driven Contracts :

. , . , / , / .
. , , .
. . , Consumer-Driven Contract , . , , .

, :


					/
					/

कार्यान्वयन

Consumer-Driven Contracts , Consumer-Driven Contracts. , , , / .

. , -. unit-, , , . Schematron WS-Policy, .

, , . Consumer-Driven Contracts , , , , . / , . , , - .

Consumer-Driven Contracts , . -, . , . Consumer-driven contracts , , — , , . "" , -, . — — , .

, , . Consumer-Driven Contracts . Consumer-driven contracts , , . , , , , . , , .

Consumer-Driven Contracts , , Consumer-Driven Contracts , . , , CDC.

Consumer-Driven Contracts , , : , , , . , , , . .

, , Consumer-Driven Contracts, , . , — : , . , , , . , , , , . , — , deprecated , .

Consumer-Driven Contracts . , , . , , «» , .

, Consumer-Driven Contracts . , - — - — , , , WS-Agreement WSLA, SLA. , ; . — — , " " .

, : , . , , , , .

संदर्भ

Ian Robinson. Consumer-Driven Contracts ( )
Martin Fowler. Microservices , Decentralized Governance
. , " "
.

एक सेवा को विकसित करने के तरीके के रूप में उपभोक्ता-संचालित अनुबंध