सूचना विनिमय स्वरूपों का प्रलेखन - आसान और सरल

1. परिचय

2. मुद्दे

3. समस्या का सार

• 1. सूचना विनिमय के लिए डेटा की मात्रा निर्धारित करें - इस चरण में सूचना विनिमय के प्रतिभागियों के बीच प्रेषित किए जाने वाले डेटा की मात्रा निर्धारित की जाती है - इकाई, उनकी उत्तरदायी संरचना और संबंध।
• 2. XSD योजनाएं विकसित करें - चरण संख्या 1 पर आधारित, वास्तुकार या डेवलपर XSD योजनाएं विकसित करते हैं, जो स्वयं डेटा के अलावा, परिवहन, सुरक्षा, आदि के लिए आवश्यक SOAP संदेश तंत्र को शामिल करते हैं।
• 3. संदेश स्वरूपों का वर्णन करें - इस चरण में, प्रलेखन विकसित किया गया है जो स्वरूपों का वर्णन करता है और संदेशों के उदाहरण प्रदान करता है।
• 4. सुलह - इस चरण में, इन स्वरूपों को विकसित करने वाली टीम के भीतर प्रारूपों का सत्यापन और अनुमोदन किया जाता है। यदि अशुद्धि पाई जाती है, तो विकास पुनरावृत्ति दोहराई जाती है।

• 2. एक्सएसडी योजनाओं को विकसित करें - वास्तुकार एक्सएसडी योजनाओं में बदलाव करता है, इन योजनाओं के विकास में पहले से कम किए गए समय से बहुत कम समय लगता है।
• 3. संदेश स्वरूपों का वर्णन करें - विश्लेषक या तकनीकी लेखक को प्रारूप के विवरण के साथ प्रलेखन को अद्यतन करना चाहिए।
  
  और यहां उनके पास एक दुविधा है: केवल उन परिवर्तनों को बनाने के लिए जो आर्किटेक्ट ने उन्हें उन सभी योजनाओं के बारे में या उनके बारे में सूचित किया है जिनके लिए फ़ाइल का आकार बदल गया है। कोई भी, यहां तक ​​कि सबसे ईमानदार कर्मचारी पहला विकल्प चुन लेगा - और गलत होगा। यह विकल्प काम नहीं करता है! - बहुत बार योजनाओं में अघोषित परिवर्तन होते हैं, जिसे वास्तुकार या डेवलपर रिपोर्ट करना भूल जाते हैं, और इस दृष्टिकोण के साथ प्रारूपों का विवरण अनिवार्य रूप से योजनाओं से अलग हो जाएगा। इससे क्या खतरा है? - जब विकास शुरू होता है, तो एक विसंगति पाई जाएगी जो थोड़ी अराजकता लाएगी और डिग्री को अलग-अलग करके एकीकरण में शामिल सभी टीमों के विकास को जटिल करेगी।
  
  क्या यह बदतर हो सकता है? - हां, अगर भाग लेने वाली टीमों के लिए विकास अनुसूची अलग है। वर्ष की शुरुआत में टीमों में से एक, विनिर्देश के अनुसार, गलत तरीके से भरे डेटा के साथ संदेश भेजने और सफलतापूर्वक अनुबंध को बंद करने के लिए लागू करता है। वर्ष के मध्य में एक अन्य टीम इन संदेशों के स्वागत का एहसास करती है और आवश्यक डेटा और उनके विवरण के बीच एक विसंगति का पता लगाती है। इस बार, अराजकता लंबे समय तक रहने के लिए आती है और प्रारूपों और उनके विवरण के बीच विसंगति बहुत महंगी हो सकती है।
  
  समाधान क्या है? काश - एकमात्र विकल्प बचता है - हर बार, सभी परिवर्तित पैटर्न। यह स्वीकार करना बहुत मुश्किल है। प्रारूपों के एक एल्बम के साथ एक दस्तावेज़ एक सौ से अधिक शीट ले सकता है और इसे छिड़क सकता है, यह एक बहुत ही कठिन और श्रमसाध्य काम है। बहुत बार, जो इस दस्तावेज़ को विकसित करता है, उसे कार्यान्वयन की तत्परता द्वारा दृढ़ता से दबाया जाता है। हर कोई यह नहीं समझता है कि कई योजनाओं में कई तत्वों के विवरण को बदलने के कारण पूरे कार्य दिवस या इससे भी अधिक "लागत" हो सकती है।
  
  इस प्रकार, यह कदम विकास की "अड़चन" बन जाता है, जहां हर कोई, अपनी क्षमता के अनुसार, यह निर्धारित करता है कि इस समय क्या अधिक मूल्यवान है - गुणवत्ता या समय।
• 4. सहमत - पहले प्रारूप में अनुमोदन टीम के अंदर जाता है जो प्रारूप विकसित करता है। जब आंतरिक समन्वय पूरा हो जाता है, तो यह बाहरी समन्वय की बारी है - सूचना विनिमय के सभी प्रतिभागियों के लिए।

4. संदेश स्वरूपों का दस्तावेजीकरण

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

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

• "नं। पी / पी" - यहाँ बहु-स्तरीय सूची के रूप में आरेख में तत्व की स्थिति को दर्शाता है।
• "तत्व और उसके प्रकार का नाम" - तत्व दिखाने वाला डेटा यहाँ दिखाया गया है - तत्व और उसके प्रकार का नाम।
• "तत्व का विवरण" - तत्व पर व्यावसायिक डेटा यहां दिखाया गया है - व्यवसाय के दृष्टिकोण से इसका विवरण।
• "नियम भरना" - तकनीकी डेटा यहां दिखाया गया है: एक तत्व, डेटा प्रारूप, मूल्यों के उदाहरण आदि भरने के लिए नियम।
• "Mn।" - एक तत्व की शक्ति को यहां दिखाया गया है - अनिवार्यता, बहुलता और एक तत्व चुनने की संभावना।

5. समाधान खोजना

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

6. निर्णय

6.1। एक प्रलेखित स्कीमा को संसाधित करने का एक उदाहरण

6.1.1। स्रोत सर्किट

<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Customer" xmlns:tns="http://www.example.org/Customer" elementFormDefault="qualified"> <xsd:annotation> <xsd:documentation>     .</xsd:documentation> </xsd:annotation> <xsd:element name="Customer"> <xsd:annotation> <xsd:documentation>.</xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="CustomerId" type="xsd:int"> <xsd:annotation> <xsd:documentation>ID .</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="FirstName" type="xsd:string"> <xsd:annotation> <xsd:documentation>.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="LastName" type="xsd:string"> <xsd:annotation> <xsd:documentation>.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="Address"> <xsd:annotation> <xsd:documentation>.</xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="StreetAddress" type="xsd:string"> <xsd:annotation> <xsd:documentation> .</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="City" type="xsd:string"> <xsd:annotation> <xsd:documentation> .</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="Zip" type="xsd:string"> <xsd:annotation> <xsd:documentation> . >>>       .</xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 

6.1.2। परिणाम

6.2। बाहरी विवरण उदाहरण

6.2.1। स्रोत सर्किट

 <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Customer" xmlns:tns="http://www.example.org/Customer" elementFormDefault="qualified"> <xsd:element name="Customer"> <xsd:complexType> <xsd:sequence> <xsd:element name="CustomerId" type="xsd:int" /> <xsd:element name="FirstName" type="xsd:string" /> <xsd:element name="LastName" type="xsd:string" /> <xsd:element name="Address"> <xsd:complexType> <xsd:sequence> <xsd:element name="StreetAddress" type="xsd:string"/> <xsd:element name="City" type="xsd:string"/> <xsd:element name="Zip" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 

6.2.2। बाहरी विवरण फ़ाइल डेटा

 \matr      . Customer . CustomerId ID . FirstName . LastName . Address . StreetAddress  . City  . Zip  . >>>       . 

6.2.3। परिणाम

6.3। दो योजनाओं की तुलना का एक उदाहरण

6.3.1। स्रोत सर्किट

 <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Customer" xmlns:tns="http://www.example.org/Customer" elementFormDefault="qualified"> <xsd:element name="Customer"> <xsd:complexType> <xsd:sequence> <xsd:element name="CustomerId" type="xsd:int" /> <xsd:element name="FirstName" type="xsd:string" /> <xsd:element name="LastName" type="xsd:string" /> <xsd:element name="Address"> <xsd:complexType> <xsd:sequence> <xsd:element name="StreetAddress" type="xsd:string"/> <xsd:element name="City" type="xsd:string"/> <xsd:element name="Zip" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 

6.3.2। योजना का पिछला संस्करण

 <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Customer" xmlns:tns="http://www.example.org/Customer" elementFormDefault="qualified"> <xsd:element name="Customer"> <xsd:complexType> <xsd:sequence> <xsd:element name="CustomerId" type="xsd:int" /> <xsd:element name="FullName" type="xsd:string" /> <xsd:element name="Address"> <xsd:complexType> <xsd:sequence> <xsd:element name="StreetAddress" type="xsd:string"/> <xsd:element name="City" type="xsd:string"/> <xsd:element name="Country" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 

6.3.3। परिणाम

7. सारांश